1
Feature Driven Development - FDD
(Desenvolvimento Guiado por Funcionalidades)
Guilherme Camargo
Gustavo Carvalho
Maurício Escobar
Prof.ª Dr.ª Andrea Bordin
2
Roteiro
● Introdução
● Padrão “ETVX”
● Etapas
● Fases
● Vantagens
● Desvantagens
● Papéis envolvidos
● Estudo de Caso
● Questionamento sobre o FDD
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
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
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
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
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
• 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
• Modelo Abrangente;
• Criar Lista de Funcionalidade;
• Planejar por Funcionalidade;
• Detalhar por Funcionalidade;
• Construir por Funcionalidade.
Fases
Concepção e Planejamento
Construção
10
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
Desvantagens
● Questionamento sobre a eficácia/aplicabilidade de FDD;
● Controvérsias sobre o tamanho mínimo de um time FDD;
● Manutenção.
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
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
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
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
• 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

Feature Driven Development - FDD

  • 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 é umametodologia á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 ePlanejamento: 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 porFuncionalidade: 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.
  • 11.
    11 ● Resultados úteisa 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 sobrea eficácia/aplicabilidade de FDD; ● Controvérsias sobre o tamanho mínimo de um time FDD; ● Manutenção.
  • 13.
    13 Papéis envolvidos Enquanto queXP 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 principaissã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 oFDD 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-DrivenDevelopment. 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