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.