Feature Driven

Development
FDD
Desarrollo Basado en
Funcionalidades
Es un proceso gil para el desarrollo de
sistemas.
Fue diseado por Peter Coad, Eric Lefebvre y
Jeff DeLuca.
No hace nfasis en la obtencin de los
requerimientos sino en como se realizan las
fases de diseo y construccin.
Se preocupa por la calidad, por lo que incluye
un monitoreo constante del proyecto.
FDD

Ayuda a contrarrestar situaciones como el

exceso en el presupuesto, fallas en el
programa o el hecho de entregar menos
de lo deseado.
Propone tener etapas de cierre cada dos
semanas.
Se obtienen resultado peridicos y
tangibles.
FDD

Se basa en un proceso iterativo con

iteraciones cortas que producen un
software funcional que el cliente y la
direccin de la empresa pueden ver y
monitorear.
Define claramente entregas tangibles y
formas de evaluacin del progreso del
proyecto.
Proceso

El proceso consiste de cinco pasos

secunciales durante los cuales se disea y
se construye el sistema:
Desarrollo de un modelo global.
Construccin de una lista de
funcionalidades.
Planeacin por funcionalidad.
Diseo por funcionalidad.
Construccin por funcionalidad.
Proceso
Descripcin del Proceso

Desarrollo de un modelo global:

Cuando comienza el desarrollo, los expertos del
dominio estn al tanto de la visin, el contexto y
los requerimientos del sistema a construir.
Sedivide el dominio global en reas que son
analizadas detalladamente.
Los desarrolladores construyen un diagrama de
clases o de objetos por cada rea.
Se construye un modelo global del sistema.
 Descripcin del Proceso
Construccin de una lista de
funcionalidades:
Una funcionalidad es un tem que genera valor
al cliente.
Se elabora una lista de funcionalidades que resuma la funcionalidad general del
sistema.
La lista es elaborada por los desarrolladores y es evaluada por el cliente.
Se divide la lista en subconjuntos segn la afinidad y la dependencia de las
funcionalidades.
La lista es finalmente revisada por los usuarios y los responsables para su
validacin y aprobacin.
Descripcin del Proceso

Planeacin por funcionalidad:

En este punto se procede a ordenar
los conjuntos de funcionalidades
conforme a su prioridad y
dependencia, y se asigna a los
programadores jefes.
Descripcin del Proceso

Diseo por funcionalidades y Construccin por

funcionalidades:
Se selecciona un conjunto de
funcionalidades de la lista.
Se procede a disear y construir la
funcionalidad mediante un proceso
iterativo.
Una iteracin puede tomar de unos
pocos das a un mximo de dos semanas.
El proceso iterativo incluye inspeccin de
diseo, codificacin, pruebas unitarias,
integracin e inspeccin de cdigo.
Roles y
Responsabilidades
Categoras

Key Roles / Roles claves

Supporting Roles / Roles de soporte

Additional Roles / Roles adicionales

Key Roles / Roles claves
Project Manager / Director del Proyecto:
* Lder administrativo y financiero del proyecto.
* Protege al equipo de situaciones externas.
Chief Architect / Arquitecto jefe:
* Diseo global del sistema.
* Ejecucin de todas las etapas.
Development Manager / Director de desarrollo
* Lleva diariamente las actividades de desarrollo.
 * Resuelve conflictos en el equipo.
* Resuelve problemas referentes a recursos.
Chief Programmer / Programador Jefe
* Analiza los requerimientos.
* Disea el proyecto.
* Selecciona las funcionalidades a desarrollar de la
ultima fase del FDD.
Class Owner / Propietario de clases
* Responsable del desarrollo de las clases que se le
asignaron como propias.
* Participa en la decisin de que clase ser incluida en
la lista de funcionalidades de la prxima iteracin.
 Expertos de dominio

* Puede ser un usuario, un cliente, analista o una

mezcla de estos.
* Poseen el conocimiento de los requerimientos del
sistema.
* Pasa el conocimiento a los desarrolladores para que
se asegure la entrega de un sistema completo.
Supporting roles / Roles de
soporte
Domain Manager
* Lidera al grupo de expertos del dominio.
* Resuelve sus diferencias de opinin concernientes a
los requerimientos del sistema.
Release Manager
* Controla el avance del proceso mediante la revisin
de los reportes del Chief Programmer.
* Reporta resultados obtenidos semanalmente al
gerente, al cliente donde incluye el porcentaje de
avance de cada feature.
 Language Lawyer / Guru del Lenguaje
* Responsable de poseer un vasto conocimiento
en un lenguaje especfico de programacin o
tecnologa.
* Es muy importante cuando se trabaja una
nueva tecnologa.
BuildEngineer / Ingeniero de
construccin
* Responsable de preparar, mantener y correr el
proceso de construccin.
* Realiza el mantenimiento de las versiones y la
publicacin de la documentacin.
 Toolsmith / Herramentista
* Rol para la construccin de herramientas
especficas para el desarrollo, conversin de
datos y testeo.
* Puede trabajar en la preparacin y
mantenimiento tanto de bases de datos o webs
destinados al proyecto.
System Administrator / Administrador
del sistema
* Configura, administra y repara los servidores,
estaciones de trabajo y equipos de desarrollo y
testeo utilizados por el equipo.
Additional roles / Roles
adicionales
Tester
* Verifica que el sistema recin creado cumpla con los requerimientos del cliente.
* Puede llegar a ser una persona independiente del equipo del proyecto.
Deployer
* Es el encargado de convertir la informacin existente requerida por el nuevo
sistema.
* Participa en el lanzamiento de los nuevos productos.
Technical Writer / Escritores de documentos tecnicos
* Prepara la documentacin para los usuarios, que pueden formar parte o no del
equipo del proyecto.
Comparacin
 Tamao de los equipos: RUP esta pensado para
proyectos y equipos grandes, en cuanto a tamao
y duracin. FDD y XP se implementan mejor para
proyectos cortos y equipos ms pequeos, siendo
quizs FDD ms escalable que XP.
Obtencin de requisitos: RUP y XP crean como
base UseCases y UserStories, por lo contrario FDD
no define explcitamente esa parte del proyecto
sobre la adquisicin de requisitos.
Evaluacin del estado del proyecto: FDD es
posiblemente el proceso ms adecuado para
definir mtricas que definan el estado del
proyecto, puesto que al dividirlos en unidades
pequeas es bastante sencillo hacer un
seguimiento de las mismas.
XP tambin define esos componentes pequeos. RUP
por su parte, es tan grande y complejo en este
sentido como en el resto, por lo que manejar el
volumen de informacin que puede generar requiere
mucho tiempo.
Carga de trabajo: XP es un proceso ligero, esto
es, que los creadores del proceso han tenido cuidado
de no poner demasiadas tareas organizativas sobre
los desarrolladores. RUP es un proceso pesado,
basado mucho en la documentacin, en la que no
son deseables todos esos cambios voltiles. FDD es
por su parte un proceso intermedio, en el sentido de
que genera ms documentacin que XP pero menos
que RUP.
 Relacin con el cliente:Con RUP se presentarn
al cliente los artefactos del final de una fase, en
contrapartida, la aseguracin de la calidad en XP
y FDD no se basa en formalismos en la
documentacin, si no en controles propios y una
comunicacin fluida con el cliente.
Conocimiento sobre la arquitectura: En RUP se
intentar reducir la complejidad del software a
producir a travs de una planificacin intensiva .
En XP se conseguir a travs de la programacin a
pares que ya en la creacin del cdigo se puedan
evitar errores y malos diseos. En FDD sin
embargo se usan las sesiones de trabajo
conjuntas en fase de diseo para conseguir una
arquitectura sencilla y sin errores
 Puntos dbiles:
1. FDD presenta requiere tener en el equipo
miembros con experiencia que marquen el
camino a seguir desde el principio, con la
elaboracin del modelo global, puesto que no
es tan gil como podra serlo XP.
Conclusiones

FDD, es una metodologa de desarrollo gil, que

disminuye el riesgo de los proyectos, pues gracias
a sus entregas tangibles y a el constante
monitoreo de su calidad, se asegura el firme
avance del mismo.
FDD, permite cumplir con las expectativas y
requerimientos de los desarrolladores, gerentes y
clientes sin afectar el proyecto. Esto gracias a un
buen manejo de las actividades, a la disminucin
del riesgo del proyecto y al aseguramiento de la
calidad del mismo, respectivamente.