DESARROLLO GUIADO POR CARACTERÍSTICAS

DESARROLLO GUIADO
POR CARACTERÍSTICAS
FDD
FEATURE DRIVEN DEVELOPMENT
FDD es un proceso diseñado por Peter Coad, Erich
Lefebvre y Jeff De Luca y se puede considerar
intermedio entre RUP y XP, aunque al seguir siendo
un proceso ligero se parece mas a XP.
No hace énfasis en la obtención de requerimientos
sino en como se realizan las fases de diseño y
construcción.
FDD está pensado para proyectos con tiempo de
desarrollo relativamente cortos (-1año).
Se basa en un proceso iterativo con iteraciones cortas
(-2 semanas) que producen un software funcional que
el cliente y la empresa pueden ver y monitorear.
Las iteraciones de deciden en base a características o
funcionalidades; que son pequeñas partes del software
con gran significado para el cliente y no
necesariamente para nosotros.
Ejm: En un sistema de ventas; para el cliente si es
importante enviar un pedido por e-mail, pero la
construcción de un sistema de persistencia no tiene
significado para el cliente.
Se preocupa por la calidad, lo que implica un
monitoreo constante del proyecto
Ayuda a contrarrestar situaciones como el exceso de
presupuesto, fallas en el programa o el hecho de
entregar menos de lo deseado.
El proceso consiste en 5 pasos secuenciales durante
los cuales se diseña y se construye el sistema:
1.
2.
3.
4.
5.
Desarrollo de un modelo general
Construcción de una lista de funcionalidades
Planeación por funcionalidad
Diseño por funcionalidad
Construcción por funcionalidad.
EL PROCESO
1. DESARROLLO DE UN MODELO GLOBAL
Al comienzo del desarrollo los expertos del dominio
están al tanto e la visión, contexto y 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.
2. CONSTRUCCIÓN DE UNA LISTA DE
FUNCIONALIDADES
Una funcionalidad des 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 desarrolladores y es evaluada por
el cliente.
Se divide la lista en subconjuntos según la afinidad y la
dependencia de las funcionalidades.
La lista es finalmente revisada por los usuarios y los
responsables para su validación y aprobación.
3. PLANEACIÓN 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.
4-5. DISEÑO Y CONSTRUCCIÓN POR
FUNCIONALIDADES
Se selecciona un conjunto de funcionalidades de la
lista
Se procede a diseñar y construir la funcionalidad
mediante un proceso iterativo.
Una iteración de máximo unas dos semanas, incluye
inspección de diseño, codificación, pruebas unitarias,
integración e inspección de código.
DEBILIDADES
La debilidad de FDD está en la necesidad de tener en
el equipo miembros con experiencia que marquen el
camino a seguir desde el principio, con la elaboración
del modelo global, puesto que no es tan ágil como
podría serlo XP.
COMPARACIONES
Tamaño de los equipos: RUP está pensado para
proyectos y equipos grandes en cuanto a tamaño y
duración. FDD y XP en proyectos cortos y equipos mas
pequeños.
Obtención de requisitos: RUO y XP crean como base
UseCase y UserStories, por lo contrario FDD no define
explícitamente esa parte del proyecto sobre la
adquisición de requisitos.
Evaluación del estado del proyecto: FDD es
posiblemente el proceso mas adecuado para definir
métricas que definan el estado del proyecto debido a
las pequeñas divisiones en donde su seguimiento
Evaluación del estado del proyecto: FDD es
posiblemente el proceso mas adecuado para definir
métricas que definan el estado del proyecto debido a
las pequeñas divisiones en donde su seguimiento.
RUP es tan grande y complejo que requiere mucho
tiempo manejar el volumen de la información.
Carga de trabajo: XP es un proceso ligero, debido a
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 documentación, en la que no son
deseables todos esos cambios volátiles. FDD es un
proceso intermedio, en el sentido que genera mas
documentación que XP pero menos que RUP.