Ingeniera Multimedia

ANLISIS Y ESPECIFICACIN DE SISTEMAS MULTIMEDIA

PRCTICA 3

Otras Metodologas giles

Carlos Javier Lpez Lpez Cristina Palomares Crespo Rubn Martnez Vilar Vctor Puche Leal Grupo 4 (Mircoles 17:00 19:00)

ndicendice ............................................................................................................................................................ 2 1. Metodologas giles .................................................................................................................................. 3 1.1. Dynamic Systems Development Method ............................................................................... 3 1.2. Feature Driven Development ................................................................................................. 9 1.3. Crystal (Crystal Clear) ........................................................................................................... 15 1.4. Agile Unified Process............................................................................................................. 22 2. Comparativas .......................................................................................................................................... 27 2.1. Similitudes y Diferencias ...................................................................................................... 27 2.2. Ventajas y Desventajas .......................................................................................................... 29 2.3. Adecuacin para distinto tipo de aplicaciones.................................................................... 31 Bibliografa................................................................................................................................................. 32

1. Metodologas giles1.1. Dynamic Systems Development MethodINTRODUCCINEl mtodo de desarrollo de sistemas dinmicos es un mtodo para el desarrollo gil de software. Es un desarrollo iterativo e incremental sensible a requerimientos cambiantes que requiere la continua implicacin del cliente. La idea fundamental de DSDM se basa en que en vez de fijar las funcionalidades de un producto y despus el tiempo y el coste, fijar primero el coste y el tiempo y con esto fijado, determinar las funcionalidades que se pueden implementar en el producto. Fue desarrollado por un consorcio de proveedores y expertos en desarrollos de sistemas de informacin. El consorcio de DSDM es una organizacin no lucrativa y proveedor independiente, que posee y administra el marco de desarrollo. DSDM es una extensin del desarrollo rpido de aplicaciones (RAD). DSDM se centra en los proyectos caracterizados por presupuestos y agendas apretadas. Este mtodo trata los problemas comunes en el desarrollo de sistemas de informacin respecto al tiempo y presupuesto y otras razones como puede ser la falta de implicacin del usuario final. En algunas ocasiones se pueden insertar contenidos de otros mtodos como RUP o XP para complementar a DSDM. Existe otra metodologa gil que tiene semejanzas en procesos y conceptos al DSDM, es Scrum.

PRINCIPIOSDynamic Systems Development Method se basa en ocho principios: Centrarse en las necesidades del negocio: la entrega ha de responder a las necesidades empresariales determinadas y actuales. Un sistema perfecto que se ocupa de todas las necesidades del negocio es menos importante que el que se centra en necesidades crticas. Para ello hay que comprender bien las prioridades de la empresa y garantizar el subconjunto mnimo utilizable de caractersticas en el sistema. Entrega a tiempo: se han de poner plazos. Las entregas han de cumplir dichos plazos respetando los presupuestos y la calidad preestablecida. Colaboracin: la participacin de los usuario es la clave principal en la gestin de un proyecto eficiente y eficaz. Los usuarios y los desarrolladores han de compartir el lugar de trabajo (fsica o virtualmente) de modo que las decisiones se pueden tomar en colaboracin y con rapidez.

Compromiso de calidad: se ha de establecer la calidad del producto desde el principio asegurndose que no se convierta en una variable. Se ha de disear, documentar y aprobar adecuadamente. Tambin hay que hacer una revisin constante del producto y realizar pruebas tempranas y continuas. Construccin de forma incremental: a partir de las bases hay que realizar las entregas de la forma ms anticipada posible para el beneficio empresarial. Reevaluar las prioridades y viabilidad del proyecto con cada incremento. Desarrollo iterativo: siempre es mejor entregar una parte buena pronto que entregar todo perfectamente al final. Al entregar el producto con frecuencia desde las primeras etapas del proyecto, es probado y revisado en las sucesivas iteraciones y, consecuentemente, el producto es de mejor calidad. Comunicacin continua y clara: ha de haber un clara comunicacin entre todos los interesados del proyecto ya sea mediante documentacin, reuniones, comunicados o incluso talleres. Demostracin de control: presentacin de informes y planes hacia el cliente as como la evaluacin continua de la viabilidad del proyecto sobre la base de los objetivos de negocio.

FASESEl DSDM consiste en tres fases: pre-proyecto, proyecto de ciclo de vida y post-proyecto. Fase 1- El pre-proyecto: se identifican candidatos, se realiza una financiacin del proyecto y el compromiso de llevarlo a cabo. La respuesta de estas cuestiones en una etapa temprana evita los problemas en etapas posteriores del proyecto. Fase 2- El ciclo de vida del proyecto: el ciclo de vida del proyecto esta compuesto por cinco etapas: estudio(2 etapas), iteracin del modelo funcional, diseo e iteracin de la estructura e implementacin, que veremos el siguiente apartado en profundidad. Fase 3- El post-proyecto: en esta fase se asegura que el sistema funcione de manera eficaz y eficiente. Se realizan tareas relacionadas con el mantenimiento, mejoras y correcciones. Esto puede ser visto como desarrollo continuo del desarrollo iterativo. En lugar de terminar en esta etapa, el proyecto puede volver a fases o etapas anteriores para refinar el producto.

CICLO DE VIDA Y ATERFACTOSETAPA ACTIVIDAD DESCRIPCIN Etapa en que la adecuacin de DSDM se evala. Segn el tipo de proyecto, de organizacin y problemas personales, se toma la decisin, si se utiliza DSDM o no. Va a generar un informe de viabilidad, un prototipo de viabilidad y un esbozo de plan global que incluye un plan de desarrollo y un registro de riesgos. Etapa en que las caractersticas esenciales de los negocios y la tecnologa son analizados. Aproximacin a la organizacin de talleres, donde se reunirn los clientes para poder considerar todos los aspectos relevantes del sistema, y para ponerse de acuerdo sobre las prioridades de desarrollo. En esta etapa, se crea una lista de requisitos priorizada, una definicin del rea de negocio, una definicin de arquitectura del sistema, y un esbozo del plan de prototipos que se desarrollan. Determinar las funciones que se ejecutarn en el prototipo que resulta de esta iteracin. En esta etapa, un modelo funcional se desarrolla de acuerdo con el resultado de los entregables de la etapa de estudio de negocios. Ponerse de acuerdo sobre cmo y cundo el desarrollo de estas funcionalidades. Desarrollar el prototipo funcional, de acuerdo con el calendario acordado y el modelo funcional. Verificar la correccin del prototipo desarrollado. Esto se puede hacer a travs de las pruebas realizadas por los usuarios finales y / o documentacin de la revisin. El entregable es un documento de prototipos y su revisin funcional. Identificar los requisitos funcionales y no funcionales que deben estar en el sistema ensayado. Y en base a estas identificaciones, una estrategia de implementacin. Ponerse de acuerdo sobre cmo y cundo se dan cuenta estos requisitos. Crear un sistema (prototipo de diseo) que con seguridad puede ser

Estudiar

Estudio de viabilidad

Estudio de la empresa

Iteracin del Identificar modelo prototipo funcional funcional Planificacin de la programacin Crear prototipo funcional Revisar prototipo funcional Disear y Identificar el construir la prototipo de iteracin diseo Planificacin de la programacin Crear prototipo

de diseo

entregado a los usuarios finales para el uso diario, tambin para fines de prueba. Comprobar la exactitud del sistema diseado. Una vez ms, las pruebas y el examen son las principales tcnicas utilizadas. Una documentacin de usuario y un registro de prueba se desarrollar en esta fase. Los usuarios finales deben aprobar el sistema de prueba para la ejecucin, y crear las directrices con respecto a la aplicacin y el uso del sistema. Formar los futuros usuarios finales en el uso del sistema. Implementar el sistema de prueba en la ubicacin de los usuarios finales. Examinar el impacto del sistema implementado en el negocio, una cuestin central ser si el sistema cumple con los objetivos establecidos al inicio del proyecto. Dependiendo de este proyecto, se pasa a la etapa siguiente, el post-proyecto o vuelve de nuevo a una de las etapas anteriores para un mayor desarrollo, en este ltimo caso, se generarn documentos de la revisin del proyecto.

Revisin del prototipo de diseo

Ejecucin

Aprobacin y directrices Formar a los usuarios Implementar

Revisin del negocio

En este grfico se pueden observar la relacin entre las actividades de las distintas etapas que se acaban de describir para una mayor claridad.

TCNICAS BSICAS DE DSDMTimeboxing - Timeboxing es una de las tcnicas de proyectos de DSDM. Se utiliza para realizar el desarrollo de un SI a tiempo, dentro del presupuesto y con la calidad deseada. La idea principal detrs de Timeboxing es dividir el proyecto en partes, cada una con un presupuesto fijo y una fecha de entrega. Para cada porcin una serie de requisitos que se seleccionan son priorizados de acuerdo con la MoSCoW principio. Como el tiempo y el presupuesto es fijo, las nicas variables que quedan son los requisitos. As que si un proyecto se est quedando sin tiempo ni el dinero de los requisitos con la prioridad ms baja se omiten. Esto no significa que un producto no acabado se entrega. Como se acaban las funciones con crticas, el sistema cumple con las necesidades del negocio. Ningn sistema est construido totalmente en el primer intento.

MosCow - representa una forma de dar prioridad a los elementos. En el contexto del DSDM la tcnica de MoSCow es utilizada para dar prioridad a las necesidades. Se trata de un acrnimo en ingls que significa: MOST- debe tener este requisito SHOULD- es conveniente tener este requisito, si es posible, pero el xito del proyecto no depende de l. COULD- podra tener este requisito si el transcurso del proyecto no se ve afectado. WOULD- tendra este requisito si hay tiempo. Prototipos - Esta tcnica se refiere a la creacin de prototipos del sistema en fase de desarrollo en una etapa temprana del proyecto. Permite la deteccin temprana de deficiencias en el sistema y permite a los usuarios futuros del sistema participar en la creacin del proyecto. Esta participacin es uno de los factores clave de xito de DSDM. Pruebas - Un tercer aspecto importante de la meta del DSDM para la creacin de un SI con buena calidad. A fin de alcanzar una solucin de buena calidad, los usuarios y testers prueban el sistema a lo largo de cada iteracin. Taller - Una de las tcnicas del DSDM. Tiene como objetivo reunir los diferentes actores (roles) del proyecto para discutir los requisitos, funciones y el entendimiento mutuo. En un taller, las partes interesadas se reunen y discuten acerca del proyecto y su desarrollo. Modelado - Esta tcnica es esencial, y utilizada a propsito para visualizar la representacin esquemtica de un aspecto especfico del sistema o rea de negocio que se est desarrollando. El modelado da una mejor comprensin para el equipo de un proyecto de DSDM en un dominio del negocio. Gestin de la Configuracin - tcnica es importante para la naturaleza dinmica de DSDM. Dado que hay ms de una parte siendo manejada al menos una vez durante el proceso de desarrollo del sistema, y los productos se entregan con frecuencia a una velocidad muy rpida, los productos deben ser controlados estrictamente como logran su terminacin, aunque sea parcial.

ROLESEs muy importante que los miembros del proyecto queden asignados a sus respectivas funciones antes de empezar el proyecto. Cada rol tiene sus propias responsabilidades. Las funciones son las siguientes: Patrocinador Ejecutivo: llamado el "campen del proyecto". Tiene la capacidad y la responsabilidad de destinar fondos y recursos apropiados. Esta funcin tiene un mximo poder de tomar decisiones. Visionario: tiene la responsabilidad de inicializar el proyecto, asegurando que los requisitos esenciales se encuentran desde el principio. Otra tarea es supervisar y mantener el proceso de desarrollo en el camino correcto. Embajador: aporta el conocimiento de la comunidad de usuarios en el proyecto, asegura que los desarrolladores reciben la cantidad suficiente de retroalimentacin de los usuarios durante el proceso de desarrollo. Asesor del usuario: puede ser cualquier usuario que representa un punto de vista importante y aporta el conocimiento diario del proyecto.

Project Manager: puede ser cualquier persona de la comunidad de usuarios o personal del equipo que gestiona el proyecto en general. Coordinador tcnico: responsable en el diseo de la arquitectura del sistema y de controlar la calidad tcnica en el proyecto. Jefe de equipo: lidera a su equipo y asegura que funciona de manera efectiva en su conjunto. Desarrollador: interpreta los requisitos del sistema y del modelo. Incluye el desarrollo de los cdigos de entregables y la construccin de prototipos. Tester: comprueba la correccin tcnica en una extensin mediante la realizacin de algunos testeos.El tester tendr que dar algunos comentarios y documentacin. Escriba: responsable de recopilar y registrar los requerimientos, acuerdos y decisiones tomadas en cada taller. Facilitador: responsable en el manejo de los talleres, acta como un motor para la preparacin y la comunicacin en los usuarios. Funciones de especialista: Business Architect, gerente de calidad, integrador de sistemas, etc

FACTORES PARA EL XITO DE DSDMAceptacin por los empleados y la directiva de DSDM como mtodo para el desarrollo, motivando ms a los empleados y fomentando la continuacin del proyecto. Compromiso de la administracin para asegurar la participacin del usuario final. El enfoque de creacin de los prototipos requiere una gran participacin del usuario para la aprobacion y juicio a stos. El equipo de proyecto ha de estar compuesto por miembros hbiles que conformen una unin estable. Tambin es importante la potenciacin de sus miembros, ya que uno o varios de ellos tendrn que tomar importantes decisiones sin consultar al escaln superior dentro de la empresa ya que se suele perder mucho tiempo en ello. El equipo de proyecto tambin ha de tener disponible las herramientas necesarias para llevar a cabo su trabajo. Ha de haber una relacin entre el cliente y el vendedor tanto para proyectos internos como para contratos externos.

1.2. Feature Driven DevelopmentQu es FDD?La metodologa FDD, es uno de los procesos giles de los que menos se habla. Se puede encontrar informacin e intercambio de documentos en foros y libros de desarrollo de software gil.

FDD fue inventada por Jeff de Luca, quien pens en disear un modelo de trabajo para un gran equipo. Esto hace que los desarrolladores tengan que llevar a cabo diferentes retos, pues, por ejemplo, en un grupo pequeo lo ms probable es que tengan xito con su proyecto. Pero en uno ms grande no se espera que todos estn igualmente cualificados. Adems de trabajar con grandes equipos y planes, FDD se caracteriza por dar mucha importancia a la calidad del proyecto durante todo el proceso de desarrollo y por los precisos informes de estado y seguimiento significativos para todos los niveles de liderazgo.

Caractersticas La principal diferencia entre dos programadores trabajando en un despacho y cien personas ocupndose de un trabajo multimillonario es la comunicacin. Si hablamos de los desarrolladores como nodos conectados entre s por una red, dos nodos necesitan una conexin entre ambos. Sin embargo para cien desarrolladores tendremos 4950 conexiones. Si esto no se organiza correctamente se dedicar demasiado tiempo a la comunicacin y los resultados no se podrn integrar. Cuanto mayor sea el equipo, la dificultad de comunicacin ir en aumento. En un equipo de desarrollo de muchos componentes siempre aparecer el problema de la comunicacin, adems de por la cantidad de personas, por los diferentes idiomas que puede hablar cada uno de ellos. Las traducciones siempre hacen que se pierdan datos importantes e informacin que podra ser clave para conseguir aquello que el cliente quiere. A medida que el tamao del sistema de software crece, tambin lo hace de manera cuadrtica la complejidad del mismo. El mtodo para resolver problemas tan grandes es la descomposicin: dividir el problema en otros cada vez ms pequeos, hasta llegar a un tamao de problema que podemos manejar. A una pareja de programadores les resultara muy costoso solucionar tantos problemas en un perodo de tiempo corto. Aadiendo ms programadores se podran resolver estos problemas de forma paralela y de as conseguir disminuir el tiempo de trabajo. Se puede hablar de calidad desde la cara externa y la interna, de manera distinta pero ambas siempre relacionadas. Un usuario hablando de la calidad de un sistema, hablar de la interfaz de usuario, el tiempo de respuesta, la fiabilidad y la facilidad de uso. Por otro lado, el desarrollador dir que su sistema tiene calidad cuando el diseo es elegante, cuando es fcil mantenerlo y mejorarlo y cuando se cumplen las pautas establecidas. Tomando de nuevo el ejemplo de los dos programadores y el equipo de

desarrolladores: si una organizacin establece un nivel interno de calidad aceptable, puede incluso ser menor que la idea de los desarrolladores individuales. Por tanto en un FDD, el equipo desde un principio tiene que decidir qu es un nivel aceptable de calidad y qu no.

Componentes ArtefactosUn proyecto de desarrollo de software incluye: El enunciado del problema, el propsito o alguna lista de metas de alto nivel de requisito que describen lo que el sistema tiene que hacer. Esto es vital para que el proyecto exista. Una lista con los roles de cada integrante del equipo. Al escribir esto, se obtiene un organigrama abstracto. Los diferentes roles requieren un conjunto de habilidades y nivel de experiencia. Cada rol define las responsabilidades y lleva un control sobre las cuentas. Personas con habilidades y experiencia necesarias para poder desempear las funciones del organigrama abstracto. Al asignar a cada persona una funcin del organigrama, se produce un grfico de organizacin para el proyecto. Un conjunto de procesos delimitados que describen cmo interactan entre s las personas del equipo para producir el sistema software deseado. Un conjunto de tecnologas, lenguajes de programacin, herramientas de desarrollo, productos Una arquitectura, un marco que contendr la construccin del sistema de software. El proyecto puede reutilizar una arquitectura existente. Puede no existir el marco apropiado, por ello las primeras actividades del proyecto necesitan producir y probar la arquitectura.

RolesFeature Driven Development define seis funciones principales en el proyecto. Cuando se relacionan estas funciones con los procesos del FDD se organiza un proyecto en el que se utilizan plenamente las potencias individuales y se apoya siempre a las reas de debilidad. Los seis roles clave son: Jefe de Proyecto. Es el responsable administrativo del proyecto, informa sobre el progreso, la gestin de presupuestos, la lucha por el nmero de empleados, gestiona los equipos, el espacio y los recursos Su trabajo como director del proyecto es crear y mantener un entorno en el que el desarrollo funcione mejor, en el que el equipo trabaje de forma productiva. Ser quien proteja al equipo de distracciones externas. El director de un proyecto FDD es quien tiene la ltima palabra sobre el avance, el cronograma y el personal. Dirige el proyecto superando los obstculos administrativos y financieros. Arquitecto Jefe. Se responsabiliza del diseo global del sistema. Es quien tiene la ltima palabra, dirige las sesiones del taller de diseo, donde el equipo de trabajo colabora en el diseo del sistema. El Arquitecto Jefe ha de tener unas buenas habilidades tcnicas y resolutivas. Encargado de Desarrollo. Dirige las actividades de desarrollo del da a da. Este papel requiere buenas habilidades tcnicas, resuelve los conflictos cotidianos cuando los Programadores Jefe no pueden hacerlo entre ellos. En algunos casos se combina con el rol de Jefe de Proyecto. Es habitual encontrar a una persona que realice dos papeles a la vez, o que los combine con otras personas.

Programadores Jefe. Desarrolladores experimentados que han pasado por ciclos de vida de un desarrollo de software algunas veces. Participan en los anlisis de requisitos, disean actividades del proyecto y son responsables de dirigir a grupos de 3 a 6 personas. Los Programadores Jefe trabajan a la vez con otros de su mismo rol. Por s mismos producen resultados de calidad en un tiempo. Son personas de confianza para sus administradores y respetadas por sus compaeros desarrolladores. Propietarios de la Clase. Desarrolladores que trabajan como miembros de pequeos equipos de desarrollo bajo la direccin de un Jefe Programador. Disean, codifican, prueban y documentan las caractersticas requeridas por el sistema software. Son desarrolladores con talento que, con ms experiencia, estarn capacitados para jugar el papel de Programador Jefe. Hay otros que se conforman con ser programadores y no guiar a otras personas. Expertos de Dominio. En este rol se agrupa a los usuarios, clientes, patrocinadores, analistas de negocio y combinaciones de stos. Explican con profundidad a los desarrolladores las tareas que el sistema debe realizar. Son la base del conocimiento que permitir a los desarrolladores entregar el sistema correcto. Es fundamental su conocimiento y participacin para el xito del sistema. Estos expertos deben presentar buenas habilidades verbales y escritas. Implcitamente FDD sugiere unas funciones de apoyo adicionales de apoyo: Jefe de Lanzamiento. Para equipos grandes que realicen el FDD, lidera a los Expertos de Dominio y es responsable de resolver las diferencias de opinin sobre los requisitos del sistema. Si el proyecto fuera pequeo, este rol se combinara con el de Jefe de Proyecto. Abogado de Lenguajes. Responsable de conocer el lenguaje de programacin o una tecnologa especfica. Su funcin es til en un proyecto en el que el lenguaje escogido se usa por primera vez. Cuando el equipo est al da con el lenguaje, este papel se ir reduciendo hasta desaparecer por completo. Especialista en Herramientas. Establece, mantiene y ejecuta el proceso construccin. Esto incluye la gestin del control de la versin del sistema, la publicacin de los informes o documentos generados y la escritura de cualquier script de implementacin. Administrador del Sistema. Configura, gestiona y resuelve los fallos de los servidores y la red de estaciones de trabajo especficas para el equipo del proyecto. Tambin se ve involucrado a menudo en la implementacin inicial del sistema. Tambin sugiere unos roles adicionales: Testers (encargados de pruebas). Verifican que las funciones del sistema cumplen con los requisitos de los usuarios y que el sistema las realiza correctamente. Implementadores. Convierten los datos existentes a los nuevos formatos requeridos por el nuevo sistema. Trabajan en las nuevas versiones del sistema. - Escritores Tcnicos. Escriben la documentacin de usuario.

ProcesosFDD est documentado como cinco procesos que consisten en tres proyectos iniciales: actividades que crean un modelo general, una lista inicial de las funciones valuadas por el cliente (caractersticas) y un plan inicial de desarrollo general. A estos les siguen otros dos proyectos relacionados con el diseo y la construccin de las actividades, que se repiten simultneamente. Cada iteracin de estas actividades tiene unas caractersticas relacionadas a travs de un anlisis, diseo, construccin y verificacin de ciclo.

El trabajo se realiza en grupo (tanto el modelado como el desarrollo) para conseguir que todos formen parte del proyecto y que los inexpertos puedan aprender de las discusiones de los ms experimentados. Siempre habr un responsable (Arquitecto Jefe o Programador Jefe) que tendr la ltima palabra si no se llega a un acuerdo. Develop an Overall Model Los criterios de entrada en el primer proceso es que en esta actividad de proyecto inicial trabajen los miembros del dominio y el desarrollo juntos, bajo la direccin de un Arquitecto Jefe. Los Expertos de Dominio realizan un recorrido de alto nivel del mbito de aplicacin del sistema. Despus ellos realizan tutoriales detallados para cada rea del dominio que se va a modelar. Tras esto se forman pequeos grupos que crean su propio modelo en apoyo al tutorial de dominio y presentan sus resultados para una revisin y discusin. Uno de los modelos presentados es seleccionado por consenso y se convierte en el modelo para el rea de dominio, que se combina con el modelo general. El Arquitecto Jefe ha de estar satisfecho con el modelo de objeto que el grupo ha creado, ahora podemos salir del proceso. El modelo de objeto se actualiza iterativamente con el proceso 4: Diseo por Rasgo. Build a Feature List Una vez completado el proceso 1, se cumplen los criterios de entrada del proceso 2. Un equipo compuesto por el Jefe de Programadores desde el proceso 1 est formado para descomponer el dominio funcional. Basado en la particin del dominio por los Expertos de Dominio, el equipo divide el dominio en un nmero de reas (conjunto de caractersticas). Cada rea se subdivide en una serie de

actividades, y cada paso dentro de una actividad se identifica como un rasgo o caracterstica. El resultado es una lista de caractersticas clasificadas jerrquicamente. Una vez desarrollada la lista de caractersticas y conseguida la satisfaccin del Jefe de Proyecto y del Encargado de Desarrollo, podemos salir del proceso. Plan by Feature El criterio de entrada es el criterio de salida del proceso 2: que el equipo tenga una lista de caractersticas completada. El Jefe de Proyecto, Encargado de Desarrollo y los Programadores Jefe planifican el orden en que se van a llevar a cabo las funciones, se asignan al equipo de desarrollo y se define la complejidad de las caractersticas que han de aplicarse. Primero se considera la secuencia de desarrollo, luego la asignacin de los conjuntos de funciones al Jefe de Programadores y, hecho esto, considerar cuales de las clases fundamentales se asignan a los desarrolladores (recordando que el Programador Jefe tambin es un desarrollador). La clase se completa cuando se logra el equilibrio y cuando la secuencia de creacin y asignacin de actividades de negocio que se han asignado a los programadores principales se ha finalizado. Design by Feature Mediante la asignacin a un Programador Jefe de una serie de caractersticas, stas estn programadas para el desarrollo. El Programador Jefe selecciona las caractersticas para el desarrollo de sus funciones asignadas. A menudo se da el caso de que el Programador Jefe programa en un momento grupos pequeos de caractersticas para el desarrollo. El Programador Jefe forma un grupo de trabajo mediante la identificacin de los propietarios de las clases (desarrolladores) que pueden intervenir en el desarrollo de la caracterstica seleccionada, para la cual el equipo produce un diagrama de secuencia detallado. El Programador Jefe refina el modelo de objetos y los desarrolladores escriben prlogos de clase y el mtodo en s. El grupo de trabajo producir un paquete de inspeccin del diseo para salir de este proceso. Build by Feature Cuando el paquete de diseo del proceso 4 ha sido inspeccionado con xito, entramos en el proceso 5. Trabajando a partir de este paquete, los Propietarios de Clase implementan los elementos necesarios para sus clases, consiguiendo apoyar el diseo de la caracterstica en el paquete de trabajo. Se ha desarrollado un cdigo, que ser analizado y probado. El orden lo establece el Programador Jefe. Despus de una inspeccin correcta del cdigo, ste es ascendido a la construccin. El criterio de salida es que el grupo de trabajo complete el desarrollo de una o ms caractersticas de los clientes (las funciones que ellos han valorado). Para ello, el cdigo debe de haber ascendido a la construccin del conjunto de clases nuevas y mejoradas que admitan dichas funciones. Estas clases tienen que ser inspeccionadas y probadas de forma exitosa.

Herramientas SoftwareCASE Spec. Herramienta de una empresa comercial para el Feature Driven Development. TechExcel DevSuite. Conjunto de aplicaciones comerciales para activar el FDD FDD Tools. El FDD Tools tiene como objetivo producir cdigo abierto, plataformas de soporte y un conjunto de herramientas de apoyo para este mtodo. Capturas de Pantalla de esta herramienta para una visin general.

1.3. Crystal (Crystal Clear)CARACTERSTICASFAMILIA CRYSTALAlistair Cockburn es uno de los promotores del movimiento de metodologas giles en el desarrollo de software, y ayud a escribir el Manifiesto para el desarrollo gil de software, en 2001, y lo que se conoce ahora como La declaracin de interdependencia para la administracin moderna, en 2005. La filosofa de Cockburn se plasma en estas metodologas y se traduce en el reconocimiento de que cada equipo tiene unos talentos y habilidades diferentes, por lo que el proceso que se debe aplicar debe ser tambin nico y adapatado estas habilidades. Crystal son una familia de metodologas, descritas por Cockburn, y codificadas por colores segn el tamao y complejidad del proyecto (como el color y dureza en los minerales). De esta manera tenemos Clear (3 a 8 personas), seguida por Yellow (10 a 20 personas), Orange (25 a 50 personas), y as sucesivamente hasta azul. Cuanto ms grande sea el proyecto, con ms dureza se debe aplicar el mtodo a utilizar. En la siguiente figura se establece la codficacin por colores y niveles segn los parmetros de Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L), es decir, la criticalidad del sistema, desde una situacin de prdida de comodidad por algn error del sistema, pasando por prdidas de dinero disponible hasta el punto en que las prdidas sea crticas e incluso puedan afectar a vidas humanas. Junto a estos factores se muestra la media de personas que trabaja en el proyecto.

CRYSTAL CLEARLa metodologa ms documentada es la menor de todas, Crystal Clear, orientada a equipos de menos de 10 personas y proyectos de un mximo de 2 aos. Esta requiere seguir una serie de mtodos, como son la entrega frecuente de cdigo usable por los usuarios/clientes, seguridad en los entregables as como en los propios miembros del equipo, eficiencia en el desarrollo, buena comunicacin entre equipo y clientes o mejoras en futuras entregas apoyadas en lo realizado hasta el momento, entre otros. No se centra tanto en procesos o artefactos. Se trata de un modelo de juego cooperativos en el que el desarrollo del software consiste en inventar y comunicar. El equipo debe cumplir el objetivo de entregar el software del partido actual y prepararse para el siguiente. De esta manera se mantiene la concentracin y efectividad del equipo. Alistair Cockburn describe en su libro Crystal Clear A human powered methodology for small teams una serie de prioridades y propiedades que comparte toda la familia Crystal, como parte de un mismo cdigo gentico, pero que sobretodo queda patente en la versin Clear.

PRIORIDADESEficiencia en el desarrollo: Para que un proyecto sea econmicamente rentable se debe ser eficiente durante la etapa de desarrollo. Seguridad en lo que se entrega: Como veremos, establecer una alta frecuencia en los entregables hace que estos Habitabilidad: Se ha de conseguir un entorno de trabajo agradable entre los miembros del equipo, donde la comunicacin no tenga ningn impedimento. El equipo ha de ser capaz de seguir las pautas de trabajo establecidas.

PRINCIPIOSCrystal no es una metodologa estricta, el grado de detalle para documentar los requerimientos, el diseo, plan, etc, vara segn el tamao y naturaleza del propio proyecto. La documentacin se ha de presentar de manera accesible para todos los miembros del grupo, sea cual sea su rol. Para ello se ha lograr un balance entre lo tcnico y lo informal, adems de ser precisa. El equipo debe ser capaz, en todo momento, de ajustar su forma de trabajo para lograr una buena cohesin entre todos sus miembros, teniendo en cuenta las particularidades del entorno y de cada asignacin.

PROPIEDADESSe definen una serie de propiedades esenciales que toda la familia Crystal comparte, independientemente del tamao del proyecto: Propiedad 1. Frecuencia de las entregas Segn Cockburn, la propiedad ms importante de cualquier proyecto, pequeo o grande, gil o no. Es difcil argumentar en contra de las ventajas que nos proporciona la entrega frecuente de software usable para usuarios expertos: Proporciona la oportunidad de recibir feedback de los clientes de manera constante, cada pocas iteraciones. Introducir cambios sobre la marcha resulta mucho ms fcil que realizarlos al final. Los sponsors pueden confirmar que el proyecto est avanzando. El equipo de desarrollo tiene la oportunidad de depurar y programar nuevos procesos de implementacin sobre la marcha. Y quiz lo ms importante, proporciona a los desarrolladores el sentimiento de realizacin, del trabajo cumplido. Los entregables puede tomar diferentes formas, como veremos en roles y artefactos, dependiendo de la naturaleza del proyecto, los clientes o el entorno. Cuando un cliente no puede aceptar una entrega incremental de actualizaciones se puede establecer una espacio de trabajo de testeo, dejando acceso permanente al usuario a la versin actual de desarrollo del software. Es muy importante el feedback del cliente al final de cada iteracin que produzca un entregable. La frecuencia de los entregables puede ser desde una hora hasta unos 3 meses, estando la media de tiempo entre las dos semanas y los dos meses. Propiedad 2. Crecimiento reflexivo Siguiendo la misma lnea de lo que se conoce como crecimiento continuo, el crecimiento reflexivo implica que el equipo se debe reunir periodicamente durante el desarrollo del proyecto para discutir sobre el camino que est tomando, que est funcionando y que no. La idea es no esperar hasta que el proyecto haya finalizado para mirar hacia atrs y descubrir los errores, sino hacerlo de manera continua durante el proyecto para ajustar los procesos necesarios y evitar repetir errores en la siguiente iteracin. Cockburn recomienda dedicar al menos una hora cada pocas semanas o al mes para reunir al equipo. Propiedad 3. Comunicacin Se refiere a la importancia de localizar los miembros del grupo en la misma habitacin o oficinas adyacentes, manteniendo una comunicacin directa cara a cara y evitando malentendidos. El mismo Cockburn ofrece consejos sobre la configuracin de la oficina para mejor comodidad del grupo, atendiendo a la necesidad de privacidad del personal.

Propiedad 4. Seguridad Personal Hace referencia a la confianza y buena relacin entre los miembros del equipo, la comunicacin no debe quedar mermada debido al miedo al reproche por decir algo inadecuado o recibir represalias al cometer un error. Ante todo se debe ser sincero en los sentimientos de cada uno, nunca recurrir a la falsa cortesa, que puede llevar a desacuerdos y causar ms dao. Propiedad 5. Focalizacin Se deben tener claras las prioridades en cualquier momento del desarrollo del proyecto. Asignar varias tareas simultneas a los desarrolladores les puede llevar a la falta de concentracin, hay que mantener una planificacin adecuada y una persona no tendra que llevar ms de un proyecto y una parte de otro. Propiedad 6. Acceso fcil para los usuarios expertos Cockburn recomienda reuniones semanales con usuarios expertos, al menos mediante telfono. Si no se mantiene esta periodicidad es muy probable que las oportunidades de que el proyecto tenga xito disminuyan notablemente. Si ni siquiera es posible realizar estas reuniones semanales, se aconseja asignar a un desarrollador como instructor, acompaando al cliente en su rutina diaria durante un cierto perodo de tiempo, haciendo posible realizar reuniones en el mismo lugar de trabajo de este. Propiedad 7. Entorno tcnico Un proyecto exitoso se ha de gestar en un ambiente tcnico, haciendo uso de una serie de herramientas y prcticas. Esto es test automatizados, administracin de la configuracin y la frecuente integracin de los distintos componentes desarrollados. Aunque en Crystal Clear deberan ser suficientes los tests manuales, Cockburn comenta que cada desarrollador de los que ha entrevistado, y han utilizado los tests automatizados, han declarado que ya no podran trabajar sin ellos. Una administracin de la configuracin para controlar las versiones del cdigo es crtica, ya que la integracin constante, cuando an est fresco, puede prevenir la acumulacin de demasiados errores.

ESTRATEGIASSe proponen una serie de estrategias en realizacin a las propiedades comentadas anteriormente y que estn muy ligadas unas con otras, como vamos a ver: Exploracin de 360: A diferencia de otras metodologas ms estrictas, las Crystal requieren de un estudio inicial desde el cual se estudiar el tipo de nivel de rigidez a aplicar. Para ello se estudiar que valor de negocio puede aportar el proyecto, la tecnologa implicada y se producir un plan de actuacin. Victorias tempranas: Hace referencia a la necesidad de buscar pequeos resultados en lugar de mirar directamente al final del proyecto para obtenerlos.

Esqueleto ambulante: Muy ligada con la anterior y con la rearquitectura incremental. Hay que disponer cuantos antes posible de una versin preliminar del software, simple pero usable. Las mejoras se aplicarn incrementalmente sobre esta en futuras iteraciones o entregables. Rearquitectura incremental: Algo muy caracterstico de Crystal Clear es la flexibilidad que proporciona. La arquitectura debe poder evolucionar conforme avanza el proyecto, pero sin interrumpir el proceso de desarrollo o el mismo sistema en ejecucin. Radiadores de informacin: Se tratan de lminas o fichas con informacin relevante al proyecto y siempre visibles y comprensibles para todo el personal. Debe ser renovada para que no pierdan importancia. Es muy importante para la buena comunicacin entre los miembros del equipo.

TCNICASAunque hay muchas, las ms destacables sobre las tcnicas de otras metodologas son: Reuniones: Podemos distinguir dos tipos de reuniones. Unas son las introducidas por la metodologa Scrum, y se tratan de reuniones diarias de no ms de una hora para realizar un seguimiento del proyecto. El otro tipo de reuniones son las de reflexin, donde se mira en perspectiva a los errores y triunfos conseguidos en etapas anteriores y se discute como se podra mejorar ciertos puntos en prximas iteraciones. En estas ltimas los miembros del equipo se expresan abiertamente de una manera ms distendida. Programacin lado a lado: La proximidad de los miembros en el grupo de trabajo permite que estos puedan echar un ojo al trabajo del compaero, mejora la comunicacin y el buen ambiente de trabajo. Planificacin Blitz: Se escriben las funciones del programa en tarjetas y los programadores estiman tiempos para cada una de forma independiente entre las mismas.

FASES E HITOSHemos comentado que una de las propiedades ms importantes de este mtodo es la frecuencia de los entregables y el feedback, por lo que se ha de establecer un plan de iteraciones cortas donde cada pocos das o incluso diariamente se ha integrar y compilar el cdigo y tener una versin de prueba para el usuario experto. El trabajo se ha de separar de manera que todo el equipo se encuentre ocupado en cada una de las iteraciones y no ocurra como en los antiguos mtodos en cascada, en los que ciertos miembros no pueden comenzar su trabajo hasta que otros no hayan terminado con el suyo. Por ello no se define un plan detallado al principio del desarrollo, sino que durante la marcha son los mismos miembros, en consenso, deciden como actuar para esa jornada o semana. Todo esto dicho, las fases de un proyecto que sigue la metodologa Crystal Clear tiene una serie de fases comunes con cualquier otro tipo de metodologa, pero estas se dividen en ms iteraciones, haciendo ms flexible la modificacin de cualquiera de estas en cualquier momento del proyecto. En una metodologa Crystal Clear podemos distinguir: Tareas o episodios dentro de una varias jornadas de trabajo, que en conjunto, al cabo de una semana de trabajo, se integran (perodo que no durar ms de 3 das) y pueden llevar al final de una iteracin. Un conjunto de iteraciones, que deben ser pocas, no ms de 2 o 3, deben producir una entrega. Al final el desarrollo incremental y reflexivo de estas entregas lleva a la finalizacin del mismo proyecto. En la siguiente figura podemos ver el esquema anidado de los ciclos comentados:

Sobre los hitos, ms adelante, en el apartado de roles se nombran los artefactos proporcionados por cada persona o grupo de personas al finalizar cada iteracin o entrega.

ROLES Y ARTEFACTOSEn Crystal Clear se pueden designar los ocho tipos de roles que se describen a continuacin. Como ya hemos dicho, esta metodologa se basa en las personas y no en los procesos, por lo que junto con estas vamos a poner los artefactos que producen: Patrocinador: Consigue los recursos y define la totalidad del proyecto. Produce la Declaracin de Misin con Prioridades de Compromiso (Tradeoff). Usuario experto y Experto en Negocios: Son distintos roles pero que actan conjuntamente para producir la Lista de Objetivos junto con los documentos de Casos de uso y Requerimientos. El usuario experto se debe familiarizar con el proyecto y participar en este, realizando sugerencias sobre usabilidad o proporcionando informacin. El experto en negocios hace de intermediario entre el equipo de desarrollo y el cliente, debe conocer las polticas del negocio. Diseador principal: Se supone que debe ser al menos un profesional de Nivel 3, es decir, debe ser capaz de seguir los procedimientos y pautas marcados y aprendidos, pero adems debe encontrar o crear otros distintos ms especficos para la tarea y todo esto realizarlo de manera fluida. El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programador ms experto. Produce la Descripcin Arquitectnica. Diseador programador: En Crystal Clear el nmero de miembros del equipo de muy pequeo, por lo que los programadores tambin debern tener aptitudes de diseador y viceversa, un diseador debe ser capaz de programar. Produce, junto con el Diseador Principal, los Borradores de Pantallas, el Modelo Comn de Dominio, las Notas y Diagramas de Diseo, el Cdigo Fuente, el Cdigo de Migracin, las Pruebas y el Sistema Empaquetado. Coordinador: Como su propio nombre indica, debe haber alguien que se encargue de dirigir las reuniones y en general coordinar el plan de trabajo de cada uno de los miembros. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteracin y la Agenda de Visualizacin. Tester: Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas, ya que este rol pertenece a la etapa de testeo, en la que interviene tanto el cliente experto como los mismo programadores. Escritor: Este es normalmente alguno de los programadores-diseadores. Produce el Manual de Usuario. El Equipo como grupo es responsable de producir la Estructura y Convenciones del Equipo y los Resultados del Taller de Reflexin, al finalizar cada reunin. Como apunte final, hay que decir que en otros mtodos de la familia Crystal se han de modificar o definir nuevos roles segn las necesidades.

1.4. Agile Unified ProcessQu es AUP?Agile Unified Process, en castellano Proceso Unificado gil de Scott Ambler, describe de una manera simple y fcil de entender la forma de desarrollar aplicaciones de software usando tcnicas giles y siendo una versin simplificada de RUP. Este describe de una manera simpe y fcil de entender la forma de desarrollar aplicaciones de software de negocio usando tcnicas giles y conceptos que an se mantienen vlidos en RUP. El AUP aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (TDD), Modelado gil, Gestin de Cambios gil, y Refactorizacin de Base de Datos para mejorar la productividad. En los proyectos basados en AUP normalmente se entregan versiones de desarrollo al final de cada iteracin, pudiendo estas versiones ser lanzadas en produccin al pasar la garanta de calidad y superar la fase de pruebas.

FasesEl ciclo de vida de AUP consta de las siguientes fases: Inicio: El objetivo es identificar el mbito inicial del proyecto, el alcance y dimensiones, una arquitectura potencial para el sistema, y obtener financiacin o presupuesto del cliente. Elaboracin: El objetivo es verificar la arquitectura del sistema. Construccin: El objetivo es construir un software funcional, as como unas bases incrementales que cumplan con las necesidades ms prioritarias del cliente. Transicin: Validacin e implantacin del sistema.

InicioEl objetivo de esta fase es la de establecer a un alto nivel los requerimientos de la aplicacin, los cuales van a ser modelados en un diagrama de casos de uso y su correspondiente especificacin. Las actividades definidas en esta fase son: Definir el mbito del proyecto: Incluye definir en alto nivel la funcionalidad del sistema, estableciendo as los lmites en los que el equipo trabajar. Esto es representado mediante una lista de casos de uso. Estimar el tiempo y el coste: Se estima el tiempo y el coste para el proyecto. Las estimaciones generales son usadas en iteraciones en las ltimas fases, ms especficamente se usan en las primeras iteraciones de la fase de elaboracin. Definir riesgos: Aqu es donde se definen los riesgos del proyecto. La gestin de riesgos es una parte importante del AUP, pues la lista de riesgos cambia conforme se avanza en el proyecto, por tanto se identifican nuevos riesgos, tratando los de alta prioridad en fases ms tempranas que el resto. Estudio de viabilidad: Se estudia la viabilidad del proyecto, que este pueda ser construido y que una vez desplegado seamos capaces de ponerlo en marcha. Si el proyecto no es viable debe ser cancelado. Preparar el entorno: Esto incluye reservar un espacio de trabajo para el equipo, obteniendo el hardware y software necesario, as como prever las necesidades surgidas en un futuro. Para completar esta fase necesitamos cumplir los siguientes hitos: Conseguir que el cliente est de acuerdo con el mbito acordado del proyecto. Lista inicial de requisitos. Los clientes estn de acuerdo con el coste inicial y el tiempo estimado. Aceptacin de riesgos. Viabilidad del proyecto. Tener un plan de proyecto para la realizacin de las siguientes fases.

ElaboracinEl principal objetivo es probar la arquitectura del sistema a desarrollar, asegurndose de que el equipo puede desarrollar un sistema que satisfaga los requisitos, construyendo as un prototipo arquitectnico. Es importante darse cuenta de que los requisitos no se especifican completamente en este punto. Son detallados lo suficiente para entender los riesgos de la arquitectura y para asegurarse de que se entiende el mbito de cada requisito. Durante el transcurso de esta fase se comienza a preparar la siguiente, pues a medida que se va ganando manejo con la arquitectura del sistema, se va preparando el entorno para la construccin adquiriendo las herramientas necesarias. Los hitos necesarios para finalizar la fase son: La visin del proyecto es estable y realista. La arquitectura satisface los requisitos. Aceptacin de riesgos. Viabilidad del proyecto.

Plan de proyecto para las siguientes iteraciones de construccin.

ConstruccinEl objetivo de esta fase es desarrollar el sistema hasta que este est listo para realizar las pruebas de produccin. Previo al desarrollo, se tendr que definir el modelo de anlisis y diseo de la solucin, para lo cual se usarn los diagramas de clases de anlisis y los diagramas de clases de diseo con sus correspondientes descripciones y especificaciones. Para esta fase se han establecidos las siguientes iteraciones: Comprende la codificacin de las funcionalidades relacionados a la conexin hacia las fuentes de datos origen y destino, as como la carga de la estructura de ambas bases de datos. Comprende la codificacin de las funcionalidades relacionadas a la comparacin de las estructuras de las bases de datos. Comprende la codificacin de las funcionalidades relacionadas a la sincronizacin de las estructuras de las bases de datos. En paralelo con el desarrollo, se implementarn las pruebas necesarias para probar cada funcionalidad, de manera que una vez terminada una iteracin, las funcionalidades implementadas puedan ser corroboradas y en caso de que sea necesario se hagan las correcciones pertinentes. Para llevar a cabo este trabajo se realizarn los siguientes tipos de pruebas: Pruebas de aceptacin: Permitirn corroborar que los requerimientos han sido resueltos de manera satisfactoria. Unidades de Prueba: Son pruebas que verifican que el cdigo para implementar una funcionalidad sea el correcto, verificando el comportamiento del sistema a un bajo nivel de cdigo, as como que el diseo sea correcto. Estos tipos de prueba suelen ser independientes de las funcionalidades pues verifican el cdigo fuente. La eleccin de ambos tipos de pruebas se justifica en el hecho de que son complementarias y necesarias. Las pruebas de aceptacin permitirn verificar que los requerimientos se estn implementando, mientras que las unidades de prueba verificarn que el cdigo no contenga errores. Para finalizar esta fase son necesarios los siguientes hitos: Analizar y disear el modelo. Documentar las decisiones crticas de diseo. Construirlo. Probar el software. Desarrollar scripts para su instalacin. Desarrollar una documentacin inicial.

TransicinEn esta etapa se contina con el conjunto de pruebas definidas en las fases anteriores antes la puesta en produccin de la herramienta, incrementando las pruebas y probando con una versin beta. En caso de ser necesario se realizarn algunos arreglos a la codificacin dependiendo del resultado de las pruebas. Los hitos a realizar son los siguientes: Finalizar la documentacin. Validar la documentacin. Detectar fallos. Validar el sistema. Finalizar el modelo de prueba. Finalizar el desarrollo del paquete. Colocar el sistema en produccin. Formar a los usuarios.

DisciplinasLas disciplinas son ejecutadas en una forma iterativa, definiendo las actividades que el equipo de desarrollo ejecuta para construir, validad y liberar software funciona, el cual cumple con las necesidades del usuario. Las disciplinas son las siguientes: Modelado: La meta de esta disciplina es entender el negocio de la organizacin, el dominio del problema que el proyecto aborda e identificar una solucin viable para abordar el dominio del problema. Implementacin: Se trata de transformar el modelo en un cdigo ejecutable y realizar una prueba de nivel bsico en una unidad particular de prueba. Pruebas: Esta disciplina se basa en ejecutar una evaluacin de los objetivos para asegurar la calidad, adems de encontrar defectos, validar como fue diseado el sistema y verificar que los requerimientos estn completos. Despliegue: El objetivo del despliegue es planear el desarrollo para la entrega del sistema, y ejecutar este plan para hacer que el sistema est disponible para el usuario final. Gestin de la configuracin: Se trata de gestionar el acceso a los elementos del proyecto as como controlar y administrar los cambios que ocurran. Gestin del Proyecto: Esta disciplina dirige las actividades que se llevan a cabo en el proyecto. Se trata de la coordinacin entre los distintos equipos fuera del alcance del proyecto para que este se finalice a tiempo y dentro del presupuesto. Gestin del entorno: Se trata de reforzar el resto de esfuerzos para garantizar que el proceso adecuado y herramientas estn disponibles para el equipo segn sea necesario.

RolesAgile DBA: Administrador de la base de datos que trabaja con los miembros del equipo de diseo, pruebas, implementacin y soporte del esquema de la base de datos. Agile Modeler: Crea e implementa los modelos. Desarrollador: Es el encargado de disear, probar e implementar el software. Configurator manager: Es el encargado de proveer toda la infraestructura del modelo y el entorno del equipo de trabajo. Project manager: Gestiona los miembros del equipo adems de las relaciones con los directivos, convocar las reuniones y gestionar y localizar los recursos. Test manager: Son los responsables del xito de la fase de prueba, realizando planes y fases de pruebas.

2. Comparativas2.1. Similitudes y DiferenciasDDSMCompromiso de todas las partes implicadas en desarrollar el proyecto por este mtodo Ocho principios que dirigen las actitudes del equipo Presupuestos, rasgos temporales y la relacin con los clientes y usuarios finales Adaptativo al principio de cada iteracin Equipos bastante numerosos si se consideran la implicacin del cliente y de usuarios finales Proyectos pequeos y ampliaciones de rpido desarrollo

FDDSistema para construir sistemas si se escala a proyectos grandes

CCSolo es necesario saber la complejidad general del proyecto Poco especfica, gua de buenas prcticas

AUPLos miembros del equipo deben ser expertos en esta metodologa

Requisitos

Especificaciones

No requiere modelo especfico

Esta formada por cuatro fases

Basado en...

Rasgos o caractersticas

Personas, no procesos

Desarrollar casos de uso

Rigidez

Es adaptativo

Muy flexible a cambios

Flexible a cambios

Tamao equipo

Equipos pequeos

Menos de 10 miembros

Equipos medianos

Tamao proyecto

Cortos y de misin crtica

Para proyectos grandes solo aplicar a subequipos Comunicacin continua, como uno ms del equipo

Enfocada a proyectos grandes El cliente es informado al finalizar cada iteracin

Satisfaccin Cliente

Alta. El cliente est presente en todas las fases del desarrollo

Cliente informado constantemente sobre la situacin

Herramientas

Ninguna especfica

FDD Tools

No se especifica software. Uso de pizarrones, plantillas y notas. Aunque an es joven, es muy activa (junto con Crystal Orange)

Rational XDE

Aplicacin/Adopcin actual

Una de las de mayor adopcin, con gran nmero de experiencias reales

No muy utilizada debido a la gran necesidad de expertos

No esta usada como RUP

2.2. Ventajas y DesventajasDYNAMIC SYSTEMS DEVELOPMENT METHOD: + De gran utilidad para el desarrollo de sistemas con un bajo presupuesto y/o poco tiempo. + Gracias a la priorizacin MoSCow siempre se entrega un prototipo funcional en cada iteracin. + Admite la insercin de otras etapas, tcnicas y procedimientos de otras metodologas. + Al delegar responsabilidades en el equipo de desarrollo, se favorece la velocidad de la toma de decisiones. - Requiere una intensa participacin del cliente y de los usuarios finales en el desarrollo. - Requiere una perfecta planificacin al principio de cada iteracin. - Numerosos artefactos: entre el equipo de desarrollo, para el equipo de gestin y para el cliente. CRYSTAL CLEAR: + Muy flexible y adaptable a las caractersticas del proyecto. + Flexibilidad en las tcnicas y procedimientos, a diferencia de XP, que especifica que prcticas se han de seguir. + Permite modificaciones sobre la marcha. + Iniciativa de los miembros del equipo. + Gran comunicacin entre los miembros del equipo y los clientes. + Se basa en unos principios y propiedades que las propias experiencias de proyectos reales han demostrado ser exitosos. - Al no ser una metodologa muy estricta y poco especfica en los procedimientos, proyectos de gran envergadura e importancia crtica no son adecuados para esta. - Relativamente nueva, hay poca documentacin. - Existe poca disciplina y reglas de trabajo, equipos con poca experiencia se pueden sentir perdidos. - Especificaciones iniciales escasas, puede llevar a inconsistencias.

FEATURE DRIVEN DEVELOPMENT: + Permite aplicar un mtodo para gestionar los proyectos a un nivel muy alto + Nosotros mismos establecemos unas estimaciones y horarios para conocer en todo momento el estado del proyecto. La idea de esto es saber con certeza si el proyecto avanza a buen ritmo o nos hemos atrasado. + Al ser una metodologa iterativa con iteraciones cortas, se obtienen resultados peridicos y tangibles que el cliente puede ver y monitorizar. + Es adaptativo: permite realizar cambios de ltimo momento - Es necesario tener en el equipo miembros con experiencia para marcar el camino a seguir con la elaboracin del modelo global (Proceso 1: Develop an Overall Model). - Al tratarse de un equipo muy grande han de repartirse numerosos roles y generar muchos artefactos distintos. AGILE UNIFIED PROCESS + Es una metodologa completa en s misma, con nfasis en la documentacin. + Es capaz de resolver de forma activa los riesgos de los proyectos asociados a las necesidades de los clientes que requieren una gestin cuidadosa. + El tiempo de desarrollo es menor debido a la reutilizacin de los componentes. - Los miembros del equipo tienen que ser expertos en la utilizacin de esta metodologa. - El proceso de desarrollo es demasiado complejo y desorganizado. - En los proyectos que requieran nuevas tecnologas ser imposible la reutilizacin de componentes.

2.3. Adecuacin para distinto tipo de aplicacionesDDSM Proyecto pequeoBuena. Al tratar primero el presupuesto y el tiempo se ajusta a las necesidad primarias del cliente Media. Puede provocar cansancio en cada una de las partes implicadas debido al esfuerzo de comunicacin No recomendada, aplicar con otras metodologas

FDDMs normal trabajar en proyectos grandes

CCBuena, mucha flexibilidad

AUPUtilizar metodologas ms bsicas

Proyecto medio

No se suele dar este caso

Buena, mucha flexibilidad, pero necesita de equipos experimentados

Recomendada

Proyecto grande

Muy recomendada, se dividen las tareas

No recomendada, aplicar con otras metodologas

Recomendada al estar enfocada a proyectos grandes Enfocada a equipos grandes

Equipo pequeo

No se puede dar el caso ya que ha de haber numerosos roles y funciones que cubrir Medio. Alguno de sus componentes tendra que realizar varias funciones al mismo tiempo Perfecto, se puede incluir en el equipo roles de gestin y enseanza para los usuarios finales

Buena, inexpertos aprenden de los experimentados

Perfecta para menos de 10 miembros

Equipo medio

No es lo ms adecuado

Buena, pero requiere reglas ms estrictas

Recomendada

Equipo grande

Desarrollada para equipos grandes

No recomendada, dividir en subequipos

Dividir en subequipos

Est mtodo se puede Adecuacin fusionar con cualquier con otras otro mtodo de desarrollo metodologas iterativo ya que no dispone de herramientas especficas y muchas de sus fases y subfases se encuentran ya, por si solas, en otras metodologas de desarrollo.

El estndar PMBOK, Scrum y PRINCE2 se adaptan a FDD, agregndose valor entre ellos y creando un entorno de proyecto completo

Para proyectos grandes se recomienda aplicar junto con XP o Scrum

Al ser un refinamiento del Proceso Unificado y una versin ms simple del RUP, puede ser aplicada junto con otras metodologas que provengan del UP

BibliografaDynamic Systems Development Methodltima versin de la metodologa completa http://en.wikipedia.org/wiki/Dynamic_systems_development_method#Prerequisites_for_using_DSDM Introduccin y caractersticas principales http://es.wikipedia.org/wiki/M%C3%A9todo_de_desarrollo_de_sistemas_din%C3%A1micos Informacin diversa http://www.dsdm.org/

Crystal ClearSobre Alistair Cockburn e introduccin a Crystal Clear, Fases e hitos http://en.wikipedia.org/wiki/Alistair_Cockburn http://seccperu.org/files/Metodologias%20Agiles.pdf Las 7 propiedades de Crystal Clear, extracto del libro de Cockburn http://www.informit.com/articles/article.aspx?p=345009 Estrategias y tcnicas http://www.cs.umss.edu.bo/doc/material/mat_gral_130/exposicion_Crystal.ppt

Feature Driven DevelopmentHerramientas Software para FDD Gua Prctica FDD FDD Documentacin Primera Parte FDD Documentacin Segunda Parte Roles Procesos

Agile Unified ProcessCaractersticas AUP Ciclo AUP Herramientas AUP AUP