Embedded Files
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. 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.
Los principios de FDD son pocos y simples:
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.
Hay tres categorías de rol en FDD:
roles claves
roles de soporte
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 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, basado en [ http://togethercommunities.com]
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.
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:
Las fases son:
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 á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.
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, 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.
Resumen:
Resumen:
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 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.
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.
Page updated
Google Sites
Report abuse