Please enable JavaScript.
Coggle requires JavaScript to display documents.
FDD (Feature-Driven Development) - Coggle Diagram
FDD (Feature-Driven Development)
significa
: desenvolvimento guiado a funcionalidades, seu principal objetivo é entregar ao cliente um software funcional em tempo
hábil
, seguindo o
modelo iterativo e incremental
do processo de desenvolvimento de software.
características
:
O FDD surgiu em Singapura, entre os anos de 1997 e 1999;
○ Foi desenvolvido por Peter Coad e Jeff De Luca e publicado em 1999 no livro “Java Modeling in Color with UML”.
● É uma das metodologias mais antigas, sendo criada anteriormente ao Manifesto Ágil (o manifesto ágil ocorreu apenas em 2001);
● Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia.
I. Propõe um equilíbrio entre filosofias tradicionais e
ágeis;
II. É prático para o trabalho com projetos iniciais, com grandes equipes, ou projetos com codificações já existentes.
III. Lema do FDD: “Resultados frequentes e
funcionais”
Uma
feature
“é uma funcionalidade com valor para o cliente que pode ser desenvolvida em duas ou menos semanas”;
Um dos objetivos do FDD é entregar para o
cliente funcionalidades com rapidez;
Em um período fixo de tempo, em geral, duas semanas ou menos. Exemplo:
calcular o valor de uma compra
calcular itens em estoque
listar fornecedores locais
Um projeto que segue a metodologia FDD deve ser estruturado de acordo
com as seguintes premissas:
Desenvolvimento por funcionalidades
Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este
planejamento é incremental.
Um único programador é responsável pela funcionalidade desenvolvida
ATENÇÃO: Esse é um ponto que diverge do XP!!!
-No FDD é incentivado que UM desenvolvedor seja o único responsável pela funcionalidade que
este desenvolve, já no XP, o código deve ser comunitário.
O FDD é composto por cinco etapas, e é indicado que cada iteração siga o padrão de etapas chamado de
ETVX
, oriundo de:
Entrada
(Entry): especifica e define os critérios de entradas para as etapas.
Tarefa
(Task): é composto por uma lista com as tarefas que deverão ser realizadas.
Verificação
(Verification): especifica tipos de avaliações (internas e externas) e inspeções de projeto e código.
Saída
(Exit): especifica os critérios de saída, definindo os produtos tangíveis.
O FDD possui 5 papéis principais, são eles:
Gerente de Projeto
: É o líder administrativo e financeiro do projeto: tem a palavra final no que
se trata de escopo, cronograma e recursos do projeto.
Gerente de Desenvolvimento
: É o líder nas atividades diárias do desenvolvimento. É responsável por
resolver qualquer tipo de conflito que venha a ocorrer dentro da equipe.
Arquiteto-chefe
: É responsável pela modelagem do projeto. Deve auxiliar a equipe de
desenvolvedores e contribuir na construção do software.
Proprietários de código/classe (desenvolvedores)
: São os responsáveis pela modelagem e desenvolvimento de novas
funcionalidades de um software.
Especialistas do Domínio (negócio)
: Pode ser qualquer pessoa que tenha o melhor conhecimento sobre o
software em particular, e pode ajudar as Equipes a entendê-lo.
No FDD, uma pessoa pode desempenhar mais de um papel e um papel pode ser desempenhado por mais de uma pessoa.
Em projetos maiores e que possuam tal necessidade, outros papéis podem ser incluídos
no projeto, tais como:
Gerente de domínio
Gerente de versão
Administrador de Sistema
Guru da Linguagem
Fases e processos do FDD:
2 Fases
:
1º Concepção e Planejamento: Pensar um pouco antes de fazer
(tipicamente de 1 a 2 semanas);
2º Construção: Fazer de forma iterativa (tipicamente em
iterações de 2 semanas).
O planejamento é realizado por processos, onde o conjunto de processos se divide em duas fases.
5 Processos bem definidos e integrados
:
1 . DMA (Desenvolver um Modelo Abrangente) - análise orientada por objetos.
2 . CLF (Construir a Lista de Funcionalidades) - decomposição funcional.
3 . PPF (Planejar por Funcionalidade) - planejamento incremental.
4 . DPF (Detalhar por Funcionalidade) - desenho (projeto) orientado por objetos.
5 . CPF (Construir por Funcionalidade) - programação e teste orientados por objetos.
1
. O primeiro momento é de conhecer para analisar o sistema e o contexto
em que ele está inserido. - A partir disso são estudados os domínios do sistema e um modelo
geral é desenvolvido com base nesses estudos. Criado o modelo geral, pequenas equipes são responsáveis por criar
uma modelagem superficial para cada área de domínio do sistema.
Cada modelo criado é revisado por outros membros do projeto, que
não fazem parte da equipe que criou o modelo, a fim de escolher o
melhor modelo de domínio para cada área.
Assim, ao final do processo os modelos escolhidos são unificados no modelo
geral do domínio do sistema e o trabalho é iniciado.
2
. Nesta fase é criada uma lista de funcionalidades do sistema,
descrevendo e identificando a área de domínio de cada uma delas.
As funcionalidades são importantes para o processo porque cada
uma é uma pequena tarefa que precisa ser implementada ao
projeto.
Os itens de funcionalidade não devem levar mais de duas semanas para
serem concluídos e são ordenados na lista por ordem de prioridade no
desenvolvimento.
Por exemplo, uma lista de funcionalidades pode conter os seguintes
itens: “validar a senha do usuário”, “liberar o login” e “gerar relatório
de vendas”.
3
. De acordo com a lista de funcionalidades é feito o planejamento de
desenvolvimento delas.
Para cada funcionalidade são designados programadores-chefe
que ficarão responsáveis por algumas classes ou códigos. A partir disso são formadas as equipes de planejamento e cada
integrante da equipe é encarregado de uma parte do projeto.
4
.
Assim como na primeira fase, nessa etapa é criada uma
modelagem com as funcionalidades a serem
desenvolvidas.
A diferença dessa modelagem é que o programador
chefe a cria de acordo com uma funcionalidade
específica e a divide em classes, métodos e atributos.
Quando finalizada, a funcionalidade passa por testagens da
equipe desenvolvedora.
5
.
Após a modelagem passar por diversos testes, o código
começa a ser implementado no sistema. Dessa forma, as
funcionalidades são incorporadas e já podem ser colocadas em
prática.
Efetivado o código, ele é escrito e essa funcionalidade é
concluída.
Fazem parte dessa fase a implementação das regras de
negócio das classes, a inspeção do código, a condução dos
testes unitários e o release da funcionalidade.