FASE DE CONCEPÇÃO - facom.ufu.brbacala/ES/11.3 - FaseDeConcepcao.pdf · Design: fazer o design...
Transcript of FASE DE CONCEPÇÃO - facom.ufu.brbacala/ES/11.3 - FaseDeConcepcao.pdf · Design: fazer o design...
FASE DE CONCEPÇÃO
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
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
O Time inicial
1 gerente
1 arquiteto
1 ou 2 desenvolvedores
1 engenheiro de teste
2011 MDS 4
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
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
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
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
Julgando o business case inicial
O business case inicial é bom o suficiente para justificar ir adiante com o projeto?
2011 MDS 9
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 2011 MDS 10
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
Capturando os requisitos
Capturar requisitos funcionais
Capturar requisitos não-funcionais
2011 MDS 12
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
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
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 use-cases do sistema
Se for feita análise de classe e pacote é feita minimamente
2011 MDS 15
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)
2011 MDS 16
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
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
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
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
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
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
Fases x
Workflows
2011 MDS 23
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.
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.
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.
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.