INTRODUO

Com o crescente aumento da competitividade dos mercados internacionais, a

exigncia sobre o produto tornou-se um diferencial determinante. E, visto que o
software tornou-se essencial para a manuteno do controle e da produtividade
nos mais diversos setores organizacionais, j era previsvel o surgimento de
novas metodologias e tcnicas que buscassem garantir agilidade e ao mesmo
tempo robustez no processo de desenvolvimento de software.
Assim surgiu o Manifesto gil, com o objetivo de promover prticas geis de
desenvolvimento de software e gerenciamento de projetos. Essas prticas tm
como conceito base o incentivo ao trabalho em equipe, equipes autoorganizadas e responsveis, um conjunto de tcnicas de engenharia que
permitem rpidas entregas de produtos com alto nvel de qualidade, alm de
uma nova abordagem ao alinhar os interesses dos clientes com os objetivos
dos desenvolvedores.
Como os conceitos advindos do Manifesto gil mostraram-se de intenso valor
para as boas prticas organizacionais, uma grande quantidade de engenheiros
de software e gerentes de projeto comeou a adaptar tais conceitos para o seu
prprio contexto. Dessa forma surgiram novas metodologias e diferentes
tcnicas focadas em dinamizar o processo de desenvolvimento. Entretanto,
essas tcnicas e metodologias podem se mostrar tambm deficientes em
alguns aspectos. Porm, ao analisar as fraquezas e os pontos fortes de cada
uma delas, possvel encontrar os pontos onde estas se complementam.
A filosofia aceita e pregada para o desenvolvimento de sistemas de que o
processo de desenvolvimento perfeitamente previsvel, podendo ser
planejado, estimado e completado com sucesso. No entanto, isso tem se
mostrado incorreto na prtica. O ambiente de desenvolvimento catico e
sofre constantes mudanas, muitas vezes bruscas, o que causa grande
impacto no produto final.
O processo de desenvolvimento gil prope uma nova abordagem. Essa
abordagem um conjunto de novas ideias, e ideias modificadas, enfatizando:

Uma maior colaborao entre programadores e especialistas do

domnio;
Comunicao cara a cara (como sendo mais eficiente do que

comunicao documentada).
Entregas constantes de novas funcionalidades com valor de negcio;
Equipes auto-organizadas;
Maneiras de adaptar o cdigo e a equipe a novos requisitos que
poderiam causar grande confuso.

De forma geral, metodologias geis priorizam o software funcionando como

principal mtrica de progresso. Tendo em vista a preferncia por comunicao
cara a cara, os mtodos geis normalmente produzem menos documentao
do que os outros mtodos. notvel tambm a grande adaptabilidade dos
projetos em relao a mudanas.

1. FEATURE DRIVEN DEVELOPMENT

Desenvolvimento por funcionalidade (FDD) uma abordagem gil e adaptativa
para desenvolvimento de sistemas. A abordagem FDD no cobre todo o
processo de desenvolvimento software mas concentra-se nas fases de
concepo e planejamento: pensar um pouco antes de fazer (tipicamente de 1
a 2 semanas) e construo: fazer de forma iterativa (tipicamente em iteraes
de 2 semanas). No entanto, ele foi projetado para trabalhar com outras
atividades de um projeto de desenvolvimento de software e no necessita de
qualquer modelo de processo especfico para ser utilizado. A abordagem FDD
encarna o desenvolvimento iterativo com as melhores prticas encontradas
para ser eficazes na indstria. Ele enfatiza os aspectos de qualidade durante
todo o processo e inclui entregas freqentes e tangveis, juntamente com um
acompanhamento preciso da evoluo do projeto.
FDD consiste em cinco processos seqenciais e fornece os mtodos, tcnicas
e orientaes necessrias para os participantes do projeto para entregar o
sistema. Alm disso, FDD inclui os papis, artefatos, metas e prazos
necessrios em um projeto. Ao contrrio de algumas outras metodologias
geis, FDD afirma ser apropriado para o desenvolvimento de sistemas crticos.

1.1 PROCESSO
Como mencionado anteriormente, FDD consiste em cinco processos
seqenciais durante o qual a concepo e construo do sistema realizada
(Figura 8). A parte iterativa dos processos FDD (concepo/planejamento e
construo) apia o desenvolvimento gil com adaptaes rpidas para as
mais recentes modificaes nas exigncias e necessidades de negcio.
Normalmente, uma iterao de um recurso envolve um perodo no mximo de
trs semanas de trabalho para a equipe.

A seguir descrito cada um dos cinco processos.

1.1.1 DESENVOLVER UM MODELO ABRANGENTE (DMA)
uma atividade inicial que abrange todo o projeto, realizada por membros do
domnio do negcio e por desenvolvedores, sob a orientao de um modelador
de objetos experiente, no papel de arquiteto-lder.
Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto.
Ento, so realizados estudos mais detalhados sobre o domnio do negcio
para cada rea a ser modelada. Aps cada estudo dirigido sobre o domnio,
pequenos grupos so formados por membros do domnio do negcio sendo
estudado e por desenvolvedores, que comporo seus prprios modelos que
satisfaam o domnio em questo. Os pequenos grupos apresentam seus
modelos para serem revisados por parceiros e para discusso. Um dos
modelos propostos, ou uma combinao dos modelos, selecionada por
consenso, tornando-se, assim, o modelo para aquela rea do domnio do

negcio. Realiza-se, ento, uma combinao do modelo da rea do domnio

dentro de um modelo abrangente, ajustando a forma do modelo se for
necessrio.
O modelo de objetos , ento, iterativamente atualizado em seu contedo pelo
processo n 4 Detalhar por Funcionalidade.
1.1.2 CONSTRUIR A LISTA DE FUNCIONALIDADES (CLF)
uma atividade inicial que abrange todo o projeto, para identificar todas as
funcionalidades que satisfaam aos requisitos.
Uma equipe, geralmente composta apenas por programadores-lderes do
processo n 1, formada para decompor funcionalmente o domnio em reas
de negcio, atividades de negcio dentro delas e passos dentro de cada
atividade de negcio, formando assim a lista categorizada de funcionalidades.
A categorizao de mais alto nvel para a lista de funcionalidades vem da
diviso do domnio feita pelos especialistas do domnio no processo n 1.

1.1.3 PLANEJAR POR FUNCIONALIDADE (PPF)

uma atividade inicial que abrange todo o projeto, para produzir o plano de
desenvolvimento.
O gerente de projeto, o gerente de desenvolvimento e os programadoreslderes planejam a ordem na qual as funcionalidades sero implementadas,
baseada nas dependncias entre elas, na carga de trabalho da equipe de
desenvolvimento e tambm na complexidade das funcionalidades a serem
implementadas. As principais atividades neste processo no so uma
seqncia estrita. Como muitas atividades de planejamento, elas so
consideradas em conjunto, com refinamentos feitos a partir de uma ou mais
atividades e ento considerando os outros novamente.
Um cenrio tpico levar em conta a seqncia de desenvolvimento, depois
levar em conta a atribuio das atividades de negcio aos programadoreslderes e, ao faz-lo, considerar quais das classes principais (apenas) so
atribudas a quais desenvolvedores (lembrar que o programador-lder tambm
um desenvolvedor).

Quando esse equilbrio for alcanado, e a seqncia de desenvolvimento e a

atribuio das atividades de negcio aos programadores-lderes estiver
essencialmente completada, ento a posse das classes estar completada
(alm das classes principais que j foram consideradas para posse).
1.1.4 DETHALAR POR FUNCIONALIDADE (DPF)
uma atividade executada para cada funcionalidade, para produzir o pacote
de projeto (design) para ela.
Certo nmero de funcionalidades so agendadas para desenvolvimento ao
atribu-las a um programador-lder. Ele seleciona as funcionalidades para
desenvolvimento a partir de sua caixa de entrada de funcionalidades
atribudas. Ele pode escolher diversas funcionalidades que utilizem as mesmas
classes (e portanto, desenvolvedores). Operacionalmente, com freqncia
acontece o caso de conjuntos de funcionalidades serem agendados para
desenvolvimento de uma vez pelo programador-lder. Tal conjunto chamado
de Pacote de Trabalho do Programador-Lder (PTPL).
O

programador-lder,

identificando

os

ento,

forma

proprietrios

das

uma

equipe

classes

de

funcionalidades,

(desenvolvedores)

que

provavelmente sero envolvidos no desenvolvimento das funcionalidades que

ele selecionou. Esta equipe produz o(s) diagrama(s) de seqncia para a(s)
funcionalidade(s) atribuda(s). O programador-lder, ento, refina o modelo de
objetos, baseado

no

contedo

do(s) diagrama(s) de

seqncia.

Os

desenvolvedores escrevem os prefcios das classes e mtodos. Realiza-se

uma inspeo no projeto (design).

1.1.5 CONSTRUIR POR FUNCIONALIDADE (CPF)

uma atividade executada para cada funcionalidade, para produzir uma
funo com valor para o cliente (funcionalidade).
Comeando com o pacote de projeto (design), os proprietrios de classes
implementam os itens necessrios para que suas classes suportem o projeto
para esta funcionalidade. O cdigo desenvolvido passa pelo teste de unidade e
pela inspeo a ordem aqui determinada pelo programador-lder. Aps
passar pela inspeo, o cdigo promovido verso atual (build).