Apresentação desenvolvida para a disciplina Processos de Software, do curso de Engenharia de Software da Universidade Federal do Pampa. É apresentado um Overview da metodologia ágil de desenolvimento de software, Desenvolvimento Guiado por funcionalidade.

1. 1
Feature Driven Development - FDD
(Desenvolvimento Guiado por Funcionalidades)
Guilherme Camargo
Gustavo Carvalho
Maurício Escobar
Prof.ª Dr.ª Andrea Bordin

2. 2
Roteiro
● Introdução
● Padrão “ETVX”
● Etapas
● Fases
● Vantagens
● Desvantagens
● Papéis envolvidos
● Estudo de Caso
● Questionamento sobre o FDD

3. 3
Introdução
● 1997 - 1998, Cingapura - Banco United Overseas Bank, de
Singapura;
● Anteriormente, após 2 anos de consultoria, 3.500 páginas
de casos de uso e um modelo de objetos com centenas de
classes, foi avaliado como impossível;
● Peter Coad e Jeff de Luca se unem para resolver o
problema, como resultado, 15 meses após a contratação da
dupla, 2.000 features entregues por uma equipe de 50
pessoas.
● Oficialmente “formalizada” em 1999, no capítulo 6 do livro
“Java Modeling in Color With UML”, de Peter Coad, Eric
Lefebvre e Jeff de Luca.

4. 4
FDD é uma metodologia ágil para desenvolvimento de
Software, com foco na entrega frequente de artefatos
funcionais para os clientes e na adoção de boas práticas
de gerenciamento de projeto e Engenharia de Software
Orientada à Objetos durante todo o ciclo de
desenvolvimento. É um processo formado em duas etapas
compostas por cinco fases.
Tendo como resultado um Software com qualidade que
teve feedback constante do cliente para que assim a
solução seja precisa ao problema proposto.
“Resultados frequentes, tangíveis e funcionais.”

5. 5
Padrão “ETVX”
Entry, Task, Verification and Exit
É o padrão proposto por Jeff de Luca para seja utilizado em todos as
fases do FDD, pode-se entender como sendo uma regra que define
o momento em que uma fase foi finalizada e outra pode ser iniciada.
Esse padrão é composto por quatro itens:
• Entry: Define e especifica os critérios de entrada para cada fase.
• Task: É uma lista de tarefas que devem ser realizadas em cada
fase.
• Verification: Especifica os tipos de inpeções e avaliações de
projetos e código.
• Exit: São os critérios que determinam que a fase foi concluída.

6. 6
Etapas
• Concepção e Planejamento: Abstrair o modelo, especificar
as características e utiliza-las no planejamento. Tal etapa
tem duração de uma a duas semanas e é executada
apenas uma vez.
• Construção: É o desenvolvimento iterativo e incremental
do software, onde cada funcionalidade deve ser entregue
em no máximo duas semanas.

7. 7
Fases
• Modelo Abrangente: É feito um estudo para entendimento do
domínio do problema, utilizando-se de técnicas de Engenharia de
Requisitos e Modelagem de Projetos de Software.
• Criar Lista de Funcionalidades: Nesta fase é feita a
decomposição funcional do domínio, em área de negócio,
atividades de negócio e processo elementar de negócio
(funcionalidades).
• Planejar por Funcionalidade: A lista de funcionalidades
priorizadas é refinada, é definido o tempo estimado pra cada
funcionalidade com base nos níveis de prioridade e complexidade
de cada uma. E por fim são atribuídas as tarefas.

8. 8
• Detalhar por Funcionalidade: Um programador chefe pega o
próximo recurso, identifica as classes e entra em contato com o
proprietário da classe. Esta equipe de recursos trabalha com um
diagrama de seqüência detalhado. Os proprietários da classe
escrevem classe e método prólogos. A equipe realiza uma
inspeção de projeto.
• Construir por Funcionalidade: É desenvolvido a funcionalidade
e os testes, logo após é feita a integração ao branch principal
para que seja feita a entrega ao cliente.
Fases

9. 9
• Modelo Abrangente;
• Criar Lista de Funcionalidade;
• Planejar por Funcionalidade;
• Detalhar por Funcionalidade;
• Construir por Funcionalidade.
Fases
Concepção e Planejamento
Construção

10. 10

11. 11
● Resultados úteis a cada 2 semanas ou menos;
● Foco em “características de valor para o cliente”;
● Inovação contínua devido a constante comunicação
com o cliente.
● Rastreabilidade e relatórios com precisão;
● Monitoramento detalhado dentro do projeto;
● Resultados confiáveis.
Vantagens

12. 12
Desvantagens
● Questionamento sobre a eficácia/aplicabilidade de FDD;
● Controvérsias sobre o tamanho mínimo de um time FDD;
● Manutenção.

13. 13
Papéis envolvidos
Enquanto que XP e Scrum não possuem papéis definidos
relacionados ao desenvolvimento (por exemplo:
programador ou gerente de projetos), FDD possui 03 tipos
de papéis: papéis principais, papéis de apoio e papéis
adicionais.

14. 14
Os papéis principais são: Gerente de Projeto, Arquiteto
Chefe, Gerente de Desenvolvimento, Programador Chefe,
Proprietário de Classe e Especialista de Domínio.
Os papéis de apoio são: Gerente de Domínio, Gerente de
Versão, Especialista (Guru) da Linguagem, Coordenador
de Construção, Ferramenteiro (toolsmith) e Administrador
de Sistema.
Os papéis adicionais são: Testador, Desenvolvedores e
Escritor Técnico.

15. 15
Estudo de Caso
1. 2012, Utilização das melhores práticas do SCRUM e do
FDD no desenvolvimento de aplicações web: estudo de
caso sistema GIP. (Revista T.I.S. - Tecnologias,
Infraestrutura e Software).
2. 2013, Developing Secure Websites Using Feature
Driven Development (FDD): A Case Study. (Journal of
Clean Energy Technologies).

16. 16
Questionamento sobre o FDD
1. Quais características do SCRUM são encontradas no
FDD? Qual a importância delas no produto final ?
2. Qual o impacto da adoção do padrão ETVX em cada
processo ?
3. Definir explicitamente os papéis tem impacto negativo
na metodologia ágil?

17. 17
• 6 Feature-Driven Development. PACE University. Disponivel em:
<http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd2.pdf>. Acesso em 14 Abr. 2018.
• Developing Secure Websites Using Feature Driven Development (FDD): A Case Study.
JOCET. Disponível em:
<http://www.jocet.org/index.php?m=content&c=index&a=show&catid=29&id=340>. Acesso em
14 Abr. 2018.
– https://pdfs.semanticscholar.org/ea2a/0300eff71e3083061cffb04abf9b03e0dbc3.pdf
• Utilização das melhores práticas do SCRUM e do FDD no desenvolvimento de aplicações
web: estudo de caso sistema GIP. UFSCAR. Disponível em:
<http://revistatis.dc.ufscar.br/index.php/revista/article/viewFile/15/19>. Acesso em: 15 abr.
2018.
Referências