04/2012

[Escribir texto]

Feature Driven Development (FDD)

Mdulo: Gestin Operativa de la Calidad de Software Maestra de Ingeniera de Software

INTEGRANTES: Centellas Hinojosa, Milca Luna Tellez, Linda Vaca Pinto, Roberto Carlos

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

I.

INTRODUCCION Feature Driven Development (FDD) como casi todas las metodologas es un modelo de desarrollo iterativo, especialmente orientado a obtener funcionalidades tangibles al terminar cada iteracin, objetivo que permite el vnculo con el cliente, que va viendo y testeando el producto durante todo el ciclo de desarrollo.

El desarrollo dirigido a las funcionalidades basado en cinco pasos, o actividades, secuenciales y especficas. Develop Overall Model, Build a Feature List, Plan by Feature, Design by Feature, Build By Feature y conjunto de mejores prcticas de desarrollo descritas en el presente documento. II. FEATURE DRIVEN DEVELOPMENT (FDD) Feature Driven Development (FDD) es una metodologa gil iterativo y adaptativo, es una tcnica de guiada por rasgos o caractersticas, centrada en el usuario, no as en el programador especialmente orientado a obtener funcionalidades tangibles al terminar cada iteracin, es decir, tiene por objetivo conseguir software funcional tras cada iteracin para as estar ms ntimamente relacionado con el cliente que va viendo y testeando el producto durante todo el ciclo de desarrollo. No cubre todo el ciclo de vida sino slo las fases de diseo y construccin. FDD se considera adecuado para proyectos grandes y de misin crtica as mismo no requiere un modelo especfico de proceso ya que se complementa con otras metodologas aunque hay coincidencias entre la programacin orientada por rasgos FOP y el desarrollo guidado por rasgos, FDD no necesariamente implementa FOP. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacin del progreso.

1. UN POCO DE HISTORIA FDD es marca registrada de la empresa, Nebulon Pty. Se lo report por primera vez en el libro Java Modeling in Color with UML de Peter Coad, Eric Lefebvre y Jeff DeLuca [1]; Naci a raz de que un proyecto de software de un gran banco en Singapur en 1997, llevaba un par aos de trabajo cuyo resultado solo fueron 3.500 pginas de casos de uso, modelo de objetos complejos y ningn cdigo con funcionamiento llegando concluirse que no se poda realizarse el proyecto. Entonces Jeff De Luca a finales de 1997 es contratado para salvar este gran y complicado proyecto de software que posteriormente contrata a Peter Coad.
2

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

Junto a 50 programadores durante 15 meses entregaron 2000 caractersticas funcionando, con un presupuesto por debajo del estimado y haciendo viable un proyecto no factible. Naturalmente el proyecto basado en FDD fue todo un xito, y permiti fundar el mtodo en un caso real de misin crtica. 2. PRINCIPIOS DE FDD A. VALORES 3 Se requiere un sistema para construir sistemas si se pretende escalar proyectos grandes. Un proceso simple es mejor. Las etapas del proceso debe ser, evidentemente valioso 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.

B. ROLES Hay tres categoras de rol en FDD: Roles claves. Roles de soporte. Roles adicionales.

ROLES CLAVE
ROL Administrador del proyecto Arquitecto jefe DESCRIPCION Es el que tiene la ltima palabra en materia de visin, cronograma, asignacin del personal, presupuesto e informes de progreso Puede dividirse en arquitecto de dominio y arquitecto tcnico son responsables del diseo general del sistema, llevan a cabo talleres de diseo (ms en que en proceso) y clarifican aspectos tcnicos. Lleva da a da las actividades de desarrollo, resuelve los conflictos de recursos, pueden combinarse con el Administrador de proyecto y Arquitecto jefe. Desarrolladores experimentados, que participa en el anlisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la cada iteracin. Lidera un grupo pequeo de desarrolladores. Es un rol clave, debe ser respectado por los desarrolladores y administradores. 3

Manager de desarrollo

Programador jefe

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad Propietarios de clases Son desarrolladores individuales, trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin de las caractersticas repartidas. Usuarios, clientes, patrocinadores, analista de negocios son base de conocimiento para desarrolladores. Tabla 1. Lista de roles Clave en FDD

Experto de dominio

ROLES SOPORTE
ROL Administrador de entrega DESCRIPCION Controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con l y reporta al manager del proyecto. Conoce a la perfeccin el lenguaje y la tecnologa. Encargado del control de versiones de los builds y publicacin de la documentacin. Construye herramientas ad-hoc Ej. Mantiene bases de datos y sitios Web. Controla el ambiente de trabajo y pone en produccin el sistema cuando se lo entrega. Tabla 2. Lista de roles Soporte en FDD

4
Abogado/gur de lenguaje Ingeniero de construccin Herramientista (toolsmith), Administrador del sistema,

ROLES ADICIONALES
ROL Verificadores y encargados del despliegue y escritores tcnicos. DESCRIPCION Un miembro de un equipo puede tener otros roles a cargo, y un solo rol puede ser compartido por varias personas.

Tabla 3. Lista de roles adicionales en FDD

C. CARACTERISTICA O RASGO Desde el punto de vista de una definicin es una pequea funcin expresada en trminos de valor del cliente. Para FDD es la forma de expresar un requisito del cliente expresada en la forma con los operadores adecuados entre los trminos. <Accin> <resultado> <por | para | de | a> <objeto> Por ejemplo, o calcular el importe total de una venta o determinar la ltima operacin de un cajero o validar la contrasea de un usuario.

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

D. PROCESOS FDD FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. La parte iterativa soporta desarrollo gil con rpidas 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. Tpicamente, la iteracin de un rasgo tiene un tiempo de 1 a 3 semanas mximo. 5

Fig. 1. Diagrama de los procesos de FDD

Las fases son: 1. DESARROLLAR UN MODELO GENERAL En esta fase participan los expertos de dominio, arquitecto en jefe, los programadores jefe para formar los equipos de modelado. Los expertos de dominio ya estn al tanto de la visin, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos 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 descripcin de alto nivel del sistema.

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

El dominio general podra subdividirse en reas ms especficas y se define un ensayo ms detallado para cada uno de los miembros del dominio. Luego de cada ensayo, un equipo de desarrollo trabaja en pequeos grupos para producir modelos de objeto de cada rea de dominio. Simultneamente, se construye un gran modelo general para todo el sistema. La Meta de esta fase es que todos los miembros del equipo obtengan una buena comprensin, compartida del dominio del problema y construir la base. 6

Fig. 2. Diagrama descriptiva del proceso desarrollar el modelo General en FDD.

2. CONSTRUIR UNA LISTA DE CARACTERSTICAS O RASGOS En esta fase el equipo encargado de listar los rasgos son: expertos de dominio, programadores jefe, Arquitectos Jefe. Los ensayos, modelos de objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de rasgos. Los rasgos son pequeos 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 especficas. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad. Los rasgos que requieran ms de diez das se descomponen en otros ms pequeos.
Todos los rasgos estn organizadas en una jerarqua de tres niveles: (1) rasgos sujetos al rea, relacionados a una cadena de caractersticas; (2) conjunto de rasgos, relacionados a un momento o intervalo sobre el dominio o del problema y por ltimo los (3) rasgos individuales que significa un mtodo en el dominio del problema.

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

Fig. 3. Diagrama de agrupacin de la lista de caractersticas en FDD.

3. PLANEAMIENTO POR CARACTERISTICA O RASGO En esta fase el equipo de planificacin es formada por: El administrador del proyecto el administrador de desarrollo y jefes de programadores, esta fase incluye la creacin de un plan de alto nivel, los miembros colaboran para obtener un anlisis y diseo completo a bajo 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 diseo. Luego se asignan las clases definidas en la seleccin del modelo general a programadores individuales, o propietarios de clases. Se pone fecha para los conjuntos de rasgos. El equipo necesita actualizar el modelo para soportar sus cambios.

Fig. 4. Diagrama descriptiva de la fase de elaboracin de plan por rasgos de FDD. 7

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

4. DISEO POR RASGO El equipo responsable de esta fase es: el programador jefe, los propietarios de clases, que trabaja en a nivel de paquetes, basado en la arquitectura tcnica. Se define con precisin las clases y objetos de diseo y se crea diagramas de secuencia si es necesario. Los rasgos son ms claros y se actualiza el modelo de la fase de la primera etapa. En esta fase una iteracin puede tomar de unos pocos das a un mximo de dos semanas. Puede haber varios grupos trabajando en paralelo. El proceso iterativo incluye inspeccin de diseo, codificacin, prueba de unidad, integracin e inspeccin de cdigo.

Fig. 4. Diagramas especificas en clases o secuencia de acciones producto de la fase de diseo por rasgos de FDD. 8

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

5. DESARROLLO DE RASGO Son responsables de esta fase los programadores jefe y propietarios de clases. Una iteracin puede tomar de unos pocos das a un mximo de dos semanas. Puede haber varios grupos trabajando en paralelo. El proceso iterativo incluye inspeccin de diseo, codificacin, prueba de unidad, integracin e inspeccin de cdigo. Luego de una iteracin exitosa, los rasgos completos se promueven al build principal.

E. PRACTICAS Uno de los motivos por los que nos puede resultar especialmente atractivo Feature Driven Development es el hecho que est construido alrededor de una serie de prcticas que si bien desde otras metodologas de desarrollo se apoyan, es en FDD en donde se exigen. 1. ISPECCIONES REGULARES Inspecciones obligatorias de cdigo, dos las principales razones de las inspecciones son encontrar ms errores as como diferentes tipos de errores como gran experiencia y aprendizaje. Se refiere al uso de los mejores mecanismos de deteccin conocidos. FDD es tan escrupuloso en materia de inspeccin como lo es Evo. 2. EQUIPOS DE RASGOS Los equipos son pequeos y dinmicamente formados. La existencia de un equipo garantiza que un conjunto de mentes se apliquen a cada decisin y se tomen en cuenta mltiples alternativas. La nica manera prctica de desarrollar por rasgo es que deben tener la propiedad de clase, bajo la direccin de un programador en jefe. Todos son propietarios de cdigo en el equipo lo que beneficia en la propiedad y compromiso colectivo destaca el trabajo en equipo. No se da por terminado hasta que el rasgo del equipo es terminado.

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

10

Fig. 5. Diagrama de Equipos de desarrollo dinmicos guiados por rasgos en FDD.

3. REPORTE DE PROGRESO Se comunica a todos los niveles organizacionales necesarios. FDD suministra un rico conjunto de artefactos para la planificacin y control de los proyectos.
FDD hace hincapi en la capacidad de proporcionar informacin sobre el progreso preciso, relevante y dentro y fuera del proyecto.

Device Management Ike II Cumulative Flow

240 220 200 180 160 140 120 100 80 60 40 20 0
-F 10 eb -F 17 eb -F 24 eb ar M 2ar M 9ar -M 16 ar -M 23 ar -M 30

Features

Time
Inventory Started Designed Coded Complete

Fig. 6. Diagrama descriptivo de los Reportes de avance del proyecto en FDD.

En http://www.nebulon.com/articles/fdd/fddimplementations.html se encuentran diversos formularios y tablas con informacin real de implementaciones de FDD: Vistas de desarrollo, Vistas de planificacin, Reportes de progreso, Reportes de tendencia, Vista de plan etc. Se han
10

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

desarrollado tambin algunas combinadas o especficas.

herramientas que

generan

vistas

Se comunica a todos los niveles organizacionales necesarios. FDD suministra un rico conjunto de artefactos para la planificacin y control de los proyectos. 4. GESTION DE CONFIGURACION 11 Esta prctica ayuda a separar el cdigo de las funcionalidades completas hasta la fecha as como llevar un control de versiones e historial de cambios. F. NORMAS DE USO DE FDD De 10-250 desarrolladores Practico para los trabajadores con experiencia por encima del promedio. No usar este modelo en equipos menores a 10 personas o cuando el equipo es escalando la curva de aprendizaje y no existe un sistema de apoyo.

5. POSICIN EN EL MERCADO Coad se uni en 1999 TogetherSoft hoy Borland que tenia 35 empleados (1999), 266 empleados (2000), 400 (hoy) 15/01/2003: Borland compra por $ 82.5 m + 9 millones de acciones . 6. FDD vs XP
RUP ??? Rational Heavy ~30 25-30 FDD 10-250 developers TogetherSoft (Borland) Medium ~6 (9 optional) Flexible ~10-15 XP 50 developers ??? Agile ~7 ~30

Developer Tools Process Roles Artifacts

FDD
Mas jerrquica Propietarios de Clases Exitoso con un desarrolladores por encima del promedio Cliente trabaja en fases 1, 2 y 4 El proceso es nico

XP
En pares Propietarios colectivos Exitoso con un desarrolladores con conocimiento promedio Cliente es parte del equipo Refactorizacin constante

Tabla 3. Cuadro de diferencias entre FDD y XP.

11

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

III.

CASO DE APLICACIN SOFTWARE PARA ENTIDAD FINANCIERA A. PROBLEMA Una entidad Financiera requiere un sistema para el manejo de las cuentas, los clientes y de las transacciones de estos, las cuales usualmente se hacen personalmente en alguna de las sucursales del banco, no obstante algunas de ellas como por ejemplo las consultas de saldo, o las consignaciones de una cuenta a otra se pueden realizar a travs de la pgina Web de la entidad, la cual debe estar habilitada para los clientes. B. PROPUESTA SOLUCION Primer paso conocer completamente la visin, el contexto y los requerimientos del sistema a desarrollar a. Visin: Manejo de las transacciones y de su interaccin con la base de datos de las cuentas de los clientes y el sistema de contabilidad. b. Contexto: Elaboraremos un diagrama de contexto que ilustre el marco del sistema.

12

Personal del banco

Clientes

Sistema de manejo de transacciones

Sistema de contabilidad del banco

Base de datos de cuentas

Fig. 7. Diagrama de contexto del problema

12

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

C. DESARROLLO DEL MODELO GENERAL DEL PROBLEMA Requerimientos: a. El sistema debe permitir la realizacin de transacciones (consulta de saldo, consignaciones de una cuenta a otra) a travs de la pgina Web de la entidad. b. La base de datos actual es muy estable, por lo cual el sistema debe trabajar con ella. c. El sistema de contabilidad tambin debe permanecer, tal como est en la actualidad, ya que es muy eficiente. d. El sistema debe ser seguro, es decir, debe detectar posibles fraudes a travs de la red, mediante accesos indebidos.

13

Cliente -Identificacion : Double = 0.0 +ObtenerDatos() : void

-Realizador -Operacion * 1 * -End1

Transaccin +Tipo : String = null +() * * -End3 -End4

Cuenta -Numero : Integer = 0 +ObtenerSaldo() : Integer

SistemaContabilidad

-End2

Fig. 7. Diagrama del modelo General del Problema.

D. CONSTRUCCION DE LISTA DE RASGOS El banco ha solicitado lo siguiente: Pgina Web. Actualizacin de la base de datos. Actualizacin del sistema de contabilidad Buenas interfaces de usuario (pagos, retiros, depsitos, consultas de saldo, actualizacin de datos). Sistema de seguridad del sistema. Manejo adecuado de las transacciones y consulta en interaccin con la base de datos y el sistema de contabilidad. Ahora, agrupamos las funcionalidades segn su afinidad y dependencia: Pgina Web dinmica e interactiva, en comunicacin con la base de datos y el sistema de contabilidad.

13

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

Sistema de consultas y transacciones y la correspondiente actualizacin de la base de datos y del sistema de contabilidad. Interfaces de usuario, para todas las consultas y las transacciones y su correspondiente integracin al sistema. Sistema de seguridad, que incluya las restricciones del sistema y proteccin contra accesos indebidos y su integracin al sistema.

E. PLANIFICACION DE RASGOS 14 Se han ordenado los grupos de funcionalidades, segn su prioridad y la dependencia y a cada una de ellas se le asign un responsable: Grupo 2: Luis. Grupo 3: Gabriela. Grupo 4: Jos. Grupo 5: Mara. Cronograma: La construccin de cada grupo de funcionalidades dura, mximo 2 semanas, y al final de este perodo se realizar una exposicin del avance del sistema al cliente. En total, la construccin del sistema dura 8 semanas y dos ms de prueba e implementacin la entidad financiera.

F. DISEO Y CONSTRUCCION DE RASGOS Estas dos fases, implican un proceso iterativo, que comienza con el diseo y termina con la prueba del funcionamiento de la funcionalidad implementada, pasando por la codificacin, su evaluacin y la integracin al sistema. El proceso se desarrolla, segn el orden definido en la fase de planificacin. Al finalizar las dos semanas dispuestas para cada grupo de funcionalidades, se muestra su implementacin al cliente, para verificar su aprobacin, si esto ocurre se procede con el siguiente grupo de funcionalidades, de lo contrario se inicia nuevamente el proceso iterativo introduciendo los cambios que el cliente especifico. Al finalizar las 8 semanas destinadas, se hace entrega del sistema y de la documentacin correspondiente que se ha ido recolectando en todas las fases del proceso, que incluye notas importantes sobre el sistema, descripcin de los errores y un manual de funcionamiento.

14

Feature Driven Development FDD Universidad Autnoma Gabriel Ren Moreno Gestin Operativa de la Calidad

IV.

CONCLUSION FDD combina muchas de las mejores prcticas de otros modelos giles, FDD fue creado inicialmente orientado hacia los equipos de proyectos grandes. FDD pone menos nfasis en el diseo inicial y enfoca rpidamente al punto donde el equipo puede ofrecer una nueva funcionalidad a alguna caracterstica de proyecto. FDD es flexible a mayor necesidad de cdigo, mayor organizacin y documenta lo necesario. Por otro lado las flaquezas que esta metodologa es la necesidad la de contar con miembros experimentados en el equipo y la dependencia de miembros en la jerarqua de roles. Debe resaltarse as mismo que es una de las metodologas giles que presenta guas muy concretas, con tcnicas muy especficas.

15

V.

REFERENCIAS
[1] Peter Coad, Eric Lefebvre y Jeff DeLuca. Java modeling in color with UML: Enterprise components and process. Prentice Hall, 2000. [2] Feature-driven development (FDD) http://en.wikipedia.org/wiki/Feature_Driven_Development [3] Feature-driven development (FDD), David J. Anderson http://www.agilemanagement.net. [4] Palmer, Stephen. "FDD History." N.p., 2010. Web. 27 Mar 2010. http://www.step10.com/SoftwareProcess/FeatureDrivenDevelopment/FDDHistory.html [5] Palmer, Stephen, John Felsing A practical guide to feature driven development the Coad Series Prentice Hall, 2000. [6] Feature-driven development (FDD), Portal, http://www.featuredrivendevelopment.com/ [7] Ejemplo Feature-Driven Development (FDD), Universidad Nacional de Colombia.

15