Delimitar claramente o escopo do projeto Estimar custo, tempo e retorno do investimento (feasibility)

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) 2

3 INICIALMENTE Obter uma visão geral do projeto Capturar o máximo de informação Organiza-lá 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 3

4 O TIME INICIAL 1 gerente 1 arquiteto 1 ou 2 desenvolvedores 1 engenheiro de teste 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) 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? 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 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 8

9 JULGANDO O BUSINESS CASE INICIAL O business case inicial é bom o suficiente para justificar ir adiante com o projeto? 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 planeja testes 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 11

12 CAPTURANDO OS REQUISITOS Capturar requisitos funcionais Capturar requisitos não-funcionais 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 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 14

15 ANÁLISE Priorizar os use-cases e/ou cenários refinar (detalhar) e entende-los Refina-se aproximadamente a metade dos usecase detalhados na fase anterior, ou seja 5% dos use-cases do sistema Se for feita análise de classe e pacote é feita minimamente 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ão-funcionais Projeto de use-cases, classes e pacotes é mínimo (se existir) 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 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) 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 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? 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% 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) 22

23 FASES X WORKFLOWS 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.