Concepção lança o projeto

Transcrição

1 FASE DE CONCEPÇÃO

2 Concepção lança o projeto Realizar o business case inicial Delimitar claramente o escopo do projeto Estimar custo, tempo e retorno do investimento (feasibility) Formular a arquitetura candidata Identificar e eliminar riscos Planejamento (cronograma, custos, retorno) 2011 MDS 2

3 Inicialmente Obter uma visão geral do projeto Capturar o máximo de informação Organiza-la Verificar se algum ponto não foi contemplado Custo é inversamente proporcional a originalidade do projeto O planejamento inicial é uma tentativa o melhor entendimento do problema pode muda o planejamento 2011 MDS 3

4 O Time inicial 1 gerente 1 arquiteto 1 ou 2 desenvolvedores 1 engenheiro de teste 2011 MDS 4

5 Definindo o escopo do sistema O que deve ser feito esta claro? não uma idéia, mas uma definição precisa Todos os atores estão definidos? A natureza geral das interfaces com os atores é determinada? Existe uma parte do sistema que pode se comportar como um sistema funcional (subsistema) 2011 MDS 5

6 Resolvendo ambigüidades nos requisitos desta fase Um número limitado de use-cases de requisitos necessários para atingir os objetivos desta fase foram identificados e detalhados? Requisitos suplementares tem sido identificados e detalhados? 2011 MDS 6

7 Estabelecendo uma arquitetura candidata A arquitetura vai de encontro às necessidades do usuário? A arquitetura parece funcionar (promissora)? Não há um protótipo 2011 MDS 7

8 Identificar e eliminar os riscos críticos Todos os riscos foram identificados? Todos os riscos identificados foram eliminados, ou existe um plano para eliminá-los? modificar os requisitos plano de cotingência reduzir risco, minimizar efeito caso ocorra 2011 MDS 8

9 Julgando o business case inicial O business case inicial é bom o suficiente para justificar ir adiante com o projeto? 2011 MDS 9

10 Papel dos workers Analista identifica os use-cases e atores Arquiteto prioriza use-cases e seleciona os relevantes para propor a arquitetura candidata Desenvolvedor implementa o protótipo Engenheiro de testes 2011 planeja testes MDS 10

11 Capturando os requisitos Listar requisitos candidatos requisitos de sistemas similares requisitos obtidos com pesquisas de mercado (sistemas de prateleira) Entender o contexto do sistema modelo de negócio identificar use-cases de negócio e técnicos que relatam que processos suportar 2011 MDS 11

12 Capturando os requisitos Capturar requisitos funcionais Capturar requisitos não-funcionais 2011 MDS 12

13 Capturando os requisitos como use-cases Encontrar atores e use-cases priorizar use-cases que definem o escopo do projeto e ajudam a planejar a arquitetura detalhar os use-cases e cenários necessários para que os riscos possam ser identificados e eliminados, e para que uma arquitetura seja proposta Cerca de 10% dos use-cases é detalhada na fase de concepção 2011 MDS 13

14 Análise Analisar os requisitos para refiná-los e estruturá-los num modelo que funciona como um modelo de projeto inicial Resulta num modelo de análise inicial definir precisamente os use-cases guia a definição da arquitetura candidata aproximadamente 5% da análise é executada na fase de concepção 2011 MDS 14

15 Análise Priorizar os use-cases e/ou cenários refinar (detalhar) e entende-los Refina-se aproximadamente a metade dos use-case detalhados na fase anterior, ou seja 5% dos usecases do sistema Se for feita análise de classe e pacote é feita minimamente 2011 MDS 15

16 Projeto Projetar a arquitetura candidata se preciso desenvolver um protótipo do projeto (utilizando alguma técnica de desenvolvimento rápido) validar a os requisitos dos clientes/usuários Iniciar a definição do modelo de projeto contemplar requisitos funcionas e nãofuncionais Projeto de use-cases, classes e pacotes é mínimo (se existir) 2011 MDS 16

17 Implementação e teste Protótipo para validar a arquitetura se for necessário novas tecnologias projeto sem similares Planejamento de testes que tipos de testes serão necessários para um sistema desta natureza 2011 MDS 17

18 Produzindo o Business case inicial Transformar a visão (arquitetura candidata, riscos) em termos econômicos considerando: recursos custos aceitação do mercado (interna) 2011 MDS 18

19 O valor investido (custo) Usar fórmulas O tamanho do produto na fase de concepção pode diferir em 50% do tamanho do produto final estimativa de custo inicial pode diferir em 50% do custo final 2011 MDS 19

20 Retorno de investimento Difícil de ser estimado geralmente a margem de erro é bem grande sistemas de prateleira estimativa de cópias a serem vendidas valor de cada cópia no caso de sistemas internos qual a economia que o sistema trará a empresa? 2011 MDS 20

21 O que fazer ao final da fase de concepção Baseado no entendimento do projeto, análise de riscos, arquitetura candidata decidir de o projeto deve ou não continuar Planejar a fase de Elaboração descrever de 80% dos use-case analisar metade destes implementar 10% 2011 MDS 21

22 Resultado da fase de concepção primeira versão do modelo de negócio (descreve o contexto do sistema) primeira versão dos modelos de use-case primeira versão da arquitetura candidata protótipo demostrando o uso do sistema lista de riscos e suas prioridade planejamento geral das demais fases primeira versão do business case (estimativas e retorno) 2011 MDS 22

23 Fases x Workflows 2011 MDS 23

24 CONCEPÇÃO E WORKFLOWS Requisitos: capturar os requisitos mais críticos (na forma de casos de uso) e definir o escopo do sistema. Análise: analisar os requisitos e montar uma proposta para o modelo de classes e objetos, com foco nas classes de negócio, mais o glossário. Design: preparar o Modelo de Design ou storyboard, apresentando um rascunho preliminar da arquitetura do sistema: identificar os primeiros componentes, interfaces e subsistemas, assim como o Modelo de Implantação. Implementação: pode ser necessário criar um protótipo descartável para demonstrar o caminho escolhido. Testes: criar primeiros esboços de teste com base nas informações já adquiridas.

25 ELABORAÇÃO E WORKFLOWS Requisitos: encontrar, priorizar, detalhar e estruturar os Casos de Uso, obtendo aproximadamente 80% dos requisitos. Análise: detalhar as classes de negócio, fazer o particionamento em pacotes, atualizar o glossário e refinar os Casos de Uso. Design: fazer o design dos Casos de Uso, classes e subsistemas para estabelecer uma estrutura básica do sistema. Pacotes de análise e subsistemas de design, são importantes. São considerados: sistema operacional, linguagem, banco de dados, distribuição de objetos, etc.. Implementação: implementar e testar os componentes arquiteturalmente significantes. Eventualmente criar protótipos para testar alguma nova tecnologia. Testes: planejar e especificar os testes, definindo casos de teste e rotinas de teste.

26 CONSTRUÇÃO E WORKFLOWS Requisitos: capturar os requisitos remanescentes, refinando Casos de Uso e cenários. Análise: capturar algum detalhe que passou despercebido nas classes pertinentes ao negócio. Design: refinar os casos de uso e cenários remanescentes com base na tecnologia utilizada. Implementação: codificar e integrar componentes, priorizando os casos de uso mais importantes. Testes: testar funcionalidades e performance do sistema. Se necessário testar novos casos e rotinas de teste.

27 TRANSIÇÃO E WORKSFLOWS Requisitos: eventual correção da documentação devido a bugs encontrados no sistema. Análise: eventual correção do modelo de análise devido a bugs encontrados no sistema. Design: eventual correção do modelo de design devido a bugs encontrados no sistema. Implementação: eventual correção do código devido a bugs encontrados no sistema. Testes: eventual correção do modelo de teste devido a bugs encontrados no sistema.