Metodologa FDD

Metodologa FDD (Feature

Driven Development). Es Metodologa FDD
una metodologa gil para el
desarrollo de sistemas,
basado en Parte de la familia Metodologa gil de Desarrollo de
la calidad del software, que
incluye un monitoreo Software
constante del proyecto.
FDD fue desarrollado por
Jeff De Luca y Peter Coad a
mediados de los aos 90.
Esta metodologa se enfoca
en iteraciones cortas que
permite entregas tangibles
del producto en corto
Desarrollo basado en funcionalidades (FDD)
periodo de tiempo que como
mximo son de dos
semanas. Creador Jeff De Luca, Peter Coad y Eric
Lefebvre
Contenido
[ocultar] Lanzamiento inicial Mediados de los aos 1990

1 Caractersticas
2 Procesos
3 Roles y responabilidades
4 Comparacin
5 Fuentes

Caractersticas
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.
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 resultados peridicos y tangibles.
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.

Procesos
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

1. Desarrollar un modelo global: Al inicio del desarrollo se construye un

modelo teniendo en cuenta la visin, el contesto y los requisitos que debe
tener el sistema a construir. Este modelo se divide en reas que se
analizan detalladamente. Se construye un diagrama de clases por cada
rea.
2. Construir una lista de los rasgos: Se elabora una lista que resuma las
funcionalidades que debe tener el sistema, cuya lista es evaluada por el
cliente. Cada funcionalidad de la lista se divide en funcionalidades ms
pequeas para un mejor entendimiento del sistema.
3. Planear por rasgo: Se procede a ordenar los conjuntos de funcionalidades
conforme a su prioridad y dependencia, y se asigna a los programadores
jefes.
4. Disear por rasgo: Se selecciona un conjunto de funcionalidades de la
lista. Se procede a disear y construir la funcionalidad mediante un proceso
iterativo, decidiendo que funcionalidad se van a realizar en cada iteracin.
Este proceso iterativo incluye inspeccin de diseo, codificacin, pruebas
unitarias, integracin e inspeccin de cdigo.

Construir por Rasgo: se procede a la construccin total del proyecto.

Roles y responabilidades
El equipo de trabajo est estructurado en jerarquas, siempre debe haber un jefe
de proyecto, y aunque es un proceso considerado ligero tambin incluye
documentacin (la mnima necesaria para que algn nuevo integrante pueda
entender el desarrollo de inmediato).

Director del Proyecto: Lder administrativo y financiero del proyecto. Protege

al equipo de situaciones externas.
Arquitecto jefe: Realiza el diseo global del sistema. Ejecucin de todas las
etapas.
Director de desarrollo: Lleva diariamente las actividades de desarrollo.
Resuelve conflictos en el equipo. Resuelve problemas referentes a recursos.
Programador Jefe: Analiza los requerimientos. Disea el proyecto. Selecciona
las funcionalidades a desarrollar de la ltima fase del FDD.
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.

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.
Fuentes

Metodologa FDD (Feature Driven Development / Desarrollo Basado en Funciones)

Es una metodologa gil diseada para el desarrollo de software, basada en la calidad y el

monitoreo constante del proyecto.

Fue desarrollada por Jeff De Luca y Peter Coad a mediados de los aos 90. Esta
metodologa se enfoca en iteraciones cortas, que permiten entregas tangibles del
producto en un periodo corto de tiempo, de como mximo dos semanas.

Caractersticas
Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

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 resultados peridicos y
tangibles.

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.

No hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases
de diseo y construccin.

Ventajas:

El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando

soluciones innecesariamente generales y complejas que en realidad no son un requisito
del cliente.
 Cada componente del producto final ha sido probado y satisface los
requerimientos.
Rpida respuesta a cambios de requisitos a lo largo del desarrollo.
Entrega continua y en plazos cortos de software funcional.
Trabajo conjunto entre el cliente y el equipo de desarrollo.
Minimiza los costos frente a cambios.
Importancia de la simplicidad, al eliminar el trabajo innecesario.
Atencin continua a la excelencia tcnica y al buen diseo.
Mejora continua de los procesos y el equipo de desarrollo.
Evita malentendidos de requerimientos entre el cliente y el equipo.
Desventajas:

Falta de documentacin del diseo. El cdigo no puede tomarse como una

documentacin. En sistemas de tamao grande se necesitar leer los cientos o miles de
pginas del listado de cdigo fuente.
Problemas derivados de la comunicacin oral. Este tipo de comunicacin resulta
difcil de preservar cuando pasa el tiempo y est sujeta a muchas ambigedades.
Fuerte dependencia de las personas. Como se evita en lo posible la
documentacin y los diseos convencionales, los proyectos giles dependen crticamente
de las personas.
Falta de reusabilidad. La falta de documentacin hacen difcil que pueda
reutilizarse el cdigo gil.

Procesos
Desarrollar un modelo global: Al inicio del desarrollo se construye un modelo teniendo en
cuenta la visin, el contexto y los requisitos que debe tener el sistema a construir. Este
modelo se divide en reas que se analizan detalladamente. Se construye un diagrama de
clases por cada rea.

Construir una lista: Se elabora una lista que resuma las funcionalidades que debe tener el
sistema, cuya lista es evaluada por el cliente. Cada funcionalidad de la lista se divide en
funcionalidades ms pequeas para un mejor entendimiento del sistema.

Planear: Se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y

dependencia, y se asigna a los programadores jefes.

Disear: Se selecciona un conjunto de funcionalidades de la lista. Se procede a disear y

construir la funcionalidad mediante un proceso iterativo, decidiendo que funcionalidad se
van a realizar en cada iteracin. Este proceso iterativo incluye inspeccin de diseo,
codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

Construir : se procede a la construccin total del proyecto.

Roles y responsabilidades
El equipo de trabajo est estructurado en jerarquas, siempre debe haber un jefe de
proyecto, y aunque es un proceso considerado ligero tambin incluye documentacin (la
mnima necesaria para que algn nuevo integrante pueda entender el desarrollo de
inmediato).

Arquitecto jefe: Realiza el diseo global del sistema. Ejecucin de todas las etapas.

Director de desarrollo: Lleva diariamente las actividades de desarrollo. Resuelve conflictos

en el equipo. Resuelve problemas referentes a recursos.

Programador Jefe: Analiza los requerimientos. Disea el proyecto. Selecciona las

funcionalidades a desarrollar de la ltima fase del FDD.

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.

Cuando usarla

Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y
humanos, tiempo de desarrollo, tipo de sistema).
Exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos
pequeos y con requisitos muy cambiantes.
Las metodologas giles ofrecen una solucin casi adecuada para una gran cantidad de
proyectos.

Otras metodologas:

metodologia XP http://teo2grupo2.blogspot.com
metodologia SCRUM. http://teo2grupo3.blogspot.com/

Mtodo de desarrollo de sistemas dinmicos (DSDM)

http://tresparedesyunanexo.blogspot.com/

METODOLOGA ASD(ADAPTIVE SOFTWARE DEVELOPMENT)

http://adaptivesoftwaredevelopment.blogspot.com/2012/06/ads.html

Metodologa Agil http://ingenierosenformacionusac.blogspot.com/

Tema Crystal Clear http://reddycys.blogspot.com/

Bibliografa

https://docs.google.com/viewer?a=v&q=cache:6PASlfahbIcJ:www.seccperu.org/files/Meto
dologias%2520Agiles.pdf+&hl=es-
419&gl=gt&pid=bl&srcid=ADGEESgoC46tFZay_tzjsKlFucxhduRwsQtDysqGp9-PXdd_i7e-
DIEGAiuD8bLMsmFuTLfNXwALPQCq0o_XP50jByd0KDVuC7wsyv9awSbLfRTGrX8aGsn
q5m9k5XoOIBrO8KOB8RQM&sig=AHIEtbSUKA2-yriR3jSfRkuDUKoIDOCfqw

http://www.buenastareas.com/ensayos/Metodologia-Fdd/551499.html

http://rousselz.wordpress.com/2010/08/08/metodologia-fdd-feature-driven-development-
desarrollo-basado-en-funciones/

Artculo: Una exclusiva base de datos de ensayos para estudiantes. Metodologia Fdd.
Disponible en: "www.buenastareas.com". Consultado: 20 de enero del 2012. Artculo: La
nueva metodologa. Disponible en: "www.programacionextrema.org". Consultado: 20 de
enero del 2012.

http://es.wikipedia.org/wiki/Desarrollo_gil_de_software