FDD: Feature Driven Development

Desarrollo Basado en
Funcionalidades

Sarah Gutirrez
Hernn Zapata
Juan Pablo Arias
Cristian Zambrano
 FDD
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
monitoriar.
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:
Desarrollode un modelo global.
Construccin de una lista de funcionalidades.
Planeacin por funcionalidad.
Diseo por funcionalidad.
Construccin por funcionalidad.
Proceso
 Descripcin del Proceso(1)
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.
Se divide 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(2)
Construccin de una lista de funcionalidades:
Una funcionalidad es un tem til a los ojos del
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(3)

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(4)
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.

Miremos una representacin grfica del proceso

iterativo que involuclan estas dos ltimas fases:
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:
* Lider 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,
por ejemplo, un lenguaje especfico de programacin o
tecnologa.
* Es muy importante cuando se trabaja una nueva
tecnologa.
Build Engineer / 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 sitios web 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
Puesto que todos los procesos se
centran en la produccin de
software es deseable una
comparacin, no en su conjunto,
sino segn los medios que
emplean y sus resultados.
Realizamos una comparacin
entre FDD, RUP y XP.
 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 flacos:
1. FDD presenta su taln de Aquiles en la necesidad de
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.
2. Para el desarrollo de software por medio de equipos
pequeos (hasta unas diez personas) es RUP
definitivamente muy grande y practicamente
inalcanzable. Se deben repartir 31 roles y generar ms
de 100 artefactos distintos.
3. XP es un proceso muy orientado a la implementacin.
Lo que es muy poco deseable en XP es el hecho de
evitar cualquier tipo de documentacin fuera del
cdigo fuente (UML juega un papel prcticamente
nulo, por ejemplo).
 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 dejar satisfechos a 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.
 En conclusin FDD:
Ayuda al equipo a producir resultados peridicos y
tangibles.
Esta metodologa utiliza pequeos bloques llamados
features, los cuales contienen la funcionalidad del
sistema.
Organiza los bloques que estn relacionados entre
s, en una lista llamada feature set.
Hace nfasis en la obtencin de resultados cada
dos semanas.
Asegura en gran parte la calidad del software
entregado.
Es adaptativo, pues permite realizar cambios de
ltimo momento debido a nuevos requerimientos y
a las necesidades del negocio.