Esta apresentação, mostra detalhes de uma das abordagens ágeis para desenvolvimento de software, a FDD - Feature Driven Development – Desenvolvimento Guiado por Funcionalidades.

1. Hiury Araújo – hiury14@gmail.com
Hugo Nathan - hugonbr@gmail.com
127/05/2014

2.  Objetivos;
 Introdução;
 Histórico;
 Conceituando o FDD;
 Vantagens e desvantagens;
 Conclusão.
2

3.  Apresentar o que é o FDD – Feature Driven
Development;
• Histórico;
• Características;
• Processo;
• Fases.
3

4.  Metodologia ágil para gerenciamento e
desenvolvimento de software;
 Criada em 1997 em um grande projeto em Java;
 Engenharia de software orientada por objetos;
 Conquista os três principais públicos de um projeto de
software: Clientes, gerentes e desenvolvedores.
4

5.  O FDD foi criado em 1997;
 Foi inicialmente publicado no capítulo 6 do livro “Java
Modeling in Color with UML”;
 Em 2002, Stephen Palmer e John Mac Felsing
publicaram o livro “A Pratical Guide to Feature Driven
Development”;
 Em 2003, David Anderson publicou um marco na
literatura ágil, “Agile Management for Software
Engenering: Using the Theory of Constraints for Business
Results”.
5

6.  O que é o FDD?
• FDD é uma metodologia ágil para gerenciamento e
desenvolvimento de software;
• Seus princípios e práticas proporcionam um
equilíbrio entre as filosofias tradicionais e as mais
extremas;
• O lema da FDD é: “Resultados frequentes, tangíveis
e funcionais.”.
6

7.  Resultados úteis em curto prazo de tempo;
 Blocos pequenos de funcionalidades valorizada pelo
cliente, chamados “Features”;
 Complexidade do sistema e tamanho da equipe;
 Rastreabilidade e relatórios com precisão;
 Agrada a clientes, gerentes e desenvolvedores.
7

8.  Gerente do projeto;
 Arquiteto chefe;
 Gerente de desenvolvimento;
 Programador chefe;
 Proprietário de classe;
 Especialista do domínio.
8

9.  Gerente do domínio;
 Gerente de versão;
 Especialista (guru) de linguagem;
 Coordenador de construção;
 “Ferramenteiro” (toolsmith);
 Administrador de sistema.
9

10.  Testador;
 Desenvolvedores;
 Escritor técnico.
10

11.  Padrão “ETVX”:
• Entry - Entrada;
• Task - Tarefa;
• Verification -Verificação;
• Exit - Saída.
11

12.  FDD é um metodologia muito objetiva que pode ser
dividida em duas etapas e as mesmas em cinco fases:
• Concepção e Planejamento:
 Essa fase é executada apenas uma vez e dura de
uma a duas semanas;
• Construção:
 Período de tempo de no máximo duas semanas.
12

13.  Desenvolver um modelo abrangente
• Critérios de entrada:
 Os especialistas no domínio do negócio, os
programadores-líderes e o arquiteto-líder foram
selecionados.
• Critérios de saída:
 Diagramas de classes, métodos e atributos,
diagramas de sequência e/ou máquina de estados
e comentários sobre o modelo.
13

14.  Construir a lista de funcionalidades
• Critérios de entrada:
 Os especialistas no domínio do negócio, os
programadores-líderes e o arquiteto-líder foram
selecionados.
• Critérios de saída:
 Lista de áreas de negócio, lista de atividades e
funcionalidade para cada passo das atividades.
14

15.  Planejar por funcionalidade
• Critérios de entrada:
 O processo de construção de uma lista de
funcionalidades foi completado.
• Critérios de saída:
 Atividades de negócio com datas de término (mês
e ano), programadores-líderes atribuídos as
atividades de negócio e lista de proprietários de
classes.
15

16.  Detalhar por funcionalidade
• Critérios de entrada:
 O processo de planejamento foi completado.
• Critérios de saída:
 Uma capa com comentários, que completa e
descreve o pacote de projeto de tal forma a ser
suficiente para futuros revisores e alternativas de
projeto.
16

17.  Construir por funcionalidades
• Critérios de entrada:
 O processo de detalhar por funcionalidade foi
completado, isto é, o pacote de projeto (design)
passou com sucesso pela inspeção.
• Critérios de saída:
 Classes e/ou métodos que passaram na inspeção
de código com sucesso, classes que foram
promovidas à versão atual e o término de uma
função com valor para o cliente.
17

18. 18

19.  Fases muito fortes de análise, se comparada com outras
metodologias ágeis;
 Recomendada para qualquer tipo de desenvolvimento;
 O FDD prioriza aquilo que o cliente prioriza;
 Os resultados produzidos geram bastante e rápida
visibilidade para o cliente;
 Seus princípios e práticas proporcionam um equilíbrio
entre as filosofias tradicionais e as mais extremas.
19

20.  Relatos de uso bem-sucedido ainda não são
encontráveis;
 Há controvérsias sobre o tamanho mínimo de um time
FDD;
 A especificação original da metodologia não comenta
sobre sua aplicabilidade à manutenção de sistemas.
20

21.  É um método ágil e altamente adaptativo;
 Oferece vantagens dos métodos pesados;
 Oferece vantagens dos métodos extremamente ágeis;
 É orientada às necessidades dos clientes, gerentes e
desenvolvedores.
21

22.  http://pt.scribd.com/doc/37146865/FDD-Completo
 http://engenheirosdosoftware.blogspot.com.br/2008/1
0/fdd-feature-driven-development.html
 http://www.heptagon.com.br/fdd
 http://www.heptagon.com.br/fdd-oque
 http://www.heptagon.com.br/fdd-estrutura
 http://www.heptagon.com.br/files/FDD-Processos.pdf
22