Ingenieria de Software
| Más


Si requiere informacion adicional o tiene alguna sugerencia para mejorar este sitio por favor pongase en contacto con nosotros, con gusto atenderemos sus requerimientos

 FDD (Feature Driven Development)

 Desarrollo Basado en Funcionalidades

FDD con sus siglas en inglés Feature Driven Development es un enfoque á gil para el desarrollo de sistemas. Fue desarrollado por Jeff De Luca y el viejo gurú de la Orientacióna Objetos Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangibleDicho enfoque no hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de desarrollo de software y no requiere la utilización de ningún modelo de proceso específico. Además, hace énfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologías, FDD  afirma ser conveniente para el desarrollo de sistemas críticos.

Los desarrolladores entran en dos tipos:

  • Dueños de clases
  • Programadores jefe

Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Sólo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor, mientras los dueños de clases hacen gran parte de la codificación del rasgo.

FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

  • Desarrollar un Modelo
  • Global Construir una Lista de los Rasgos
  • Planear por Rasgo
  • Diseñar por Rasgo
  • Construir por Rasgo

En las primeras tres fases se ocupa gran parte del tiempo al inicio del proyecto, pero a medida que se avanza en las iteraciones las otras dos van ocupando más tiempo, y las primeras solo son para el refinamiento del release siguiente.

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.


El Proceso

Dicho proceso consiste de cinco fases secuenciales durante las cuales el diseño y la construcción del sistema se llevan a cabo.

 

 La parte iterativa del proceso de FDD (Diseño y Construcción) soporta un desarrollo ágil, con adaptaciones rápidas para cambios de último momento en los requerimientos.

 

1- Develop an Overall Modell (desarrollar modelo general)

Cuando esta fase comienza, los expertos del dominio ya tienen una idea del contexto y los requerimientos del sistema. Es probable que el documento de especificación de requerimientos ya exista. Sin embargo, FDD no hace énfasis en la recolección y administración de los requerimientos. Los expertos del dominio presentan un informe llamado walkthrough en el cual los miembros del equipo y el Chief Arquitect son informados a través de una descripción de alto nivel del sistema.

El dominio global es dividido en diferentes áreas y se realiza un walkthrough detallado para cada una de dichas áreas por parte de los expertos del dominio. Luego de cada walkthrough, un grupo de desarrolladores realizan un modelo de objetos para el área del dominio. Además, el equipo de desarrollo discute y decide cual es el modelo de objetos más apropiado para cada área del dominio. Simultáneamente, el modelo global del sistema es construido.

2- Build a Features List (construir lista de rasgos)

Los walkthroughs, el modelo de objetos y los requerimientos existentes ofrecen una buena base para construir una features list que resuma la funcionalidad del sistema a ser desarrollado. En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Las funcionalidades son presentadas por cada área del dominio y éstas forman un Mejor List Sets. Dicha lista es divida en subconjuntos en base a la funcionalidad. Estas representan diferentes actividades con un área específica del dominio. La features list es revisada por los usuarios y sponsors del sistema para su validación y aprobación.

3- Plan by Feature (planear por rasgos)

En esta etapa se incluye la creación de un plan de alto nivel, en el cual la features list es ordenada en base a la prioridad y a la dependencia entre cada feature. Además, las clases identificadas en la primera etapa son asignadas a cada programador.

4y5- Design and Build by Feature (diseñar y costruir por rasgos)

Un conjunto de features es seleccionada de la features list.

El diseño y construcción de la funcionalidad es un proceso iterativo durante el cual las features seleccionadas son producidas. Una iteración puede llevar desde unos pocos días a un máximo de dos semanas. Este proceso iterativo incluye tareas como inspección del diseño, codificación, testing unitario, integración e inspección del código. Luego que la iteración llega a su fin se realiza un main build de la funcionalidad en el cual se integra la funcionalidad. Dicho main build se realiza mientras la siguiente iteración comienza.

1 Feature : Son pequeñas funcionalidades que el cliente quiere.

2 Feature List : Lista que agrupa toda la funcionalidad del sistema

3 CMS : Es un repositorio en el cual se almacena toda la información del proyecto como ser documentación, código fuente, etc.

La siguiente imagen detalla como se desarrollan las iteraciones 4 y 5.

Develop an Overall Model

Resumen: Los expertos del dominio presentan un walkthrough inicial de alto nivel sobre el alcance del sistema y su contexto. A continuación los expertos del dominio y los desarrolladores construyen el esqueleto de un primer  modelo del sistema bajo la tutela del Arquitecto jefe Luego el dominio es dividido en distintas áreas y a cada subgrupo se le asigna un á rea de dominio a desarrollar. Una vez finalizada cada área, el grupo se reúne para realizar un modelo global en base a todas las alternativas.

Entrada: El cliente está listo para comenzar con la construcción del sistema. Además posee una lista de requerimientos especificada de alguna forma.

Tareas No

Nombre de la Tareas N

 

Descripción

 

rResponsablesp

 

Requerida

 

opcional

 

Formación del model team

El model team es un equipo permanente formado por expertos del dominio y desarrolladores.

Director del Proyecto 

Requerida

 

Domain Walkthrough 

Un experto del dominio realiza un pequeño  tutorial del á rea a ser modelada.

 

Modeling Team

Requerida

Estudio delos documentos

El equipo investiga los documentos disponibles incluyendo si es necesario modelo de componentes, requerimientos funcionales, user guides, etc.

Modeling Team

Opcional

 

Construcción de una Feature List informal

 

El equipo construye una Features List antes de comenzar con la Fase 2 y especifica que documentos ser á n necesarios para dicha etapa.

 

 Programador Jefe  Arquitecto jefe 

Requerida

 

Desarrollo del modelo en áreas

El dominio global es dividido en diferentes áreas. Cada subgrupo construye un diagrama para el á rea de dominio especificada, bajo ciertas consideraciones del Chief Arquitect, haciendo énfasis en las clases y asociaciones, luego en los m é todos y finalmente en los atributos. Los subgrupos agregan m é todos en base a lo extraído de los walkthrough y de la feature list. Los subgrupos también realizan uno o más diagramas de secuencias informales.

Modeling Team

 

divido en

 

peque ñ os

 

grupos

Requerida

Desarrollo del Modelo Global

 

Cada subgrupo presenta su propuesta para el área de dominio especificada. El Chief  Architect puede proponer una alternativa  adicional si as í lo desea. El Model Team selecciona una propuesta como base y se va mejorando con las demás. También se realiza un diagrama de secuencia informal de dicho modelo.

Jefe  Arquitecto,

 

Modeling Team

 

Requerida

Registro de alternativas

Un miembro del equipo es asignado para registrar las alternativas m á s importantes al modelo que el equipo evaluó para referencias futuras en el proyecto.

Jefe Programador  jefe  Arquitecto  

Requerida

 

Requerida/Opcional

Verificación: Se realizan evaluaciones sobre el equipo para clarificar el entendimiento de los aspectos del dominio, la funcionalidad necesaria y el alcance. Además, se realizan controles y verificaciones sobre el modelo desarrollado.

Salida: Al final de la etapa, el equipo debe obtener los siguientes resultados, sujetos a revisiones y a la aprobación del Director de desarrolloy el Arquitecto jefe: Diagrama de clases del sistema. Feature list informal  Registros de las alternativas m á s importantes sobre el modelo.


Build By Feature (BBF)

 

Resumen: En esta etapa cada Propietario de clases construye los métodos de las clases para cada feature correspondiente y luego realiza el testing unitario para cada clase. El Feature Team realiza una inspección del código antes del testing unitario. Luego que el código fue implementado e inspeccionado, el Class Owner realiza un check-in al CMS  (Configuration Management System). Luego se realiza un main build en el cual se hace la integración con la funcionalidad antes realizada. También se realizan los testing de integración correspondiente.

Tareas.

Nombre de la Tareas N

Descripción 

rResponsablesp

Requerida

 

opcional 

Implementación de clases y métodos

Cada Class Owner implementa los m é todos de sus correspondientes clases en base al diagrama de secuencia. Además realiza testing de los m é todos

 

Feature Team

 

Requerida

Inspección del código 

El Chief Programmer establece en el

cronograma una inspección del código que puede realizar antes o después del testing unitario. El Feature Team conduce dicha inspección y si lo requiere puede pedir la ayuda a expertos externos al equipo.

 

Feature Team

Requerida

Testing unitario 

Cada Class Owner realizar un testing unitario de las clases asignadas. El Chief Programmer ayuda al Class Owner sobre los datos de prueba que deben utilizarse. 

Feature Team

 

Ver Documento Completo    Ver Diapositivas

 

© 2019 Ingenieria de Software