Si requiere informacion adicional o tiene alguna sugerencia para mejorar este sitio por favor pongase en contacto con nosotros, con gusto atenderemos sus requerimientos
Si buscas
hosting web,
dominios web,
correos empresariales o
crear páginas web gratis,
ingresa a
PaginaMX
Por otro lado, si buscas crear códigos qr online ingresa al Creador de Códigos QR más potente que existe
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 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 |
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
