Articulo FDD

Introducción

El desarrollo basado en funcionalidades en ingles feature-driven-development (FDD) es una metodología enfocada en el desarrollo ágil del software, como su nombre lo indica esta se organiza en torno al progreso de las funciones. Se basa en un modelo simple que consta de cinco actividades básicas. Para obtener informes de estado preciso y realizar seguimientos del proyecto de desarrollo de software de manera que se enfoca en iteraciones cortas que permiten entregas tangibles del producto en un corto periodo de tiempo.

Antecedentes

La primera aplicación en hacer uso de la metodología FDD fue un proyecto de desarrollo de software en el que trabajaron 50 personas para una institución financiera con sede en Singapur de la cual resulto un conjunto de cinco procesos que cubrían el desarrollo de un modelo general y el listado, planificación, diseño y construcción de características. El primer proceso está fuertemente influenciado por el enfoque de Peter Coad para el modelado de objetos. El segundo proceso incorpora las ideas de Coad de utilizar una lista de funciones para gestionar los requisitos funcionales y las tareas de desarrollo. Los otros procesos son el resultado de la experiencia de Jeff De Luca. La primera discusión pública de la metodología se dio en el libro Java Modeling in color with UML de Jeff De Luca y Peter Coad a mediados de los años 90.

Procesos:

FDD fue diseñado para seguir un proceso de desarrollo de cinco pasos, construido en gran parte alrededor de proyectos de "características" discretas. Ese ciclo de vida del proyecto se ve así:

1. Desarrollar un modelo global.

Al iniciar el desarrollo se constituye un modelo teniendo en cuenta los requisitos con los que debe contar el sistema a construir. Este modelo se fragmenta en áreas en las que se realiza un análisis detallado. Consiguiente se construye un diagrama de clases por cada área.

1. Construir una lista de funcionalidades.

Las funcionalidades del sistema de plasman en una lista, la cual es evaluada por el cliente. Cada una de estas funcionalidades se divide en funcionalidades más simples para establecer un claro entendimiento del sistema.

1. Planificar por funcionalidad.

Se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, Seguido a esto se asignan a los programadores jefes.

1. Diseñar por funcionalidad.

De la lista de funcionalidades se selecciona un conjunto de estas, para proceder a construir la funcionalidad mediante un proceso iterativo, decidiendo que funcionalidad se realizara para cada iteración. Para cada proceso de iteración se realiza una inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.

1. Construir por funcionalidad.

Luego del proceso de diseño, los propietarios de cada clase desarrollan el código para sus clases. Después de la prueba unitaria y la inspección exitosa del código, la función completa se promueve a la compilación principal.

Conclusiones:

Las fortalezas de FDD incluyen:

1.        El proceso simple de cinco pasos permite un desarrollo más rápido

2.        Permite a los equipos más grandes hacer avanzar los productos con éxito continuo

3.        Aprovecha los estándares de desarrollo predefinidos, por lo que los equipos pueden moverse rápidamente

Las debilidades de FDD incluyen:

1.        No funciona de manera eficiente para proyectos más pequeños.

2.        Menos documentación escrita, lo que puede generar confusión.

3.        Muy dependiente de los desarrolladores o programadores principales

En resumen, FDD es un excelente proceso ágil y

su estrategia de desarrollo guarda similitudes con la de

técnicas orientadas a aspectos. Sin embargo, debido a que no es

originalmente diseñado para orientación de aspecto, todavía carece

algunas propiedades para ser un completo orientado a aspectos

solución al desarrollo de software. Un refinamiento basado

en una técnica orientada a aspectos puede hacer que los primeros tres FDD procesa buenos candidatos para aspectos tempranos,

a saber, análisis de requisitos orientado a aspectos.

 Con los tres ejemplos de representación de características,

concluyen que la idea "los aspectos tempranos pueden ser todos

descrito uniformemente con una plantilla de características, luego

planeado, diseñado e implementado posteriormente con un

técnica de programación orientada a aspectos” es viable.

 Si bien esta teoría provino de nuestro software

prácticas de desarrollo, es vital volver a utilizar esta teoría

al desarrollo del mundo real. El trabajo futuro es

Estudiar la utilidad de esta metodología en una variedad de

...