fase de concepÇÃobacala/mds2011/mds13.pdf · 2011-06-16 · da fase de concepÇÃo baseado no...
TRANSCRIPT
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
2
MD
S
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
2011
3
MD
S
O TIME INICIAL
1 gerente
1 arquiteto
1 ou 2 desenvolvedores
1 engenheiro de teste
2011
4
MD
S
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
5
MD
S
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
6
MD
S
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
7
MD
S
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
8
MD
S
JULGANDO O BUSINESS CASE
INICIAL
O business case inicial é bom o suficiente para
justificar ir adiante com o projeto?
2011
9
MD
S
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
10
MD
S
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
11
MD
S
CAPTURANDO OS REQUISITOS
Capturar requisitos funcionais
Capturar requisitos não-funcionais
2011
12
MD
S
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
13
MD
S
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
14
MD
S
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
15
MD
S
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
16
MD
S
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
17
MD
S
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
18
MD
S
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
19
MD
S
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
20
MD
S
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
21
MD
S
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
22
MD
S
FASES
X
WORKFLOWS
2011
M
DS
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.