fase de concepÇÃobacala/mds2011/mds13.pdf · 2011-06-16 · da fase de concepÇÃo baseado no...

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


Capturar requisitos funcionais

Capturar requisitos não-funcionais

2011

12

MD

S


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


Design: eventual correção do modelo de design


Implementação: eventual correção do código


Testes: eventual correção do modelo de teste


fase de concepÇÃobacala/mds2011/mds13.pdf · 2011-06-16 · da fase de concepÇÃo baseado no...

Documents