Desarrollo impulsado por funciones

desarrollo basado en funciones (FDD) es un proceso de desarrollo de software iterativo e incremental. Es un método ligero o ágil para desarrollar software. FDD combina una serie de mejores prácticas reconocidas por la industria en un todo cohesivo. Estas prácticas se impulsan desde una perspectiva de funcionalidad (característica) valorada por el cliente. Su objetivo principal es entregar software tangible y funcional repetidamente de manera oportuna de acuerdo con los Principios detrás del Manifiesto Ágil.

Historia

FDD fue ideado 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 resultó en 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 sobre 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 demás procesos son 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ó al mundo por primera vez en el capítulo 6 del libro Modelado Java en color con UML de Peter Coad, Eric Lefebvre y Jeff De Luca en 1999. Más tarde, en Stephen En el libro de Palmer y Mac Felsing Una guía práctica para el desarrollo basado en funciones (publicado en 2002), se ofrece una descripción más general de FDD desacoplada del modelado de Java.

Descripción general

FDD es un proceso de iteración corta impulsado por modelos que consta de cinco actividades básicas. Para obtener informes de estado precisos y realizar un seguimiento del proyecto de desarrollo de software, se definen hitos que marcan el progreso realizado en cada característica. Esta sección ofrece una descripción general de alto nivel 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 la forma general del modelo. Las últimas tres actividades se repiten para cada característica.

Desarrollar modelo general

El proyecto FDD comienza con un recorrido de alto nivel del alcance del sistema y su contexto. A continuación, grupos pequeños crean modelos de dominio detallados para cada área de modelado y los presentan para su revisión por pares. Se seleccionan 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.

Crear lista de funciones

El conocimiento recopilado durante el modelado inicial se utiliza para identificar una lista de características descomponiendo funcionalmente el dominio en áreas temáticas. Cada una de las áreas temáticas contiene actividades comerciales y los pasos dentro de cada actividad comercial forman la base de una lista de características categorizadas. Las características a este respecto son pequeñas partes de funciones valoradas por el cliente expresadas en la forma "<action> <resultado> <objeto>", por ejemplo: 'Calcular el total de una venta' o 'Validar la contraseña de un usuario'. Las funciones no deberían tardar más de dos semanas en completarse; de lo contrario, deberían dividirse en partes más pequeñas.

Planificar por función

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

Diseño por característica

Se produce un paquete de diseño para cada característica. Un programador jefe selecciona un pequeño grupo de funciones 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 la clase y del método y finalmente se realiza una inspección del diseño.

Construir por característica

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

Hitos

Dado que las funciones son pequeñas, completar una función es una tarea relativamente pequeña. Para obtener 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 función que deben completarse secuencialmente. Los primeros tres hitos se completan durante la actividad Diseño por característica y los tres últimos se completan durante la actividad Construir por característica. Para realizar un seguimiento del progreso, se asigna un porcentaje de finalización a cada hito. En la siguiente tabla 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%).

Mejores prácticas

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

• Modelo de objetos de dominio. Dominio El modelado de objetos consiste en explorar y explicar el dominio del problema a resolver. El modelo de objeto de dominio resultante proporciona un marco general en el que añadir características.
• Desarrollando por las características. Cualquier función que sea demasiado compleja para ser implementada dentro de dos semanas se descompone en funciones más pequeñas hasta que cada subproblema sea lo suficientemente pequeña como para ser llamada una característica. Esto facilita la realización de funciones correctas y la ampliación o modificación del sistema.
• Propiedad individual (Código). La propiedad individual de clase significa que piezas distintas o agrupación de código se asignan a un solo propietario. El propietario es responsable de la consistencia, rendimiento e integridad conceptual de la clase.
• Equipos de carga. Un equipo de características es un pequeño equipo formado dinámicamente que desarrolla una pequeña actividad. Múltiples mentes se aplican siempre a cada decisión de diseño, y se evalúan múltiples opciones de diseño antes de que se elija.
• Inspección. Se realizan inspecciones para garantizar el diseño y el código de buena calidad, principalmente mediante la detección de defectos.
• Configuration Management. La gestión de configuración ayuda a identificar el código fuente para todas las características que se han completado hasta la fecha y mantener un historial de cambios en las clases como equipos de características mejorarlos.
• Construcciones regulares. Las construcciones regulares aseguran que siempre hay un sistema actualizado que se puede demostrar al cliente y ayuda a resaltar errores de integración del código fuente para las características tempranamente.
• Visibilidad del progreso y los resultados. Los administradores dirigen un proyecto utilizando informes de progreso frecuentes, apropiados y precisos de todos los niveles dentro y fuera del proyecto basados en trabajos completados.

Metamodel (Metamodelling)

El metamodelado ayuda a visualizar tanto los procesos como los datos de un método. Esto permite comparar métodos y reutilizar fácilmente fragmentos de métodos en el proceso de ingeniería de métodos. El uso de esta técnica es consistente 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 utilizando 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.