Metodología FDD

1. Definición......................................................................................................................................... 2
2. Características ................................................................................................................................. 2
3. Fases ................................................................................................................................................ 2
3.1. Desarrollo de un modelo Global ............................................................................................... 3
3.2. Construcción de una lista de funcionalidades .......................................................................... 3
3.3. Planeación por funcionalidad ................................................................................................... 3
3.4. Diseño en base a las funcionalidades ....................................................................................... 3
3.5. Implementar en base a las funcionalidades.............................................................................. 3
4. Roles y Responsabilidades ............................................................................................................... 4
4.1. Roles Claves .............................................................................................................................. 4
4.2. Roles De Soporte ...................................................................................................................... 4
4.3. Roles Adicionales ...................................................................................................................... 4
5. Ventajas ........................................................................................................................................... 4
6. Desventajas...................................................................................................................................... 5
7. Ámbito de Aplicación ....................................................................................................................... 5
1. Definición
Es una metodología ágil diseñado para el desarrollo de software, basada en la calidad y el
monitoreo constante del proyecto.

Fue desarrollado por Jeff De Luca y Peter Coad a mediados de los años 90. Esta metodología se
enfoca principalmente en iteraciones cortas que permite entregas tangibles del producto en corto
periodo de tiempo que como máximo son de dos semanas.

Las iteraciones se deciden en base a features (de ahí el nombre del proceso) o funcionalidades, que
son pequeñas partes del software con significado para el cliente. Así, construir el sistema de ventas
es algo que requiere mucho tiempo, y construir el sistema de persistencia no tiene significado para
el cliente.

A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y
construcción.

No requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza

cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

2. Características
 No hace énfasis en la obtención de los requerimientos sino en cómo se realiza las fases de
diseño y construcción.
 Se preocupa por la calidad, por lo que incluye un monitoreo constante.
 El método es cooperativo, ya que aconseja que el cliente y los desarrolladores trabajen en
equipo.
 Es un método que nos ayuda a evitar desviaciones sustanciales sobre lo presupuestado,
ayuda a contrarrestar fallos en el software y a evitar entregas un producto inferior a lo
pactado.
 Esto se consigue porque el método propone establecer pequeñas etapas de cierre, en las
que tanto el cliente como los desarrolladores pueden hacer una evaluación continua del
producto. Es decir, se obtienen resultados periódicos
 Y es adaptivo. Es decir, es posible realizar cambios de último momento sin que la etapa de
desarrollo se vea sustancialmente afectada.

3. Fases
El FDD tiene cinco procesos. Las primeras 3 fases ocupan gran parte del tiempo en las primeras
iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando
el proyecto, limitándose las primeras a un proceso de refinamiento, las cinco fases son:

 Desarrollo de un modelo general.

 Construcción de la lista de funcionalidades.
 Planeación por funcionalidad.
 Diseñar en base a las funcionalidades.
 Implementar en base a las funcionalidades.
3.1. Desarrollo de un modelo Global
En esta fase inicial, los participantes ya tienen una visión del dominio, del contexto y de los
requerimientos funcionales del software.

A continuación, dicho dominio se divide en partes o áreas que serán estudiadas detalladamente.
Consiste en dividir el dominio global en otros dominios más pequeños llamados áreas (divide y
vencerás).

Después, los desarrolladores son los encargados de construir los diagramas de clases por cada una
de las áreas.

3.2. Construcción de una lista de funcionalidades

Los desarrolladores elaboran una lista de funcionalidades del sistema global y es evaluada por el
cliente.

Dicha lista, recurriendo nuevamente a la división para abordar problemas más pequeños, se divide
en subconjuntos según la dependencia de las funcionalidades. Los subconjuntos resultantes son
nuevamente revisados por el cliente y por los responsables para su aprobación.

3.3. Planeación por funcionalidad

Se ordena los subconjuntos de funcionalidades del paso anterior en función de su prioridad y
dependencia, y son entregados a los programadores jefes.

3.4. Diseño en base a las funcionalidades

Se selecciona el primer subconjunto de funcionalidades y se procede a elaborar el diseño haciendo
uso de diagramas de secuencia detallado y actualizando los diagramas de clases.

3.5. Implementar en base a las funcionalidades

En base al diseño de la fase anterior, se procede a construir las funcionalidades mediante un
proceso iterativo. Como ya se ha dicho, las iteraciones deben ser cortar (de unos 3-4 días a un par
de semanas), e incluye revisión de diseños, generación de códigos, pruebas unitarias, integración y
revisión del código.
4. Roles y Responsabilidades
El método FDD define tres categorías de roles: roles claves, roles de soporte y roles adicionales.
4.1. Roles Claves
 Gerente del proyecto: Es el líder de, proyecto. Se encarga de la administración, dirección y
financiamiento del proyecto.
 Arquitecto jefe: Responsable del diseño global del sistema.
 Director de desarrollo: Puede ser un rol combinado con el de gerente del proyecto. Se
encarga diariamente de las actividades de desarrollo. Resuelve problemas de conflictos
dentro del equipo y problemas referentes a recursos.
 Programador jefe: Es el responsable de analizar requerimientos, participa en el diseño del
proyecto y selecciona las próximas funcionalidades a desarrollar.
 Propietarios de clases: Es el responsable de desarrollar las clases que le fueron asignada.
Trabajan guiados por el programador jefe en el diseño, codificación, pruebas y
documentación.
 Experto de dominio: Poseen el conocimiento de los requerimientos del sistema. Son los que
trasladan a los desarrolladores dicho conocimiento, y puede ser un usuario, un cliente, un
analista….cualquiera que sepa perfectamente que es lo que tiene que hacer el sistema.
4.2. Roles De Soporte
 Gerente de entrega: Controla el avance del proyecto. Reporta resultados al gerente de
proyecto y al cliente donde se aprecia el porcentaje de avance de cada funcionalidad.
 “Guru” de lenguaje: Experto especialista en un tipo de lenguaje de programación o
tecnología.
 Herramientista: Es el encargado de administrar y mantener los servidores, conexiones,
comunicaciones, etc.
4.3. Roles Adicionales
 Tester: Es el encargado de ir probando las funcionalidades del sistema y verificar que éstas
cumplan con los requerimientos del cliente.
 Técnico de documentación: Son los responsables de elaborar documentación para los
usuarios finales del sistema.

5. 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.
 Rápida 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.
 Atención contínua a la excelencia técnica y al buen diseño.
 Mejora continua de los procesos y el equipo de desarrollo.
 Evita malentendidos de requerimientos entre el cliente y el equipo.
6. Desventajas
 Falta de documentación del diseño. El código no puede tomarse como una documentación.
En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de
código fuente.
 Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de
preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
 Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los
diseños convencionales, los proyectos ágiles dependen críticamente de las personas.
 Falta de reusabilidad. La falta de documentación hace difícil que pueda reutilizarse el código
ágil.

7. Ámbito de Aplicación
Su uso es adaptable, puede ser usado en proyectos pequeños, aunque es más recomendable usarlo
en proyectos grandes, en los que debido al tamaño del mismo es difícil gestionar el personal, es ahí
donde se aplica la jerarquía que trae FDD, haciendo que el equipo funcione ya no de manera
horizontal como comúnmente se hace con SCRUM y XP.

Se puede aplicar a juegos, software comercial, desarrollo a medida para grandes empresas,
plataformas servidas en la nube, etc.