Feature Driven Development (FDD)

Criado por Jeff de Luca e Peter Code ((PALMER e FELSING, 2002) apud (ABRAHAMSSON et al, 2002)), o método FDD é um método ágil e adaptável ao sistema.

Não cobre o processo inteiro de desenvolvimento do software, mas focaliza-o particularmente no projeto e nas fases de construção (ABRAHAMSSON et al, 2002).

FDD incorpora o desenvolvimento iterativo e as melhores práticas da modelagem ágil. Os aspectos de qualidade são enfatizados durante todo o processo de desenvolvimento, incluindo entregas freqüentes e tangíveis, bem como monitoração do progresso do projeto no período de desenvolvimento (ABRAHAMSSON et al, 2002).

9 http:\\www.controlchaos.com. Acesso em Outubro/2005

FDD possui cinco processos seqüenciais durante o projeto e o desenvolvimento do sistema, como ilustrado na Figura 2.2 e logo em seguida descrito. A parte iterativa dos processos de FDD (“projetar por característica” e “construir por característica”) suporta o desenvolvimento ágil com adaptações rápidas às mudanças, de acordo com as exigências e as necessidades do negócio (ABRAHAMSSON et al, 2002). As iterações do projeto e construção de uma característica seguem por um período de uma a três semanas de trabalho.

Figura 2.2: Processos FDD (adaptado de ABRAHAMSSON et al, 2002)

Processo 1: “Desenvolver um modelo abrangente” – Os membros de um projeto devem estar cientes do contexto e das exigências do sistema a ser construído logo no início do desenvolvimento do projeto. Isso é alcançado por meio de casos de uso ou especificações funcionais exigidos neste processo.

Processo 2: “Construir uma lista de Características” – A equipe identifica as características, agrupa-as hierarquicamente e atribui prioridades e tamanho. Entre as tarefas deste processo incluem a formação da equipe que irá projetar a lista de características.

Processo 3: “Planejar por Características” – Um plano de projeto é construído e usado nos processos seguintes, determinando a seqüência de desenvolvimento com as prioridades e as datas que cada característica deve ser completada.

Processo 4: “Projetar por Características” – Um pequeno grupo de características é selecionado do conjunto de características. Deste grupo são identificadas as classes que estão envolvidas e os seus respectivos proprietários. Cada característica selecionada irá passar por esta etapa, em que a equipe de características define um diagrama de seqüência (BOOCH et al, 2000) detalhado para ela. Os proprietários das classes estruturam suas classes e métodos.

No final a equipe faz uma inspeção no projeto. Entre as tarefas deste processo incluem a formação da equipe de projeto e a definição de um guia de domínio, a construção do diagrama de seqüência, a estruturação das classes e métodos e a inspeção do projeto.

Processo 5: “Construir por Características” – Neste processo são realizados a implementação das classes e métodos, a inspeção do código, os testes de unidade e o desenvolvimento de cada característica ou conjunto delas.

A iteratividade entre os dois últimos processos é representada de forma incremental, em que as características vão sendo concluídas e novas características vão sendo inicializadas, dando origem a uma versão do software.

FDD possui requisitos mais formais e um mecanismo mais preciso para acompanhamento do projeto. Segundo Khramtchenko (2004), o desenvolvimento baseado em FDD consiste de dois estágios principais: descobrir uma lista de características a serem implementadas e realizar a implementação baseada em característica.

Khramtchenko (2004) relata que descobrir a lista de características é o processo mais crítico e o estágio principal para o sucesso do projeto. O fator crítico deste estágio está relacionado às dificuldades encontradas na especificação dos requisitos e na interpretação de determinados requisitos ambíguos. O sucesso do projeto pode ser atribuído à qualidade identificada na lista de características.

O método FDD tem participação integral do cliente junto à equipe de desenvolvimento.

2.3.3.1 Práticas

Algumas práticas do FDD possuem semelhanças às práticas do método Scrum, por exemplo, a lista de funcionalidades. No método Scrum a lista de funcionalidades é denominada “Backlog do Produto” e no método FDD é denominada “Desenvolvimento por Características”. Tanto no método Scrum como no método FDD a lista de funcionalidades é um requisito muito importante, pois representa todo o sistema. Uma outra prática é com relação à equipe de projeto. No método Scrum é denominada “Equipes Scrum” e no método FDD “Equipes de característica”; em ambos os métodos as equipes são pequenas. Uma outra semelhança é com relação à maneira como é realizada a revisão. No método Scrum são realizadas reuniões diárias com o objetivo de verificar o andamento do projeto e no método FDD são realizadas configurações regulares, que visam assegurar que o sistema está disponível para adição de novas funcionalidades.

FDD possui algumas boas práticas apresentadas a seguir, segundo Abrahamsson et al (2002):

• Modelo de objeto do domínio: faz a exploração e a explanação do domínio do problema.

• Desenvolvimento por características: desenvolve uma lista de características, acompanhando seu progresso.

• Posse individual da classe: possui uma única pessoa nomeada para ser responsável por uma classe e pela sua consistência, desempenho e integridade.

• Equipes das características: formada por equipes pequenas que orientam o projeto.

• Inspeção: realiza inspeções no projeto ou no código fonte durante o desenvolvimento do projeto.

• Configurações regulares: utiliza configurações regulares para garantir a demonstração do sistema disponível, fornecendo base às novas características que poderão ser adicionadas.

• Gerência de configuração: realiza um controle das versões permitindo a identificação do histórico das últimas modificações, mantendo um histórico de todas as versões.

A equipe de projeto deve utilizar todas as práticas descritas anteriormente, obedecendo as regras do desenvolvimento e podendo ainda adaptá-las de acordo com a necessidade do projeto (ABRAHAMSSON et al, 2002).