Está en la página 1de 26

DESARROLLO BASADO EN FUNCIONES (FDD)

ndice

DESARROLLO BASADO EN FUNCIONES (FDD)

DEFINICIN HISTORIA DEL MODELO DE CASCADA PRINCIPIOS BSICOS DEL MODELO DE CASCADA FASES DEL MODELO DE CASCADA INGENIERA Y ANLISIS DEL SISTEMA:

ERROR! BOOKMARK NOT DEFINED.

ERROR! BOOKMARK NOT DEFINED.

ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED.

ANLISIS DE LOS REQUISITOS DEL SOFTWARE:ERROR! BOOKMARK NOT DEFINED. DISEO: LA ETAPA DE DISEO CODIFICACIN: PRUEBA: MANTENIMIENTO: MODELO EN CASCADA PURO O SECUENCIAL ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. Bookmark not

Modelo en cascada realimentado para el ciclo de vidaError! defined. Modelos Modificados de Cascada El modelo Sashimi Modelo en Cascada Bennington 1956: La metodologa en cascada es esencialmente: Argumentos a favor del modelo de cascada Ventajas Desventajas Problemas del modelo de cascada El fracaso del modelo de cascada Uso La crtica del modelo de cascada

Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined.
i

ndice

Conclusin MAPA CONCEPTUAL CUESTIONARIO BIBLIOGRAFIA

Error! Bookmark not defined. 1 Error! Bookmark not defined. 23

ii

Contenido

DESARROLLO BASADO EN FUNCIONES (FDD) Introduccion Esta metodologa se basa en la definicin de funcionalidades que deben ser implementadas en el sistema. FDD est pensado para proyectos con duracin relativamente cortos, menores a un ao. En esta metodologa se presenta una jerarqua de funcionalidades, la primera en la jerarqua agrupa las propiedades relacionadas con aspectos en comn 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 comn del negocio. FDD constituye un proceso iterativo con iteraciones cortas (menores a dos semanas) obteniendo como resultado un software funcional que la direccin de la empresa cliente puede ver y monitorizar. FDD (Feature-Driven Development) es un proceso de ingeniera 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 participacin de los clientes (internos o externos) para el proceso de planificacin 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 programacin o el alcance de un modelo bien definido, sino que hace uso de una planificacin iterativo, que tiene como objetivo abstracto y satisfacer las principales necesidades de la empresa, que determinan la forma de desempeo del equipo de desarrollo. Los pasos y el modelo utilizado para el desarrollo de software EVOLUCIN SYS estn definidas por los pasos a continuacin e incluyen los siguientes procesos: Desarrollo Basado en Funcionalidades FDD con sus siglas en ingls Feature Driven Development es un enfoque gil para el desarrollo de sistemas. Fue desarrollado por Jeff De Luca y el viejo gur de la Orientacina Objetos Peter Coad. Como las otras metodologas adaptables,
1

Contenido

se enfoca en iteraciones cortas que entregan funcionalidad tangibleDicho enfoque no hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases de diseo y construccin. Sin embargo, fue diseado para trabajar con otras actividades de desarrollo de software y no requiere la utilizacin de ningn modelo de proceso especfico. Adems, hace nfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologas, FDD afirma ser conveniente para el desarrollo de sistemas crticos.

Definicion FDD es un mtodo de desarrollo de ciclos cortos que se concentra en la fase de diseo y construccin. 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, mtodos y atributos. Los mtodos no reflejan conveniencias de programacin sino rasgos funcionales. Feature Oriented Programming (FOP) es una tcnica de programacin guiada por rasgos o caractersticas (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 trminos de FOP, los objetos se organizan en mdulos o capas conforme a rasgos. FDD, en cambio, es un mtodo gil, iterativo y adaptativo. A diferencia de otros MAs, no cubre todo el ciclo de vida sino slo las fases de diseo y construccin y se considera adecuado para proyectos mayores y de
2

Contenido

misin crtica. FDD es, adems, marca registrada de una empresa, Nebulon Pty. Aunque hay coincidencias entre la programacin orientada por rasgos y el desarrollo guidado por rasgos, FDD no necesariamente implementa FOP. FDD no requiere un modelo especfico de proceso y se complementa con otras metodologas. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacin 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 segn va avanzando el proyecto, limitndose 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 funcin 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 quin las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada debern estar todos los dueos de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habr tambin un programador jefe (normalmente el ms experimentado) que har las funciones de lider del grupo que implementa esa funcionalidad. En el proceso de implementar la funcionalidad tambin se contemplan como partes del mismo (en otros mtodos se describen como actividades independientes) la preparacin y ejecucin de pruebas, as como revisiones del cdigo (para distribuir el conocimiento y aumentar la calidad) e integracin 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
3

Contenido

amplitud en un proyecto mayor de desarrollo por DeLuca, Coad y Stephen Palmer. Su implementacin de referencia, anlogo al C3 de XP, fue el Singapore Project; DeLuca haba sido contratado para salvar un sistema muy complicado para el cual el contratista anterior haba producido, luego de dos aos, 3500 pginas de documentacin y ninguna lnea de cdigo. Naturalmente, el proyecto basado en FDD fue todo un xito, y permiti fundar el mtodo en un caso real de misin crtica.

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 reunin de la comprensin del problema (Reunin de Planificacin), donde los miembros del equipo (Scrum Master y Team) y el cliente (Product Owner) definen lo que se producir durante el Sprint. En esta reunin, se establecen los requisitos para ser tratada, dejando que el tiempo de la construccin de modelos, artefactos y de negocios del usuario Historias. Los

artefactos producidos durante esta fase son: Visin de FBS (Estructura de Desglose de funciones), Diagrama de Clase Ejecutiva, el establecimiento de los criterios de aceptacin. 2. Construccin de la lista de funcionalidades. En esta etapa se construyen las listas de caractersticas que se abordarn durante el sprint y su FBS (similar a la WBS) es refinado. Despus de obtener este punto de vista, los responsables de cada una de las modelos, agrupados por caractersticas se denominan, de modo que el trabajo de anlisis y desarrollo se inici. Los artefactos producidos durante esta fase son: FBS: estructura de los componentes de averas y los diagramas de clases. 3. Plan de entregables en base a las funcionalidades a implementar. La planificacin de cmo las caractersticas se desarrollar marcar esta fase, donde se define la secuencia en el desarrollo de las caractersticas de las actividades empresariales, que se asignan a los responsables de acuerdo con la clase de
4

Contenido

desarrollo.

Los artefactos producidos durante esta fase son: Visin de FBS

(Estructura de Desglose de funciones), diagrama de clases. 4. Disear en base a las funcionalidades. El desglose por funcionalidad no es ms que el anlisis del sistema en s mismo. En esta etapa, se describe el desarrollo de documentos y artefactos, junto con la documentacin 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 mquina del Estado y de la comunicacin, si es necesario), Diagrama de entidad-relacin (DER) y Storyboard. 5. Implementar en base a las funcionalidades. En esta etapa, se hace para implementar las clases y mtodos. Como buena prctica, que aprob la revisin del cdigo y la generacin de evidencia para las pruebas unitarias antes de que se apliquen los planes de prueba y la profundidad integrada de la aplicacin generada. Los principales artefactos generados al final de esta etapa son el Cdigo, diagrama de clases (Final) Pantallas y Pruebas Funcionales Unidad. 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 funcin 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 cdigo 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 colaboracin de los dos grupos se genera un conocimiento global de la aplicacin a construir y los primeros bosquejos de las funcionalidades del software. Segunda Fase

Contenido

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 jerrquica. El trabajo de desarrollo es organizado en funcin de priorizacin de las funcionalidades definidas, en caso de obtener actividades cuyo desarrollo implique ms 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 lderes de proyecto deben delinear los hitos de finalizacin de cada iteracin 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 aplicacin. Mediante la utilizacin de lenguaje UML, se disea las clases atributos y mtodos requeridos para la implementacin de la funcionalidad de la aplicacin. La metodologa FDD est orientada completamente a la funcionalidad del software sobre las tareas. La metodologa recomienda organizar bloques de

funcionalidades para ser construidos en forma incremental mediante iteraciones de dos semanas de duracin, cada subgrupo de programacin debe ser dirigido por un programador jefe. Diseo por funcionalidades y Construccin por funcionalidades En esta etapa se selecciona un conjunto de funcionalidades de la lista y se procede a disear y construir la funcionalidad mediante un proceso iterativo. Una iteracin puede tomar de unos pocos das a un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo. Para cada una de estas iteraciones en la fase de diseo se debe generar: Diagrama de secuencia detallado Diagrama de clases actualizado Descripcin de clases y mtodos
6

Contenido

Notas adicionales

En la fase de construccin: Implementacion e inspeccion de metodos Testing unitarios para cada metodo Check in de las clases Main Build del sistema y testing de integracin.

Roles

Gerente de proyecto Arquitecto en jefe Gerente de desarrollo Programador en Jefe Experto del dominio Gerente del dominio Administrador de release Language Guru Ingeniero de construccin Administrador del sistema Tester Deployer Escritor Tcnico

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 Disear por Rasgo Construir por Rasgo

Contenido

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 ms tiempo, y las primeras solo son para el refinamiento del release siguiente. Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en tareas y se da un criterio de comprobacin. El Proceso Dicho proceso consiste de cinco fases secuenciales durante las cuales el diseo y la construccin del sistema se llevan a cabo. La parte iterativa del proceso de FDD (Diseo y Construccin) soporta un desarrollo gil, con adaptaciones rpidas 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 especificacin de requerimientos ya exista. Sin embargo, FDD no hace nfasis en la recoleccin y administracin 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 travs de una descripcin 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. Adems, el equipo de desarrollo discute y decide cual es el modelo de objetos ms apropiado para cada rea del dominio. Simultneamente, 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
8

Contenido

lista es divida en subconjuntos en base a la funcionalidad. Estas representan diferentes actividades con un rea especfica del dominio. La features list es revisada por los usuarios y sponsors del sistema para su validacin y aprobacin. 3- Plan by Feature (planear por rasgos) En esta etapa se incluye la creacin 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. Adems, las clases identificadas en la primera etapa son asignadas a cada programador. 4 y 5- Design and Build by Feature (disear y costruir por rasgos) Un conjunto de features es seleccionada de la features list. El diseo y construccin de la funcionalidad es un proceso iterativo durante el cual las features seleccionadas son producidas. Una iteracin puede llevar desde unos pocos das a un mximo de dos semanas. Este proceso iterativo incluye tareas como inspeccin del diseo, codificacin, testing unitario, integracin e inspeccin del cdigo. Luego que la iteracin 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 iteracin comienza. 1 Feature : Son pequeas 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 informacin del proyecto como ser documentacin, cdigo fuente, etc. CARACTERISTICAS FDD No cubre todo el ciclo de vida del proyecto sino el diseo y construccin. Se considera apto para proyectos de misin crtica. Metodologa de desarrollo de centrado en ciclos cortos. El modelo del dominio consta de diagramas de clases, relaciones mtodos y atributos. Los mtodos reflejan rasgos funcionales del software ms no conveniencias de programacin. Roles y Responsabilidades. El FDD clasifica sus roles en las siguientes tres categoras:
9

Contenido

Key roles Project manager Chief architect Development manager Chief programmer 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 lder 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 diseo global del sistema y de la ejecucin de todas las etapas del diseo. Tambin tiene la ltima palabra sobre las decisiones del diseo 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.Adems, este rol incluye la responsabilidad de resolver problemas referentes a los recursos. Las tareas de
10

Contenido

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 el diseo del proyecto. El Chief Programmer es el responsable de guiar a pequeos equipos en el an lisis, diseo y desarrollo de nuevas Funcionalidades. Adems, selecciona las funcionalidades a desarrollar de la lista de funcionalidades de la prxima iteracin en la ltima fase del FDD, identifica las clases y el Class Owner que se necesita en el equipo para la iteracin. Con la ayuda de otros Chief Programmers resuelve problemas tcnicos y de recursos, y reporta el progreso del equipo durante la semana. Class Owner Trabaja bajo la gua del Chief Programmer en las tareas de diseo, codificacin, testing y documentacin. l es responsable del desarrollo de las clases que se le asignaron como propias. Para cada iteracin los Class Owner participan en la decisin de que clase ser incluida en la lista de funcionalidades de la prxima iteracin. 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 revisin de los reportes del Chief Programmer y realiza pequeas reuniones con l. Adems, 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 especfico lenguaje de programacin o tecnologa. Este rol es particularmente importante cuando el equipo trabaja con una nueva tecnologa.

11

Contenido

Build Engineer Es la persona responsable de preparar, mantener y correr el proceso de construccin, incluidas las tareas de mantenimiento de las versiones y la publicacin de la documentacin. Toolsmith Es un rol para la construccin de herramientas especficas para el desarrollo, conversin de datos y testeo. Adems, puede trabajar en la preparacin 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 recin 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 informacin existente requerida por el nuevo sistema y participa en el lanzamiento de los nuevos productos. Technical Writer Se encarga de preparar la documentacin 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 lgicos y su mrito inmediatamente obvio para cada miembro del equipo. Vanagloriarse del proceso puede impedir el trabajo real. Los buenos procesos van hasta el fondo del a sunto, 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 categoras 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 visin, cronograma y
12

Contenido

asignacin del personal; (2) arquitecto jefe (puede dividirse en arquitecto de dominio y arquitecto tcnico); (3) manager de desarrollo, que puede combinarse con arquitecto jefe o manager de proyecto; (4) programador jefe, que participa en el anlisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la siguiente iteracin; (5) propietarios de clases, que trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin, 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 perfeccin el lenguaje y la tecnologa; (3) ingeniero de construccin, que se encarga del control de versiones de los builds y publica la documentacin; (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 tcnicos. Un miembro de un equipo puede tener otros roles a cargo, y un solo rol puede ser compartido por varias personas.

13

Contenido

Procesos secuenciales en 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 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 estn al tanto de la visin, 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 descripcin de alto nivel del sistema. El dominio general se subdivide 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

14

Contenido

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. 2) Construccin de la lista de rasgos. 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. 3) Planeamiento por rasgo. Incluye la creacin 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 diseo. Luego se asignan las clases definidas en la seleccin del modelo general a programadores individuales, o sea propietarios de clases. Se pone fecha para los conjuntos de rasgos. 4) Diseo por rasgo y Construccin por rasgo. Se selecciona un pequeo 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 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. Este proceso puede demorar una o dos semanas en implementarse. FDD consiste en un conjunto de mejores prcticas que distan de ser nuevas pero se combinan de manera original. Las prcticas cannicas 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 diseo y la implementacin de cada clase u objeto es un
15

Contenido

problema pequeo a resolver. Cuando se combinan las clases completas, constituyen la solucin al problema mayor. Una forma particular de la tcnica es el modelado en colores [CLD00], que agrega una dimensin adicional de visualizacin. 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 fun cionen no refleja lo que el cliente pide. El seguimiento del progreso se realiza mediante examen de pequeas funcionalidades descompuestas y funciones valoradas por el cliente. Un rasgo en FDD es una funcin pequea expresada en la forma <accin> <resultado> <por | para | de | a> <objeto> con los operadores adecuados entre los trminos. Por ejemplo, calcular el importe total de una venta; determinar la ltima operacin de un cajero; validar la contrasea de un usuario. Propiedad individual de clases (cdigo). Cada clase tiene una sola persona nominada como responsable por su consistencia, performance e integridad conceptual. Equipos de Rasgos, 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. Inspeccin. Se refiere al uso de los mejores mecanismos de deteccin conocidos. FDD es tan escrupuloso en materia de inspeccin como lo es Evo. Builds regulares. Siempre se tiene un sistema disponib le. Los builds forman la base a partir de la cual se van agregando nuevos rasgos. Administracin de configuracin. Permite realizar seguimiento histrico de las ltimas versiones completas de cdigo fuente. 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. En http://www.nebulon.com/articles/fdd/fddimplementations.html se encuentran diversos formularios y tablas con informacin real de

implementaciones de
16

Contenido

FDD: Vistas de desarrollo, Vistas de planificacin, Reportes de progreso, Reportes de tendencia, Vista de plan (<accin><resultado><objeto>), etctera. Se han desarrollado tambin algunas herramientas que generan vistas combinadas o especficas. 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 Implementacin de las prestaciones Diseo y revisin del diseo Introduccin a la Gestin de Calidad de Software Construccin y revisin de cdigo Reunin de liberacin Los requisitos tienden a ser buenos porque incluyen el modelo que fue desarrollado en conjunto con los clientes Incluye un mtodo de seguimiento cuantitativo del plan Proceso de FDD

17

Contenido

Las 8 mejores practicas

Elija FDD si Est dispuesto a entregar cierta agilidad a cambio de un proceso claramente escalable Su organizacin tiene slidas habilidades en UML La mayora de los requisitos son conocidos desde el Comienzo o son ms o menos estables Usted no considera que los equipos auto-organizados son un factor crtico de xito La comparacin RUP, XP y FDD tienen pocas similitudes entre si, aunque XP y FDD poseen algunas ms al ser ambos ligeros, orientados al cliente y de iteraciones cortas y rpidas. Tamao de los equipos FDD y XP se implementan mejor para proyectos cortos y equipos ms pequeos, siendo quizs FDD ms escalable que XP, ya que a mayor tamao de cdigo y/o equipo mayor es la necesidad de cierta organizacin. Obtencin de requisitos
18

Contenido

RUP y XP crean como base UseCases y UserStories, ambos describen los requerimientos de la aplicacin desde el punto de vista del usuario. Ambos definen los requisitos tcnicos sin meterse con detalles de implementacln. FDD por el contrario no define explcitamente esa parte del proyecto sobre la adquisicin 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 ms documentacin que XP (donde apenas existe fuera del cdigo fuente) pero menos que RUP (que intenta documentar todo). Se entrega bastante libertad a los desabolladores, pero siempre bajo cierto orden marcado por una jerarqua (arquitecto, programador jefe, etc), que representa tambin en nivel de responsabilidad existente en cada caso. Relacin con el cliente En contrapartida, la aseguracin de la calidad en XP y FDD no se basa en formalismos en la documentacin, si no en controles propios y una comunicacin fluida con el cliente. Tanto en XP como en FDD, el cliente recibe despus de cada iteracin un pedazo funcional del programa. A travs de un ciclo de iteracin corto (pocas semanas) el cliente est informado constantemente sobre la situacin del proyecto y puede intervenir rpidamente si el desarrollo se aleja de sus necesidades. En XP el desarrollo ve en que direccin debe ir gracias al feedback del cliente, sin ningn tipo de restriccin 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 rpido en detalles, aunque las iteraciones de XP y FDD tienen por lo general una duracin menor que en RUP, puesto que la
19

Contenido

carga a llevar por los programadores a parte del desarrollo del propio software es menor. RUP y FDD se centran ms en la organizacin global, y muchas de esas actividades, como ejecucin 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 programacin 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 diseo para conseguir una arquitectura sencilla y sin errores y las revisiones de cdigo guiadas por algn programador con ms experiencia. Estas sesiones, habituales en cada equipo e iteracin, estn ms enfocadas al trabajo en conjunto que al intercambio de impresiones y/o estado, como podra ser el caso de las daily meetups de XP. En todo caso, como no podra ser de otra forma, todos los mtodos de desarrollo modernos ponderan la utilizacin frecuente de reuniones entre los miembros del equipo, que pueden ir desde diarias, como propone Evaluacin del estado del proyecto FDD es posiblemente el proceso ms adecuado para definir mtricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeas es bastante sencillo hacer un seguimiento de las mismas. XP tambin define esos componentes pequeos, pero la tarea del reporting recae solo en los jefes de proyecto, mientras que en FDD esta ms distribuida en la jerarqua. Puntos flacos. Por desgracia ningn proceso puede ser considerado perfecto, ni ser aplicado en su totalidad en en la mayora de los casos, por lo que tambin es necesario saber donde estn sus puntos dbiles para corregirlos, si es necesario. FDD presenta su taln de Aqulles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboracin del modelo global, puesto que no es tan gil como podra 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
20

Contenido

rigurosidad de RUP lo hacen sin duda un proceso interesante, pero a pesar de cambiar la forma de afrontar el problema, la jerarqua existente puede hacer que las dependencias de esa gente experimentada sean grandes. Conclusion En sntesis, FDD es un mtodo de desarrollo de ciclos cortos que se concentra en la fase de diseo y construccin. 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, mtodos y atributos. Los mtodos no reflejan conveniencias de programacin sino rasgos funcionales. Algunos agilistas sienten que FDD es demasiado jerrquico para ser un mtodo gil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros crticos sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. Los promotores del mtodo aducen que las empresas ya tienen implementadas sus herramientas de prueba, pero subsiste el problema de su adecuacin 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 dcada 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 misin crtica. No cubre todo el ciclo de vida, sino diseo y construccin Se considera apto para proyectos mayores o de misin crtica Hay arquitectos en FDD Numerosos artefactos para el control del proceso Ligero A medio camino entre el desarrollo y la organizacin Existe un jerarqua dentro del equipo El codigo fuente tiene propietario Los equipos varan en funcin de la funcionalidad a implementar

21

Contenido

El conocimiento de la aplicacin se reparte a travs de trabajo en equipo y revisiones Documentacin aceptable FDD es un proceso que ayuda al equipo a producir resultados peridicos y tangibles. Esta metodologa utiliza pequeos 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 obtencin de resultados cada dos semanas. Incluye estrategias de planificacin que hacen que las features puedan desarrollarse en dichos lapsos.

22

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

23