Engenharia de Software
Feature Driven Development
Allyson José
Edivânia Pontes
Thomas Matheus
Stephany Silva
Metodologias Ágeis
• Foi criada durante os anos 90 como reação contra os
métodos de desenvolvimento “pesados”, tipificados pelo
modelo em cascata.
• Denominadas como métodos de desenvolvimento
“leves”.
Como surgiu o FDD
• Concebido originalmente por Jeff de Luca, o FDD surgiu
em Singapura, entre os anos de 1997 e 1999 com base
no método Coad (Criado por Peter Coad – 1980/1990) e
nos processos interativos e lean já utilizados por Jeff de
Luca.
FDD
• É uma metodologia ágil para o processo de engenharia
de software.
• Busca o desenvolvimento por funcionalidade, ou seja,
por um requisito funcional do sistema.
Agentes e Atores
Análise do risco de utilização de
Métodos Ágeis e Preditivos
• Métodos ágeis:
Pouca crítica à implementação
Equipe de desenvolvimento constituída por elementos
experientes
Grandes mudanças nos requisitos
Equipe de desenvolvimento constituída por poucos
elementos
Cultura que prospera na falta de organização.
Análise do risco de utilização de
Métodos Ágeis e Preditivos
• Métodos preditivos:
Muita crítica à implementação
Equipe de desenvolvimento constituída por elementos
inexperientes
Poucas mudanças nos requisitos
Equipe de desenvolvimento constituída por muitos
elementos
Cultura que exige ordem e organização.
Ciclo de Vida do Projeto
Requisitos
Desenvolver
um modelo
abrangente
Detalhar
por
Feature
Construir
Listas de
Features
Construir
por
Feature
Planejar
por
Feature
Produto
Develop an Overall Model
Desenvolvimento de Modelo Abrangente
• O cliente indica quais os requisitos que quer ver
cumpridos no sistema
• Cabe à equipe de desenvolvimento: analisar e verificar os
requisitos dados pelo cliente; Sugerir novos requisitos; E
colocar todas questões que possam ainda não terem sido
respondidas, ou que tenham sido esquecidas
• A equipe de desenvolvimento dividem-se em pequenos
grupos para desenvolver seus modelos
• Os resultados são adicionados a um modelo comum, um
modelo abrangente
Build by Features List
Construção de Lista de Funcionalidades
• Identifica todas as funcionalidades e agrupa-as por
ordem hierárquica
• Critérios de divisão: áreas e classes
• Entra a provisória lista de funcionalidades
• Sai uma detalhada lista de funcionalidades
Plan by Feature
Planejar por Funcionalidade
• Desenho por funcionalidade e Construção por
funcionalidade
• Sequência e conjunto inicia de datas
• A cada chefe de programação é fornecida uma lista de
funcionalidades a serem desenvolvidas.
• Revisão e aprovação do desenvolvedor e chefe de design.
• Previsão de término do projeto
Design by Feature
Detalhar por Funcionalidade
• Desempenho da estrutura para cada funcionalidade.
• Análise do processo
• Identificação das classes envolvidas
• Dependendo da complexidade da funcionalidade, o
programador chefe poderá consultar os especialistas da
área
• O programador consulta o diagrama sequencial
• A equipe de programadores toma nota daquilo que é
relevante
Build by Feature
Desenvolver por Funcionalidade
• Implementar classes e métodos;
• Inspecionar código: o desenvolvedor “convida” outro
para verificar seu código;
• Testes unitários, realizados pelo próprio desenvolvedor;
• Promover a build, se a classe estiver testada e
inspecionada;
Percentual de tempo gasto em cada
funcionalidade
• Levantamento do domínio da aplicação = 1%;
• Projeto = 40%;
• Inspeção do projeto = 3%;
• Desenvolvimento = 45%;
• Inspeção do código = 10%;
• Integração = 1%.
Afinal, por que usar FDD?
• Planejamento e modelo na medida certa. Sem exageros,
mas também sem ausência;
• Os processos favorecem a aproximação de especialistas,
gerentes e desenvolvedores;
• Permite realizar entregas frequentes ao cliente;
• A inspeção de código e de design permite obter
qualidade no produto final.
Vantagens
• Por cada feature ser pequena, coletar os requisitos se
torna mais fácil, pois estes podem ser melhor descritos,
e durante a revisão, se torna mais fácil encontrar
ambiguações e erros.
• Features podem ser organizadas de forma hierárquica;
• Menor custo humano, dado que cada feature pode ser
desenvolvida de maneira independente, e ser lançada
em média a cada 2 semanas.
• Como cada feature é algo reduzido, inspecionar erros
em seu design ou em seu código é uma tarefa mais
fácil (menor custo de tempo).
Desvantagens
• Questionamento sobre efetividade/aplicabilidade do
FDD.
• Não existe um consenso do tamanho que cada feature
deve ter.
• Manutenção.
Referências
• http://www.slideshare.net/ruancarvalho/featuredrivendevelopment-viso-geral
• http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final
_22.pdf
• http://www.devmedia.com.br/introducao-ao-fdd-featuredriven-development/27971
OBRIGADO!