FDD

Feature Driven Development (Desarrollo Basado en Funcionalidades) es un proceso gil

para el desarrollo de sistemas. Fue diseado por Peter Coad, Eric Lefevre ! "eff
DeLuca. En FDD no se #ace $nfasis en la otenci%n de los re&uerimientos sino en como
se reali'an las fases de diseo ! construcci%n preocupndose por la calidad, por lo &ue
inclu!e un monitoreo constante del pro!ecto.
FDD (e asa en un proceso iterativo, con iteraciones cortas &ue producen un soft)are
funcional &ue el cliente ! la direcci%n de la empresa pueden ver ! monitorear. Define
claramente entregas tangiles ! formas de evaluaci%n del progreso del pro!ecto.
Etapas
El proceso FDD consiste de cinco pasos secu$nciales durante los cuales se disea ! se
constru!e el sistema*
Desarrollo de un modelo gloal.
Construcci%n de una lista de funcionalidades.
Planeaci%n por funcionalidad.
Diseo por funcionalidad.
Construcci%n por funcionalidad.
#ttp*++))).step,-..com+(oft)areProcess+FeatureDrivenDevelopment+images+fdd./pg
Desarrollo de un modelo global
Como entrada a este proceso el cliente dee estar listo para comen'ar con la
construcci%n del sistema. 0dems se dee tener una lista de re&uerimientos especificada
en alguna forma, #ec#a por los e1pertos del dominio.
Cuando comien'a el proceso, los e1pertos del dominio estn al tanto de la visi%n, el
conte1to ! los re&uerimientos del sistema a construir. (e divide el dominio gloal en
reas &ue son anali'adas detalladamente ! los desarrolladores constru!en un diagrama
de clases o de o/etos por cada rea. 0 su ve' se constru!e un modelo gloal del
sistema.
Esta etapa termina con el desarrollo del diagrama de clases gloal del sistema, una lista
de funcionalidades o caracter2sticas, ! un modelo gloal del sistema a construir.
Construccin de una lista de funcionalidades
3na funcionalidad se define como un 2tem 4til a los o/os del cliente.
Basado en el modelo gloal otenido en la etapa anterior, ! en la lista de
funcionalidades informal, se procede a elaora una lista de funcionalidades &ue resuma
la funcionalidad general del sistema. Dic#a lista dee ser elaorada por los
desarrolladores ! es evaluada por el cliente.
(e divide la lista en sucon/untos seg4n la afinidad ! la dependencia de las
funcionalidades. Luego la lista es finalmente revisada por los usuarios ! los
responsales para su validaci%n ! aproaci%n.
Planeacin por funcionalidad
En este punto se procede a ordenar los con/untos de funcionalidades conforme a su
prioridad ! dependencia, ! se asigna a los programadores /efes.
5ami$n se dee generar un cronograma donde se especifi&ue la duraci%n del diseo !
la construcci%n de cada una de las caracter2sticas.
Diseo por funcionalidades y Construccin por funcionalidades
En esta etapa se selecciona un con/unto de funcionalidades de la lista ! se procede a
disear ! construir la funcionalidad mediante un proceso iterativo.
3na iteraci%n puede tomar de unos pocos d2as a un m1imo de dos semanas. El proceso
iterativo inclu!e inspecci%n de diseo, codificaci%n, prueas unitarias, integraci%n e
inspecci%n de c%digo.
Para cada una de estas iteraciones en la fase de diseo se dee generar*
Diagrama de secuencia detallado
Diagrama de clases actuali'ado
Descripci%n de clases ! m$todos
6otas adicionales
En la fase de construcci%n*
7mplementacion e inspeccion de metodos
5esting unitarios para cada metodo
C#ec8 in de las clases
9ain Build del sistema ! testing de integraci%n.
Roles
:erente de pro!ecto
0r&uitecto en /efe
:erente de desarrollo
Programador en "efe
E1perto del dominio
:erente del dominio
0dministrador de release
Language :uru
7ngeniero de construcci%n
0dministrador del sistema
5ester
Deplo!er
Escritor 5$cnico
Diferencias entre RUP, FDD, y XP
5amao de los e&uipos*
;3P esta pensado para pro!ectos ! e&uipos grandes, en cuanto a tamao ! duraci%n.
FDD ! <P se implementan me/or para pro!ectos cortos ! e&uipos ms pe&ueos, siendo
&ui's FDD ms escalale &ue <P.
=tenci%n de re&uisitos*
;3P ! <P crean como ase 3seCases ! 3ser(tories, por lo contrario FDD no define
e1pl2citamente esa parte del pro!ecto sore la ad&uisici%n de re&uisitos.
Evaluaci%n del estado del pro!ecto*
FDD es posilemente el proceso ms adecuado para definir m$tricas &ue definan el
estado del pro!ecto, puesto &ue al dividirlos en unidades pe&ueas es astante sencillo
#acer un seguimiento de las mismas. <P tami$n define esos componentes pe&ueos.
;3P por su parte, es tan grande ! comple/o en este sentido como en el resto, por lo &ue
mane/ar el volumen de informaci%n &ue puede generar re&uiere muc#o tiempo.
Carga de traa/o*
<P es un proceso ligero, esto es, &ue los creadores del proceso #an tenido cuidado de no
poner demasiadas tareas organi'ativas sore los desarrolladores. ;3P es un proceso
pesado, asado muc#o en la documentaci%n, en la &ue no son deseales todos esos
camios voltiles. FDD es por su parte un proceso intermedio, en el sentido de &ue
genera ms documentaci%n &ue <P pero menos &ue ;3P.
;elaci%n con el cliente*
Con ;3P se presentarn al cliente los artefactos del final de una fase, en contrapartida,
la aseguraci%n de la calidad en <P ! FDD no se asa en formalismos en la
documentaci%n, si no en controles propios ! una comunicaci%n fluida con el cliente.
Conocimiento sore la ar&uitectura*
En ;3P se intentar reducir la comple/idad del soft)are a producir a trav$s de una
planificaci%n intensiva. En <P se conseguir a trav$s de la programaci%n a pares &ue !a
en la creaci%n del c%digo se puedan evitar errores ! malos diseos. En FDD sin emargo
se usan las sesiones de traa/o con/untas en fase de diseo para conseguir una
ar&uitectura sencilla ! sin errores.
Puntos flacos*
FDD presenta su tal%n de 0&uiles en la necesidad de tener en el e&uipo miemros con
e1periencia &ue mar&uen el camino a seguir desde el principio, con la elaoraci%n del
modelo gloal, puesto &ue no es tan gil como podr2a serlo <P.
Para el desarrollo de soft)are por medio de e&uipos pe&ueos (#asta unas die'
personas) es ;3P definitivamente mu! grande ! prcticamente inalcan'ale. (e deen
repartir >- roles ! generar ms de -.. artefactos distintos.
<P es un proceso mu! orientado a la implementaci%n. Lo &ue es mu! poco deseale en
<P es el #ec#o de evitar cual&uier tipo de documentaci%n fuera del c%digo fuente (39L
/uega un papel prcticamente nulo, por e/emplo).
#ttp*++))).featuredrivendevelopment.com+
#ttp*++)))."ustin0ngel.6et+files+FeatureDrivenDevelopment.ppt
#ttp*++pisis.unalmed.edu.co+cursos+material+>..?@AB+-+PresentacionFDD.ppt