Apresentação fdd
-
Upload
marlon-ribeiro -
Category
Documents
-
view
2.097 -
download
0
description
Transcript of Apresentação fdd
Técnicas em Projetos de Sistemas
Professor: Marinaldo
FDDFEATURE DRIVEN DEVELOPMENT
DESENVOLVIMENTO GUIADO POR FUNCIONALIDADE
•Cícero Alves•Délio Peres Barros•Hussein Mohamad•José Emerson•Marlon Ribeiro
HISTÓRICO
Criado em 1997 num grande projeto de sistema de empréstimos em Java para o
banco United Overseas Bank, em Singapura.
Problema: Após dois de consultoria, 3.500 páginas de casos de uso e um modelo de
objetos com centenas de classes, foi considerado impossível.
Decisão: União entre a experiência de análise e modelagem orientadas por objetos de
Peter Coad, e o gerencimento de projetos de Jeff De Luca.
Resultado: 15 meses depois da contratação da dupla, 2.000 features entregues por
uma equipe de 50 pessoas.
Inicialmente publicada em 1999, no capítulo 6 do livro “Java Modeling In Color With
UML”.
Em 2002, o livro “A Practical Guide To Feature Driven Development” foi publicado
com a versão completa, atualizada e comentada da metodologia.
CONCEITOS O Desenvolvimento Guiado Por Funcionalidades (FDD) é uma metodologia
ágil para o processo de engenharia de software, elaborado com foco na entrega freqüente de “software funcionando” para os clientes e na utilização de boas práticas durante o ciclo de seu desenvolvimento.
Um fato marcante é o forte favorecimento ao envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software.
Diferentemente de outras metodologias, o FDD não é extremamente focado na programação ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos.
Não é uma metodologia de gerenciamento de projetos de software. Apesar de, em suas práticas, existirem atividades relacionadas a esse fim. Apresenta como foco principal cobrir o processo de engenharia de software, e não do gerencimento.
CARACTERÍSTICAS Entrega resultados funcionais e tangíveis a cada duas semanas ou menos.
Pequenos blocos de funcionalidades (features) valorizados pelo cliente.
Planejamento detalhado e guiado para medição.
Rastreabilidade e relatórios precisos.
Monitoramento detalhado, com resumos em termos de negócio para o cliente.
Realiza trabalho significativo desde o início, antes de se tornar iterativa.
Fornece uma forma de saber, com 10%, se o plano e a estimativa são sólidos.
Fornece a estrutura suficiente para equipes maiores.
Enfatiza a produção de software de qualidade.
PRÁTICAS DO FDD Modelagem de objetos do domínio.
Desenvolvimento por feature (funcionalidade).
Posse individual de classe (código).
Equipes de features (papéis por áreas de negócio).
Inspeções (especificações, código, teste de unidades).
Builds regulares (geração de versões com novos features).
Gerenciamento de configuração.
Relatório/Visibilidade de resultados.
CONCEITO DE FEATURE Característica ou funcionalidade que representem algum valor para o cliente.
Um feature não deve ultrapassar o tamanho de sua iteração. Deve ser pequena o suficiente
para ser implementada no tempo médio de duas semanas.
Mapeia passos em uma atividade de negócio. Pode ser um passo de um caso de uso, ou às
vezes, pode ser o próprio caso de uso.
Conceito muito próximo ao de um requisito funcional.
É representada através do template: <ação> <resultado> <objeto>. Ex: Calcular o desconto
de uma venda. Listar os clientes ativos de uma empresa. Sendo o conjunto de funcionalidades que será entregue para o cliente ao final de uma
iteração, não deve se economizar tempo, atenção e criatividade no processo de definição das mesmas.
ESTRUTURA FASES:
Concepção & Planejamento: Pensar um pouco antes de fazer (entre 1 e 2 semanas).
Construção: Fazer de forma iterativa (geralmente em interações de 2 semanas).
PROCESSOS:
Desenvolver Um Modelo Abrangente (DMA): Análise Orientada Por Objetos.
Construir A Lista De Funcionalidades (CLF): Decomposição Funcional.
Planejar Por Funcionalidade (PPF): Planejamento Incremental.
Detalhar Por Funcionalidade (DPF): Projeto Orientado Por Objetos.
Construir Por Funcionalidade (CPF): Programação e Teste Orientado Por Objetos.
ESTRUTURA
PRINCIPAIS PAPÉIS
1.Desenvolver um Modelo
geral2. Construir uma lista de
características3. Planejar através de
característica4. Projetar através de
característica
5. Construir através de
característica
Os 5 processos do FDD
Modelo de Objeto (mais formas do que
conteúdo)
Uma lista de características categorizada
Um plano de desenvolvimento
Um pacote de projeto (seqüências)
Uma função do cliente completada
(mais conteúdo do que forma)
Descrição dos Processos de FDDCada processo é descrito em não mais do que
duas páginas de papel tamanho carta, frente-e-verso
Cada descrição do processo apresenta-se de acordo com a estrutura: Entrada, Tarefas, Verificação e Saídas (ETVX)
FDD Processo #1: Desenvolver um modelo geral
• Adquirir conhecimento do domínio e construir o modelo geral– Estabelecimento do “propósito de negócio” do
novo sistema– Construção de um “modelo conceitual” do sistema
FDD Processo #1- Atividades
Formar a Equipe de Modelagem
Estudo dirigido sobre o Domínio
Estudar Documentos
Desenvolver pequenos Modelos de Grupo
Desenvolver um Modelo da Equipe Refinar o Modelo Geral
Escrever Anotações do Modelo
• Entrada– Especialistas no domínio, programadores e arquitetos chefes
são selecionados• Saídas
– Modelo geral do domínio– Diagrama das classes principais com alguns métodos e atributos
identificados– Diagramas de seqüência de algumas funcionalidades mais
complexas (se houver)– Comentário sobre o modelo
FDD Processo #1:Entradas e Saídas
FDD Processo #2:Construir lista de características
• O domínio é decomposto até chegar nas características
• Características são agrupadas e categorizadas• Características são granuladas até ser
necessário menos de 2 semanas pro seu desenvolvimento
FDD Processo #2 - Atividades
Formar a Equipe da Lista de Características
Construir a lista de características
• Entrada– O processo #1 ter sido concluído com sucesso
• Saídas– Uma lista das áreas do domínio identificadas– Para cada área, uma lista de atividades de negócio
(conjunto de características)– Para cada atividade, os passos a serem realizados
(características)
FDD Processo #2:Entradas e Saídas
FDD Processo #3:Planejar através de características
• Uma data de lançamento é estabelecida para o release inicial
• A lista de características priorizadas é refinada
• O trabalho técnico é planejado e atribuído – plano de desenvolvimento
FDD Processo #3 - Atividades
Formar a Equipe de Planejamento
Determinar a Seqüência de Desenvolvimento
Atribuir Conjuntos de Características para Programadores Chefes
Atribuir Classes para Desenvolvedores
• Entrada– O processo de construir a lista de características
(processo #2) ter sido concluído com sucesso• Saídas
– Atividades de negócio com datas de término– Programadores-chefes atribuídos a atividades de
negócio– A lista de classes e seus donos (desenvolvedores)
FDD Processo #3: Entradas e Saídas
FDD Processo #4:Projetar através de características
• Regras e transações são identificadas• O modelo da interface do usuário é esboçado• Diagramas de seqüência mais detalhados são
produzidos• Especialistas são consultados para descobrir
qualquer necessidade específica adicional
FDD Processo #4 - Atividades
Formar a Equipe de Características
Estudo do Domínio Estudar Documentos de Referências
Desenvolver Diagramas de Seqüência
Refinar o ModeloDescrever os prefácios de
classes e métodos
• Entrada– O processo de planejado (processo #3) ter sido concluído com
sucesso• Saídas
– Diagramas de seqüência– Projetos alternativos (caso exista)– O modelo de objeto com classes, métodos e atributos novos
ou atualizados– A documentação da API do sistema– Lista de tarefas (calendário/ To-Do)
FDD Processo #4:Entradas e Saídas
FDD Processo #5:Construir através de características
• Características são construídas implementando todas as classes e métodos necessários
• Testes de unidades• Características são inseridas no build quando
o teste resulta em sucesso
FDD Processo #5- Atividades
Codificar
Testar Unidades Inspecionar Código
Promover à versãoatual (Build) Ponto de integração para a
funcionalidade inteira
• Entrada– O processo anterior ter sido concluído com sucesso
• Saídas– Classe(s) e/ou método(s) que passaram na inspeção
de código com sucesso– Classes inseridas no build– A conclusão da funcionalidade do cliente
FDD Processo #5:Entradas e Saídas
• Cada característica é uma unidade planejada de trabalho que pode ser devolvida
• A soma de características entregues é igual ao status do projeto
Divulgando Resultados
Os seis marcos do FDD
Projetar pelas características Construir pelas características
Análise do domínio
Projeto Inspeção do projeto
Código Inspeção do código
Geração de build
1% 40% 3% 45% 10% 1%
Relatando resultados
Dez 2001
Porcentagem completa:
Status Completo:
Completo
Mês de conclusão
Exemplo: Conjunto de características: Fazendo avaliação de produtos – Trabalho em progresso CP-1 é o programador chefe inicial
(14) esse conjunto de características possui 14 características
Conjunto de características está 75% completado
A conclusão é para dezembro de 2001
Status Geral:
MY
Barra de progresso
Trabalhos em progresso
Atenção (ie, atrasado)
Completo
Fazendoavaliação
de produtos(14)
75%Não iniciado
CP-1
• FDD– Fornece clareza– Eleva o controle– Facilita a comunicação – reporta resultados– Status do projeto completo é determinado pelas
características entregues – Características quebram o trabalho em entregas
menores e mais gerenciáveis– Builds regulares– É bom para os desenvolvedores, gerentes e clientes...
Conclusão