Desarrollo basado en características

El desarrollo basado en características ( FDD , por sus siglas en inglés) es un proceso de desarrollo de software iterativo e incremental . Es un método ligero ^{[ ¿según quién? ]} o ágil para desarrollar software . FDD combina varias prácticas recomendadas reconocidas por la industria ^{[ ¿según quién? ]} en un todo cohesivo. Estas prácticas se impulsan desde una perspectiva de funcionalidad ( característica ) valorada por el cliente ^{[ se necesita aclaración ]} . Su propósito principal ^{[ ¿según quién? ]} es entregar software tangible y funcional de manera repetida y oportuna de acuerdo con los Principios detrás del Manifiesto Ágil . ^[1]

FDD fue concebido inicialmente por Jeff De Luca para satisfacer las necesidades específicas de un proyecto de desarrollo de software de 15 meses y 50 personas en un gran banco de Singapur en 1997. Esto dio como resultado un conjunto de cinco procesos que cubrían el desarrollo de un modelo general y el listado, la planificación, el diseño y la construcción de características. El primer proceso está muy influenciado por el enfoque de Peter Coad para el modelado de objetos . El segundo proceso incorpora las ideas de Coad de usar una lista de características para administrar los requisitos funcionales y las tareas de desarrollo. Los otros procesos son el resultado de la experiencia de Jeff De Luca. Ha habido varias implementaciones de FDD desde su uso exitoso en el proyecto de Singapur.

La descripción de FDD se presentó por primera vez al mundo en el Capítulo 6 del libro Modelado Java en color con UML ^[1] de Peter Coad, Eric Lefebvre y Jeff De Luca en 1999. Más tarde, en el libro de Stephen Palmer y Mac Felsing, Una guía práctica para el desarrollo basado en características ^[2] (publicado en 2002), se dio una descripción más general de FDD desacoplada del modelado Java.

FDD es un proceso de iteración corta basado en modelos que consta de cinco actividades básicas. Para generar informes de estado precisos y realizar un seguimiento del proyecto de desarrollo de software, se definen hitos que marcan el progreso logrado en cada característica. Esta sección ofrece una descripción general de las actividades. En la figura de la derecha, se muestra el modelo de metaproceso para estas actividades. Durante las dos primeras actividades secuenciales, se establece una forma general del modelo. Las tres actividades finales se iteran para cada característica.

El proyecto FDD comienza con un recorrido general del alcance del sistema y su contexto. A continuación, pequeños grupos crean modelos de dominio detallados para cada área de modelado y los presentan para su revisión por pares . Se selecciona uno o más de los modelos propuestos para convertirse en el modelo para cada área de dominio. Los modelos de áreas de dominio se fusionan progresivamente en un modelo general.

El conocimiento obtenido durante el modelado inicial se utiliza para identificar una lista de características mediante la descomposición funcional del dominio en áreas temáticas. Cada área temática contiene actividades comerciales y los pasos dentro de cada actividad comercial forman la base para una lista de características categorizada. Las características en este sentido son pequeñas partes de funciones valoradas por el cliente expresadas en la forma "<acción> <resultado> <objeto>", por ejemplo: "Calcular el total de una venta" o "Validar la contraseña de un usuario". Las características no deberían tardar más de dos semanas en completarse, de lo contrario deberían dividirse en partes más pequeñas.

Una vez completada la lista de características, el siguiente paso es producir el plan de desarrollo y asignar la propiedad de las características (o conjuntos de características) como clases a los programadores .

Se produce un paquete de diseño para cada característica. Un programador jefe selecciona un pequeño grupo de características que se desarrollarán en dos semanas. Junto con los propietarios de las clases correspondientes, el programador jefe elabora diagramas de secuencia detallados para cada característica y perfecciona el modelo general. A continuación, se escriben los prólogos de las clases y los métodos y, por último, se lleva a cabo una inspección de diseño .

Después de que se haya planificado una inspección de diseño exitosa para cada actividad a fin de producir una característica, los propietarios de las clases desarrollan el código para sus clases. Después de las pruebas unitarias y la inspección de código exitosa , la característica completada se promueve a la compilación principal.

Dado que las características son pequeñas, completar una característica es una tarea relativamente pequeña. Para generar informes de estado precisos y realizar un seguimiento del proyecto de desarrollo de software, es importante marcar el progreso realizado en cada característica. Por lo tanto, FDD define seis hitos por característica que se deben completar de manera secuencial. Los primeros tres hitos se completan durante la actividad de diseño por característica y los últimos tres se completan durante la actividad de creación por característica. Para realizar un seguimiento del progreso, se asigna un porcentaje completado a cada hito. En la tabla a continuación se muestran los hitos y su porcentaje de finalización. En el momento en que comienza la codificación, una característica ya está completa en un 44 % (recorrido del dominio 1 %, diseño 40 % e inspección del diseño 3 % = 44 %).

El desarrollo basado en características se basa en un conjunto básico de mejores prácticas de ingeniería de software orientadas a una perspectiva de características valoradas por el cliente.

• Modelado de objetos de dominio . El modelado de objetos de dominio consiste en explorar y explicar el dominio del problema que se va a resolver. El modelo de objetos de dominio resultante proporciona un marco general al que se pueden añadir características.
• Desarrollo por característica . Cualquier función que sea demasiado compleja para implementarse en dos semanas se descompone en funciones más pequeñas hasta que cada subproblema sea lo suficientemente pequeño como para llamarse característica. Esto facilita la entrega de funciones correctas y la extensión o modificación del sistema.
• Propiedad de clase (código) individual . La propiedad de clase individual significa que se asignan fragmentos o grupos de código distintos a un único propietario. El propietario es responsable de la coherencia, el rendimiento y la integridad conceptual de la clase.
• Equipos de diseño . Un equipo de diseño es un equipo pequeño y dinámico que desarrolla una actividad pequeña. Siempre se aplican varias mentes a cada decisión de diseño y se evalúan varias opciones de diseño antes de elegir una.
• Inspecciones . Las inspecciones se llevan a cabo para garantizar la buena calidad del diseño y del código, principalmente mediante la detección de defectos.
• Gestión de configuración . La gestión de configuración ayuda a identificar el código fuente de todas las funciones que se han completado hasta la fecha y a mantener un historial de los cambios en las clases a medida que los equipos de funciones las mejoran.
• Compilaciones periódicas . Las compilaciones periódicas garantizan que siempre haya un sistema actualizado que se pueda demostrar al cliente y ayudan a destacar errores de integración del código fuente para las funciones de manera temprana.
• Visibilidad del progreso y los resultados . Los gerentes dirigen un proyecto mediante informes de progreso frecuentes, adecuados y precisos de todos los niveles, tanto dentro como fuera del proyecto, en función del trabajo completado.

El metamodelado ayuda a visualizar tanto los procesos como los datos de un método . Esto permite comparar los métodos y reutilizar fácilmente los fragmentos de métodos en el proceso de ingeniería de métodos . El uso de esta técnica es coherente con los estándares UML .

El lado izquierdo del modelo de metadatos muestra las cinco actividades básicas involucradas en un proyecto de desarrollo de software que utiliza FDD. Todas las actividades contienen subactividades que corresponden a subactividades en la descripción del proceso FDD. El lado derecho del modelo muestra los conceptos involucrados. Estos conceptos se originan a partir de las actividades representadas en el lado izquierdo del diagrama.

• Desarrollo de software ágil
• Desarrollo impulsado por el comportamiento
• Ciclo de vida del proyecto
• Arquitectura de software
• Proceso de desarrollo de software
• Ingeniería de software

• 1. ^ Coad, P. , Lefebvre, E. y De Luca, J. (1999). Modelado Java en color con UML: componentes y procesos empresariales . Prentice Hall International. ( ISBN 0-13-011510-X ) 
• 2. ^ Palmer, SR y Felsing, JM (2002). Una guía práctica para el desarrollo basado en características . Prentice Hall. ( ISBN 0-13-067615-2 ) 

• Comunidad de desarrollo basada en características
• Desarrollo basado en características en Curlie
• Página FDD de Nebulon: Nebulon es la práctica de consultoría de Jeff De Luca
• Metodologías de desarrollo web exitosas: uso de FDD para proyectos de desarrollo web
• Cómo ofrecer valor comercial real mediante el desarrollo basado en funciones: el artículo ofrece una descripción general básica del desarrollo basado en funciones
• FDD y modelado ágil
• Mejor software más rápido: otro libro de la serie Coad que hace referencia al desarrollo basado en características. Autores: Andy Carmichael y Dan Haywood ISBN 0-13-008752-1 
• Entrevista con el creador de FDD, Jeff DeLuca (podcast)