Metodologas giles

Prctica 3

#AESMultimedia - aesmultimedia.blogspot.com
Jos Lus Contreras Martnez Ana Garca Domene Daniel Martnez Espadas Begoa Morillas Guijarro @DkLawis @agado92 @danielme91 @begomori

ndice
Introduccin a las metodologas giles DSDM: Dynamic Systems Development Method FDD: Feature Driven development Crystal: (Crystal Clear) AUP: Agile Unified Process Anlisis comparativo Bibliografa

Introduccin a las metodologas giles

Las metodologas giles surgen a principios de los 90 ante ciertos problemas de tiempo, costo y calidad en el desarrollo de creacin de software. Este nuevo enfoque de desarrollo se dio a conocer como RAP (Rapid Application Development). En l, el trabajo se organizaba en pequeos grupos de trabajo de alto rendimiento. Las metodologas giles se inician con la creacin del eXtreme programming o XP que impulsa el desarrollo mediante iteraciones, aunque stas ya se utilizaban anteriormente. Tambin destacamos que estos ciclos son cortos intervalos de tiempo, de una a cuatro semanas, lo que favorece la minimizacin de riesgos. Actualmente existen diversas metodologas giles que se fueron basando en los principios de esta metodologa.

Imagen 1: Desarrollo gil de software

A continuacin estudiaremos cuatro de las metodologas giles ms destacadas del momento: DSDM Dynamic Systems Developmemt Method, Crystal (Crystal Clear), FDD Feature Driven Development y AUP: Agile Unified Process.

DSDM: Dynamic Systems Development Method

Esta metodologa surge de un consorcio en Reino Unido. Su primera versin aparece en 1994, posteriormente se han realizado varias versiones. Situada dentro de las RAD, DSDM es excelente para proyectos de sistemas de la informacin con presupuestos limitados y agendas muy ocupadas y apretadas.

Caractersticas
Los proyectos tendrn las siguientes caractersticas que refieren a la aplicabilidad de DSDM: - Proyectos interactivos con funcionalidad visible en la interfaz de usuario - De baja o media complejidad computacional. - Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran tamao, cuentan con flexibilidad en los requerimientos. - Une tcnicas de desarrollo y gestin del proyecto en una misma metodologa que se centra en conseguir un producto que funcione correctamente en los casos ms crticos. - Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders. Con un grupo de usuarios bien definidos y comprometidos al proyecto. - El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus superiores para realizar entregas, siempre cortas, de forma frecuente, siendo stas funcionales. sto es adecuado al tener el tiempo total acotado, por lo que previene que transcurra mucho tiempo y la tecnologa cambie. - El desarrollo es iterativo e incremental. - Todos los cambios pueden ser revertibles y son verificados durante todo el desarrollo.

Roles
Esta metodologa define 15 roles para usuarios y desarrolladores, a continuacin se describen los ms destacados. Desarrollador y desarrollador senior (developer and senior developer) Son los nicos roles definidos para desarrolladores, por esto este rol incluye a todo el personal de desarrollo, sean diseadores, analistas, programadores o testers. La diferencia entre desarrollador y desarrollador senior es que los segundos tienen gran experiencia en las tareas que realizan, por lo que suelen dirigir el equipo. Coordinador tcnico (Technical coordinator) Responsable tanto de la calidad tcnica como del control tcnico del proyecto, por ejemplo el uso de software de gestin de configuracin y el cumplimiento de estndares tcnicos. Est encargado de mantener la arquitectura. Usuario embajador (Ambassador user). 4

Equivale al on-site customer de XP. El usuario embajador debe ser miembro del grupo de usuarios, que espera utilizar el sistema, pues este rol tiene como funcin aportar el conocimiento de este grupo al proyecto y difundir informacin de los avances del proyecto al resto de usuarios. De esta forma se asegura una correcta retroalimentacin de los usuarios. se ofrece conocimiento del negocio y define los requisitos del software. Asesor de usuario (Adviser user). Consejero del usuario embajador. Este rol se emplea cuando el rol de usuario embajador no es suficiente para expresar todas las opiniones o puntos de vista importantes de los usuarios sobre un punto del proyecto. Visionario (Visionary). El trabajo del visionario es el encargado de asegurar que se satisfacen las necesidades de negocio, es decir, que desde el principio, los requisitos esenciales se encuentran y que el proyecto sigue la direccin correcta para cumplir dichos requisitos. Es el rol con la visin ms precisa sobre los objetivos del negocio del sistema y del proyecto y probablemente aquel que tiene la idea inicial de la construccin del sistema. Patrocinador ejecutivo (Executive sponsor). Es el rol de la organizacin de usuario que tiene la autoridad y responsabilidad financiera relacionada al proyecto, por lo tanto tiene el mximo poder en la toma de decisiones. Director de proyecto (Project Manager). Es responsable de entregar los productos acordados de forma exitosa, al acordado standar de calidad, a tiempo y dentro del presupuesto. Adems de ser capaz de entregar los beneficios estipulados en el PID. El director del proyecto puede venir de IT o de la comunidad de usuarios, e informa a la Junta del Proyecto.

Artefactos
Podemos describir los artefactos obtenidos mediante la metodologa DSDM a travs de las distintas fases que lo forman.

Fase 1. Estudio de viabilidad. - Informe de viabilidad. Anlisis de viabilidad del proyecto - Esbozo del plan para el desarrollo. Planteamiento del desarrollo del proyecto a grandes rasgos. - Listado de riesgos. Lista con los riesgos que puede ofrecer el sistema. - Prototipo rpido. Es un artefacto opcional, slo aparecer si no se conoce lo suficiente el negocio o tecnologa. Fase 2. Estudio de la empresa. - Descripcin de los procesos de negocio y especificacin de casos de uso. La identificacin de los casos de uso ayuda a involucrar al cliente.

- Documento de Especificacin de Requerimientos de Software (SRS). Descripciones a alto nivel de los requisitos que se presentan en formato correcto diagramas ER, modelos de negocio objetivos, etc. - Definicin de la arquitectura del sistema. Es un primer borrador de la arquitectura que puede cambiar durante el desarrollo del proyecto. - Esbozo del plan de prototipado. Debe declarar la estrategia de prototipado para las siguientes fases y un plan para la configuracin de la administracin. Fase 3. Iteracin del modelo funcional. - Modelo funcional. Contiene el cdigo prototipo y los modelos de anlisis - Casos de prueba. Pruebas a realizar a cdigo. - Funciones prioritarias. Lista de prioridades de las funciones que se entregan al final de la iteracin. - Resumen de los documentos de prototipos funcionales. Recoge los comentarios de los usuarios sobre el incremento actual, servir de artefacto de entrada para las siguientes iteraciones. - Requisitos no funcionales. Lista de requisitos que se tratarn en la siguiente fase. - Anlisis de riesgos de desarrollo superior. Documento de gran importancia en esta fase, pues, a partir de la siguiente fase, los errores encontrados sern ms difciles de ubicar y dirigir. Fase 4. Diseo e iteracin de la estructura. - Sistema probado. Debe cumplir al menos los requisitos mnimos acordados. Fase 5. Implementacin. - Sistema entregado. Sistema finalizado y entregado al cliente. - Manual de usuario. Instrucciones de uso del sistema. - Informe de revisin de proyecto. Resume el resultado del proyecto. Segn los resultados, se establece el curso del desarrollo adicional.

Prcticas
Dado el enfoque hacia proyectos de caractersticas RAD, la ideologa de la metodologa DSDM se define en nueve principios: 1. Involucrar al usuario es la base para obtener un proyecto eficiente y efectivo. Cliente y desarrolladores comparten entorno de trabajo para mejorar la precisin de las decisiones. 2. Los equipos de DSDM deben tener poder de toma de decisiones. Es importante que se puedan tomar decisiones para el desarrollo del proyecto sin esperar la aprobacin de superiores 3. El foco est puesto en la entrega frecuente de productos. Esto permite una verificacin y revisin continua del producto desde el principio. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables.

DSDM se centra en las funcionalidades crticas del proyecto, no en todas sus posibles necesidades. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. Se basa en la retroalimentacin de os usuarios para dirigirse hacia una solucin precisa. 6. Todos los cambios durante el desarrollo son reversibles. Saber dnde estamos en cada momento para tener la posibilidad de deshacer y probar otro camino si el elegido no funciona. 7. Los requerimientos estn especificados a un alto nivel. Alcance de alto nivel y requisitos deben ser base-lined desde el inicio del proyecto. 8. El testing es integrado a travs del ciclo de vida. Durante todo el ciclo de vida se realizan pruebas para evitar costes extraordinarios en mantenimiento y arreglos del sistema. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. La colaboracin y cooperacin entre el equipo, usuarios y stakeholders es esencial para un correcto desarrollo del proyecto.

Aparte de estos principios, DSDM tambin se basa en una serie de consideraciones muy importantes: Ningn sistema es construido a la perfeccin en el primer intento. La entrega del proyecto deber ser a tiempo, respetando presupuesto y asegurando la calidad. DSDM solo requiere que se complete cada paso que forma una iteracin con la funcionalidad suficiente como para que inicie el siguiente paso de la siguiente iteracin. DSDM puede utilizarse en proyectos de ampliacin de sistemas TI pero tambin podra utilizarse para proyectos de cambio de algn sistema aunque no sea TI. La evaluacin de riesgo debe estar enfocada en entregar funcionalidad de negocio y no en el proceso de desarrollo. La estimacin debe estar basada en funcionalidad del negocio no en lneas de cdigo. La gestin recompensa la entrega continua de productos antes que la consecucin de tareas.

Proceso
DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes segn las necesidades de la empresa. Para alcanzar sus metas, DSDM favorece el uso del RAD con el consecuente riesgo de que demasiadas partes estn sin definir correctamente y esto lleve a errores. DSDM aplica algunos principios, roles, y tcnicas en las 5 fases en las que define la construccin de un sistema:
1. Estudio de viabilidad: Estudia la factibilidad del proyecto en una pequea fase que

propone DSDM para determinar si la metodologa se ajusta ste. se realiza un estudio de los requisitos humanos materiales y financieros y los problemas de la empresa o el cliente. 7

2. Estudio de la empresa: Durante el estudio del negocio se involucra al cliente para

tratar de entender la operatoria que el sistema deber automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las caractersticas de alto nivel que deber contener el software, es decir, planifica la base de las actividades de la empresa. 3. Iteracin del modelo funcional: Se inician las iteraciones en las que se describirn en detalle las caractersticas definidas en la fase anterior, planteando un modelo previo que de solucin aceptable a la problemtica. Esta es la etapa de diseo. 4. Diseo e iteracin de la estructura: Se realizar el diseo de los mismos codificando el modelo diseado, se construirn los componentes de software, se prueba paralelamente la calidad del producto y se documenta el manual de usuario y tcnico. 5. Implementacin: Entrega del producto al cliente o usuario final. Cuando ste de su aprobacin se implantar el sistema en produccin.

La primera y segunda fase son secuenciales y, por lo tanto, realizadas una nica vez al principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las caractersticas del modelo iterativo e incremental ya tratado.

Imagen 2. Diagrama de procesos de DSDM

DSDM aproxima las iteraciones como timeboxes. Una timebox dura un periodo predefinido de tiempo y la iteracin debe finalizar dentro de la timebox que suele durar desde unos das hasta unas pocas semanas.

Sin embargo, lo que diferencia a DSDM de otros modelos son los principios alrededor de los cuales se estructura, tratados en el apartado anterior, y que hacen nfasis en los equipos de desarrollo, en el feedback con el cliente y en las entregas frecuentes de productos.

Posibles integraciones
Es posible integrar DSDM con otros mtodos para complementar el desarrollo del proyecto. Entre ellos tenemos el Proceso Unificado de Rational (RUP), Programacin Extrema (XP), y Proyectos en ambientes controlados (PRINCE2), Otro mtodo gil que tiene semejanzas proceso y concepto con DSDM es Scrum. Entre DSDM y RUP se puede crear una fuerte unin, RUP podra considerarse una implementacin de DSDM. RUP est ms orientado a la arquitectura y a la calidad y DSDM tiene como objetivo el desarrollo rpido de aplicaciones, sin embargo, esto no impide combinarlos, incluso se pueden relacionar todas las fases y artefactos de RUP con los de DSDM. Al combinarse podemos obtener un sistema con una arquitectura fuertemente definida en un tiempo rcord.

FDD: Feature Driven development

Es un proceso gil diseado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorizar. Estas iteraciones se deciden en base a features o funcionalidades, que son pequeas partes del software con significado para el cliente. A diferencia de otros procesos giles no cubre todo el ciclo de vida sino slo las fases de diseo y construccin. 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.

Caractersticas
FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y una salida. Desarrollo de un modelo general: Cuando comienza el desarrollo, los expertos de dominio estn al tanto de la visn, 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. Los expertos de dominio presentan un ensayo ms en el que los miembros del equipo y el arquitecto jefe 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, un equipo de desarrollo trabaja en pequeos grupos para producir modelos de objetos de cada rea de dominio. Simultneamente, se construye un gran modelo general para todo el sistema. 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. Estos rasgos son pequeos tems tiles a los ojos del cliente. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de ms de diez das se descomponen en otros ms pequeos. Planeamiento por rasgos: 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. Diseo por rasgos y Construccin por rasgos: 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 un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

10

Miremos una representacin grfica del proceso iterativo que involucran estas dos ltimas fases:

Imagen 3. Flujo de los procesos en FDD

Roles
Key Roles / Roles claves
Project Manager / Director del Proyecto: Es el lder administrativo y financiero del proyecto. Tambin protege al equipo de situaciones externas. Chief Architect / Arquitecto jefe: Se encarga del diseo global del sistema y de la ejecucin de todas las etapas. Development Manager / Director de desarrollo: Lleva diariamente las actividades de desarrollo, resuelve conflictos en el equipo y resuelve problemas referentes a recursos. Chief Programmer / Programador Jefe: Analiza los requerimientos, disea el proyecto y selecciona las funcionalidades a desarrollar de la ltima fase del FDD. Class Owner / Propietario de clases: Responsable del desarrollo de las clases que se le asignaron como propias. Participa en la decisin de que clase ser incluida en la lista de funcionalidades de la prxima iteracin. Expertos de dominio: Puede ser un usuario, un cliente, analista o una mezcla de estos. Tambin poseen el conocimiento de los requerimientos del sistema. Y pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

Supporting Roles / Roles de soporte

Domain Manager: Lidera al grupo de expertos del dominio y resuelve sus diferencias de opinin concernientes a los requerimientos del sistema.

11

Release Manager: Controla el avance del proceso mediante la revisin de los reportes del Chief Programmer. Y reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada feature. Language Lawyer / Guru del Lenguaje: Es el responsable de poseer un vasto conocimiento en, por ejemplo, un lenguaje especfico de programacin o tecnologa. Este rol es fundamental cuando se trabaja una nueva tecnologa. Build Engineer / Ingeniero de construccin: Es el responsable de preparar, mantener y correr el proceso de construccin. Tambin realiza el mantenimiento de las versiones y la publicacin de la documentacin. Toolsmith / Herramentista: Construye herramientas especficas para el desarrollo, conversin de datos y testeo. Puede trabajar en la preparacin y mantenimiento tanto de bases de datos o sitios web destinados al proyecto. System Administrator / Administrador del sistema: Configura, administra y repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.

Additional Roles / Roles adicionales

Tester: Verifica que el sistema recin creado cumpla con los requerimientos del cliente. Y 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. Participa en el lanzamiento de los nuevos productos. Technical Writer / Escritor de documentos tcnicos: Prepara documentacin para los usuarios, que pueden formar parte o no del equipo del proyecto.

Artefactos
El Release Manager se rene con los Chief Programmers para que stos reporten como es el avance de las tareas. En esta reunin, que tiene una duracin de 30 minutos o menos, cada Chief Programmer informa de manera verbal el avance de sus features. Hacer esto de forma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo de escuchar a los otros y saber dnde estn situados los dems en el proceso de desarrollo. Al final de la entrevista, el release manager anota los resultados, actualiza la base de datos y genera los reportes. El release manager reporta los resultados obtenidos semanalmente, tanto para el equipo, para el cliente y para el Project Manager. Para los clientes y los gerentes, el reporte debe incluir el porcentaje de avance de cada feature. Para el equipo se informa cual es el desempeo del mismo.

Prcticas
FDD consiste en establecer "mejores prcticas" y los desarrolladores del mtodo argumentan que a pesar de que las prcticas seleccionadas no son nuevas, la mezcla especfica de estos ingredientes hacen a los cinco procesos FDD nicos para cada caso. Palmer y Felsing tambin argumentan que todas las prcticas disponibles deben ser utilizadas para obtener el mayor beneficio del mtodo y no que una nica prctica domine todo el proceso (2002). FDD consiste en las siguientes prcticas: 12

Dominio de modelado de objetos: exploracin y explicacin del dominio del problema. Los resultados se dan en un marco donde las caractersticas se aaden. El desarrollo por funcin: El cliente valora las funciones, desarrollando y siguiendo los progresos a travs de una lista de pequeas funcionalidades descompuestas. Propiedad de clase individual (cdigo): Cada clase tiene una sola persona elegida para ser la responsable de la consistencia, rendimiento e integridad conceptual de la clase. Caractersticas de los equipos: Se refiere a pequeos equipos formados dinmicamente. Inspeccin: Se refiere a la utilizacin de los mecanismos de deteccin de defectos ms conocidos. Construcciones regulares: se refiere a asegurar que siempre hay un sistema en funcionamiento, demostrable y disponible. Las construcciones regulares forman la lnea base a la que se aaden nuevas funciones. Gestin de la configuracin: Permite la identificacin y el seguimiento histrico de las ltimas versiones de cada archivo de cdigo fuente completo. Los informes de progreso: Se informa del progreso basado en el trabajo completado a todos los niveles organizativos necesarios. El equipo del proyecto debe poner todas las prcticas anteriores en uso con el fin de cumplir con las normas de desarrollo del FDD. Sin embargo, al equipo se le permite adaptarlas de acuerdo a su nivel de experiencia.

13

Crystal: (Crystal Clear)

Crystal es una metodologa de desarrollo de software gil, aunque ms bien se la considera un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que forman parte del equipo y en la reduccin al mximo del nmero de artefactos producidos. El equipo de desarrollo se considera un factor clave en esta metodologa, por lo que se deben invertir esfuerzos en mejorar las habilidades y destrezas, as como tener polticas de trabajo en equipo bien definidas. Estas polticas dependern del nmero de personas que formen el equipo, establecindose una clasicacin por colores, por ejemplo Crystal Clear (3 a 8 personas, es decir proyectos pequeos) y Crystal Orange (25 a 50 personas). En este trabajo se hablar en concreto de Crystal Clear.

Caractersticas
Las seis caractersticas o propiedades de Crystal Clear son las siguientes: 1. Entrega frecuente. Se trata de entregar software a los clientes de forma frecuente, no solamente cuando el proyecto est acabado. La frecuencia depender del proyecto, puede ser diaria, semanal o mensual. Lo importante es mantener informado al cliente del estado del sistema. 2. Comunicacin osmtica. Todos los miembros del proyecto deben estar juntos en la misma habitacin. 3. Mejora reexiva. Disponer de un tiempo breve (unas pocas horas cada ciertas semanas o una vez al mes) para observar bien el progreso, cotejar ideas y notas, reexionar y discutir. 4. Seguridad personal. Cuando hay alguna inquietud o problema en el equipo, hablarlo para solucionarlo. 5. Foco. Siempre se debe tener claro lo que se est haciendo en cada momento del proyecto, tener el tiempo y la tranquilidad necesaria para llevarlo a cabo. 6. Fcil acceso a usuarios expertos. Disponer de ayuda y consejo de desarrolladores expertos y con experiencia en proyectos similares.

Roles y artefactos
El patrocinador se encarga de conseguir recursos y de definir el proyecto general. Produce un slo artefacto: la Misin con Prioridades de Compromiso. El equipo como Grupo es responsable de producir dos artefactos: Estructura y los Convenios del Equipo Resultados del Taller de Reflexin El coordinador, junto con el equipo, es responsable de la produccin de: Mapa de proyecto. Plan de Lanzamiento Estado del proyecto Lista de riesgos 14

Plan de Iteracin y Estado Visualizacin del Calendario El experto en negocios y el usuario experto; el primero debe conocer las reglas y polticas de la empresa; el segundo debe familiarizarse con el uso del software, sugerir mejoras e ideas, en definitiva, implementar una buena interfaz de cara a los usuarios finales. Juntos son responsables de producir los siguientes artefactos: Lista de Actores-Objetivos Archivos de Casos de Uso y Requerimientos Modelo del Rol de Usuario El diseador jefe es el responsable de producir la Descripcin de la Arquitectura. El diseador-programador, junto con el diseador jefe, son los responsables de los siguientes artefactos: Borradores de Pantallas Modelo Comn de Dominio Bocetos de Diseo y Notas Cdigo Fuente Cdigo de Migraciones Pruebas Empaquetacin del Sistema Como curiosidad, en la metodologa Crystal Clear no tiene cabida un diseador que no programe. El verificador (tester) se encargar de producir Informes de Errores de ltima hora. Por ltimo, el escritor producir el Manual de Ayuda para el Usuario.

Proceso
En lugar de la interpretacin lineal de los modelos clsicos, que es interpretada en muchos casos como inconvenientes, Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se perciben siete ciclos: 1. El proyecto en s. 2. El ciclo de entrega de una unidad. 3. La iteracin (ntese que 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 fragmento de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas.

15

Imagen 4. Ciclos anidados de Crystal Clear

Prcticas
En cuanto a las prcticas o tcnicas que se favorecen dentro de esta metodologa, podemos mencionar las siguientes: 1. Entrevistas de proyectos. Es costumbre entrevistar a ms de un responsable para tener visiones ms enriquecedoras y variadas. 2. Talleres de reexin. El equipo debe descansar de treinta minutos a una hora para reexionar, discutir sobre posibles problemas y mejoras y organizarse de cara a la siguiente etapa. 3. Planeamiento Blitz. Tcnica equivalente al Juego de Planeamiento de XP. Se ponen tarjetas enumeradas en la mesa, con una historia de usuario o funcin visible en cada una. El grupo simula que no hay dependencias entre ellas, y se alinean en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada funcin. El patrocinador escribe el orden de prioridades, teniendo en cuenta los tiempos y el valor de negocio de cada funcin. Las tarjetas se agrupan en iteraciones que se agrupan a su vez en entregas, normalmente no ms largas de tres meses. 4. Estimacin Delphi con estimaciones de pericia. Se renen los expertos y proponen el tamao del sistema, su tiempo de ejecucin, la fecha de entregas y equilibrarlas entregas en paquetes de igual tamao. 5. Encuentros diarios de pie. Deben ser muy breves, de 5 a 10 minutos. Se trata nicamente de identificar problemas y no de debatir. 6. Miniatura de procesos. Para que as la gente pueda disfrutar de esta metodologa sin que les resulte muy pesada. 7. Grcos de quemado. Se usan tambin en Scrum. Es una tcnica de gracacin para descubrir retardos y problemas en el proceso a tiempo, evitando que se descubran demasiado tarde o cuando ya no tengan solucin. Para ello se hace una estimacin del tiempo que falta para programar lo que queda al ritmo actual. Esta tcnica se asocia con la Lista Tmpana, llamada as porque se reere al agregado de tareas u objetos de alta prioridad al principio de las listas de trabajos pendientes, esperando que los dems se hundan debajo de la lnea de flotacin los elementos 16

que estn sobre la lnea se entregarn en la iteracin siguiente, los que estn por debajo en las restantes. Los grcos de quemado muestran grficamente la velocidad del proceso. 8. Programacin lado a lado. Crystal Clear establece proximidad con los miembros del equipo. Cada persona se enfoca a su propia tarea asignada pero echando un ojo a lo que hace su compaero. Es una ampliacin de la Comunicacin Osmtica al contexto de la programacin, y un contraste a la presin extrema que muchos consideran a la programacin en pares de XP.

17

AUP: Agile Unified Process

Caractersticas
Es un enfoque al desarrollo de software basado en el Rational Unified Process (RUP) de IBM. El ciclo de vida de AUP es en serie a lo grande e iterativo en lo pequeo, liberando artefactos incrementales en el tiempo. El AUP consta de 7 flujos de trabajo o disciplinas: Modelado, Implementacin, Prueba, Despliegue, Gestin de configuracin, Gestin de proyectos y Ambiente. - Modelado: Tiene como objetivo entender el negocio, entender cul es el problema que se va a abordar e identificar las posibles soluciones viables para dicho problema. - Implementacin: El objetivo de esta disciplina es transformar el modelo en cdigo y realizar pruebas bsicas sobre l. - Prueba: Tiene como meta evaluar una evaluacin de los objetivos y encontrar defectos para mejorar la calidad. Se encarga tambin de verificar si el sistema funciona correctamente. - Despliegue: Su objetivo es ejecutar un plan para que el sistema est a disposicin de los usuarios. - Administracin de la configuracin: Su meta es administrar el acceso a los artefactos del proyecto. Lleva un registro de las versiones del producto y controla los cambios que ocurran. - Administracin del proyecto: Tiene el objetivo de administrar los riesgos, la asignacin de tareas, el seguimiento de los procesos y coordinar con las personas fuera del proyecto para facilitar que acabe a tiempo y sin pasar el presupuesto. - Entorno: Apoya los esfuerzos para garantizar la disponibilidad de los procesos, normas y herramientas cuando sea necesario.

Tambin consta de 4 fases del ciclo de desarrollo: - Inicio: se trata de identificar el alcance y dimensin del proyecto, su arquitectura y el presupuesto junto con su aprobacin por parte de aquellos que pertenecen al proyecto. Como hito de esta fase obtenemos los objetivos de ciclo de vida. - Elaboracin: en esta fase se prueba y se confirma la arquitectura del sistema. Como hito obtenemos la arquitectura del ciclo de vida. - Construccin: esta fase consiste en la construccin del software sobre la base incremental siguiendo unas prioridades impuestas por los implicados en el proyecto o por los propios usuarios. Como hito obtenemos la capacidad operacional inicial. - Transicin: esta fase tiene el objetivo de validar e implantar el sistema en el entorno de produccin. Como hito tenemos la liberacin del producto. 18

Roles
- Administrador de bases de datos: trabaja con los miembros del equipo del proyecto para disear, probar y dar soporte a los esquemas de datos. Trabaja dentro de la disciplina de implementacin. - Modelador: se encarga de crear modelos (dibujos, archivos, etc) de manera colaborativa y evolutiva. Trabaja dentro de las disciplinas de modelado e implementacin. - Administrador de la configuracin: se encarga de la infraestructura del medio donde trabaja el equipo de desarrollo. Forma parte de la disciplina de administracin de configuracin. - Implementador: es el encargado de poner el software a punto para la preproduccin. Su parte se desarrolla dentro de la disciplina de desarrollo. - Desarrollador: escribe el cdigo, lo prueba y construye el software. Trabaja en las disciplinas de modelado, implementacin y desarrollo. - Especialista del proceso: desarrolla, adapta y apoya el material de los procesos de organizacin. Trabaja en la disciplina de entorno. - Administrador del proyecto: se encarga de administrar los miembros de los equipos de trabajo, maneja las interacciones entre los involucrados en el proyecto y tambin se encarga de administrar los recursos y las prioridades. Trabaja dentro de las disciplinas de modelado, pruebas, desarrollo y administracin del proyecto. - Examinador: es el miembro que se encarga de someter a evaluacin los productos del proyecto. Su trabajo forma parte de la disciplina de pruebas. - Documentador tcnico: se encarga de la documentacin sobre los materiales, operaciones, mantenimiento y del usuario. Forma parte de la disciplina de desarrollo. - Administrador de pruebas: se encarga de que las pruebas a las que se somete el producto tengan xito. Forma parte de la disciplina de pruebas. - Equipo de pruebas: son los miembros que se encargan de ejecutar las pruebas y documentar las. Pertenecen a la disciplina de pruebas. - Especialista en herramientas: son los responsables de la eleccin, adquisicin, configuracin y mantenimiento de los equipos que se utilizaran durante el proceso. Forma parte de la disciplina de entorno.

Artefactos
- Sistema: el sistema es el software, hardware y documentacin que ser liberado a la produccin. - Cdigo fuente: es el cdigo de programacin para los sistemas.

19

- Suite de pruebas de regresin: son casos de prueba con sus respectivos cdigos listos para ser ejecutados en un orden predefinido. - Scripts de instalacin: cdigo necesario para instalar el sistema en el entorno de preproduccin. - Documentacin del sistema: es la documentacin que fluye junto con el sistema para ayudar a los desarrolladores a mantenerlo actualizado. Contiene las operaciones, soportes y documentacin general del sistema. - Notas: son resmenes que se pasan sobre aquellas modificaciones que se realizan en el proceso de construccin. - Modelado de requerimientos: contiene los requisitos a cumplir, junto con pruebas de aceptacin, automatizacin, modelos de procesos de negocio, reglas, modelos de dominio y organizacin, glosarios, requisitos tcnicos y modelos de UI. - Modelo de diseo: es una descripcin del diseo del sistema que contiene modelos de despliegue, objetos, datos fsicos y seguridad, as como un resumen del sistema y un modelo de UI.

20

Anlisis comparativo
Similitudes y diferencias
Las metodologas giles pueden seguir una gua rgida y concreta de la que no hay que salirse, con tcnicas muy especficas, como sucede con las metodologas FDD y XP, o por el contrario, seguir una gua flexible y abstracta, con mtodos que nos ayudan a obtener el mismo resultado de una manera ms eficiente, como es el caso de Crystal. Una de las similitudes que comparten prcticamente todas las metodologas giles es que presentan guas ajustables y adaptables ante cambios una vez empezado el proyecto. Crystal es la nica excepcin. En cuanto a los roles que intervienen en las diferentes metodologas comentadas en los anteriores apartados, se puede decir que no difieren prcticamente, y que en su mayora los mismos papeles se repiten en todas. Siempre hay un representante del cliente, que normalmente es el que se encarga de comprobar que se van cumpliendo todos los requisitos; un experto en la metodologa para guiar al equipo; un gestor del proyecto; y el equipo de desarrolladores (con mayor o menor grado de subdivisiones dentro de esta unidad). En conclusin podemos decir que la asignacin de los roles es independiente de la metodologa y que tan slo se van adaptando segn el estilo que tenga cada una. Las herramientas usadas por las metodologas giles son en general muy comunes, XP es de las pocas que se desvan de esta norma y han introducido novedades, especialmente en lo que se refiere a herramientas en las fases de pruebas (aunque en este trabajo no se habla de XP). La familia de las metodologas Crystal es la nica que sugiere explcitamente principios del mtodo de diseo para permitir la adaptacin en funcin del tamao del proyecto y la criticidad. DSDM se diferencia por usar prototipos y presenta algunos roles no considerados por el resto: ambassador, visionary y advisor (representan diferentes puntos de vista del cliente). FDD no cubre las primeras fases de un proyecto, pues presupone que se ha realizado trabajo anteriormente

Ventajas y desventajas
DSDM une tcnicas de desarrollo y gestin del proyecto en una misma metodologa que se centra en conseguir un producto que funcione correctamente en los casos ms crticos, por lo que crea un producto en un plazo corto que slo cubre casos de uso bsicos. El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus superiores evitando tiempos de espera y su consecuente prdida de tiempo, en el

21

desarrollo al esperar una aprobacin. Sobre todo teniendo en cuenta que los plazos de desarrollo y las iteraciones son cortos perodos de tiempo, punto que tiene la ventaja de prevenir que transcurra mucho tiempo y la tecnologa cambie, adems de permitir una revisin continua del producto a travs de entregas frecuentes de productos. Llegados aqu, gracias a que los cambios son revertibles y verificados es posible volver a un punto anterior y corregir errores detectados. Otra ventaja es la continua realimentacin (feedback) entre cliente y desarrolladores que ayuda a obtener un proyecto eficiente y efectivo aunque el desarrollo sea rpido y en tiempo reducido.

Como ventajas, FDD tiene que es una metodologa de desarrollo gil, que disminuye el riesgo de los proyectos, pues gracias a sus entregas tangibles cada dos semanas y al constante monitoreo de su calidad, se asegura el firme avance del mismo. Esta metodologa utiliza pequeos bloques que contienen la funcionalidad del sistema, llamados features. Estos bloques, que estn relacionados entre s, son organizados en una lista llamada feature set. Tambin permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar el proyecto. Esto gracias a un buen manejo de las actividades, a la disminucin del riesgo del proyecto y al aseguramiento de la calidad del mismo, respectivamente. FDD presenta su taln de Aquiles 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 otras metodologas. 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.

En cuanto a Crystal Clear podramos meter en el saco de ventajas que es una de las metodologas ms giles y flexibles, con gran nfasis en la comunicacin (de hecho es lo ms importante y crucial) y a los individuos que forman parte del proyecto. Otro punto que se puede considerar ventaja es que se dispone de la figura del usuario real, que realiza validaciones sobre la interfaz de usuario, propone ideas para una mejor implementacin de cara a los usuarios finales de primera mano y participa en la definicin de requerimientos funcionales y no funcionales del software, lo cual implica que se consigue un sistema totalmente preparado y adaptado a los usuarios finales. Este hecho muchas metodologas no lo integran.

Como inconveniente podramos decir que es una metodologa que no se puede aplicar a grandes proyectos donde absolutamente todo se debe controlar y donde se deben seguir 22

por necesidad instrucciones ms disciplinadas y concretas, Crystal Clear es demasiado gil y abstracta en sus mtodos, lo que hace que esta metodologa por s sola sea aplicable en la prctica en casos muy concretos.

Adecuacin para distinto tipo de aplicaciones

DSDM es excelente para proyectos de sistemas de la informacin con presupuestos limitados y agendas muy ocupadas y apretadas. Puede usarse en proyectos de ampliacin de sistemas TI pero tambin podra utilizarse para proyectos de cambio de algn sistema aunque no sea TI. Proyectos interactivos con funcionalidad visible en la interfaz de usuario

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. Un rasgo llamativo de FDD es que no exige la presencia del cliente.

Crystal Clear al darle ms importancia a los individuos y basarse fundamentalmente el xito del proyecto en la comunicacin cara a cara, es una metodologa que nicamente se puede aplicar a proyectos pequeos, de equipos reducidos y menos a 10 personas, pues en proyectos ms ambiciosos es fcil que se pase algo por algo, lo que puede ser fatal. En cambio en proyectos menores, donde la gente se conoce ms y todos estn apoyados unos en otros, es posible llegar a buen puerto con este mtodo tan flexible y menos estresante en comparacin con otras metodologas. Esto ltimo en proyectos ms grandes y de ms importancia es necesario que as sean para poder controlar, por ejemplo, los riesgos crticos a los que se debe enfrentar, algo que Crystal Clear no contempla. Ms bien Crystal Clear est pensada para combinarse junto a otras metodologas como XP o Scum.

AUP es un mtodo gil entre XP y RUP que incluye las actividades y herramientas tradicionales. El AUP resulta ser un proceso muy pesado pero en comparacin con el RUP es muy simple.

23

Bibliografa
Introduccin Diseo de una Metodologa gil de Desarrollo de Software - Marcelo Schenone Desarrollo gil de software - Wikipedia [Imagen 1] DSDM: Dynamic Systems Development Method Mtodo de desarrollo de sistemas dinmicos - Wikipedia Metodologa gil DSDM - Bitcora de Audieman [Imagen 2] Diseo de una Metodologa gil de Desarrollo de Software - Marcelo Schenone Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo, Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG) FDD: Feature Driven development FDD - Wikipedia(Traducido) Presentacin FDD (PPT) Procesos giles (MSWord) Metodologa FDD - Luis Calabria (ctedra) Diseo de una Metodologa gil de Desarrollo de Software - Marcelo Schenone Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo, Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG) Crystal: (Crystal Clear) Diseo de una Metodologa gil de Desarrollo de Software - Marcelo Schenone Documento sobre la metodologa Crystal Crystal Clear Roles and Work Products (ENG) Metodologas giles [Imagen 4] Presentacin sobre Crystal Clear AUP: Agile Unified Process Gestion de proyectos gil: Conceptos bsicos (PDF) http://www.ecured.cu/index.php/Agile_Unified_Process http://www.ambysoft.com/unifiedprocess/agileUP.html http://wikis.uca.es/wikiCE/index.php/Agile_unified_process http://www.ambysoft.com/downloads/agileUP.zip http://www.adolfo.mex.tl/images/18149/METODOLOGIAS%20AGILES.pdf

Anlisis comparativo Metodologas giles, tesis de master

24