Otras metodologas giles

Anlisis y especificacin de sistemas multimedia

David Agudo Ruano Pablo Nioles Aznar Fernando Garca Cuss Pablo Delgado de Robles #aesmppdf

TABLA DE CONTENIDO
DSDM FDD Crystal Clear AUP Comparativa Bibliografa 3 6 9 12 18 19

DSDM
Dynamic Systems Development Method (DSDM) es una metodologa de trabajo para la combinacin eciente del conocimiento de las personas y tcnicas para realizar proyectos rpidamente. DSDM surgi de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las mejores prcticas que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de implementar el mtodo. Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios: Involucrar al cliente es la clave El equipo del proyecto debe tener el poder para tomar las decisiones. El foco est puesto en la entrega frecuente de productos. El principal propsito es entregar un sistema que satisface las actuales necesidades de negocio El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. Todos los cambios durante el desarrollo son reversibles. Los requerimientos estn especicados a un alto nivel. Las pruebas estn integradas a travs del ciclo de vida. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

DSDM dene cinco fases en la construccin de un sistema, stas son: Estudio de factibilidad. En esta fase se determina si la metodologa se ajusta al proyecto en cuestin. Estudio del negocio. Junto al cliente se determinan las caractersticas principales que debe contener el software. Iteracin del modelo funcional. Se desarrollan los aspectos funcionales del proyecto. Iteracin del diseo y construccin. Se inicia el diseo de las caractersticas anteriormente denidas y se empieza a construir los componentes de software. Implantacin. Fase en la que el cliente ya ha aceptado el producto y se implementa el sistema de produccin.

Es importante que los miembros del proyecto tengan claro el rol que van a desempear antes de que empiece. Cada rol tiene su responsabilidad. Los roles ms importantes son: Patrocinador ejecutivo. Es el responsable de tomar las decisiones ms importantes. Visionario. El encargado de asegurar que se satisfacen las necesidades del negocio Jefe de equipo. Lidera su equipo y se asegura que el equipo trabaja ecientemente en conjunto Asesor del usuario. Puede ser cualquiera que tenga un puesto importante en el equipo y aporta un conocimiento diario del proyecto Director del proyecto. Es el responsable de dirigir el proyecto. Facilitador. Se encarga de favorecer la comunicacin entre el equipo, administrar el desarrollo del proyecto. Desarrollador. Cubren todos los aspectos del desarrollo del software, desde los analistas hasta los programadores. Coordinador tcnico. Es la persona encargada de mantener la arquitectura y vericar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estndares tcnicos. Escriba. Se encarga de tomar nota de todas las decisiones y acuerdos que se han llevado a cabo durante las diferentes sesiones y reuniones. Tester. Encargado de crear y realizar las pruebas del proyecto

La rapidez de DSDM se basa en seleccionar las funcionalidades ms prioritarias para el negocio. El mecanismo para manejar esto en DSDM es el timebox. Cada timebox tiene una fecha de nalizacin y un conjunto de requerimientos a satisfacer indicando la prioridad de cada uno. Si algo no funciona se ignoran los requisitos con menos prioridad. Para dar prioridades a los requisitos de DSDM usa las MoSCoW rules. stas denen 4 clases de requisitos: M (Must Have). Imprescindibles para el proyecto. o S (Should Have). Necesarias para obtener el mximo de benecio. C (Could Have). Deben implementarse si el tiempo lo permite. o W (Wont Have). Pueden dejarse para otro momento.

DSDM ha sido utilizado en todo el mundo, desde British Ariways hasta el gobierno del Reino Unido. Sin ir ms lejos, el centro de reparaciones de Fujitsu aplic DSDM para renovar su sistema y en siete meses consigui pasar de atender 500 unidades mensuales a 4.000. Sin embargo tambin hay casos en los que DSDM no ha funcionado.

FDD
Feature Oriented Programming (FOP) es una tcnica de programacin guiada por rasgos o caractersticas y centrada en el usuario, no en el programador; su objetivo es sintetizar un programa conforme a los rasgos requeridos. 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 otras metodologas giles no cubre todo el ciclo de vida sino slo las fases de diseo y construccin y se considera adecuado para proyectos mayores y de misin crtica. FDD es, adems, marca registrada de una empresa, concretamente de 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 especco de proceso y se complementa con otras metodologas. Enfatiza cuestiones de calidad y dene claramente entregas tangibles y formas de evaluacin del progreso. Se lo report por primera vez en un libro de Peter Coad, Eric Lefebvre y Jeff De Luca: Java Modeling in Color with UML; luego fue desarrollado con 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.

Los principios de FDD son:

Se requiere un sistema para construir sistemas si se pretende escalar a proyectos grandes. Un proceso simple y bien denido trabaja mejor. Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio para cada miembro del equipo. Enorgullecerse 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 son mejores

Hay tres categoras de rol en FDD: roles claves, roles de soporte y roles adicionales. Los seis roles claves de un proyecto son: administrador del proyecto, quien tiene la ltima palabra en materia de visin, cronograma y asignacin del personal. arquitecto jefe (puede dividirse en arquitecto de dominio y arquitecto tcnico) manager de desarrollo, que puede combinarse con arquitecto jefe o manager de proyecto; programador jefe, que participa en el anlisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la siguiente iteracin. propietarios de clases, que trabajan bajo la gua del programador jefe en diseo, codicacin, prueba y documentacin, repartidos por rasgos. experto de dominio, que puede ser un cliente, patrocinador, analista de negocios o una mezcla de todo eso.

Los cinco roles de soporte son: 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; abogado/guru de lenguaje, que conoce a la perfeccin el lenguaje y la tecnologa; ingeniero de construccin, que se encarga del control de versiones de los builds y publica la documentacin; herramientista (toolsmith), que construye herramientas ad hoc o mantiene bases de datos y sitios Web. administrador del sistema, que controla el ambiente de trabajo.

Proceso FDD

Los tres roles adicionales son los de vericadores, 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. 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 nes de la dcada de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes, y recomiendan adoptarlo en forma gradual.

Crystal Clear
Alistair Cockburn es el propulsor de las metodologas Crystal. Estas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. Crystal realiza iteraciones cortas con feedback frecuente, y as, al contrario que otras metodologas, minimiza la necesidad de productos intermedios. La serie Clear es la ms gil de todas las metodologas Crystal, con mucho nfasis en la comunicacin, es de la que mas documentacin se dispone. Cockburn, en contra de la visin ingenieril de mantener los modelos completos y vigentes o que estn al da con la versin actual del lenguaje, ha alternado diversas visiones que lo han conducido a adoptar XP, en el sentido mas radical, o DSDM, y en este caso, a elaborar su propia familia de Metodologas Crystal. La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a una tabla elaborada por Cockburn que se usa en muchas metodologas giles para denir la complejidad de una metodologa. Los parmetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, si la cada de un sistema ocasiona incomodidades, indica que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del cuadro indican el nmero de personas afectadas a un proyecto.

Hay cuatro variantes de metodologas, segn en nmero de integrantes en el proyecto: Crystal Clear (Claro como el cristal) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Como hemos dicho antes, la ms documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeos de categora D6, aunque con alguna extensin se aplica tambin a niveles E8 a D10.

Los siete valores o propiedades de Crystal Clear son: 1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual, etc. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseador senior; eso se llama Experto al Alcance de la Oreja. Una reunin separada para que los integrantes se concentren mejor es descrita como El Cono del Silencio. 3. Mejora reexiva. Tomarse un pequeo tiempo (unas pocas horas por algunas semanas o una vez al mes) para pensar bien qu se est haciendo, reexionar, discutir, etc. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al mnager que la agenda no es realista, o a un colega que su cdigo necesita mejorarse. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es bueno encubrir los desacuerdos con gentileza y conciliacin, a la larga, acaban provocando enfados y distensiones, y esto es perjudicial para el equipo. Tcnicamente, estas cuestiones se han caracterizado como una importante variable de conanza. 5. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre direccin y prioridades, generalmente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea obligada a hacer otras cosas incompatibles. 6. Fcil acceso a usuarios expertos. Es muy importante el contacto directo con expertos en el desarrollo de un proyecto. Un encuentro semanal o semi-semanal con llamados telefnicos adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente tcnico con prueba automatizada, management de conguracin e integracin frecuente. Microsoft estableci la idea de los builds cotidianos, y no es una mala prctica. Muchos equipos giles compilan e integran varias veces al da.

Crystal Clear se basa en un estudio detallado de los inconvenientes de los modelos clsicos. La mayora de modelos de proceso se describan como secuencia de pasos. El problema con estos procesos es que estn describiendo un grafo de dependencia: el equipo no puede entregar un sistema hasta que est integrado y funciona. No puede integrar y vericar hasta que el cdigo no est escrito y funcionando. Y no puede disear y escribir el cdigo hasta que se les dice cules son los requerimientos. En lugar de esta interpretacin lineal, Cristal Clear destaca el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se distingue siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteracin ( CC requiere mltiples entregas por proyecto pero no muchas iteraciones por entrega), (4) la semana laboral, (5) el perodo de integracin, de 30 minutos a tres das, (6) el da de trabajo, (7) el episodio de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas. Los mtodos Crystal no dictan las prcticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros mtodos como Scrum o XP. Cockburn conesa que cuando imagin a Crystal Clear pensaba proporcionar un mtodo ligero; comparado con XP, sin embargo, Cristal Clear resulto muy pesado, en cambio es ms fcil de aprender e implementar. A pesar de su jerga chocante XP es ms disciplinado, piensa Cockburn.

AUP
El Proceso Unicado Agil es una versin reducida o simplicada del Proceso Unicado Rational (RUP). En este proceso dene un mtodo fcil y sencillo de comprender las tcnicas para desarrollar aplicaciones empresariales empleando tcnicas giles y conceptos que se mantienen vigentes y eles en RUP. El AUP aplica tcnicas giles en su metodologa incluyendo Modelado gil, Gestin de cambios gil, Refactorizacin de Base de datos para mejorar la productividad y efectividad y Desarrollo dirigido por pruebas. Caractersticas Las caractersticas de este proceso son: Iterativo e Incremental. - Descomposicin de un proyecto grande en partes ms pequeas, mini-proyectos. - Cada mini-proyecto es una iteracin. - Las iteraciones deben estar controladas. - Cada iteracin trata un conjunto de casos de uso. Ventajas del enfoque iterativo - Deteccin temprana de riesgos. - Administracin adecuada del cambio. - Mayor grado de reutilizacin. - Mayor experiencia para el grupo de desarrollo. Dirigido por Casos de Uso Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interacta con l. Casos de uso como el hilo conductor que orienta las actividades de desarrollo.

Centrado en la Arquitectura Concepto similar a la arquitectura de un edicio Varios planos con diferentes aspectos del edicio Tener una imagen completa del edicio antes que comience la construccin. Arquitectura en software Diferentes vistas del sistema: estructural, funcional, dinmico, etc. Plataforma en la que va a operar Determina la forma del sistema Arquitectura: determina la forma del sistema

Dimensin Dinmica del proceso

Se recuerda que un hito es un punto donde se evalan los objetivos logrados y se pueden tomar decisiones crticas. Desarrollo Iterativo

Disciplinas A diferencia de las disciplinas que podemos encontrar en el modelo RUP que son 9, el AUP tiene solamente 7 disciplinas, algunas de estas son combinaciones de dos disciplinas del RUP. 1. Modelo: Entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver este problema. 2. Implementacin (Aplicacin): Transformar el modelo(s) en cdigo ejecutable y realizar un nivel bsico de pruebas individuales. 3. Prueba: El objetivo de esta disciplina consiste en realizar una evaluacin para garantizar la calidad. Esto incluye buscar defectos, vericar que el sistema funciona correctamente, y que se cumplan los requisitos establecidos. 4. Despliegue: Realizar un plan para la presentacin del sistema y ejecutarlo para hacer que el sistema se encuentre a disposicin de los usuarios nales. 5. Gestin de Conguracin: Realizar la gestin de acceso a artefactos de su proyecto. Esto incluye no slo el seguimiento de las versiones del artefacto en el tiempo, sino tambin el control y la gestin de cambios para ellos. 6. Gestin del Proyecto: El objetivo es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestin de los riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc), y coordinar con las personas para garantizar que se entrega todo a tiempo y dentro del calendario. 7. Ambiente: Apoyar el resto de los esfuerzos para garantizar que el proceso adecuado, la orientacin (normas y directrices), y herramientas (hardware, software, etc) estn disponibles para el equipo de desarrollo en el momento en el que lo requieran. El primer aspecto notable es que las disciplinas han cambiado. La disciplina "Modelo" abarca el Modelado de Negocios, Requisitos y Anlisis y Diseo del RUP. El Modelo es una parte importante del AUP, como se puede ver, no domina el proceso. Las disciplinas Conguracin y Gestin del Cambio se transforma ahora en la Gestin de Conguracin, en su desarrollo gil de Gestin del Cambio son parte de de los esfuerzos de gestin de requerimientos, que forma parte de la disciplina del Modelo. Ciclo de vida

Analicemos todas las fases de este proceso: Fase de Concepcin Objetivo: Denir la razn de ser y el alcance del proyecto. Estudio de oportunidad. Visin = QU + PARA QU + CUNTO

Actividades Especicacin de los criterios de xito del proyecto Denicin de los requisitos Estimacin de los recursos necesarios Cronograma inicial de fases

Artefactos (Pieza de informacin producida, modicada y utilizada en un Proceso) Documento de denicin del proyecto

Fase de Elaboracin Objetivo Establecer un plan de proyecto y una arquitectura correcta del sistema

Actividades Anlisis del dominio del problema Denicin de la arquitectura bsica Anlisis de riesgos Planicacin del proyecto

Artefactos Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura bsica

Fase de Construccin Construccin - Objetivo: Desarrollar el sistema a lo largo de una serie de iteraciones - Actividades Anlisis Diseo Implementacin / Codicacin Pruebas (individuales, de integracin)

Fase de Transicin El sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y aceptacin y nalmente se despliega en los sistemas de produccin. Ventajas y desventajas del AUP Pasemos ahora a comenar algunas ventajas y desventajas de usar este modelo: Ventajas El personal sabe lo que esta haciendo. No obliga a conocer detalles, las personas implicadas en el proyecto no van a leer la documentacin entera si no que una orientacin de alto nivel Simplicidad: apuntes concisos. Agilidad: El AUP se ajusta a los valores y principios de la Alianza gil. Centrarse en actividades de alto valor: esenciales para el desarrollo, la atencin recae sobre las actividades que realmente cuentan. Herramientas independientes: a disposicin del usuario, se puede emplear cualquier herramienta con el AUP, es recomendable usar aquellas herramientas que se adapten mejor al trabajo a realizar que a menudo son simples e incluso de software libre. Fcil adaptacin de este producto: El producto AUP es fcil de manejar a traves de HTML por lo que no es necesario comprar una herramienta especial u obtener formacin avanzada para adaptar el AUP Desventajas El AUP es un producto muy pesado en relacin al RUP. Como es un proceso simplicado, muchos desarrolladores eligen trabajar con el RUP, por tener a disposicin mas detalles en el proceso.

Incrementos de tiempo

Los equipos AUP suelen ofrecer versiones de desarrollo al nal de cada iteracin en preproduccin rea(s). La primera entrega de versin de produccin a menudo toma ms tiempo para entregar versiones posteriores, este tiempo de espera puede ser de doce meses. La segunda versin de nueve meses. Las otras versiones se entregan cada seis meses. Resumen AUP se encarga o preocupa especialmente de la gestin de riesgos. En su metodologa, propone que aquellos elementos con alto riesgo obtengan una prioridad mayor prioridad en el proceso de desarrollo y sean elaborados en las etapas tempranas. El proceso AUP establece un Modelo ms simple que el que aparece en RUP por lo que rene en una nica disciplina las disciplinas de Modelado de Negocio, Requisitos y Anlisis y Diseo. El resto de disciplinas coinciden con las restantes de RUP.

Comparativa
Soporta varios equipos trabajando en paralelo. Todos los aspectos de un proyecto de seguimiento por funcin. Diseo por funcin y construir por los aspectos de caractersticas son fciles de entender y adoptar. Se ampla hasta los equipos grandes o proyectos as. Metodologa robusta con muchos artefactos y disciplinas para elegir. Escalas muy bien. La documentacin ayuda a comunicarse en entornos distribuidos. Prioridades establecidas sobre la base de mayor riesgo. El riesgo puede ser un negocio o de riesgo tcnico. Familia de metodologas diseadas para escalar por el tamao del proyecto y la criticidad. nica metodologa que dan cuenta de aquellos proyectos crticos de la vida. Como el tamao del proyecto crece, los equipos multifuncionales se utilizan para garantizar la coherencia. El "ser humano" componente se ha considerado para cada aspecto de la estructura de soporte del proyecto. Un nfasis en las pruebas es tan fuerte que al menos un probador se espera que haya en cada equipo del proyecto. Tiene como objetivo el desarrollo rpido de aplicaciones. Hace un nfasis muy fuerte en la fase de pruebas, en la que es necesario que un probador este en cada equipo del proyecto. Diseado desde cero por gente de negocios, por lo que el valor del negocio se identifica y se espera que sea la ms alta prioridad entrega. Tiene un enfoque especfico para determinar la importancia de cada requisito. Establece expectativas de las caractersticas desde el inicio del proyecto y no todos los requisitos sern incluidos en la entrega final. Promueve la propiedad del cdigo de forma individual frente a la participacin compartida / equipo. Iteraciones no estn tan bien definido por el proceso como otras metodologas giles. Los aspectos centrados en el modelo, pueden tener enormes efectos cuando se trabaja en los sistemas existentes que no tienen modelos. Los niveles ms altos de la ceremonia puede ser un obstculo en proyectos ms pequeos. Una mnima atencin a la dinmica del equipo. La documentacin es mucho ms formal que la mayora de los enfoques mencionados aqu. Espera a todos los miembros del equipo para ser colocado. Puede que no funcione bien para los equipos distribuidos. Los ajustes se requiere de un proyecto de tamao / estructura a otra, para seguir el sabor determinado de cristal para que el proyecto de tamao / criticidad. Pasar de un tipo de cristal a otro en la mitad del proyecto no funciona, ya que Cristal no fue diseado para ser compatible hacia arriba o abajo.

FDD

AUP

Cristal

DSDM

Espera que la participacin del usuario continue. Define varios artefactos y productos de trabajo para cada fase del proyecto, la documentacin es ms pesada. Acceso al material es controlada por un consorcio, y se podrn establecer tasas slo para acceder a material de referencia. No se especifican las tcnicas de programacin No es apto para proyectos donde la arquitectura es lo ms importante

Condicin
Equipo pequeo Requisitos altamente voltiles Los equipos distribuidos Cultura de alta Ceremonia Sistemas de alta criticidad Los clientes Mltiples/ Partes Interesadas

FDD
X -

AUP
X -

Cristal
X -

DSDM
X X X X

Bibliografa
http://en.wikipedia.org/wiki/Dynamic_systems_development_method http://users.dsic.upv.es/asignaturas/facultad/lsi/trabajos/292002.ppt http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf http://www.onlinebatraining.com/ba-interview-questions/what-is-aup-agile-unified-process.html http://es.wikipedia.org/wiki/Agile_Unified_Process http://kasyles.blogspot.com/2008/10/procesos-unificados-y-aup.html http://cgi.una.ac.cr/AUP/index.html http://en.wikipedia.org/wiki/FDD http://www.featuredrivendevelopment.com/