ndice

DSDM...... 2
Qu es el DSDM? .......................................................................................................................................................... 2 Caractersticas ................................................................................................................................................................ 2 Ciclo de vida del proyecto .............................................................................................................................................. 4 Cundo es apropiado usar la metodologa DSDM? ...................................................................................................... 5 Cundo no es apropiado aplicar la metodologa DSDM? ............................................................................................. 5

FDD...6
Procesos ......................................................................................................................................................................... 6 1.- Desarrollo de un modelo global. .......................................................................................................................... 6 2.- Construccin de una lista de funcionalidades. ..................................................................................................... 7 3.- Planeacin por funcionalidad. .............................................................................................................................. 7 4.- Diseo por funcionalidad. .................................................................................................................................... 7 5.- Construccin de la funcionalidad. ........................................................................................................................ 7 Roles y responsabilidades .............................................................................................................................................. 8 Roles claves ............................................................................................................................................................... 8 Roles de soporte ....................................................................................................................................................... 8 Roles adicionales ....................................................................................................................................................... 8 Herramientas ................................................................................................................................................................. 9 Conclusiones FDD:.......................................................................................................................................................... 9

Crystal Clear...11
Los siete valores o propiedades de Crystal Clear son: ................................................................................................. 11 En cuanto a las tcnicas, se favorecen: ........................................................................................................................ 12 Conclusion: ................................................................................................................................................................... 13

AUP14
Qu es el AUP? ........................................................................................................................................................... 14 Caractersticas .............................................................................................................................................................. 14 Ciclo de vida del proyecto ............................................................................................................................................ 15 Fase de Elaboracin: ............................................................................................................................................... 16 Fase de Construccin: ............................................................................................................................................. 16 Fase de Transicin: .................................................................................................................................................. 17 Conclusin .................................................................................................................................................................... 17

Comparacin...18
Tamao de los equipos:...................................................................................................................................... 18 Obtencin de los requisitos: ............................................................................................................................... 18 Evaluacin del estado del proyecto: ................................................................................................................... 18 Carga de trabajo: ................................................................................................................................................ 18 Relacin con el cliente: ....................................................................................................................................... 18 Desarrollo: .......................................................................................................................................................... 19 Cdigo fuente: .................................................................................................................................................... 19 Conocimiento sobre la arquitectura: .................................................................................................................. 19 Puntos flacos: ..19

Referencias .20

En esta prctica se definirn con detalle varias metodologas giles de desarrollo para posteriormente hacer una comparacin exhaustiva entre ellas. De cada una de las metodologas, se estudiarn sus caractersticas, roles, artefactos prcticas y herramientas.

DSDM (Dynamic Systems Development Method)

Qu es el DSDM?
El Mtodo de Desarrollo de Sistemas Dinmicos es una metodologa para el desarrollo de software, de naturaleza iterativa e incremental y es considerada como la primera metodologa gil. Surgi en el ao 1995, como respuesta a la crisis del software. El DSDM pretenda as solucionar los principios de la crisis del software, permitiendo llevar a cabo proyectos de desarrollo de software en un tiempo y presupuesto especfico y que cumpliese con las expectativas de los usuarios. Para ello permita la existencia de requisitos cambiantes que se producan en las diferentes evoluciones del producto.

Caractersticas
El Mtodo de Desarrollo de Sistemas Dinmicos se basa en los siguientes principios: Es indispensable la implicacin de los usuarios a los que est dirigido el producto participen en su definicin para lograr un proyecto eficiente y efectivo. Con el fin de evitar retrasos, el equipo de desarrollo ha de ser capaz de tomar decisiones importantes para que el proyecto contine sin necesidad de tener que esperar la aprobacin de niveles superiores. Es preferible entregar con frecuencia un producto bueno y temprano a uno perfecto pero con retraso, ya que a partir de las diferentes iteraciones, al ser posible utilizar tempranamente el producto, permite que desde etapas muy tempranas comience el continuo proceso de revisin de calidad del producto y que con cada iteracin, se aproxime cada vez ms a las expectativas del usuario. Parte de las funcionalidades ms importantes que debe cumplir el producto, las ms necesarias, y a partir de ah, mediante las diversas iteraciones, se va perfeccionando el producto. Se rige por la regla MoSCoW, cuyas siglas en ingles significan: o Must have: el equipo de desarrollo se centra primero en las funcionalidades crticas que han de llevar a cabo para el desarrollo del producto. Dichos requisitos han de ser pactados y aceptados entre todas las partes que participan en el proyecto, antes de que ste comience. o Should have: una vez llevados a cabo los aspectos que debe tener el producto, el equipo se centra en las funcionalidades que convendra

incorporar al sistema, aquellas que debera tener. o Could have: una vez logrado los aspectos ms importantes del producto, se revisa ste y se analizan nuevos aspectos y funcionalidades que el producto podra incorporar. Would like to have (but wont): finalmente, se produce una ltima revisin donde el equipo de desarrollo concreta aspectos que ven convenientes que incorporara el producto final, aquello que les gustara incorporar.

Su estrategia de desarrollo es iterativa e incremental. Facilita los cambios en el producto; cualquier cambio realizado durante su desarrollo, es reversible. Este aspecto es conveniente dado que durante la fase de especificacin del producto, el usuario podra haberse equivocado al especificar una funcionalidad o en cualquier aspecto del producto. Si esto sucede, en vez de continuar con dicho error, se realizan cambios para solventarlo. Se realizan pruebas del producto a lo largo de todo el ciclo de vida del proyecto, no nicamente entre iteracin e iteracin. Esto permite una temprana deteccin y solucin de los errores. La cooperacin y comunicacin entre todas las partes implicadas en el desarrollo del proyecto es vital.

Adems de estos principios, el DSDM se basa tambin en los siguientes, denominados asunciones: 1. Ningn sistema es construido a la perfeccin en el primer intento; siguiendo el denominado Principio del Pareto, con el 20% del esfuerzo total para realizar una actividad se alcanza el 80% de la misma. Por lo tanto, el proceso de desarrollo ha de centrarse en priorizar las funcionalidades ms importantes del sistema. Construir un sistema perfecto es imposible, e intentar aproximarse demasiado a la perfeccin supone una prdida de energa. 2. Hay que conseguir proyectos de calidad dentro de los plazos establecidos. 3. Es necesario que cada paso del desarrollo se complete lo suficiente para que pueda continuar el siguiente, aunque no finalice el anterior. Es decir, pueden realizarse a la vez varios incrementos, siempre y cuando no se obstaculicen entre s. Esto proporciona una reduccin del tiempo de desarrollo. 4. Es posible aplicar el DSDM a proyectos de ampliacin o a proyectos inacabados.

Ciclo de vida del proyecto

El Mtodo de Desarrollo de Sistemas Dinmicos se divide en tres fases, el Pre-proyecto, el Ciclo de la vida del proyecto, y el Post-proyecto: Pre-proyecto: en l se especifica el alcance del proyecto, se identifican los departamentos, los compromisos y los objetivos de cada parte, las personas implicadas en el proyecto y quin financiar el proyecto. Ciclo de vida del proyecto. Se compone por las siguientes fases: o Estudio de la viabilidad: Se estudian los riesgos y se identifica el grado de adecuacin de la metodologa del DSDM al proyecto. De esta fase surge un informe de viabilidad y un plan general del proyecto donde se redacta el plan de desarrollo del proyecto y un registro de riesgos. o Estudio del negocio: Una vez se ha determinado si el DSDM es propicio para llevar a cabo el proyecto, se lleva a cabo un anlisis en profundidad de los procesos de negocio que se van a informatizar. Es esencial la participacin del usuario en esta fase para el correcto funcionamiento del sistema. Esta fase produce un modelo de procesos, un catlogo de requisitos priorizado y la arquitectura del sistema. Iteracin del modelo funcional: Se divide en cuatro fases; la Identificacin del prototipo funcional (donde se define las funcionalidades bsicas que implementara el prototipo), la Definicin del calendario (donde se acuerda el plan de trabajo), la Obtencin del prototipo funcional y la Revisin de ste, donde se compara el prototipo obtenido al ideado inicialmente mediante diversas pruebas realizadas por el usuario. Es esencial conocer la opinin del usuario tras la prueba para poder conocer los aspectos en los que se puede mejorar o solucionar los problemas que presente el prototipo con las distintas iteraciones, con tal de que se adece a sus necesidades. Iteracin del diseo y de la construccin: Se divide en cuatro fases; Identificacin del prototipo de diseo (donde se determinan las funcionalidades que cubrir el proyecto y las que no), la Definicin del calendario, la Construccin del prototipo de diseo (el cual debe de ser un producto utilizable para los usuarios)y la Revisin del prototipo de diseo. Implementacin: Se divide de nuevo en cuatro fases; Aprobacin del usuario (donde ste da su veredicto sobre el producto), Formacin (se instruye a los usuarios finales de la aplicacin/producto para que realicen un correcto uso de ste), Implementacin (se instala el producto en las instalaciones del cliente), Revisin de negocio (se revisa la adecuacin del sistema a las necesidades del negocio y a los objetivos iniciales que se haban planteado). En funcin de esta ltima revisin, se decidir si se contina con la fase del Post-proyecto o se

retrocede a algunas de las anteriores del ciclo de vida (con el objetivo de mejorar el producto). Post-Proyecto: Es el correcto mantenimiento del producto llevado a cabo con tal de que ste siga siendo til con el paso del tiempo a los usuarios.

Cundo es apropiado usar la metodologa DSDM?

Existen diversos factores para averiguar si el Mtodo de Desarrollo de Sistemas Dinmicos se adeca o no a un proyecto concreto. El DSDM es apropiado cuando: Se trata de un proyecto que puede verse mejorado a travs de las interacciones Existe un grupo de desarrollo perfectamente definido y en el que existe una buena comunicacin con el usuario. Cabe destacar este ltimo aspecto, ya que el usuario ha de participar activamente en el desarrollo del producto, aportando su opinin, sus sugerencias, etc. Se trata de un proyecto complejo o de gran dimensin pero que puede descomponerse en diversas partes funcionales ms sencillas. Existe un lmite de tiempo especfico en el que el producto ha de ser entregado. Se trata de un proyecto con unos requisitos perfectamente priorizados. El proyecto sea dinmico y se preste a realizar cambios durante su desarrollo.

Cundo no es apropiado aplicar la metodologa DSDM?

El DSDM no apropiado cuando: Se trata de un sistema en tiempo real y/o crtico. Se trata de un proyecto computacionalmente complejo que impida desglosarlo en distintas partes ms sencillas. Todas las exigencias que ha de cubrir el proyecto estn perfectamente predefinidas desde un principio, antes de la construccin. Esto va totalmente en contra de la metodologa del DSDM, las cual nicamente fija unos requisitos prioritarios (must have) que el producto ha de cumplir y a partir de ah, de forma dinmica, se van aportando nuevas caractersticas y funcionalidades al producto (should have, could have y what we want to have (MoSCoW)).

FDD (en ngles Feature Driven Development)

FDD se traduce como Desarrollo Basado en Funcionalidades. Se trata de un enfoque gil para el desarrollo de sistemas. La metodologa fue desarrollada por Jeff De Luca y Peter Coad, conocido por ser el gur de la Orientacin a Objetos. Sigue una estructura como la del resto metodologas adaptables, pero con algunas diferencias: No hace nfasis en la obtencin de los requerimientos sino en cmo se realizan las fases de diseo y construccin. Sin embargo, fue diseado para trabajar con otras actividades de desarrollo de software y no requiere la utilizacin de ningn modelo de proceso especfico. Por otro lado hace nfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto, es decir, 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 monitorear. Adems se caracteriza por permitir contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Las etapas de las que se compone, tratan de cerrarse cada dos semanas, obteniendo as un resultado peridico y tangible.

Procesos
El proceso consta de cinco pasos secunciales durante los cuales se disea y se construye el sistema: 1. 2. 3. 4. 5. Desarrollo de un modelo global. Construccin de una lista de funcionalidades. Planeacin por funcionalidad. Diseo por funcionalidad. Construccin por funcionalidad.

Modelo global 1
Lista de funcionalidades

Planeacin por funcionalidad 3

Diseo y Construccin por funcionalidad

4 5

1.- Desarrollo de un modelo global.

En esta primera fase, los expertos del dominio ya tienen una idea aproximada del contexto y conocen los requerimientos del sistema. Puede que el documento de especificacin de requerimientos ya exista. Como ya se ha comentado, FDD no se centra en la recoleccin y administracin de los requerimientos. Los expertos presentan un informe llamado

walkthrough en el cual los miembros del equipo y el Chief Arquitect son informados a travs de una descripcin de alto nivel del sistema. El dominio global se divide en diferentes reas, y posteriormente se realiza un walkthrough detallado para cada una de dichas reas, ms tarde, de cada walkthrough, un grupo de desarrolladores realizan un modelo de objetos para el rea del dominio. Adems, el equipo de desarrollo discute y decide cual es el modelo de objetos ms apropiado para cada rea del dominio. Trabajando de este modo, el modelo global del sistema es construido simultneamente

2.- Construccin de una lista de funcionalidades.

Una funcionalidad es un tem til a los ojos del cliente. En esta fase, se toman los walkthroughs, el modelo de objetos y los requerimientos existentes para construir una lista que resuma las funcionalidades del sistema que va a ser desarrollado. En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Las funcionalidades son presentadas por cada rea del dominio y stas forman una lista con las mejores funcionalidades, despus, dicha lista de divide en subconjuntos segn la afinidad y la dependencia de las funcionalidades. stos representan diferentes actividades con un rea especfica del dominio. Por ltimo, la lista es revisada por los usuarios y sponsors del sistema para su validacin y aprobacin.

3.- Planeacin por funcionalidad.

Durante esta etapa se incluye la creacin de un plan de alto nivel, esto quiere decir que, la lista de funcionalidades es ordenada en base a la prioridad y a la dependencia entre otras funcionalidades. Adems, las clases identificadas en la primera etapa son asignadas a cada programador.

4.- Diseo por funcionalidad.

Hasta la fase tres, la metodologa se centraba en seleccin, seleccin y organizacin de las funcionalidades, pero en la cuarta fase se selecciona unos de esos conjuntos para proceder a disear dicha funcionalidad. Para el diseo, se crea un diagrama de secuencia que contiene la descripcin de las clases y los mtodos y notas del equipo, y ms tarde se inspecciona y verifican los diagramas.

5.- Construccin de la funcionalidad.

Una vez tenemos el diseo y la estructura a seguir, se procede a construir la funcionalidad mediante un proceso iterativo. Una iteracin puede durar varios das o incluso dos semanas, y dicho proceso incluye revisiones de diseo. Codificacin, pruebas unitarias e inspeccin de cdigo. Cuando todo se ha verificado y est correcto, el sistema est terminado y se procede a una reunin con el cliente.

Roles y responsabilidades
Roles claves
Director del Proyecto: Lder administrativo y financiero del proyecto. Protege al equipo de situaciones externas. Arquitecto jefe: Diseo global del sistema. Ejecucin de todas las etapas. Director de desarrollo: Lleva diariamente las actividades de desarrollo. Resuelve conflictos en el equipo. Resuelve problemas referentes a recursos. Programador Jefe: Analiza los requerimientos. Disea el proyecto. Selecciona las funcionalidades a desarrollar de la ltima fase del FDD. 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. Poseen el conocimiento de los requerimientos del sistema. Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

Roles de soporte
Domain Manager: Lidera al grupo de expertos del dominio. Resuelve sus diferencias de opinin concernientes a los requerimientos del sistema. Release Manager: Controla el avance del proceso mediante la revisin de los reportes del Chief Programmer. Reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada funcionalidad. Gur del Lenguaje: Responsable de poseer un vasto conocimiento en, por ejemplo, un lenguaje especfico de programacin o tecnologa. Es muy importante cuando se trabaja una nueva tecnologa. Ingeniero de construccin: Responsable de preparar, mantener y correr el proceso de construccin. Realiza el mantenimiento de las versiones y la publicacin de la documentacin. Herramientista: Rol para la construccin de 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. Administrador del sistema: Configura, administra y repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.

Roles adicionales
Tester: Verifica que el sistema recin creado cumpla con los requerimientos del cliente. Puede llegar a ser una persona independiente del equipo del proyecto. Deployer: Es el encargado de convertir la informacin existente requerida por el nuevo sistema. Participa en el lanzamiento de los nuevos productos. Escritores de documentos tcnicos: Prepara la documentacin para los usuarios, que pueden formar parte o no del equipo del proyecto.

Herramientas
Como herramienta para manejar y organizar esta metodologa, encontramos FDDTools . Dicho software nos ofrece una sencilla para producir grficos de seguimiento de proyectos, detallando fechas de entrega, revisiones y funcionalidades completadas. Por tanto, podemos compartirlo con nuestro equipo de trabajo.

Conclusiones FDD:
Se implementan mejor para proyectos cortos y equipos ms pequeos no define explcitamente la parte del proyecto sobre la adquisicin de requisitos. Ms adecuado para definir mtricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeas es bastante sencillo hacer un seguimiento de las mismas. FDD es por su parte un proceso intermedio, en el sentido de que genera una documentacin que no es muy extensa ni muy corta. No se basa en formalismos en la documentacin, si no en controles propios y una comunicacin fluida con el cliente. Se usan las sesiones de trabajo conjuntas en fase de diseo para conseguir una arquitectura sencilla y sin errores.

CRSTAL CLEAR
Crystal es una metodologa de desarrollo de Software gil. Ms que una metodologa se la considera una familia de metodologas, debido a que se subdivide en varios tipos de metodologas en funcin a la cantidad de persona que vayan a estar en el proyecto. Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Presentan un enfoque gil, con gran nfasis en la comunicacin y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. Crystal Clear es la encarnacin ms gil de la serie y de la que ms documentacin se dispone. Adems, Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a una forma tabular elaborada por Cockburn que se usa en muchas metodologas giles para situar el rango de complejidad al cual se aplica una metodologa. En la siguiente figura se muestra una evaluacin de las prdidas que puede ocasionar la falla de un sistema y el mtodo requerido segn este criterio. Los parmetros son: Comodidad (C) Dinero Discrecional (D) Dinero Esencial (E) Vidas (L).

La cada de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del cuadro indican el nmero de personas afectadas a un proyecto.

10

Cuando el nmero de personas aumenta, tambin aumenta la necesidad de coordinar. Cuando el potencial de daos se incrementa, la tolerancia a variaciones se ve afectada. La sensibilidad del tiempo en que se debe estar en el mercado vara: a veces este tiempo debe acortarse al mximo y se toleran defectos, otras se enfatiza la auditoria, confiabilidad, proteccin legal, entre otros. Las personas se comunican mejor cara a cara, con la pregunta y la respuesta en el mismo espacio de tiempo. El factor ms signicativo es comunicacin.

Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: - Crystal Clear (Claro como el cristal) para equipos de 8 o menos integrantes - Amarillo, para 8 a 20 - Naranja, para 20 a 50 - Rojo, para 50 a 100. Se promete seguir con Marrn, Azul y Violeta. La ms exhaustivamente documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeos de categora D6, aunque con alguna extensin se aplica tambin a niveles E8 a D10. Como casi todos los otros mtodos, CC consiste en valores, tcnicas y procesos.

Los siete valores o propiedades de Crystal Clear son:

1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue, si es que se consigue algn usuario corts o curioso que suministre feedback. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseador senior; eso se llama Experto al Alcance de la Oreja. 3. Mejora reflexiva. Tomarse un pequeo tiempo (unas pocas horas durante algunas semanas o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su cdigo necesita mejorarse, o que sera conveniente que se baase ms seguido. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliacin. Tcnicamente, estas cuestiones se han caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la literatura. 5. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre direccin y prioridades, tpicamente con el Patrocinador Ejecutivo. 6. Fcil acceso a usuarios expertos. Es muy importante el contacto directo con expertos en el desarrollo de un proyecto. No hay un dogma de vida o muerte sobre

11

esto, como s lo hay en XP. Un encuentro semanal o semi-semanal con llamados telefnicos adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente tcnico con prueba automatizada, management de configuracin e integracin frecuente. Microsoft estableci la idea de los builds cotidianos, y no es una mala prctica. Muchos equipos giles compilan e integran varias veces al da.

En cuanto a las tcnicas, se favorecen:

a) Entrevistas de proyectos. Se suele entrevistar a ms de un responsable para tener visiones ms ricas b) Talleres de re exin. El equipo debe detenerse treinta minutos o una hora para reexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el perodo siguiente. c) Planeamiento Blitz. Una tcnica puede ser el Juego de Planeamiento de XP. En este juego se ponen tarjetas indexadas en una mesa, con una historia de usuario o funcin visible de cada una. El grupo nge que no hay dependencias entre tarjetas, y las alinea en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada funcin. El patrocinador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada funcin. Las tarjetas se agrupan en perodos de tres semanas llamados iteraciones que se agrupan en entregas, usualmente no ms largas de tres meses. d) Estimacin Delphi con estimaciones de pericia. En el proceso Delphi se renen los expertos responsables y proceden a proponer el tamao del sistema, su tiempo de ejecucin, la fecha de las entregas segn dependencias tcnicas y de negocios, y equilibrar las entregas en paquetes de igual tamao. e) Encuentros diarios de pie. La palabra clave es brevedad, cinco a diez minutos como mximo. No se trata de discutir problemas, sino de identicarlos. f) Miniatura de procesos. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un da. La idea es que la gente pueda degustar la nueva metodologa. g) Grficos de quemado. Su nombre viene de los grficos de quemado de caloras de los regmenes dietticos, se usan tambin en Scrum. Se trata de una tcnica grfica para descubrir demoras y problemas lo antes posible en el proceso evitando que se descubran demasiado tarde. h) Programacin lado a lado. Mucha gente siente que la programacin en pares de XP Involucra una presin excesiva la versin de Crystal Clear establece proximidad, pero cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su compaero, quien tiene su propia mquina. Esta es una ampliacin de la Comunicacin Osmtica al contexto de la programacin.

12

El proceso de Cristal Clear se basa en una exploracin refinada de los inconvenientes de los modelos clsicos. Dice Cockburn que la mayora de los modelos de proceso propuestos entre 1970 y 2000 se describan como secuencias de pasos. Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se perciben siete ciclos: El proyecto El ciclo de entrega de una unidad La iteracin (ntese que CC requiere mltiples entregas por proyecto pero no muchas iteraciones por entrega) La semana laboral El perodo de integracin, de 30 minutos a tres das El da de trabajo El episodio de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas.

Conclusion:
Los mtodos Crystal no prescriben las prcticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros mtodos como Scrum, XP y Microsoft Solutions Framework. En un comentario Cockburn confiesa que cuando imagin a Crystal Clear pensaba proporcionar un mtodo ligero; comparado con XP, sin embargo, Cristal Clear result muy pesado pero es ms fcil de aprender e implementar. A pesar de su jerga chocante XP es ms disciplinado, piensa Cockburn, pero si un equipo ligero puede tolerar sus rigores, lo mejor ser que se mude a XP.

13

AUP (Agile Unified Process)

Qu es el AUP?
Esta metodologa es una versin ms simplificada del Proceso Unificado de Racional (RUP). ste lo que hace es coger las mejores prcticas del RUP y la Metodologa gil. Pero la RUP no tiene nada que ver con la forma de trabajar de la AUP. El AUP est basada en que de una manera simple y fcil se puede llegar a una forma de aplicar tcnicas para desarrollar aplicaciones de software dirigidas a los negocios utilizando cmo he dicho antes, tcnicas giles. Esto ayuda para entender la forma de desarrollar aplicaciones de software de negocio usando estas tcnicas .Esto ltimo es lo que caracteriza al AUP. El AUP utiliza adems del uso de tcnicas giles utiliza un Desarrollo Dirigido por Pruebas (TDD), un modelado gil, un gestin de Cambios gil, y una refactorizacin de Base de Datos para mejorar la productividad.

Caractersticas
La metodologa AUP es una versin simplificada de la metodologa RUP. Se le caracteriza porque contiene 4 ingenieriles,3 de apoyo y 7 flujos de trabajos. (Modelado, Implementacin, Prueba, Despliegue, Gestin de configuracin, Gestin de proyectos y Ambiente). Adems, el modelo sintetiza los tres primeros flujos de la metodologa RUP : Modelamientos, Requerimientos y Anlisis & diseo). AUP contiene cuatro fases como las contiene el RUP. stas son : Incepcin o Creacin, Elaboracin, Construccin y Transicin. La AUP tambin se caracteriza por ser iterativa y adems incremental. Esto quiere decir que en el desarrollo de un proyecto importante, ste se divide en pequeos proyectos derivados. Esto sirve para tener el control de las pequeas partes y si sale cualquier problema solucionarlo lo antes posible. A cada pequea parte de la divisin del proyecto es una iteracin. Esto hace que vaya poco a poco, y todo vaya saliendo bien como he explicado antes. Cada parte adems, trata un conjunto de casos de uso. Esto lo que hace es que le da importancia a la funcionalidad que el sistema tiene que tener para satisfaces todo lo que el usuario necesite en un futuro. Los casos de Uso es el que orienta todas las actividades del desarrollo del producto software. Las ventajas de que sta metodologa se iterativa es que existe una deteccin de los riesgos y peligros con anterioridad. Adems de una buena administracin del cambio en el transcurro de cada iteracin. Todas estas caractersticas hacen que exista un grado mayor de reutilizacin a parte de la experiencia para el grupo del desarrollo. La arquitectura que sigue esta metodologa es muy parecida a la que contiene una construccin. Esto se refiere a que existen varios planos de ste, y esto sirve para tener una imagen global del proyecto antes de que empiece el desarrollo de ste.

14

Adems existe una arquitectura en el software. El cual tiene diferentes modos dentro del sistema, stos son por ejemplo : funcional, dinmico, estructural .. etc. Esta arquitectura del software es la base dnde se realiza el proyecto. Y adems, un punto importante, es la que define la forma del sistema.

Ciclo de vida del proyecto

El AUP se divide en cuatro fases, Incepcin, Elaboracin, Construccin y por ltimo Transicin. Fase de Incepcin: Esta es la fase de inicio del desarrollo del producto. El objetivo de sta es establecer un consenso entre los interesados sobre el proyecto en relacin a los objetivos de ste para conseguir el dinero que financiar el proyecto. Las actividades principales son: 1. Definir el alcance del proyecto. Esto quiere decir qu se har en el sistema y lo que no se har, que tambin es muy importante. Adems, se realiza una lista de caractersticas del nivel o de puntos de casos de uso, donde se establecern los lmites desde los cuales trabajarn el equipo. Esto suele tomar la forma de una lista de caractersticas de alto nivel y / o el punto de casos de uso. 2. Estimacin de costos y calendario. En un nivel importante del proyecto, existe unas estimaciones en el calendario y en el costo del proyecto. Las estimaciones principales se realizan en fases posteriores, y se implementarn en la fase de Elaboracin. Las tareas que van a ser realizadas en el futuro son especificadas con ms precisin y con bastante confianza mientras que las tareas bajo la lnea son estimadas y que no es posible programar todo en un proyecto, en la salida con cualquier grado aceptable de confianza con un margen de error mayor. Normalmente, se planifican para corto plazo y precisar a lo largo plazo. 3. Definicin de Riegos. Los riesgos que pueden aparecer en el transcurro del desarrollo se definen en esta parte. La administracin del riego es importante en proyectos de AUP. La lista de riegos se modifica cuando los riesgos son identificados, evitados, exterminados, solucionados El control de riegos del proyecto son los que llevan a cabo la programacin de las iteraciones. Los riegos ms altos son dirigidos en iteraciones anteriores que los riegos de menor prioridad.

15

4. Determinar la factibilidad del proyecto. El proyecto tiene que ser capaz de crear un sentido desde la perspectiva operacional tcnica y del negocio, y tiene que ser de llevarlo a cabo. Si el proyecto no es viable, ser suspendido. 5. Preparar el entorno del proyecto. Aqu se prepara el rea de trabajo. Conseguir al personal, obtener todo el material ( hardware y software). Adems, deber ajustar AUP para completar las necesidades de su equipo. La fase de Iniciacin acaba con el hijo de Objetivos del Ciclo de Vida.El objetivo principal es que el equipo de desarrollo tenga claro el alcance del proyecto y todo el esfuerzo que conlleva. Si no finaliza esto, el proyecto tendr que ser cancelado o suspendido. Los Artefactos (Pieza de informacin producida, modificada y utilizada en un Proceso) es el documento que define todo el proyecto.

Fase de Elaboracin:
En esta fase, el objetivo es probar la arquitectura del sistema que se desarrollar. La cosa es que el equipo sea capaz de desarrollar un sistema que cumpla con los requisitos, y para ello es necesario construir una especia de esqueleto que recorra todo el sistema del trabajo(prototipo de la arquitectura).Esto un concepto pobre pero su significado es software funcional de alto nivel, el cual incluye varias casos de uso de alto riegos para demostrar que el sistema es tcnicamente factible. No todos los requisitos se especifican en esta fase. Se especifican lo justo como para comprender los riesgos de la arquitectura y asegurar que haya un entendimiento de los alcances de cada requerimiento para que la fase siguiente se lleve a cabo. Los riegos de la Arquitectura son identificados y priorizados durante la Elaboracin. El nivel de la arquitectura del sistema tiene que reflejar la arquitectura general de la empresa tambin. Durante la Elaboracin, el equipo tambin piensa en la Fase de Construccin, y se prepara para ello. Una vez con todo el material necesario de Hardware y de Software, el equipo crea el ambiente de trabajo segn la arquitectura del sistema establecido. Desde la Administracin del Proyecto se dirige a todas las personas del proyecto. La fase de Elaboracin termina con el hito de la Arquitectura del Ciclo de Vida. Con esto, se ve si el equipo contiene un prototipo viable para empezar con la produccin, y que la financiacin sigue adelante. Si por cualquier circunstancia, el equipo no pasa esta prueba, el proyecto se cancelar. Los artefactos que contiene esta fase cuenta con un modelo del dominio, un modelo de procesos, un modelo funcionas del alto nivel, y una arquitectura bsica del proyecto.

Fase de Construccin:
Esta fase de Construccin tiene como objetivo el desarrollo del sistema hasta la preproduccin de ste en diferentes pruebas. En fases anteriores, los requisitos generalmente eran identificados y ahora, la arquitectura del sistema se ha establecido. Lo ms importante es dar prioridad y entender todos los requerimientos que conlleva esta fase, el modelado que ataca una solucin, y ms tarde sera la codificacin y todas las pruebas para el software. El

16

hecho es que, existen unas versiones para que se obtengan unos comentarios de los usuarios sobre el proyecto. La fase de Construccin finaliza con el hito de la Capacidad Operativa Inicial. En esta fase, el equipo se plantea si la versin que tiene actualmente es la buena, ya que sta es la que tiene que ir ahora a la fase de pre-produccin y pasar todas las pruebas. Si el equipo, no pasa esta fase, el proyecto se debe cancelar o suspender. Si no, el quipo para a la fase de Transicin.

Fase de Transicin:
El objetivo de esta fase es la de llevar el sistema a produccin. Para ello existen un tipo de pruebas en el transcurro de esta fase. Una peculiaridad de esta fase es el retrabajo que consiste en que si el usuario ve algn defecto importante en la versin actual del proyecto. El tiempo y esfuerzo que conlleva esta fase cambia de un proyecto a otro. Shrink-wrapped software supone la fabricacin y distribucin de software y documentacin. Los sistemas internos son ms simples de desplegar que sistemas externos generalmente. Los sistemas que conllevan un alto nivel pueden requerir pruebas betas extensivas por grupos pequeos antes de entregrsela a los usuarios. La liberacin de un nuevo sistema de marca puede traer consigo la compra y configuracin de hardware mientras se actualiza un sistema existente que tambin puede traer una conversin de datos y una coordinacin exhaustiva con la comunidad de usuarios. Cada proyecto comparado con otros es diferente. Cada proyecto se desarrolla segn sus necesidades. Esta fase de Transicin acaba con el hito de la Liberacin del producto. Un problema que surge en esta fase, que es bastante importante, es declara que el sistema est preparado para una produccin segura y eficiente. Si el proyecto no sale como se pensaba ,y fracasa el proyecto tiene dos opciones o ser redirigido dndole otro enfoque o utilizando otros recursos o ser cancelados. Si el equipo pasa este hito el proyecto se mueve a produccin.

Conclusin
Esta metodologa hace realmente hincapi en la gestin de riesgos. Para solucionar, explica que cuando surgen problemas con un alto riesgo, se le tienen quedar prioridad en el proceso de desarrollo, y as solucionarlas lo antes posible. El Modelo, objetivo de esta disciplina que es la de entender el negocio de organizacin, es mucho ms simple que la de RUP.Y con esto, agrupa en una sola disciplina todas las disciplinas de Modelado de Negocio, Requisitos, Anlisis y diseo. Las dems disciplinas restantes que lleva esta metodologa son las mismas que las de RUP.

17

Comparaciones
Para realizar la comparacin entra las diferentes metodologas, trataremos los siguientes aspectos: Tamao de los equipos: Por un lado, tenemos DSDM y FDD, que son ms adecuados para equipos pequeos con el motivo de asegurar una buena comunicacin, Crystal divide por colores segn el tamao del grupo: 3 a 8 integrantes; Amarillo, de 8 a 20; Naranja, 20 a 50; Rojo, 50 a 100; por ltimo, el tamao del equipo en AUP es relativo, ya que se puede probar con proyectos de nivel. Obtencin de los requisitos: Los principales requisitos DSDM se definen durante la fase del Pre-Proyecto, donde se estudia la viabilidad y la financiacin de ste. Al contrario, FDD no define explcitamente la parte del proyecto sobre la adquisicin de requisitos. En AUP de definen de forma detallada al principio del desarrollo del producto. Evaluacin del estado del proyecto: En la metodologa AUP y DSDM se realizan pruebas durante todas las fases del ciclo de vida, lo cual permite una temprana deteccin y solucin de errores. Tambin el uso de FDD es adecuado si se desea conocer correctamente el estado del proyecto, puesto que al dividirlos en unidades pequeas es bastante sencillo hacer un seguimiento de las mismas. Carga de trabajo: La carga del trabajo en DSDM depende del integrante del grupo, que debe asumir su rol y ser capaz de gestionar las actividades que se le han asignado. Luego, CC maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Hablando de cantidad de documentacin, FDD genera una cantidad intermedia, es decir, algo ms que AUP, donde existe una gran simplicidad, haciendo que todo se escriba en pocas pginas, y no en miles de ellas. Relacin con el cliente: En DSDM es vital. El cliente, que sigue de cerca el desarrollo del producto, aporta sugerencias para la mejora de ste tras cada prueba. El equipo de desarrollo ha de estar constantemente en contacto con el cliente para asegurar la creacin de un producto de calidad y que se adapte a sus exigencias. FDD y Crystal destacan por una comunicacin fluida con el cliente. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. En cambio, en AUP, el cliente se muestra activo al final de cada se para dar la aprobacin de si el proyecto puede llegar a ser factible.

18

Desarrollo: El desarrollo en DSDM es muy dinmico, ya que a menudo se estn realizando pruebas, solventando errores y cambiando los requisitos segn la marcha. FDD tambin se centra ms en la organizacin global y en la ejecucin de pruebas, asumindolas como obligatorias. Es posible utilizar programacin por parejas en partes complejas. En Crystal, el desarrollo se produce con todo el equipo junto en el mismo cuarto. Una variante especial es disponer en la sala de un diseador senior. En AUP hay un claro seguimiento del producto a cada paso, se fija un objetivo y es de analizar cualquier posible error y solucionarlo lo antes posible. Cdigo fuente: FDD se diferencia del resto en que, al ser funcionalidades independientes, el cdigo es propietario, aunque hay puesta en comn, sobretodo cuando se trabajan en clases relacionadas. Muchos equipos giles compilan e integran varias veces al da. En AUP Las distintas funcionalidades se trabajan por separado, y ms tarde se solapan. Conocimiento sobre la arquitectura: En FDD se usan las sesiones de trabajo conjuntas en fase de diseo para conseguir una arquitectura sencilla y sin errores. DSDM cada departamento se encarga de organizar su estructura y en AUP la arquitectura se establece en la fase de Elaboracin, no se modificar, y se establecer ya en las prximas fases. Puntos flacos: En DSDM es totalmente inviable para sistemas crticos que supongan algn riesgo para el exterior (por ejemplo aquellos que traten con productos txicos, radioactivos, etc.). Adems requiere una fuerte participacin por parte del usuario y la organizacin puede ser dificultosa en equipos sin mucha experiencia. El taln de Aquiles de FDD es la necesidad de tener miembros con experiencia que marquen el camino a seguir desde el principio, adems que, debido a que existen jerarquas, puede provocar grandes dependencias de la gente experimentada. Cristal Clear resulta muy pesado pero es ms fcil de aprender e implementar. Si un equipo ligero puede tolerar sus rigores, lo mejor ser que se mude a XP. Resulta que XP es ms disciplinado. Por ltimo, de AUP puede resultar un proyecto muy pesado y complejo. Ya que est mucho ms detallado. Hay que cumplir los alcances estimados en cada fase, si no el proyecto ser cancelado y la exigencia del nivel tcnico del personal es alto, ya que se necesita exprimir todas las ventajas posibles y proporcionar un buen producto.

19

Referencias
DSDM Explicacin del DSDM Transparencias Wikipedia FDD

Transparencias FDD Documento FDD Definicin y comparacin con XP y RUP

Crystal Clear Blog Tercer Planeta, Capacidades Tcnicas SECCPERU, Metodologas giles Documentacin Crystal Clear AUP AUP ecured Documentacin AUP WIKI AUP

20