Metodologia gil:

Feature Driven Development

Antnio Barbosa1, Bruno Azevedo2, Bruno Pereira3,

Pedro Campos4, Pedro Santos5

1Estudante da LEIC
ei03023@fe.up.pt
2 Estudante da LEIC

ei01058@fe.up.pt
3 Estudante da LEIC

ei03026@fe.up.pt
4 Estudante da LEIC
ei03082@fe.up.pt
5 Estudante da LEIC

ei03005@fe.up.pt

Resumo.
Feature Driven Development(FDD) uma metodologia gil de desenvolvimento
de software. Esta metodologia permite desenvolver um sistema de forma rpida e
permite facilmente introduzir novas features (funcionalidades) a este. Uma nova
feature demora entre duas horas a duas semanas a ser concluda. O facto de no FDD
usar-se processos simples proporciona uma rpida exposio do projecto a novos
elementos que venham a fazer parte da equipa, assim como torna o trabalho menos
montono, uma vez que se esta sempre a iniciar/acabar um processo.

1.Metodologias geis

1.1. O aparecimento das metodologias geis

As metodologias geis surgiram em resposta ao problema dos atrasos do

desenvolvimentos software, e aos cancelamentos por obsolescncia, ou seja um
programa que demore muito tempo a ser desenvolvido, tem tendncia a ficar
desactualizado se seguir os objectivos propostos no seu planeamento.
Houve outros avanos que se esperavam resolver os problemas anteriores, como
os mtodos estruturados em 1980 ou as metodologias orientadas a objectos, mas os
problemas mantinham-se.
Tambm se achou que a soluo passaria pelo melhorar o processamento do
software, mas s a introduo das metodologias de desenvolvimento gil trouxeram
soluo aos problemas, visto a chave era a adaptabilidade e no apenas o
aperfeioamento dos mtodos existentes.
 Assim, esta metodologia veio a reduzir a taxa de abandono dos projectos a meio e
proporcionou um rpido desenvolvimento e um cumprir sistemtico dos objectivos.

1.2. Introduo s metodologias geis.

A definio de metodologias geis de desenvolvimento de software foi

criada durante os anos 90 como reaco contra os mtodos de desenvolvimento
"pesados", tipificados pelo modelo em cascata. Estes mtodos eram ento vistos como
burocrticos e lentos e criavam uma contradio em relao ideia que o trabalho dos
engenheiros de software eficaz.
Inicialmente, as metodologias geis eram denominadas como mtodos de
desenvolvimento "leves", mas em 2001 alguns elementos da comunidade
encontraram-se na estncia de sky de Snowbird e criaram o "The Agile Manifesto" no
qual adoptaram o nome Mtodologias geis. Este Manifesto foi criado com o intuito
de fazer a unio entre as diferentes metodologias geis, e apresentado como sendo a
definio cannica do desenvolvimento gil. O Manifesto apresentado a seguir na
sua forma original:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping

others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the
left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas

2001, the above authors

this declaration may be freely copied in any form, but only in its entirety
through this notice.
 1.3.Comparao com outros tipos de metodologias

comum afirmar-se que os mtodos geis de desenvolvimento de software so o

oposto de metodologias disciplinadas e planeadas; no entanto tal afirmao uma m
interpretao da adaptabilidade pedida. Uma distino mais precisa pode ser feita
atravs da disposio dos mtodos seguindo uma linha desde "Adaptveis" a
"Preditivas"

<--gil--> <--Iterativa--> <--Cascata-->

<-----|----------------|--------------------|------->
Adaptvel Preditiva

Mtodos adaptveis focam-se na adaptao a constantes mudanas. Uma equipa

sabe o trabalho que lhe cabe na fase actual do projecto mas desconhece o passo
seguinte, que vai sendo decidido durante o decorrer de cada fase.
Mtodos preditivos fazem o planeamento detalhado do futuro. Uma equipa
preditiva define exactamente que tarefas iro ser desempenhadas e que caractersticas
iro ser desenvolvidas durante toda a durao do processo de desenvolvimento e a
sequncia de fases a passar. Uma equipa preditiva tem dificuldades em lidar com
mudanas, pois normalmente o plano foi optimizado tendo em conta o destino original,
sendo que qualquer alterao pode fazer com que determinado trabalho ter que ser
feito de maneira completamente distinta. As equipas preditivas geralmente instituem
uma comisso de controlo de mudanas, constituda por elementos com
responsabilidades altas para o projecto, tais como clientes, gestores ou lderes de
equipas, que asseguram que apenas as mudanas mais importantes sero feitas.

Desenvolvimento iterativo

Os mtodos geis partilham o objectivo dos mtodos iterativos de criar partes

do software que possam ser lanadas em curtos perodos tempo. Diferem na durao
dos perodos de tempo, sendo que nos mtodos geis o tempo medido em semanas e
nos mtodos iterativos medido em meses. A maioria dos mtodos geis diferem
tambm pois tm em conta estritamente o tempo, ao invs de um objectivo planeado.

Modelo em cascata

O modelo em cascata o mais preditivo de todos, consiste em seguir a

sequncia rgida e planeada de recolher requisitos, analisar, desenhar, codificar e testar.
O progresso medido no cumprimento dos requisitos, planos de testes e revises de
cdigo. O modelo em cascata pode resultar num esforo substancial de integrao no
fim do ciclo, que se estende por um perodo de tempo que pode ir de vrios meses a
vrios anos. O tamanho e a dificuldade deste esforo uma das causas do falhano do
projecto em cascata. Contrariamente, os mtodos geis produzem aplicaes
completamente funcionais (mas a uma pequena percentagem do total) a cada semana.
A ideia obter uma aplicao inacabada mas funcional antes da final, que vai sendo
continuamente desenvolvida.
 Algumas equipas geis usam uma das ideias do modelo em cascata: o repetir
de um ciclo em cada iterao.

Anlise do risco de utilizao de Mtodos geis e Preditivos

Para diminuir o risco na utilizao de mtodos geis e preditivos pode-se verificar

onde os diferentes mtodos se enquadram melhor:

Mtodos geis

- Pouca crtica implementao

- Equipa de desenvolvimento constituda por elementos experientes
- Grandes mudanas nos requisitos
- Equipa de desenvolvimento constituda por poucos elementos
- Cultura que prospera na falta de organizao.

Mtodos preditivos

- Muita crtica implementao

- Equipa de desenvolvimento constituda por elementos inexperientes
- Poucas mudanas nos requisitos
- Equipa de desenvolvimento constituda por muitos elementos
- Cultura que exige ordem e organizao.

Ao analisar o projecto tendo em conta estes enquadramentos pode-se avaliar o

risco de utilizao de mtodos geis ou preditivos.

2.Feature Driven Development

2.1. Agentes/Actores desta metodologia.

No FDD existem vrios papis que os membros da equipa podem assumir. O

mesmo papel pode ser assumido por vrios membros e cada membro pode assumir
vrios papais simultaneamente.
Existem trs tipos de papis: papis principais, papis secundrios e papis
adicionais.
Os papis principais so: Gestor de Projecto, Chefe de Design, Gestor de
Desenvolvimento, Programador Chefe, Dono de Classe, Especialista da rea.

Gestor do Projecto
O gestor do projecto quem trata das questes financeiras e administrativas do
projecto. ele que tem a ltima palavra sobre os objectivos, o pessoal e a
calendarizao do projecto. Cabe-lhe tambm assegurar as condies de trabalho
ptimas, para aumentar o rendimento e evitar as distraces.
 Chefe de Design
O chefe de design responsvel por toda a arquitectura do projecto e d as sesses
de design, onde expe as suas decises s equipas.

Gestor de Desenvolvimento
O gestor de desenvolvimento lidera as actividades de desenvolvimento do cdigo
do dia-a-dia. responsvel por resolver os problemas de recursos ou conflitos entre a
equipa que venham surgindo. um papel bastante ligado aos de gestor do projecto e
pode ser executado pelo mesmo membro.

Programador Chefe
O programador chefe o responsvel por uma equipa pequena e pela diviso e
atribuio de trabalho entre os membros dela. Deve ser um programador experiente
pois cabe-lhe a escolha das features a implementar em cada iterao e as respectivas
classes e mtodos necessrios. Para este efeito deve colaborar com o chefe de design.
Vai ser ele tambm que faz o relatrio da actividade da equipa semanalmente e trata
dos problemas tcnicos e de recursos com os outros programadores chefe.

Dono de Classe
O dono de classe um membro de uma equipa sob o comando de um programador
chefe e est responsvel pela arquitectura, implementao, teste e documentao de
uma determinada classe. Em cada iterao far parte das equipas cujas features
envolvam a sua classe.

Especialista da rea
O especialista da rea algum que conhece o assunto sobre o qual a aplicao
actua. Est envolvido na deciso do preo do programa e ele que assegura que o
sistema seja competente dentro da rea, passando a quem desenvolve o programa os
conhecimentos necessrios. O especialista da rea pode ser um cliente, um analista de
negcio, um patrocinador ou um utilizador.

Os papis secundrios so: Gestor de Actividade, Guru da Linguagem, Engenheiro

de Builds e Administrador de Sistema.

Gestor de Actividade
O gestor de actividade recebe os relatrios de actividade os vrios programadores
chefe e vai mantendo o gestor do projecto informado.

Guru da Linguagem
O guru da linguagem um papel importante quando se trabalho com linguagens
ou tecnologias novas. Ele responsvel por domin-las.

Engenheiro de Builds
O engenheiro de builds o responsvel por criar e manter o processo de build para
as vrias verses incluindo a documentao respectiva.
 Administrador do Sistema
O administrador do sistema configura, gere e resolve problemas nos servidores e
redes usadas.

Os papis adicionais so: Tester, Suporte, Documentador

Tester
O Tester deve experimentar todos os casos de utilizao exaustivamente e
verificar se o sistema slido, resistente a erros e se preenche os requisitos do cliente.

Suporte
O trabalho de suporte consiste em converter a informao para o formato
necessrio a um novo sistema e a novas releases do programa.

Documentador
O documentador cria os manuais tcnicos e de utilizao.

2.2Descrio dos processos

Esta metodologia FDD consiste em cinco processos sequenciais. O uso de

processos tem vrias vantagens:
- O facto de nos FDDs usarem processos simples e bem definidos faz com
que o mover novas utilidades (features) para projectos grandes seja fcil. Pois
como fazer algo simples vrias vezes. No desenvolvimento de processos
complexos, deve-se dividir em N processos simples, o permite que o progresso
do projecto seja mais rpido.
- A integrao de novos elementos nas equipas rpida, pois o facto de os
processos serem simples faz com que seja fcil a compreenso destes por parte
dos novos membros.
- O facto de os processos serem simples, faz com que a equipa esteja sempre
concentrada no trabalho uma vez que esto constantemente a acabar/iniciar um
novo processo. No causa uma monotonia do trabalho.

Como tinha sido referido acima esta metodologia consiste em cinco processos
sequenciais sendo estes:
1. Develop an Overall Model (Trata-se de utilizar os requisitos e
funcionalidades pedidas pelo cliente e fazer o estudo destas de forma a fazer a
estrutura do sistema. Baseia-se no desenho do sistema);
2. Build by Features list (Constri uma lista de features detalhada e
ordenada por ordem hierrquica);
3. Plan By Feature (Trata-se de planear como devem ser
desenvolvidas as features);
4. Design by Feature (Analisa uma feature em particular e estuda-a de
forma a criar-se um detalhado diagrama sequencial, que ser os passos a seguir
para construir uma feature);
 5. Build By Feature (Faz todas as alteraes necessrias para ser
possvel construir uma feature).
Em baixo esta uma descrio detalhada destes processos.

2.2.1.Develop an Overall Model

Este processo inicia-se quando o cliente est pronto para dar incio ao projecto.
Este tem de alguma forma uma lista de requerimentos, que podero estar ou no
anotados. O cliente indica quais os requisitos que quer ver compridos pelo sistema.
Cabe s equipas de desenvolvimento analisar o sistema anterior e verificar se todos os
requisitos foram especificados pelo cliente, sugerir novos requisitos e colocar todas as
questes que possam ainda no ter sido respondidas, ou que tenham sido esquecidas.
O cliente chega com os seus requisitos e apresenta-os ao desenvolvedores. Estes
em conjunto com os especialistas da rea e sobre a liderana de um modelador de
componentes e/ou de objectos experiente (chefe de design), trabalham em conjunto
neste processo.
Os especialistas da rea apresentam um guia inicial e prerio do sistema e do seu
contexto. Que em conjunto com os desenvolvedores criam a estrutura inicial do
sistema, que deve ser seguido desde o incio.
Depois de desenvolvido este esqueleto os especialistas da rea voltam a fazer o
guia inicial, sendo desta vez mais detalhado.
Entretanto sempre que os membros deste processo trabalham em conjunto em
pequenas equipas, ou seja, quando trabalham em reas mais especificas a determinado
grupo, e que a participao de outros membros seria desnecessria, os resultados
desse trabalho so adicionados ao modelo comum, que sofre os respectivos ajustes
para se manter sempre vivel ao longo de todo o processo.
Neste processo necessrio de compreender perfeitamente o que o cliente deseja,
e de o explicar a todo o grupo de trabalho. Para que todos saibam o que tenham de o
fazer e como o devem fazer. Este plano descrito mais detalhadamente nos processos
seguintes.
Para melhor compreender o sistema e para mais facilmente o explicar ao grupo
de trabalho, constri-se um relatrio de requisitos, assim como um diagrama de
classes, preferencialmente ordenado por ordem descendente de importncia, classes,
ligaes, mtodos e os atributos.
As classes e as ligaes so o contedo da estrutura do sistema. Os mtodos
expressam as funcionalidades e so o material para construir a lista de features a
desenvolver.
Tambm so tomadas notas acerca de diferentes modelos que poderiam ser
tomados como alternativas.

2.2.2.Build a Feature List

A equipa de desenvolvimento identifica todas as features, e agrupa-as por ordem

hierrquica. Nesta ordem tomada em conta a prioridade de cada feature, sendo
prioritria uma feature que o cliente pediu ou que se ache que lhe agradar ver feita e
uma feature de que outras dependam. As features definidas com baixa prioridade so
muitas vezes features extra, mas que certamente iriam valorizar o projecto. Estas
podero ser desenvolvidas no futuro.
Ainda neste processo tambm se dividem pequenas equipas especialidades em
cada uma das reas de cada conjunto de features. Os especialistas da rea podero
participar em algumas das sesses referentes a este processo. A diviso das features
feita com base em certos critrios: divide-se as features por reas em que estas se
enquadrem, e de acordo com as classes envolvidas.
Se estes conjuntos de features demorarem mais de duas semanas a serem
desenvolvidos este conjunto de features ou uma feature individual, so divididos em
pequenos passos. Isto para de duas em duas semanas se poder analisar o projecto e ver
os progressos.
Chama-se de feature (funcionalidade) uma aco com o seguinte formato:
<action> the <result><by|for|of|to> a(n)<objecto>
Conjunto de features: - <action><-ing>a(n)<object>
Um maior conjunto de features: <object> management
Nota: Quando um objecto uma pessoa, lugar, ou coisa, inclui-se papeis, datas,
ou intervalos de tempo, ou catalogo entrada/descrio.

Em resumo:
Neste processo, entra a provisria lista de features desenvolvidas no processo
anterior e sai uma detalhada lista de features agrupada em maiores conjuntos de
features e conjuntos de features. Lista esta que ter de ser revista e aprovada pelo
desenvolvedor assim como pelo arquitecto chefe.

2.2.3.Plan by feature

Usando a lista detalhada e ordenada por prioridade das features, criada no

processo anterior, o chefe do projecto, o chefe de design e o chefe dos programadores
estabelecem a estrutura para o mtodo Desenho por Funcionalidade, Construo por
Funcionalidade/Design by Feature, Build by Feature.
Isto , este grupo de planeamento, determinam a sequncia, e o conjunto inicial
de datas para dar como terminada cada conjunto de features e do mais importante
conjunto de features.
Este planeamento repartido, atribuindo de acordo com o desenvolvimento
sequencial e o peso de cada feature como guia e associa as classes do sistema aos
responsveis pelas classes.
A cada chefe de programao fornecida a lista de features a desenvolver.
Como temos vindo a observar esta abordagem construo de sistemas um
planeamento top-down, em que os desenvolvedores tm a oportunidade de aceder aos
planos.
H que ter em conta que cada feature a desenvolver no devera demorar mais de
duas semanas. E que nesta atribuio de trabalhos certos desenvolvedores podero
estar de desacordo com este mtodo, pois certamente prefeririam ter uma data para
entregar todo o trabalho, mas esta uma metodologia gil e no se baseia nesse
mtodo. que portanto convence-los a apresentar os resultados assim como eles
esto planeados.
Em contraste, outros desenvolvedores podero aceitar muito bem isto, pois esto
desejosos de apresentar trabalho, mas no avaliam de uma forma cuidada o trabalho
que tero pela frente. Ou seja podero atrasar-se com o desenvolvimento de
determinada feature. que ter em ateno de no processo anterior ter sido dividido
todas as features que daro mais complexas em features mais simples. Isto para de
duas em duas semanas ser possvel ter sempre contedo novo, de forma a mostrar o
nosso trabalho.
No final deste processo deveremos ter um plano j revisto e aprovado pelo
desenvolvedor chefe e pelo chefe de design. Deveremos ter tambm j uma previso
de quando o projecto estar terminado. Assim como uma data em que os conjuntos de
features devero estar completas. O mesmo para cada classe.
Existe um truque que se pensa que acelera o desenvolvimento das features. Este
truque consiste em criar um grupo denominado Future Feature Boar(FFB). Este
truque faz com que os desenvolvedores sejam como que os bons da fita, enquanto
que os FFB so os maus da fita.
O truque consiste em incentivar os bons da fita, de maneira a que a sua
motivao esteja alta e desta maneira desenvolvam o seu trabalho de uma maneira
mais rpida.

2.2.4.Design by Feature (DBF)

Este processo ira ser repetido tantas vezes quantas o nmero de features a
desenvolver. Isto porque necessrio fazer o desenho da estrutura para cada feature.
Iremos analisar este processo com algum cuidado, isto porque apesar de o que ele
faz ser fcil de entender, este tem de analisar vrios documentos construdos noutros
processos, assim como trocar informao com outros AGENTES.
Comecemos ento a analisar este processo, o programador chefe comea por
identificar as classes que esto envolvidas nestas features. E contacta os respectivos
responsveis dessas classes, estes escrevem/actualizam a classe e os prottipos dos
mtodos que esta contm, actualizando o diagrama sequencial. Estes responsveis
incluem tipo de parmetros, tipo de valores retornados, excepes e mensagens
enviadas.
Dependendo da complexidade da feature o programador chefe poder consultar
os especialistas da rea para que estes lhe dem uma viso acerca da rea de domnio
que esta feature engloba, esta informao ser includa na construo do diagrama,
mas no far necessariamente parte da implementao. A equipa de programadores
poder tambm consultar documentos da lista de features ou de outro documento, de
forma a extrair informao detalhada acerca desta feature.
Depois de consultar todos os documentos que se ache necessrio para a
compreenso da feature, o programador consulta o diagrama sequencial construdo
num processo anterior, e com base em toda a informao recolhida este constri um
diagrama de sequncia detalhado e formal para esta feature. Este diagrama
adicionado ao projecto modelo.
 A equipa de programadores toma nota de todas as alternativas, decises e notas
que achem relevantes.
Antes de dar por terminado este processo necessrio garantir que o
programador chefe assim como arquitecto chefe revejam e aprovem:
- O diagrama sequencial e o de classes actualizado;
- As classes e os mtodos actualizados;
- As notas de considerao da equipa de programadores;
- Os documentos de referncias de features, caso haja necessidade.
Caso todos estes documentos sejam aprovados passamos ao ltimo processo
Build By Feature.

2.2.5.Build by Feature (BBF)

Tal como no processo anterior, este processo ira ser repetido para cada feature,
pois todas as features tero de ser construdas.
Este processo comea por estudar a informao proveniente do processo anterior
e seguidamente comea a construo da feature. Nomeadamente comeam os
responsveis pelas classes associadas a esta feature a construir os mtodos que esta
feature ira necessitar. Estes responsveis iro tambm estender os testes de uso desta
classe assim como os testes unitrios da mesma.
A equipa de desenvolvimento desta feature inspecciona o cdigo, antes ou depois
de estruturados os testes unitrios.
Quando o cdigo implementado com sucesso e inspeccionado, o responsvel da
classe verifica a classe assim como as configuraes de manuteno do sistema.
Quando todas as classes referentes a esta feature forem verificadas, o programador
chefe indica que o cdigo para desenvolver esta feature esta disponivel. Esta alterao
registada na lista de features.
Para dar este processo como terminado o programador chefe devera rever e
aprovar:
- A implementao, inspeco e teste dos mtodos;
- Os testes unitrios para cada mtodo;
- A verificao das classes por parte dos seus responsveis;
- A promoo das features;
- A actualizao da lista de features realizada por si prprio.

2.3.Ferramentas de aplicaes

A utilizao do FDD num projecto, torna recomendvel o uso de uma ferramenta

que permita organizar todas as implementaes que se deseja criar sendo possvel a
incluso e discriminao de todas as componentes necessrias para as novas
funcionalidades.
Uma ferramenta deste tipo deve ter alguns requisitos necessrios para facilitar a
utilizao de FDD.
 Como j foi referido, necessrio que este apresente uma discriminao de todas
as features a ser implementadas como tambm das suas respectivas componentes,
encontrando-se estas devidamente documentadas, no sentido de facilitar a equipa do
projecto, como tambm por equipas futuras, aps estas features se encontrem
concludas.
Como tal, proporciona uma viso da arquitectura geral do programa, o que
permite a tomada de conscincia da estrutura do futuro programa, permitindo a no
ocorrncia da repetio de features semelhantes, ou mesmo a criao de
componentes em duplicado. A viso da arquitectura do programa tambm permite que
as novas implementaes se possam inserir em packages j existentes, ou mesmo
em novos packages.
Estas ferramentas tambm devem incorporar a indicao do tempo necessrio
para a sua implementao, como tambm da equipa ou as pessoas responsveis pela
sua implementao.
Esta viso geral, permite que cada grupo possa opinar sobre a implementao das
novas features sugerindo outras solues, ou mesmo o refinamento das mesmas.
Nesta fase, torna-se possvel a apresentao ao cliente do futuro programa que
permita concordar, ou discordar da sua implementao, como tambm do seu tempo
necessrio e obviamente dos custos a si associados.
A utilizao destas ferramentas permite maximizar as vantagens do FDD,
essencialmente, no sentido de evitar custos extra, como tambm de tempo gasto em
criao de componentes desnecessrias.
Este tipo de ferramentas normalmente utilizado nas primeiras trs fases da
utilizao do FDD, permitindo a sua planificao.
Outras funcionalidades que se podem incluir neste tipo de ferramentas a
descrio de todos os testes necessrios para testar cada feature, como tambm a
sua durao e o seu resultado. Isto permite, que quando se interligar as
implementaes, se possa obter os mesmos resultados que se obtinham quando as
features se encontravam desligadas entre si. A implementao de um sistema de
prioridades, que permite maximizar o tempo num projecto, deixando para trs as
implementaes menos importantes.
Outra funcionalidade, possvel um grfico de decorrncia de tempo, entre a
percentagem de trabalho previsto com a percentagem de trabalho realizado,
permitindo a verificao do trabalho, se encontrar dentro dos prazos previstos, ou se
por outro lado necessrio a reverificao do tempo necessrio para o
desenvolvimento da nova implementao.
Uma funcionalidade pouco usual, mas tambm til, a possibilidade de, a dado
momento, ser possvel obter o nmero de features j criadas, permitindo a obteno
de indicadores de performance no sentido de avaliar os grupos ou as pessoas, da
equipa do projecto, permitindo a sua futura reorganizao para futuros projectos,
maximizando os recursos humanos.
Este tipo de ferramentas apresenta um seno. A sua mxima utilizao, na
planificao de novos projectos, torna-se eficaz, quando todas as implementaes,
desde o incio do projecto, se encontram descritas, no fazendo parte do actual
desenvolvimento.
O nome de algumas ferramentas que podem ser utilizadas o FDD Manager,
MagicDraw, OptimalJ, Poseidon, Rose, Simply Objects, Together, Enterprise
Architect, entre outras. Algumas destas ferramentas so bastantes simples, outras mais
complicadas, sendo tambm open source, ou mesmo de utilizao paga.

2.4.Comparao entre FDD e XP

Aps um breve estudo das metodologias geis mais conhecidas, verificamos que
a que se assemelhava a FDD era eXtreme Programming (XP), sendo esta a mais
interessante de comparar. Vamos ento apresentar as semelhanas entre FDD e XP.

Tanto FDD como XP, foram desenhadas de modo a que as equipas possam
mostrar resultados mais rapidamente sem comprometer a qualidade. So processos
altamente iterativos e orientados a resultados. So ainda metodologias que acabam
com a separao entre os analistas, os desenhadores e implementadores. Estes novos
processos em conjunto com novas ferramentas, vo permitir que a analise, concepo,
cdigo, teste e desenvolvimento sejam feitos em simultneo. Quais so ento as
diferenas entre FDD e XP?

Tamanho das Equipas

O XP foi desenhado para projectos com equipas de dois a dez programadores.
FDD foi inicialmente usado com equipas de 16 a 20 colaboradores com
diferentes habilitaes, ambientes culturais e experincia. A FDD foi desenhada para
ser aplicvel a equipas bastante maiores, sendo esse tamanho limitado pelo nmero de
Programadores Chefe existentes.

Modelo

Em FDD, quando os developers tomam conhecimento dos requisitos, comeam a

formar uma imagem mental do sistema, assumindo e estimando partindo dessa base.
Desenvolvendo um objecto modelo domnio global, fora essas assumpes a serem
expostas, de modo a que os erros sejam corrigidos e uma melhor compreenso
comum seja formada
XP usa a analogia de conduzir um carro. Conduzir requer uma continuidade de
pequenos ajustes de percurso. No se pode simplesmente orientar o carro na direco
correcta e carregar no acelerador. Um objecto modelo de domnio o mapa que nos
guia no percurso. Pode prevenir-nos de andarmos em crculos. O objecto modelo
domnio d-nos uma forma sobre a qual se vo adicionar funes, funcionalidade por
funcionalidade.
 Cdigo colectivo, ou classe colectiva.

XP promove que o cdigo seja colectivo. Cada developer pode adicionar ou

alterar qualquer parte do cdigo medida que ai sendo necessrio. Mas geralmente
este colectivismo degenera num cdigo sem proprietrios. Para projectos pequenos
resulta bastantes vezes, mas para projectos de maior dimenso raramente funciona.
XP garante 3 benefcios derivados do colectivismo do cdigo.

1. No necessrio esperar por algum para fazer a alterao

necessria ao cdigo.
2. Cdigo demasiado complexo eliminado, pois se algum que o
encontre, vai tentar simplifica-lo. Posto isto, os programadores deixam de criar cdigo
cuja complexidade no consigam justificar.
3. Cdigo colectivo espalha o conhecimento do sistema por toda a
equipa, reduzindo o risco caso um membro critico da equipa saia.

Em FDD, tambm se resolveu estes problemas, enquanto se manteve as

vantagens do cdigo individual.

1. Por definio, todos os donos de classes que necessitam de updates

para o desenvolvimento de uma determinada feature, so membros da equipa de
features. Por outras palavras, a equipa de features controla todo o cdigo que
necessita ser mudado para uma determinada feature, o que minimiza o tempo de
espera para que algum altere esse cdigo.

2. Em FDD todo o desenho de baixo nvel feito dentro das equipas

de features. O problema do desenvolvimento por surpresa, quando um developer
entrega cdigo do que foi acordado, detectado nas inspeco de cdigo pela equipa
de features. Cdigo demasiado complexo tambm detectado da mesma maneira,
antes de entrar no sistema.

3. Apesar dos donos de classes trabalharem apenas nas classes que

lhes pertencem, donos de classes prximas, trabalham geralmente na mesma equipa
de features. Todos tm conhecimento das classes que lhes esto prximas. O
conhecimento separado em blocos bem definidos e estruturados, e no espalhado ao
calhas.

Inspeco e Programao em pares

Inspeces ao desenho e ao cdigo, quando bem feitas so mais eficazes do que a

fase de teste. Outras vantagens so:

1. Os developers aprendem tcnicas uns com os outros, e o cdigo tem

tendncia a seguir um standard.
2. XP usa programao em pares, para garantir um nvel contnuo de
desenho e inspeco de cdigo.
 Todo o desenho de baixo nvel, assim como o cdigo feito em pares. Isto
revela-se bastante mais eficaz do que um nico developer criar cdigo sem nenhum
tipo de inspeco.
Em FDD promove-se as inspeces pela equipa de features. O nvel de
formalidade deixado ao cargo do chefe de programao. Este processo mais
demorado, mas tem algumas vantagens em relao programao em pares.
1. O cdigo inspeccionado por outra pessoa, que detecta falsos
pressupostos feitos pelo programador.
2. Um programador chefe est presente para garantir que as tcnicas
usadas so boas tcnicas.
3. D um certo tempo de descanso ao developer, enquanto o cdigo
est as ser inspeccionado.

No h razo para os elementos de uma equipa de features no se organizarem

em pares. comum ver-se dois elementos a trabalhar juntos, quando tal vantajoso.
Uma vantagem das equipas de features que uma feature s est completa quando a
equipa acaba o trabalho. do interesse dos seus elemento ajudarem-se mutuamente.

Testes

Em FDD o teste das unidades garantido como uma parte da fase Build by
Feature. No esto definidos os mecanismos ou os nveis de formalidade para o teste
das unidades. Deixa-se ao cargo do programador chefe definir o que apropriado.
aceitvel usar tcnicas de teste de unidades de XP em FDD. Quando novas
builds so criadas regularmente ou at continuamente, faz sentido haver um maior
nmero de testes que possam ser usados. Em FDD, no se especificou isto, visto que a
tecnologia e os recursos diferem muito de projecto para projecto. Em muitos casos
muito difcil criar um grupo isolado de testes independentes que possam ser corridos
num intervalo de tempo razovel.

Referncias

Artigos sobre metodologias geis e outros mais especficos sobre FDDs, nomeadamente:
http://www.pcoad.com/download/bookpdfs/jmcuch06.pdf
http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf
http://www.vtt.fi/ele/uutta/electra/agile.pdf
http://www.nebulon.com/articles/fdd/download/fddoverview.pdf
E ainda a consulta a pgina respectiva a esta metodologia:
http://www.featuredrivendevelopment.com/