Please enable JavaScript.
Coggle requires JavaScript to display documents.
FDD (Feature Driven Development) - Coggle Diagram
FDD (Feature Driven Development)
5 PROCESSOS
1° FASE
(Concepção e Planejamento)
Os processos são executados no começo do código
CLF (Construir a Lista de Funcionalidades)
É formado por um time para a lista de funcionalidades, que normalmente é composto pelos programadores-chefes que participaram do processo anterior e é construída uma lista de funcionalidades.
Utilizando as partes do produto que foram identificadas no processo anterior, chamadas aqui de áreas de negócio, o grupo deve identificar às atividades dessas áreas e a partir dessas atividades, as funcionalidades que as constituem.
DMA (Desenvolver um modelo abrangente)
Dependendo do quão complexo é a área de negócio apresentada, o grupo pode solicitar um pequeno período de tempo para estudar a documentação fornecida pelo especialista de negócio. Após as apresentações, o grupo é dividido em subgrupos, que elaborarão uma proposta de modelo não detalhada para aquela parte específica do negócio. Então as propostas são apresentadas e uma delas, ou uma junção de várias, é escolhida para ser o modelo.
O modelo escolhido é incluso no modelo abrangente do produto. Este modelo abrangente é o resultado da junção de todos os modelos escolhidos para cada parte do negócio apresentada. São incluídas então notas e observações nesse modelo, e essas atividades vão se repetindo até que um modelo abrangente que cubra tudo aquilo que foi previsto nas partes de negócio para o produto seja encontrado.
Durante esse processo é formado o time de modelagem composto por especialistas de negócio e programadores. Conduzido o domain Walkthrough (Estudo dirigido de domínio) onde os especialistas de negócio apresentarão para o restante do grupo uma visão do produto e depois realizarão apresentações de pequenas partes do negócio.
PPF (Planejar por funcionalidade)
Depois são atribuídas aos programadores-chefes responsabilidades sobre um conjunto de atividades de negócio, que serão responsáveis por toda as funcionalidades que a compõe. Então são atribuídos ”donos”, programadores, as classes, que serão responsáveis pela manutenção delas. Assim, as classes são distribuídas com base na experiência de cada programador.
Durante esse processo é formado o time de planejamento. Esse time faz a sequência do desenvolvimento do projeto se baseando em suas dependências, na equipe de desenvolvimento, na carga horária e na complexidade das funcionalidades.
2° FASE
(Construção)
Esses processo são executados uma vez para cada funcionalidade
CPF (Construir por funcionalidade)
Este processo também será executado uma vez para cada funcionalidade, como o anterior. São implementadas as classes e métodos de acordo com a visão abrangente e o detalhamento realizado nos processos anteriores. Então, cada desenvolvedor convida um membro de outra equipe para avaliar aquilo que foi desenvolvido em sua classe durante este processo.
E após isso os desenvolvedores ficam responsáveis por testar suas classes e métodos e assegurar que as necessidades do negocio sejam alcançadas. E com as classes testadas e funcionando, pode ser então feito o build.
DPF (Detalhar por funcionalidade)
Agora, formam-se as equipes de funcionalidades, onde o programador-chefe chama os ”donos” de cada classe para participar da equipe. Dependendo do quão complexa seja a funcionalidade, o programador chefe pode convocar um especialista de negócio para que este conduza um novo Domain Walkthrough (Estudo dirigido sobre o domínio) para a equipe, para não ficar dúvidas a respeito daquela funcionalidade em si.
Ainda dependendo do quão claro ficou para o time sua função, pode ser reservado um tempo para ser estudada a documentação de negócio e as anotações relacionadas àquela funcionalidade. E feito então um diagrama de sequência relacionado àquela funcionalidade e é refinado o modelo abrangente, já incluindo métodos e atributos nas classes envolvidas nela.
Com essas informações, cada programador cria os prólogos de suas classes, com cabeçalhos de métodos com tipagem de parâmetros, atributos e outros, não fazendo nenhuma implementação ainda. Então, o programador-chefe dessa funcionalidade convida outro membro da equipe para avaliar o desenvolvimento de sua classe durante o processo.
PADRÃO ETVX
Entrada (Entry)
Define e especifica critérios de entrada para as fases do FDD;
Saída (Exit)
Especifica os critérios de saída, ou seja, os critérios de “pronto” da fase.
Verificação (Verification)
Especifica tipos de avaliações e inspeções de projeto e códigos de “testes”;
Tarefa (Task)
É composto por uma lista de tarefas a ser realizada a cada uma das fases;
VANTAGENS E DESVANTAGENS
VANTAGENS
Ideal para trabalhar com equipes grandes em projetos grandes;
projetos bem estruturados desde a sua primeira fase;
permite que várias equipes trabalhem simultaneamente, reduzindo o tempo de execução do projeto;
o processo é altamente documentado, o que o torna muito rastreável (é mais fácil identificar gaps e corrigi-los);
equipes trabalham com as etapas de desenvolvimento com agilidade.
DESVANTAGENS
Não funciona bem em equipes menores, já que projeto FDD demanda a execução de muitas tarefas;
grande produção de documentação escrita nas primeiras fases do projeto;
o projeto depende muito das decisões dos programadores-chefe.
DIFERENÇAS ENTRE
FDD e XP
O Extreme Programming é uma metodologia de desenvolvimento ágil baseada na testagem extrema dos softwares que estão sendo desenvolvidos. Além disso, o método enfatiza o trabalho em dupla, a colaboração entre a equipe e a boa comunicação entre o cliente e a equipe.
Podemos dizer que o XP, como é conhecido o Extreme Programming, mescla características da metodologia Scrum e do FDD. Isso porque trata-se de um método criado para desenvolvimento de software com base na criação de sistemas de alta performance.
Sua estrutura, assim como o Scrum, prevê uma interação próxima com os clientes ao longo do processo de desenvolvimento. Além disso, contempla etapas de testagem em ciclos de desenvolvimento reduzidos (assim como no FDD).
FDD e RUP
O FDD é uma metodologia ágil que se concentra na entrega de funcionalidades específicas de maneira iterativa e incremental. Ele enfatiza a modelagem de domínio, a identificação e a implementação de funcionalidades. Já o RUP é um processo de desenvolvimento de software que segue uma abordagem mais prescritiva e iterativa, com foco em disciplinas como modelagem, gerenciamento de requisitos, design, implementação e testes.
A modelagem de domínio é uma parte fundamental do FDD, com ênfase na criação de um modelo claro e preciso do domínio do negócio para orientar o desenvolvimento. Já no RUP também valoriza a modelagem, mas sua abordagem pode ser mais abrangente, envolvendo diferentes tipos de modelagem, como modelagem de negócios, modelagem de requisitos e modelagem de sistemas.
O FDD pode ser mais adequado para projetos de médio a grande porte, onde a gestão de funcionalidades específicas pode ser crucial para o sucesso do projeto. Já no RUP é conhecido por ser altamente escalável e pode ser adaptado para projetos de diferentes tamanhos e complexidades, desde pequenos projetos até projetos de larga escala.