FDD FEATURE-DRIVEN DEVELOPMENT

FDD-significa desenvolvimento dirigido por funcionalidade.

A FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma das seis metodologias ágeis originais, cujos representantes redigiram o Manifesto Ágil para Desenvolvimento de Software, em 2001. Nessa ocasião, o representante da FDD foi Jon Kern, que trabalhava na TogetherSoft, substituindo Peter Coad.

• conceito:
• É um pequeno conjunto de processos orientado a modelo e com poucas e curtas interacões. A ideia é sempre gerar "produto úteis aos olhos do cliente" em ciclo rápidos de duas semanas, tanto quanto possivel.Como o ciclo é curto e orientado a caracteristica do sistema, o processo é facilmente moldável a volatividade do negócio.

• Caracteristicas:
• .Fornece a estrutura suficiente para equipes maiores.
  .Enfatiza a produçao de software de qualidade.
• .Entrega resultados frequentes,tangíveis e funcionais.
• .Realiza trabalho significativo desde o inicio,antes de torna-se altamente interativos.
• .Fornece informaçao de estado e progresso de formas simples e compreensivel.
• .Agrada a cliente, gerentes e desenvolvedores.
• 
  

Seus princípios e práticas: proporcionam um equilíbrio entre as filosofias tradicionais e as mais extremas, proporcionando uma transição mais suave para organizações mais conservadoras, e a retomada da responsabilidade para as organizações que se desiludiram com as propostas mais radicais.

A primeira descrição: oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999.
O livro de referência é "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma série editada pelo próprio Peter Coad.

Referências: das vantagens e desvantagens.
The FDD Portal
http://www.featuredrivendevelopment.com/

The New Methodology – Martin Fowler
http://martinfowler.com/articles/newMethodology.html#N102CC

• 
  Vantagens:
• 
  Uma metodologia ágil para aplicações críticas?
  Como FDD possui fases muito fortes de análise, se comparada com outras metodologias ágeis, seus autores a recomendam para qualquer tipo de desenvolvimento, incluindo crítico.
  Foco em "características de valor para o cliente" (cliente-valued features)
  FDD prioriza aquilo que o cliente prioriza. Na medida em que há participação ativa do mesmo no projeto e um entendimento profundo dos requisitos do sistema, os resultados produzido têm bastante e rápida visibilidade.
• 
  Desvantagens:
• 
  Pesquisa
  O caso inicial de aplicação de FDD foi no desenvolvimento de uma aplicação bancária. Entretanto, relatos confiáveis de uso bem-sucedido ainda não são encontráveis, questionando a eficácia/aplicabilidade de FDD.
  Escalabilidade do time
  Há controvérsias sobre o tamanho mínimo de um time FDD
  Manutenção
  Ainda que FDD pressuponha um ciclo completo de documentação, a especificação original da metodologia não comenta sobre sua aplicabilidade à manutenção de sistemas.

• curiosidades:
• 
  FDD POSSUI REQUISITOS MAIS FORMAIS E MAIS PASSOS QUE XP, ALÉM DE POSSUIR UM MECANISMOMAIS PRECISO PARA ACOMPANHAMENTO DO PROJETO.

Resumidamente, FDD é dividido em 5 fases que explicam sua função. São elas:

Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.
Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário

bibliografias:

Wikipédia, a enciclopédia livre.

http://pt.wikipedia.org/wiki/Feature_Driven_Development

The FDD Portal
http://www.featuredrivendevelopment.com/
FDD Processes
DeLuca, J. – Nebulon Pty.
FDD Overview
Nebulon Pty.
The New Methodology – Martin Fowler
http://martinfowler.com/articles/newMethodology.html#N102CC