Hispanopedia WikiEl desarrollo impulsado por características ( FDD ) es un proceso de desarrollo de software iterativo e incremental . Es un método ligero o ágil para el desarrollo de software . FDD combina varias buenas prácticas en un todo coherente. Estas prácticas se basan en la entrega de funcionalidades ( características ) valoradas por el cliente. [ 1 ] Su propósito principal es entregar software tangible y funcional de forma repetida y oportuna, de acuerdo con los principios del manifiesto ágil . [ 2 ]
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 importante banco de Singapur en 1997. Esto dio como resultado un conjunto de cinco procesos que abarcaban el desarrollo de un modelo general y la lista, planificación, diseño y construcción de funcionalidades. El primer proceso está fuertemente influenciado por el enfoque de modelado de objetos de Peter Coad . El segundo proceso incorpora las ideas de Coad sobre el uso de una lista de funcionalidades para gestionar los requisitos funcionales y las tareas de desarrollo. Los demás procesos son resultado de la experiencia de Jeff De Luca. Se han realizado 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 Java modelling in Color with UML.por Peter Coad, Eric Lefebvre y Jeff De Luca en 1999. Posteriormente, en el libro de Stephen Palmer y Mac Felsing, A Practical Guide to Feature-Driven Development.En la publicación de 2002 se ofreció una descripción más general de FDD, desacoplada del modelado en Java.
Descripción general
FDD es un proceso iterativo corto basado en modelos que consta de cinco actividades básicas. Para informar con precisión sobre el estado y realizar un seguimiento del proyecto de desarrollo de software, se definen hitos que marcan el progreso de cada funcionalidad. Esta sección ofrece una visió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 la estructura general del modelo . Las tres últimas actividades se iteran para cada funcionalidad.
Desarrollar un modelo general
El proyecto FDD comienza con una descripción 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 cada área de dominio. Los modelos de las áreas de dominio se integran progresivamente en un modelo general.
Lista de características de la compilación
El conocimiento adquirido durante el modelado inicial se utiliza para identificar una lista de funcionalidades mediante la descomposición funcional del dominio en áreas temáticas. Cada área temática contiene actividades de negocio, y los pasos dentro de cada actividad constituyen la base de una lista de funcionalidades categorizada. En este sentido, las funcionalidades son pequeñas partes de funciones valiosas para el cliente, expresadas en el formato "<acción> <resultado> <objeto>" , por ejemplo: "Calcular el total de una venta" o "Validar la contraseña de un usuario". Las funcionalidades 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 funcionalidades, el siguiente paso es elaborar el plan de desarrollo y asignar la propiedad de las funcionalidades (o conjuntos de funcionalidades) como clases a los programadores .
Diseño por característica
Se elabora un paquete de diseño para cada funcionalidad. Un programador jefe selecciona un pequeño grupo de funcionalidades que se desarrollarán en un plazo de dos semanas. Junto con los responsables de las clases correspondientes, el programador jefe elabora diagramas de secuencia detallados para cada funcionalidad y perfecciona el modelo general. A continuación, se redactan los prólogos de las clases y los métodos, y finalmente se realiza una revisión del diseño .
Construir por característica
Tras una inspección de diseño exitosa para cada actividad que permita desarrollar una funcionalidad, los responsables de las clases desarrollan el código correspondiente. Después de las pruebas unitarias y una inspección de código satisfactoria , la funcionalidad finalizada se incorpora a la versión principal.
Hitos
Dado que las funcionalidades son pequeñas, completar una funcionalidad es una tarea relativamente sencilla. Para obtener informes de estado precisos y realizar un seguimiento del proyecto de desarrollo de software, es importante marcar el progreso de cada funcionalidad. Por lo tanto, FDD define seis hitos por funcionalidad que deben completarse secuencialmente. Los tres primeros hitos se completan durante la actividad de Diseño por Funcionalidad , y los tres últimos durante la actividad de Construcción por Funcionalidad . Para realizar un seguimiento del progreso, se asigna un porcentaje de finalización a cada hito. En la tabla siguiente se muestran los hitos y su porcentaje de finalización. En el momento en que comienza la codificación, una funcionalidad 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 funcionalidades se fundamenta en un conjunto básico de buenas prácticas de ingeniería de software orientadas a una perspectiva de funcionalidades valoradas por el cliente.
- Modelado de objetos de dominio . El modelado de objetos de dominio consiste en explorar y explicar el dominio del problema a resolver. El modelo de objetos de dominio resultante proporciona un marco general para añadir funcionalidades.
- Desarrollo por funcionalidades . Cualquier función 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 considerarse una funcionalidad. Esto facilita la entrega de funciones correctas y la ampliación o modificación del sistema.
- Propiedad individual de la clase ( propiedad del código ). La propiedad individual de la clase implica que distintas partes o grupos de código se asignan a un único propietario. El propietario es responsable de la coherencia, el rendimiento y la integridad conceptual de la clase.
- Equipos de desarrollo de funcionalidades . Un equipo de desarrollo de funcionalidades es un equipo pequeño y dinámico que desarrolla una actividad específica. En cada decisión de diseño participan varias personas y se evalúan múltiples opciones antes de elegir una.
- Inspecciones . Las inspecciones se realizan para garantizar un diseño y un código de buena calidad, principalmente mediante la detección de defectos.
- Gestión de la configuración . La gestión de la configuración ayuda a identificar el código fuente de todas las funcionalidades que se han completado hasta la fecha y a mantener un historial de los cambios realizados en las clases a medida que los equipos de desarrollo las mejoran.
- Compilaciones periódicas . Las compilaciones periódicas garantizan que siempre haya un sistema actualizado que se pueda mostrar al cliente y ayudan a detectar tempranamente los errores de integración del código fuente de las funcionalidades.
- Visibilidad del progreso y los resultados . Los gerentes dirigen un proyecto utilizando informes de progreso frecuentes, apropiados y precisos de todos los niveles, tanto dentro como fuera del proyecto, basados en el trabajo completado.
Metamodelo (Metamodelado)
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 coherente con los estándares UML .
El lado izquierdo del modelo de metadatos muestra las cinco actividades básicas de un proyecto de desarrollo de software mediante FDD. Todas las actividades contienen subactividades que se corresponden con las subactividades de 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.
Véase también
Referencias
- ↑ Cadle, James; Ahmed, Tahir; BCS, The Chartered Institute for IT, eds. (2014). Desarrollo de sistemas de información: guía práctica para profesionales de TI . Londres: BCS, The Chartered Institute for IT. pág. 99. ISBN 978-1-78017-245-3.
- ↑ "Principios que sustentan el Manifiesto Ágil" . 11 de junio de 2019.
- 1. ^ Coad, P. , Lefebvre, E. y De Luca, J. (1999). Java modelling In Color With UML: Enterprise Components and Process . Prentice Hall International. ( ISBN 0-13-011510-X)
- 2. ^ Palmer, SR, & Felsing, JM (2002). A Practical Guide to Feature-Driven Development . Prentice Hall. ( ISBN) 0-13-067615-2)
Enlaces externos
- Comunidad de desarrollo basada en características
- Página de Nebulon FDD - Nebulon es la consultora de Jeff De Luca.
- Metodologías exitosas de desarrollo web : uso de FDD para proyectos de desarrollo web
- Generando valor empresarial real mediante el desarrollo basado en características : este artículo ofrece una visión general básica del FDD.
- 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 Jeff DeLuca, creador de FDD (Podcast)
- Desarrollo ágil de software
- Gestión de proyectos de software
- Características del software
