Desarrollo Basado en Funcionalidades FDD con sus siglas en ingls Feature Driven Development es un enfoque gil para el desarrollo

o de sistemas. Fue desarrollado por Jeff De Luca y el viejo gur de la Orientacina Objetos Peter Coad. Como las otras metodologas adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangibleDicho enfoque no hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases de diseo y construccin. Sin embargo, fue diseado para trabajar con otras actividades de desarrollo de software y no requiere la utilizacin de ningn modelo de proceso especfico. Adems, hace nfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologas, FDD afirma ser conveniente para el desarrollo de sistemas crticos.

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.

FDD tiene cinco procesos: Desarrollar un Modelo Global o general Construir una Lista de los Rasgos Planear por Rasgo Disear por Rasgo Construir por Rasgo En las primeras tres fases se ocupa gran parte del tiempo al inicio del proyecto, pero a medida que se avanza en las iteraciones las otras dos van ocupando ms tiempo, y las primeras solo son para el refinamiento del release siguiente. Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en tareas y se da un criterio de comprobacin. La parte iterativa del proceso de FDD (Diseo y Construccin) soporta un desarrollo gil, con adaptaciones rpidas para cambios de ltimo momento en los requerimientos.

Develop an Overall Model (desarrollar modelo general) Resumen: Los expertos del dominio presentan un walkthrough inicial de alto nivel sobre el alcance del sistema y su contexto. A continuacin los expertos del dominio y los desarrolladores construyen el esqueleto de un primer modelo del sistema bajo la tutela del Arquitecto jefe Luego el dominio es dividido en distintas reas y a cada subgrupo se le asigna un rea de dominio a desarrollar. Una vez finalizada cada rea, el grupo se rene para realizar un modelo global en base a todas las alternativas.

Nombre Tareas N

de

la Descripcin

rResponsablesp

Requerida opcional

Formacin del model El model team es un equipo Director del Proyecto team permanente formado por expertos del dominio y desarrolladores. Domain Un experto del dominio realiza un Modeling Team Walkthrough pequeo tutorial del rea a ser modelada. Estudio documentos

Requerida

Requerida

delos El equipo investiga los documentos Modeling Team Opcional disponibles incluyendo si es necesario modelo de componentes, requerimientos funcionales, user guides, etc. Construccin de una El equipo construye una Features List Programador Jefe Arquitecto Requerida Feature List informal antes de comenzar con la Fase 2 y jefe especifica que documentos ser n necesarios para dicha etapa. Desarrollo del El dominio global es dividido en modelo en reas diferentes reas. Cada subgrupo construye un diagrama para el rea de dominio especificada, bajo ciertas consideraciones del Chief Arquitect, haciendo nfasis en las clases y asociaciones, luego en los m todos y finalmente en los atributos. Los subgrupos agregan m todos en base a lo extrado de los walkthrough y de la feature list. Los subgrupos tambin realizan uno o ms diagramas de secuencias informales. Desarrollo del Cada subgrupo presenta su propuesta Modelo Global para el rea de dominio especificada. El Chief Architect puede proponer una alternativa adicional si as lo desea. El Model Team selecciona una propuesta como base y se va mejorando con las dems. Tambin se realiza un diagrama de secuencia informal de dicho modelo. Registro de Un miembro del equipo es asignado para registrar las alternativas m s importantes alternativas
al modelo que el equipo evalu para referencias futuras en el proyecto.

Modeling Team divido en pequeos grupos

Requerida

Jefe Arquitecto, Modeling Team

Requerida

Jefe Programador jefe Arquitecto

Requerida

Requerida/Opcional

Build By Feature (BBF) (construir lista de rasgos) Resumen: En esta etapa cada Propietario de clases construye los mtodos de las clases para cada feature correspondiente y luego realiza el testing unitario para cada clase. El Feature Team realiza una inspeccin del cdigo antes del testing unitario. Luego que el cdigo fue implementado e inspeccionado, el Class Owner realiza un check-in al CMS (Configuration Management System). Luego se realiza un main build en el cual se hace la integracin con la funcionalidad antes realizada. Tambin se realizan los testing de integracin correspondiente. Tareas. Nombre de la Descripcin rResponsablesp Requerida Tareas N opcional Implementacin de Cada Class Owner implementa los Feature Team Requerida clases y mtodos m todos de sus correspondientes clases en base al diagrama de secuencia. Adems realiza testing de los m todos Inspeccin cdigo del El Chief Programmer establece en Feature Team el cronograma una inspeccin del cdigo que puede realizar antes o despus del testing unitario. El Feature Team conduce dicha inspeccin y si lo requiere puede pedir la ayuda a expertos externos al equipo. Cada Class Owner realizar un Feature Team testing unitario de las clases asignadas. El Chief Programmer ayuda al Class Owner sobre los datos de prueba que deben utilizarse. Requerida

Testing unitario

3- Plan by Feature (planear por rasgos) En esta etapa se incluye la creacin de un plan de alto nivel, en el cual la features list es ordenada en base a la prioridad y a la dependencia entre cada feature. Adems, las clases identificadas en la primera etapa son asignadas a cada programador. 4 y 5- Design and Build by Feature (disear y costruir por rasgos) Un conjunto de features es seleccionada de la features list. El diseo y construccin de la funcionalidad es un proceso iterativo durante el cual las features seleccionadas son producidas. Una iteracin puede llevar desde unos pocos das a un mximo de dos semanas. Este proceso iterativo incluye tareas como inspeccin del diseo, codificacin, testing unitario, integracin e

inspeccin del cdigo. Luego que la iteracin llega a su fin se realiza un main build de la funcionalidad en el cual se integra la funcionalidad. Dicho main build se realiza mientras la siguiente iteracin comienza.

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.

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.

Glosario: Feature : Son pequeas funcionalidades que el cliente quiere. Feature List : Lista que agrupa toda la funcionalidad del sistema CMS : Es un repositorio en el cual se almacena toda la informacin del proyecto como ser documentacin, cdigo fuente, etc.

Bibliografa: metodologiafdd.blogspot.com Wikipedia.com