Desarrollo basado en funcionalidades
# Desarrollo basado en funcionalidades

El desarrollo basado en funcionalidades (en inglés: feature-driven development, FDD) es un enfoque de desarrollo ágil de software desarrollado por Jeff De Luca y Peter Coad. Los desarrolladores se agrupan en dos tipos, "dueños de clases" o "programadores jefe".

### Concepto:

Desarrollo basado en funcionalidades, o Feature Driven Development (FDD), constituye una metodología ágil de modelo de desarrollo, con carácter iterativo y adaptativo, dirigido a obtener funcionalidades tangibles al terminar cada iteración, conseguir un software funcional donde el cliente pueda ir testeando el producto durante el ciclo de desarrollo. Orientado particularmente a las fases de diseño y construcción, y se lo considera complementario con otras metodologías .

Esta metodología está compuesta por cinco pasos secuenciales específicos:

* Develop Overall Model,
* Build a Feature List,
* Plan by Feature,
* Design by Feature,
* Build By Feature

### Nacimiento:

FDD nace como consecuencia de un proyecto de desarrollo de software para el gran banco de Singapur en el año 1997, está registrada por la empresa Nebulon Pty, y fué descripta en Java Modeling in Color With UML de los autores Peter Coad, Eric Lefebvre y Jeff DeLuca.

### Roles en FDD:

Hay tres categorías: Roles claves, roles soporte y roles adicionales.

### Procesos:

El modelo consta de cinco procesos secuenciales y cada fase tiene un criterio de entrada, tares, pruebas y criterio de salida, con un tiempo promedio de cada iteración de 1 a 3 semanas.

Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida. Típicamente, la iteración de un rasgo tiene un tiempo de 1 a 3 semanas máximo.

A) PRIMERA FASE: DESARROLLO UN MODELO GENERAL

Aquí los expertos de dominio, arquitecto jefe, los jefes programadores forman un equipo para realizar el modelado. Tendiendo en cuenta contexto y requerimientos funcionales.

Se construye un modelo general para todo el sistema, y el objetivo de esta fase también es lograr buena comprensión del dominio del problema.

B) SEGUNDA FASE: CONSTRUCCIÓN DE UNA LISTA DE CARACTERÍSTICAS

Aquí se confecciona una serie de ítems que son importantes para el cliente, agrupados según las diversas actividades en áreas de dominio específicas. Se suelen dividir jerárquicamente: relacionados a una cadena de características, relacionados a un momento sobre el dominio del problema, y los relacionados a un método en el dominio del problema.

C) TERCER FASE: PLANEAMIENTO POR CARACTERÍSTICAS

Aquí se crea un plan completo de bajo nivel, en donde los rasgos o características se ponen secuencialmente conforme prioridad y dependencia de cada uno. También se asignan programadores jefes, se armas paquetes de diseño.

D) CUARTA FASE: DISEÑO POR RASGO

Se trabaja en cada paquete de diseño, se definen con precisión las clases y objetos de diseño, se crean los diagramas de secuencia. Es común que sea actualizado el modelo de la primera etapa. El proceso iterativo incluye inspección de diseño, codificación, prueba de unidad, integración e inspección de código.

E) QUINTA FASE: DESARROLLO POR RASGO

Aquí se inspecciona el diseño, codificación, prueba de unidad, integración e inspección de código.

### Prácticas características:

La metodología Feature Driven Development está constituida alrededor de una serie de prácticas exigidas:

a) Inspecciones regulares de código.

b) Constituir equipos pequeños y dinámicamente formados; establecidos por rasgos, hasta que el rasgo del equipo es terminado.

c) Existencia de reportes de progreso, que se comunican a todos los niveles, con información precisa, y relevante.

d) Gestión de configuración: separando el código de las funcionalidades y llevando historial de modificaciones y versiones.

### Algunos puntos a favor y en contra:

Es una metodología flexible, donde cuanta mas necesidad de código va aumentando la organización. Es muy clara y concreta en cuanto a sus guías, y tiene técnicas muy específicas.

FDD necesita la participación de personal experimentado en el equipo de trabajo y existen una dependencia en la jerarquía de roles de sus miembros.

## Bibliografía

* Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
* Palmer, Stephen, John Felsing. A practical guide to feature driven development the Coad Series Prentice Hall, 2000.
* Centellas Hinojosa, Milca; Luna Tellez, Linda; Vaca Pinto, Roberto Carlos. Feature Driven Development (FDD), Módulo: Gestión Operativa de la Calidad de Software Maestría de Ingeniería de Software. Universidad Autónoma Gabriel René Moreno (2012).
* Feature-driven development (FDD), Portal, http://www.featuredrivendevelopment.com/
* Datos: Q1399336
