quinta-feira, 7 de junho de 2012

RUP para Concursos - Parte 5 - Fase de Elaboração e Discplina Análise e Design

Fase de Elaboração
O que muda entre as fases é ênfase que se dá em cada disciplina e o marco da fase. Na elaboração o foco é na disciplina de Análise e Design. Entretanto, pode ser que todas as disciplinas sejam de fato executadas em uma fase, dependendo do seu plano de iteração.

Na fase de Elaboração ainda existe muita atividade nas disciplinas Modelagem de Negócios e Requisitos. O esforço maior dessa fase é na Análise e Design, mas a Implementação já ocupa grande parte do esforço porque código executável já é gerado para garantir a arquitetura estabilizada. Também começam as atividades de Implantação.

A meta princpal da Elaboração é realizar os requisitos mais significativos do sistema, com grande impacto na arquitetura e desenvolver uma arquitetura exectuável (que funciona) e estabilizada, que garanta a continuidade do projeto. Esses casos de uso são chamados de Arquiterualmente Significativos.

A estabilidade da arquitetura é avaliada através de protótipos arquiteturais.

Ao final da fase de Elaboração é gerado uma baseline arquitetural. Baseline é uma versão revisada da arquitetura ou de algum artefato.

Objetivos da Elaboração

Garangtir que a arquitetua e os requisitos estejam estáveis para mitigar os riscos. 
"Ultrapassar esta marca (Elaboração) significa passar de uma operação de baixo risco para uma operação de alto custo e alto risco". Nas duas primeiras fases os custos são baixos, poucas pessoas estão envolvidas. Dessa fase em diante a equipe aumenta. O custo e risco passam a ser significativos.

Tratar todos os riscos significativos do ponto de vista do projeto.
É aqui onde os riscos são de fato tratados. O RUP entende que estabilizar a arquitetura é tratar riscos porque os piores casos de uso são implementados neste momento.

Selecionar componentes e criar planos de iterações detalhados para a fase de Construção
É preciso pensar quais componentes podem ser reutilizados no futuro.

Principais Artefatos 

Protótipos
São usados de uma maneira direta para reduzir o risco e elicitar requistos significativos. É a implementação de um conceito que precisa ser testado.

Documento de Arquitetura de Software
Fornece uma visão geral da arquitetura do sistema usando as 4+1 visões (resumos anteriores) da arquitetura.

Modelo de Projeto
Modelo de objetos que descreve a realização dos casos de uso. Mostra como implementar os casos de uso em termos de objetos com o passar do tempo. Usa muito os diagramas comportamentais e de interação da UML, mostra como acontece a comunicação entre os objetos do caso de uso. É uma abstração do modelo de implementação e código-fonte.

Modelo de Dados
Modelo de implementação que descreve a representação conceitual, lógica ou física dos dados persistentes no sistema.

Disciplina de Análise e Design (Projeto)

Objetivos
Transformar os requisitos em um projeto do sistema a ser criado. Os casos de uso são realizados em um projeto. Os casos de uso nunca dizem como fazer, mas apenas o que fazer. O projeto vai dizer como fazer, como realizar os casos de uso.

Desenvolver uma arquitetura refinada para o sistema.

Adaptar o projeto para que corresponda ao ambiente de implementação considerando restrições de técnologia.

O nome da disciplina é Análise e Design (projeto), mas as atividades são distintas: análisar e projetar. Análise significa entender o problema, normalmente sem considerar as tecnologias. São modelos conceituais, sem restrições técnológicas.

No projeto você cuida da solução e de modelos concretos para o problema. Leva em consideração as restrições técnológicas.

O RUP diz que as atividades de análise são opcionais e é possível ir diretamente para o projeto. A análise está mais próxima do negócio e é independente da tecnologia. O modelo de projeto é dependente da técnologia. Então, o Modelo de Análise pode ser aproveitado para o projeto em qualquer que seja a técnologia escolhida.

Principais Pepeis, Atividades e Artefatos

Arquiteto de Software
É o cara que projeta a arquitetura em cima dos casos de uso mais complexos. Tem uma visão ampla do projeto.

Designer ou Projetista
É quem analisa e projeta os casos de uso em termos de classes. Esse é o papel que entra nos detalhes de como os casos de uso serão feitos. Analisa os casos de uso, projeta os casos de uso e projeta os subsistemas.

Projetista de Banco de Dados
Gera os modelos lógicos e físicos da sua base de dados para guardar as entidades persistentes do sistema.

Protótipos
São feitos para provar ou esclarecer algum conceito. Podem ser categorizados de algumas formas:

Quanto ao que eles exploram:
Comportamentos - enfatizam a exploração do comportamento do sistema.
Estruturas - trabalham questões arquiteturais ou técnológicas do sistema.

Quanto ao seu resultado:
Exploratório ou descartável - utilizado esclarecer algum requisito complicado ou nebuloso e depois é descartado
Evolutivo - o protótipo é evoluído até se tornar o sistema de fato.

Documento de Arquitetrua de Software - Documento que descreve a arquitetura e é feito pelo arquiteto de software. Já foi explicado antes.

Modelo de Design (ou de projeto) - descreve as realizações dos casos de uso e serve como uma abstração do modelo de implementação. (modelos são agrupamentos) Esse modelo diz como as coisas serão implementadas.

Relação com outras disciplinas

Modelagem de negócio - Fornece o contexo organizacional para o sistema.
Requisitos - Fornece as funcionalidades CRÍTICAS a serem implementadas.
Testes - Testa o sistema projetado durante a disciplina Análise e Design
Ambiente - Gera guias de análise e projeto, etc (a mesma coisa para as outras disciplinas).
Gerenciamento de Projeto - Planeja as atividades da discplina (a mesma coisa para as outras disciplinas).

Marco da Elaboração: Arquitetura do Ciclo de Vida
É o segundo marco mais importante do projeto. Considera a arquitetura executável e a resolução dos riscos principais. Nessa fase os riscos são resolvidos de fato e a arquitetura deve funcionar.

Critérios de Avaliação
A arquitetura está estável e robusta para comportar os requisitos atuais e futuros?
Os riscos críticos foram resolvidos?
Os planejamentos de cronograma, orçamento e qualidade estão bem defindos? Neste momento é mais fácil dar precisão aos planejamentos porque os riscos já foram tratados.
Deve-se seguir com o sistema? (O RUP diz que esse é o momento de fechar o contrato, porque é quando a arquitetura foi estabilizada, na vida real o contrato é fechado antes.)