Escolar Documentos
Profissional Documentos
Cultura Documentos
Define quem faz o que, quando e como, para atingir um certo alvo
1. 2. 3.
4.
5.
6.
Criar relatrio inicial de investigao (para construir o business case) Levantar requisitos funcionais e no funcionais Construir glossrio (ao longo da fase) Definir modelo conceitual inicial (anlise inicial) Projetar arquitetura Priorizar a funcionalidade e distribu-la entre as iteraes
Requisitos so "cortes" no espao de soluo. Entendimento do que o usurio quer. O resultado uma promessa para o cliente. No s requisitos funcionais, mas tambm:
Facilidade de uso necessria Quem utilizar o produto Hardware e software alvo para o produto Qualidade/robustez Desempenho Segurana Compatibilidade com outros produtos/verses e necessidades de migrao
Requisitos so "cortes" no espao de soluo. Entendimento do que o usurio quer. O resultado uma promessa para o cliente. No s requisitos funcionais, mas tambm:
Facilidade de uso necessria Quem utilizar o produto Hardware e software alvo para o produto Qualidade/robustez Desempenho Segurana Compatibilidade com outros produtos/verses e necessidades de migrao
Iterativo (ter vrias iteraes no tempo) Incremental (gerar novas verses incrementadas a cada release) Uma iterao dura entre 2 semanas e 2 meses.
Sempre tem algo poara entregar para o cliente apressado (a ltima iterao) Os requisitos mudam com tempo e um processo iterativo mantm frequentes contatos com o cliente o que ajuda a manter os requisitos sincronizados Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
Anlise (refinamento de requisitos, refinamento do modelo conceitual) Projeto (refinamento do projeto arquitetural, projeto de baixo nvel) Implementao (codificao e testes) Transio para produto (documentao, instalao, ...)
A anlise gera um modelo para entender o domnio do problema Anlise tambm trata em alto nvel de como uma soluo possvel pode ser montada para atender aos requisitos
Acaba gerando uma especificao, mas sempre do ponto de vista do usurio e tratando apenas do domnio do problema .
No trata de detalhes de implementao Objetos tratados so sempre do domnio do problema (business objects) Muitos diagramas uml podem ser usados
O modelo para o cliente e no para o programador.
1. 2. 3. 4.
Refinar use cases Refinar modelo conceitual Refinar glossrio Definir diagramas de sequncia (opcional) 5. Definir contratos de operao (opcional) 6. Definir diagramas de estado (opcional)