trabajo fdd
TRANSCRIPT
DESARROLLO BASADO EN FUNCIONES (FDD)
Índice
DESARROLLO BASADO EN FUNCIONES (FDD)
DEFINICIÓN 1
HISTORIA DEL MODELO DE CASCADA 1
PRINCIPIOS BÁSICOS DEL MODELO DE CASCADA 2
FASES DEL MODELO DE CASCADA 2
INGENIERÍA Y ANÁLISIS DEL SISTEMA: 3
ANÁLISIS DE LOS REQUISITOS DEL SOFTWARE: 3
DISEÑO: 4
LA ETAPA DE DISEÑO 4
CODIFICACIÓN: 4
PRUEBA: 4
MANTENIMIENTO: 5
MODELO EN CASCADA PURO O SECUENCIAL 6
Modelo en cascada realimentado para el ciclo de vida 7
Modelos Modificados de Cascada 7
El modelo Sashimi 8
Modelo en Cascada Bennington 1956: 8
La metodología en cascada es esencialmente: 9
Argumentos a favor del modelo de cascada 10
Ventajas 12
Desventajas 12
Problemas del modelo de cascada 13
El fracaso del modelo de cascada 14
Uso 14
La crítica del modelo de cascada 15
Conclusión 18
Índice
MAPA CONCEPTUAL 19
CUESTIONARIO 20
BIBLIOGRAFIA 23
Contenido
DESARROLLO BASADO EN FUNCIONES (FDD)
Introduccion
Esta metodología se basa en la definición de funcionalidades que deben
ser implementadas en el sistema. FDD está pensado para proyectos con
duración relativamente cortos, menores a un año.
En esta metodología se presenta una jerarquía de funcionalidades, la
primera en la jerarquía agrupa las propiedades relacionadas con
aspectos en común del negocio.
Una de las principales ventajas de trabajar centrado en las
funcionalidades del software es el de formar y fomentar un dialogo fluido
entre los clientes y desarrolladores y que ambos posean un modelo
común del negocio.
FDD constituye un proceso iterativo con iteraciones cortas (menores a
dos semanas) obteniendo como resultado un software funcional que la
dirección de la empresa cliente puede ver y monitorizar.
FDD (Feature-Driven Development) es un proceso de ingeniería de
software que se centra principalmente en la entrega frecuente de
software que trabaja para el cliente.
Al ser un desarrollo ágil de software centrado en el FDD incisiva favorece
la participación de los clientes (internos o externos) para el proceso de
planificación y desarrollo de software, ya que se basa en un proceso de
desarrollo de software de forma iterativa e incremental.
El FDD no se centró en la programación o el alcance de un modelo bien
definido, sino que hace uso de una planificación iterativo, que tiene
como objetivo abstracto y satisfacer las principales necesidades de la
empresa, que determinan la forma de desempeño del equipo de
desarrollo. Los pasos y el modelo utilizado para el desarrollo de
software EVOLUCIÓN SYS están definidas por los pasos a continuación e
incluyen los siguientes procesos:
Desarrollo Basado en Funcionalidades
1
Contenido
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.
Definicion
FDD es un método de desarrollo de ciclos cortos que se concentra en la
fase de diseño y construcción. En la primera fase, el modelo global de
dominio es elaborado por expertos del dominio y desarrolladores; El
modelo de dominio consiste en diagramas de clases con clases,
relaciones, métodos y atributos. Los métodos no reflejan conveniencias
de programación sino rasgos funcionales.
2
Contenido
Feature Oriented Programming (FOP) es una técnica de programación
guiada por rasgos o características (features) y centrada en el usuario,
no en el programador; su objetivo es sintetizar un programa conforme a
los rasgos requeridos [Bat03]. En un desarrollo en términos de FOP, los
objetos se organizan en módulos o capas conforme a rasgos. FDD, en
cambio, es un método ágil, iterativo y adaptativo. A diferencia de otros
MAs, no cubre todo el ciclo de vida sino sólo las fases de diseño y
construcción y se considera adecuado para proyectos mayores y de
misión crítica. FDD es, además, marca registrada de una empresa,
Nebulon Pty. Aunque hay coincidencias entre la programación orientada
por rasgos y el desarrollo guidado por rasgos, FDD no necesariamente
implementa FOP.
FDD no requiere un modelo específico de proceso y se complementa con
otras metodologías. Enfatiza cuestiones de calidad y define claramente
entregas tangibles y formas de evaluación del progreso.
Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones,
siendo las dos últimas las que absorben la mayor parte del tiempo según va
avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.
El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque
siempre habrá un responsable último (arquitecto jefe o jefe de programadores en
función de la fase en que nos encontremos), con mayor experiencia, que tendrá la
última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue
que todos formen parte del proyecto y que los menos inexpertos aprendan de las
discusiones de los mas experimentados, y al tener un responsable último, se
asignan las responsabilidades que todas las empresas exigen.
Las funcionalidades a implementar en una release se dividen entre los distintos
subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen
propietario (es decir, solo quién las crea puede cambiarlas), es por ello que en el
equipo que implementa una funcionalidad dada deberán estar todos los dueños de
las clases implicadas, pudiendo encontrarse un programador en varios grupos,
implementando distintas funcionalidades. Habrá también un programador jefe
3
Contenido
(normalmente el más experimentado) que hará las funciones de lider del grupo
que implementa esa funcionalidad. En el proceso de implementar la funcionalidad
también se contemplan como partes del mismo (en otros métodos se describen
como actividades independientes) la preparación y ejecución de pruebas, así
como revisiones del código (para distribuir el conocimiento y aumentar la calidad)
e integración de las partes que componen el software.
Historia
Se lo reportó por primera vez en un libro de Peter Coad, Eric Lefebvre y
Jeff DeLuca Java Modeling in Color with UML [CLD00]; luego fue
desarrollado con amplitud en un proyecto mayor de desarrollo por
DeLuca, Coad y Stephen Palmer. Su implementación de referencia,
análogo al C3 de XP, fue el Singapore Project; DeLuca había sido
contratado para salvar un sistema muy complicado para el cual el
contratista anterior había producido, luego de dos años, 3500 páginas
de documentación y ninguna línea de código. Naturalmente, el proyecto
basado en FDD fue todo un éxito, y permitió fundar el método en un
caso real de misión crítica.
Fases
Las iteraciones son definidas en base a las funcionalidades, un proyecto
abordado con FDD presenta cinco fases:
1.-Desarrollo de un modelo general.
Esta fase se define por una reunión de la comprensión del problema
(Reunión de Planificación), donde los miembros del equipo (Scrum
Master y Team) y el cliente (Product Owner) definen lo que se producirá
durante el Sprint. En esta reunión, se establecen los requisitos para ser
tratada, dejando que el tiempo de la construcción de modelos,
artefactos y de negocios del usuario Historias. Los artefactos producidos
durante esta fase son: Visión de FBS (Estructura de Desglose de
funciones), Diagrama de Clase Ejecutiva, el establecimiento de los
criterios de aceptación.
4
Contenido
2. Construcción de la lista de funcionalidades.
En esta etapa se construyen las listas de características que se
abordarán durante el sprint y su FBS (similar a la WBS) es refinado.
Después de obtener este punto de vista, los responsables de cada una
de las modelos, agrupados por características se denominan, de modo
que el trabajo de análisis y desarrollo se inició. Los artefactos
producidos durante esta fase son: FBS: estructura de los componentes
de averías y los diagramas de clases.
3. Plan de entregables en base a las funcionalidades a implementar. La
planificación de cómo las características se desarrollará marcar esta
fase, donde se define la secuencia en el desarrollo de las características
de las actividades empresariales, que se asignan a los responsables de
acuerdo con la clase de desarrollo. Los artefactos producidos durante
esta fase son: Visión de FBS (Estructura de Desglose de funciones),
diagrama de clases.
4. Diseñar en base a las funcionalidades.
El desglose por funcionalidad no es más que el análisis del sistema en sí
mismo. En esta etapa, se describe el desarrollo de documentos y
artefactos, junto con la documentación de las clases y sus diagramas de
clases y de secuencia. Los artefactos producidos durante esta fase son:
Perfeccionamiento de los diagramas de clases, diagramas de secuencia
(de actividad, la máquina del Estado y de la comunicación, si es
necesario), Diagrama de entidad-relación (DER) y Storyboard.
5. Implementar en base a las funcionalidades.
En esta etapa, se hace para implementar las clases y métodos. Como
buena práctica, que aprobó la revisión del código y la generación de
evidencia para las pruebas unitarias antes de que se apliquen los planes
de prueba y la profundidad integrada de la aplicación generada. Los
principales artefactos generados al final de esta etapa son el Código,
diagrama de clases (Final) Pantallas y Pruebas Funcionales Unidad.
5
Contenido
El trabajo de modelado como el de desarrollo es realizado en grupo,
pero siempre se debe contar con la presencia de un jefe o arquitecto de
desarrolladores, en función a la fase en la que el proyecto se encuentre.
Las funcionalidades que se deben implementar son divididas entre los
subgrupos del equipo, cada clase escrita tiene un propietario, y se
restringe a que solo el propietario de la clase pueda cambiar el código
de esta, esto da como resultado que un programador puede integrar
varios subgrupos y estará implementando diferentes funcionalidades en
el proyecto.
Primera Fase
En la primera fase del FDD deben participar tanto expertos en el dominio
del negocio como los desarrolladores, mediante la colaboración de los
dos grupos se genera un conocimiento global de la aplicación a construir
y los primeros bosquejos de las funcionalidades del software.
Segunda Fase
La segunda fase de FDD es construir la lista de funcionalidades del
software a desarrollar, para esta fase se toma el bosquejo elaborado en
la fase anterior refinando las funcionalidades incluidas para ubicarlas en
una estructura organizada en forma jerárquica. El trabajo de desarrollo
es organizado en función de priorización de las funcionalidades
definidas, en caso de obtener actividades cuyo desarrollo implique más
de dos semanas, estas deben ser particionadas para ser ubicadas en
iteraciones.
Tercera Fase
La tercera fase de FDD establece tiempos de desarrollo a partir de la
lista priorizada de funcionalidades que se obtuvo en la fase anterior. Los
líderes de proyecto deben delinear los hitos de finalización de cada
iteración estableciendo responsabilidades.
La parte productiva en cuanto a desarrollo está contenida en las dos
últimas fases de FDD, en estas fases se construye en forma incremental
la aplicación.
6
Contenido
Mediante la utilización de lenguaje UML, se diseña las clases atributos y
métodos requeridos para la implementación de la funcionalidad de la
aplicación.
La metodología FDD está orientada completamente a la funcionalidad
del software sobre las tareas. La metodología recomienda organizar
bloques de funcionalidades para ser construidos en forma incremental
mediante iteraciones de dos semanas de duración, cada subgrupo de
programación debe ser dirigido por un programador jefe.
Diseño por funcionalidades y Construcción por funcionalidades
En esta etapa se selecciona un conjunto de funcionalidades de la lista y
se procede a diseñar y construir la funcionalidad mediante un proceso
iterativo.
Una iteración puede tomar de unos pocos días a un máximo de dos
semanas. El proceso iterativo incluye inspección de diseño, codificación,
pruebas unitarias, integración e inspección de código.
Para cada una de estas iteraciones en la fase de diseño se debe generar:
• Diagrama de secuencia detallado
• Diagrama de clases actualizado
• Descripción de clases y métodos
• Notas adicionales
En la fase de construcción:
• Implementacion e inspeccion de metodos
• Testing unitarios para cada metodo
• Check in de las clases
• Main Build del sistema y testing de integración.
Roles
• Gerente de proyecto
• Arquitecto en jefe
7
Contenido
• Gerente de desarrollo
• Programador en Jefe
• Experto del dominio
• Gerente del dominio
• Administrador de release
• Language Guru
• Ingeniero de construcción
• Administrador del sistema
• Tester
• Deployer
• Escritor Técnico
Procesos
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.
8
Contenido
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.
9
Contenido
4 y 5- 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.
CARACTERISTICAS FDD
No cubre todo el ciclo de vida del proyecto sino el diseño y
construcción.
Se considera apto para proyectos de misión crítica.
Metodología de desarrollo de centrado en ciclos cortos.
El modelo del dominio consta de diagramas de clases, relaciones
métodos y atributos.
Los métodos reflejan rasgos funcionales del software más no
conveniencias de programación.
Roles y Responsabilidades.
El FDD clasifica sus roles en las siguientes tres categorías:
Key roles
Project manager
Chief architect
Development manager
Chief programmer
10
Contenido
Class owner
Expertos del dominio
Supporting roles
Realese manager
Language lawyer/language guru
Build engineer
Tool smith
System administrator
Additional roles
Deployers
Techical writers
Testers
Vale la pena aclarar que un miembro de un equipo puede ejercer varios
roles y un rol pude ser compartido por varias personas.
Project Manager Es el líder administrativo y financiero del proyecto. Una
de sus tareas principales es proteger al equipo de distracciones externas
y permitir que el equipo de pueda trabajar en las condiciones
apropiadas. En el FDD el Project Manager tiene la última palabra sobre
temas referidos al alcance, tiempo y personal.
Chief Architect Es el responsable por el diseño global del sistema y de la
ejecución de todas las etapas del diseño. También tiene la última
palabra sobre las decisiones del diseño de todo el sistema. Si es
necesario, este rol puede ser dividido en dos roles como ser Domain
Architect y Tecnical Architect.
Development Manager Lleva diariamente las actividades de desarrollo y
resuelve cualquier conflicto que pueda ocurrir con el equipo.Además,
este rol incluye la responsabilidad de resolver problemas referentes a los
recursos. Las tareas de este rol pueden ser combinadas con las del Chief
Architect o el Proyect Manager. Chief Programmer Es un desarrollador
con experiencia, el cual participa en el an á lisis de los requerimientos y
11
Contenido
el diseño del proyecto. El Chief Programmer es el responsable de guiar a
pequeños equipos en el an á lisis, diseño y desarrollo de nuevas
Funcionalidades. Además, selecciona las funcionalidades a desarrollar de
la lista de funcionalidades de la próxima iteración en la última fase del
FDD, identifica las clases y el Class Owner que se necesita en el equipo
para la iteración. Con la ayuda de otros Chief Programmers resuelve
problemas técnicos y de recursos, y reporta el progreso del equipo
durante la semana.
Class Owner Trabaja bajo la guía del Chief Programmer en las tareas de
diseño, codificación, testing y documentación. Él es responsable del
desarrollo de las clases que se le asignaron como propias. Para cada
iteración los Class Owner participan en la decisión de que clase ser á
incluida en la lista de funcionalidades de la próxima iteración.
Expertos del dominio Los expertos del dominio pueden ser un usuario,
un cliente, un sponsor, un analista del negocio o una mezcla de estos.
Su tarea es poseer el conocimiento de los diferentes requerimientos del
sistema. El experto del dominio pasa el conocimiento a los
desarrolladores de manera tal que asegure que estos entreguen un
sistema completo.
Domain Manager Lidera al grupo de expertos del dominio y resuelve sus
diferencias de opini ó n concernientes a los requerimientos del sistema.
Realese Manager Controla el avance del proceso mediante la revisión de
los reportes del Chief Programmer y realiza pequeñas reuniones con é l.
Además, reporta el progreso del proyecto al gerente.
Language Lawyer/Language Guru Es un miembro del equipo responsable
de poseer un vasto conocimiento en, por ejemplo, un específico lenguaje
de programación o tecnología. Este rol es particularmente importante
cuando el equipo trabaja con una nueva tecnología.
Build Engineer Es la persona responsable de preparar, mantener y correr
el proceso de construcción, incluidas las tareas de mantenimiento de las
versiones y la publicación de la documentación.
12
Contenido
Toolsmith Es un rol para la construcción de herramientas específicas
para el desarrollo, conversión de datos y testeo. Además, puede trabajar
en la preparación y mantenimiento tanto de bases de datos o sitios web
destinados al proyecto.
System Administrator La tarea del administrador del sistema es
configurar, administrar y reparar los servidores, estaciones de trabajo y
equipos de desarrollo y testeo utilizados por el equipo.
Tester Verifica que el sistema recién creado cumpla con los
requerimientos del cliente. Puede llegar a ser una persona
independiente del equipo del proyecto.
Deployer Es el encargado de convertir la información existente
requerida por el nuevo sistema y participa en el lanzamiento de los
nuevos productos.
Technical Writer Se encarga de preparar la documentación para los
usuarios, quienes pueden formar parte o no del equipo del proyecto.
Los principios de FDD
Los principios de FDD son pocos y simples:
• Se requiere un sistema para construir sistemas si se pretende escalar
a proyectos grandes.
• Un proceso simple y bien definido trabaja mejor.
• Los pasos de un proceso deben ser lógicos y su mérito
inmediatamente obvio para cada miembro del equipo.
• Vanagloriarse del proceso puede impedir el trabajo real.
• Los buenos procesos van hasta el fondo del asunto, de modo que los
miembros del equipo se puedan concentrar en los resultados.
• Los ciclos cortos, iterativos, orientados por rasgos (features) son
mejores.
Categorias de Rol en FDD
Hay tres categorías de rol en FDD: roles claves, roles de soporte y roles
adicionales. Los seis roles claves de un proyecto son: (1) administrador del
proyecto, quien tiene la última palabra en materia de visión, cronograma y
13
Contenido
asignación del personal; (2) arquitecto jefe (puede dividirse en arquitecto de
dominio y arquitecto técnico); (3) manager de desarrollo, que puede combinarse
con arquitecto jefe o manager de proyecto; (4) programador jefe, que participa en
el análisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la
siguiente iteración; (5) propietarios de clases, que trabajan bajo la guía del
programador jefe en diseño, codificación, prueba y documentación, repartidos por
rasgos y (6) experto de dominio, que puede ser un cliente, patrocinador,
analista de negocios o una mezcla de todo eso.
Proceso FDD
Los cinco roles de soporte comprenden (1) administrador de entrega, que controla
el progreso del proceso revisando los reportes del programador jefe y
manteniendo reuniones breves con él; reporta al manager del proyecto; (2)
abogado/guru de lenguaje, que conoce a la perfección el lenguaje y la tecnología;
(3) ingeniero de construcción, que se encarga del control de versiones de los
builds y publica la documentación; (4) herramientista (toolsmith), que construye
herramientas ad hoc o mantiene bases de datos y sitios Web y (5) administrador
del sistema, que controla el ambiente de trabajo o productiza el sistema cuando
se lo entrega.
Los tres roles adicionales son los de verificadores, encargados del despliegue y
escritores técnicos. Un miembro de un equipo puede tener otros roles a cargo, y
un solo rol puede ser compartido por varias personas.
14
Contenido
Procesos secuenciales en FDD
FDD consiste en cinco procesos secuenciales durante los cuales se diseña y
construye el sistema. La parte iterativa soporta desarrollo ágil con rápidas
adaptaciones a cambios en requerimientos y necesidades del negocio. Cada fase
del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida.
Típicamente, la iteración de un rasgo insume de una a tres semanas. Las fases
son:
Fases
1) Desarrollo de un modelo general. Cuando comienza este desarrollo, los
expertos de dominio ya están al tanto de la visión, el contexto y los
requerimientos del sistema a construir. A esta altura se espera que existan
requerimientos tales como casos de uso o especificaciones funcionales. FDD, sin
embargo, no cubre este aspecto. Los expertos de dominio presentan un ensayo
(walkthrough) en el que los miembros del equipo y el arquitecto principal se
informan de la descripción de alto nivel del sistema. El dominio general se
subdivide en áreas más específicas y se define un ensayo más detallado para
cada uno de los miembros del dominio. Luego de cada ensayo, un equipo de
desarrollo trabaja en pequeños grupos para producir modelos de objeto de cada
15
Contenido
área de dominio. Simultáneamente, se construye un gran modelo general para
todo el sistema.
2) Construcción de la lista de rasgos. Los ensayos, modelos de objeto y
documentación de requerimientos proporcionan la base para construir una amplia
lista de rasgos. Los rasgos son pequeños ítems útiles a los ojos del cliente. Son
similares a las tarjetas de historias de XP y se escriben en un lenguaje que todas
las partes puedan entender. Las funciones se agrupan conforme a diversas
actividades en áreas de dominio específicas. La lista de rasgos es revisada por
los usuarios y patrocinadores para asegurar su validez y exhaustividad. Los
rasgos que requieran más de diez días se descomponen en otros más pequeños.
3) Planeamiento por rasgo. Incluye la creación de un plan de alto nivel, en el que
los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y
dependencia, y se asigna a los programadores jefes. Las listas se priorizan en
secciones que se llaman paquetes de diseño. Luego se asignan las clases
definidas en la selección del modelo general a programadores individuales, o sea
propietarios de clases. Se pone fecha para los conjuntos de rasgos.
4) Diseño por rasgo y Construcción por rasgo. Se selecciona un pequeño
conjunto de rasgos del conjunto y los propietarios de clases seleccionan los
correspondientes equipos dispuestos por rasgos. Se procede luego iterativamente
hasta que se producen los rasgos seleccionados. Una iteración puede tomar de
unos pocos días a un máximo de dos semanas. Puede haber varios grupos
trabajando en paralelo. El proceso iterativo incluye inspección de diseño,
codificación, prueba de unidad, integración e inspección de código. Luego de una
iteración exitosa, los rasgos completos se promueven al build principal. Este
proceso puede demorar una o dos semanas en implementarse.
FDD consiste en un conjunto de “mejores prácticas” que distan de ser nuevas
pero se combinan de manera original. Las prácticas canónicas son:
• Modelado de objetos del dominio, resultante en un framework cuando se
agregan los rasgos. Esta forma de modelado descompone un problema mayor en
otros menores; el diseño y la implementación de cada clase u objeto es un
problema pequeño a resolver.
16
Contenido
Cuando se combinan las clases completas, constituyen la solución al problema
mayor. Una forma particular de la técnica es el modelado en colores [CLD00], que
agrega una dimensión adicional de visualización. Si bien se puede modelar en
blanco y negro, en FDD el modelado basado en objetos es imperativo.
• Desarrollo por rasgo. Hacer simplemente que las clases y objetos funcionen no
refleja lo que el cliente pide. El seguimiento del progreso se realiza mediante
examen de pequeñas funcionalidades descompuestas y funciones valoradas por
el cliente. Un rasgo en FDD es una función pequeña expresada en la forma
<acción> <resultado> <por | para | de | a> <objeto> con los operadores
adecuados entre los términos. Por ejemplo, calcular el importe total de una venta;
determinar la última operación de un cajero; validar la contraseña de un usuario.
• Propiedad individual de clases (código). Cada clase tiene una sola persona
nominada como responsable por su consistencia, performance e integridad
conceptual.
• Equipos de Rasgos, pequeños y dinámicamente formados. La existencia de un
equipo garantiza que un conjunto de mentes se apliquen a cada decisión y se
tomen en cuenta múltiples alternativas.
• Inspección. Se refiere al uso de los mejores mecanismos de detección
conocidos.
FDD es tan escrupuloso en materia de inspección como lo es Evo.
• Builds regulares. Siempre se tiene un sistema disponible. Los builds forman la
base a partir de la cual se van agregando nuevos rasgos.
• Administración de configuración. Permite realizar seguimiento histórico de las
últimas versiones completas de código fuente.
• Reporte de progreso. Se comunica a todos los niveles organizacionales
necesarios.
FDD suministra un rico conjunto de artefactos para la planificación y control de los
proyectos. En http://www.nebulon.com/articles/fdd/fddimplementations.html se
encuentran diversos formularios y tablas con información real de
implementaciones de
FDD: Vistas de desarrollo, Vistas de planificación, Reportes de progreso,
17
Contenido
Reportes de tendencia, Vista de plan (<acción><resultado><objeto>), etcétera.
Se han desarrollado también algunas herramientas que generan vistas
combinadas o específicas.
Feature Driven Development FDD, tiene un desarrollo dirigido por prestaciones
Se basa en implementar sistemas en forma iterativa
Descubrimiento de la lista de prestaciones (features)
• Desarrollo de un modelo global
• Lista priorizada de prestaciones
• Plan de desarrollo
Implementación de las prestaciones
• Diseño y revisión del diseño
Introducción a la Gestión de Calidad de Software
• Construcción y revisión de código
• Reunión de liberación
Los requisitos tienden a ser buenos porque incluyen el modelo que fue
desarrollado en conjunto con los clientes
Incluye un método de seguimiento cuantitativo del plan
Proceso de FDD
18
Contenido
Las 8 mejores practicas
Elija FDD si
Está dispuesto a entregar cierta agilidad a cambio de un proceso
claramente escalable
Su organización tiene sólidas habilidades en UML
La mayoría de los requisitos son conocidos desde el
Comienzo o son más o menos estables
Usted no considera que los equipos auto-organizados son un factor crítico
de éxito
La comparación
RUP, XP y FDD tienen pocas similitudes entre si, aunque XP y FDD poseen
algunas más al ser ambos ligeros, orientados al cliente y de iteraciones cortas y
rápidas.
Tamaño de los equipos
FDD y XP se implementan mejor para proyectos cortos y equipos más pequeños,
siendo quizás FDD más escalable que XP, ya que a mayor tamaño de código y/o
equipo mayor es la necesidad de cierta organización.
Obtención de requisitos
19
Contenido
RUP y XP crean como base UseCases y UserStories, ambos describen los
requerimientos de la aplicación desde el punto de vista del usuario. Ambos definen
los requisitos técnicos sin meterse con detalles de implementaclón. FDD por el
contrario no define explícitamente esa parte del proyecto sobre la adquisición de
requisitos, y solo define el proceder a partir del momento en que ya se han
recogido dichos requisitos, de la forma que queramos, dividiendo los requisitos (de
forma similar a las UserStories) en las tres primeras fases del proyecto.
Carga de trabajo
FDD es por su parte un proceso intermedio, en el sentido de que genera más
documentación que XP (donde apenas existe fuera del código fuente) pero menos
que RUP (que intenta documentar todo). Se entrega bastante libertad a los
desabolladores, pero siempre bajo cierto orden marcado por una jerarquía
(arquitecto, programador jefe, etc), que representa también en nivel de
responsabilidad existente en cada caso.
Relación con el cliente
En contrapartida, la aseguración de la calidad en XP y FDD no se basa en
formalismos en la documentación, si no en controles propios y una comunicación
fluida con el cliente. Tanto en XP como en FDD, el cliente recibe después de cada
iteración un pedazo funcional del programa. A través de un ciclo de iteración corto
(pocas semanas) el cliente está informado constantemente sobre la situación del
proyecto y puede intervenir rápidamente si el desarrollo se aleja de sus
necesidades.
En XP el desarrollo ve en que dirección debe ir gracias al feedback del cliente, sin
ningún tipo de restricción previa. En FDD sin embargo existe el modelo general
desarrollado en la primera fase, que si bien evoluciona a lo largo del proyecto,
provee un marco general dentro del cual evoluciona el proyecto (mientras no sea
necesario cambiarlo).
Desarrollo
Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a poco
a la solucion sin entrar demasiado rápido en detalles, aunque las iteraciones de
XP y FDD tienen por lo general una duración menor que en RUP, puesto que la
20
Contenido
carga a llevar por los programadores a parte del desarrollo del propio software es
menor.
RUP y FDD se centran más en la organización global, y muchas de esas
actividades, como ejecución de pruebas, las asumen como obligatorias aunque sin
definirlas completamente, dejando libertad a las distintas subunidades del proyecto
para implementarlas a su manera (por ejemplo usar la programación por parejas
en partes complejas), aunque las directrices de la empresa suelen marcar el
camino a seguir.
En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseño
para conseguir una arquitectura sencilla y sin errores y las revisiones de código
guiadas por algún programador con más experiencia. Estas sesiones, habituales
en cada equipo e iteración, están más enfocadas al trabajo en conjunto que al
intercambio de impresiones y/o estado, como podría ser el caso de las daily
meetups de XP. En todo caso, como no podría ser de otra forma, todos los
métodos de desarrollo modernos ponderan la utilización frecuente de reuniones
entre los miembros del equipo, que pueden ir desde diarias, como propone
Evaluación del estado del proyecto
FDD es posiblemente el proceso más adecuado para definir métricas que definan
el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante
sencillo hacer un seguimiento de las mismas. XP también define esos
componentes pequeños, pero la tarea del reporting recae solo en los jefes de
proyecto, mientras que en FDD esta más distribuida en la jerarquía.
Puntos flacos.
Por desgracia ningún proceso puede ser considerado perfecto, ni ser aplicado en
su totalidad en en la mayoría de los casos, por lo que también es necesario saber
donde están sus puntos débiles para corregirlos, si es necesario.
FDD presenta su talón de Aqulles en la necesidad de tener en el equipo miembros
con experiencia que marquen el camino a seguir desde el principio, con la
elaboración del modelo global, puesto que no es tan ágil como podría serlo XP. Es
en todo caso este requisito una necesidad en cualquier proyecto si queremos
llevarlo a buen puerto con éxito. Su punto intermedio entre la libertad de XP y la
21
Contenido
rigurosidad de RUP lo hacen sin duda un proceso interesante, pero a pesar de
cambiar la forma de afrontar el problema, la jerarquía existente puede hacer que
las dependencias de esa gente experimentada sean grandes.
Conclusion
En síntesis, FDD es un método de desarrollo de ciclos cortos que se concentra en
la fase de diseño y construcción. En la primera fase, el modelo global de dominio
es elaboradopor expertos del dominio y desarrolladores; el modelo de dominio
consiste en diagramas de clases con clases, relaciones, métodos y atributos. Los
métodos no reflejan conveniencias de programación sino rasgos funcionales.
Algunos agilistas sienten que FDD es demasiado jerárquico para ser un método
ágil, porque demanda un programador jefe, quien dirige a los propietarios de
clases, quienes dirigen equipos de rasgos. Otros críticos sienten que la ausencia
de procedimientos detallados de prueba en FDD es llamativa e impropia. Los
promotores del método aducen que las empresas ya tienen implementadas sus
herramientas de prueba, pero subsiste el problema de su adecuación a FDD. Un
rasgo llamativo de FDD es que no exige la presencia del cliente.
FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la
década de 1990. Los autores sugieren su uso para proyectos nuevos o
actualizaciones de sistemas existentes, y recomiendan adoptarlo en forma
gradual. En [ASR+02] se asegura que aunque no hay evidencia amplia que
documente sus éxitos, las grandes consultoras suelen recomendarlo incluso para
delicados proyectos de misión crítica.
No cubre todo el ciclo de vida, sino diseño y construcción Se considera apto para
proyectos mayores o de misión crítica Hay arquitectos en FDD Numerosos
artefactos para el control del proceso
Ligero
A medio camino entre el desarrollo y la organización
Existe un jerarquía dentro del equipo
El codigo fuente tiene propietario
Los equipos varían en función de la funcionalidad a implementar
22
Contenido
El conocimiento de la aplicación se reparte a través de trabajo en equipo y
revisiones
Documentación aceptable
FDD es un proceso que ayuda al equipo a producir resultados periódicos y
tangibles.
Esta metodología utiliza pequeños bloques que contienen la funcionalidad
del sistema, llamados features.
Organiza los bloques que está n relacionados entre sí , en una lista llamada
feature set.
Hace énfasis en la obtención de resultados cada dos semanas.
Incluye estrategias de planificación que hacen que las features puedan
desarrollarse en dichos lapsos.
23
Contenido
BIBLIOGRAFIA
http://www.neleste.com/modelo-vista-controlador-y-algunas-variantes/
http://rogue-development.com/uploads/model_adapter/ModelAdapterExample.html
http://www.comusoft.com/modelo-vista-controlador-definicion-y-caracteristicas
http://www.sgmweb.es/modelo.asp
http://www.leandroiriarte.com.ar/spanish/web_mvc.php
24