METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP)

1.- INTRODUCCION. Los procesos giles de desarrollo de software, conocidos anteriormente como metodologas livianas, intentan evitar los tortuosos y burocrticos caminos de las metodologas tradicionales enfocndose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos m todos de desarrollo gil! la mayora minimi"a riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteraci#n, la cual debe durar de una a cuatro semanas. $ada iteraci#n del ciclo de vida incluye% planificaci#n, anlisis de requerimientos, dise&o, codificaci#n, revisi#n y documentaci#n. 'na iteraci#n no debe agregar demasiada funcionalidad para justificar el lan"amiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteraci#n. *l final de cada iteraci#n el equipo vuelve a evaluar las prioridades del proyecto. Los m todos *giles enfati"an las comunicaciones cara a cara en ve" de la documentaci#n. La mayora de los equipos *giles estn locali"ados en una simple oficina abierta, a veces llamadas +plataformas de lan"amiento+ (bullpen en ingl s). La oficina debe incluir revisores, dise&adores de iteraci#n, escritores de documentaci#n y ayuda y directores de proyecto. Los m todos giles tambi n enfati"an que el software funcional es la primera medida del progreso. $ombinado con la preferencia por las comunicaciones cara a cara, generalmente los m todos giles son criticados y tratados como +indisciplinados+ por la falta de documentaci#n t cnica. Metodolog ! "g#le! Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Cr stal Clear D namic S stems Development Met!od (DSDM) "eature Driven Development ("DD) #ean Software Development (#SD)

Agile $nified Process (A$P) Software Development %! t!ms Agile Documentation &C'(&X Process Microsoft Solutions "ramewor) (MS") Agile Data Met!od Data*ase %efactoring #eanCMM&

PROCESO UNIFICADO AGIL (AUP).El ,roceso 'nificado *gil de -cott *mbler o *gile 'nified ,rocess (*',) en ingl s es una versi#n simplificada del ,roceso 'nificado de .ational (.',). Este describe de una manera simple y fcil de entender la forma de desarrollar aplicaciones de software de negocio usando t cnicas giles y conceptos que a/n se mantienen vlidos en .',. El *', aplica t cnicas giles incluyendo 0esarrollo 0irigido por ,ruebas (test driven development 1 200), 3odelado *gil, 4esti#n de $ambios *gil, y .efactori"aci#n de 5ase de 0atos para mejorar la productividad. El proceso unificado ($nified Process o ',) es un marco de desarrollo software iterativo e incremental. * menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y artefactos involucrados en el desarrollo de un proyecto software. 0ado que es un marco de procesos, puede ser adaptado y la ms conocida es .', (%ational $nified Process) de 653. *', se preocupa especialmente de la gesti#n de riesgos. ,ropone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. ,ara ello, se crean y mantienen listas identificando los riesgos desde etapas inciales del proyecto. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables durante la base de elaboraci#n del producto, donde se demuestre la valide" de la arquitectura para los requisitos clave del producto y que determinan los riesgos t cnicos. El proceso *', establece un 3odelo ms simple que el que aparece en .', por lo que re/ne en una /nica disciplina las disciplinas de 3odelado de 7egocio, .equisitos y *nlisis y 0ise&o. El resto de disciplinas (6mplementaci#n, ,ruebas, 0espliegue, 4esti#n de $onfiguraci#n, 4esti#n y Entorno) coinciden con las restantes de .',.

CICLO DE $IDA DEL PROCESO UNIFICADO AGIL (AUP).-

*l igual que en .',, en *', se establecen cuatro fases que transcurren de manera consecutiva y que acaban con hitos claros alcan"ados% 6nception($oncepci#n)% El objetivo de esta fase es obtener una comprensi#n com/n cliente1 equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo.

Elaboraci#n% El objetivo es que el equipo de desarrollo profundice en la comprensi#n de los requisitos del sistema y en validar la arquitectura.

$onstrucci#n% 0urante la fase de construcci#n el sistema es desarrollado y probado al completo en el ambiente de desarrollo.

2ransici#n% el sistema se lleva a los entornos de preproducci#n donde se somete a pruebas de validaci#n y aceptaci#n y finalmente se despliega en los sistemas de producci#n.

Las disciplinas se llevan a cabo de manera sistemtica, a la definici#n de las actividades que reali"an los miembros del equipo de desarrollo a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son% 8. 3odelo. El objetivo de esta disciplina es entender el negocio de la organi"aci#n, el problema de dominio que se abordan en el proyecto, y determinar una soluci#n viable para resolver el problema de dominio. 9. *plicaci#n. El objetivo de esta disciplina es transformar su modelo (s) en c#digo ejecutable y reali"ar un nivel bsico de las pruebas, en particular, la unidad de pruebas. :. ,rueba. El objetivo de esta disciplina consiste en reali"ar una evaluaci#n objetiva para garanti"ar la calidad. Esto incluye la b/squeda de defectos, validar que el sistema funciona tal como est establecido, y verificando que se cumplan los requisitos. ;. 0espliegue. El objetivo de esta disciplina es la prestaci#n y ejecuci#n del sistema y que el mismo este a disposici#n de los usuarios finales. <. 4esti#n de configuraci#n. El objetivo de esta disciplina es la gesti#n de acceso a herramientas de su proyecto. Esto incluye no s#lo el seguimiento de las versiones con el tiempo, sino tambi n el control y gesti#n del cambio para ellos. =. 4esti#n de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gesti#n de riesgos, la direcci#n de personas (la asignaci#n de tareas, el seguimiento de los progresos, etc), coordinaci#n con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. >. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuer"os por garanti"ar que el proceso sea el adecuado, la orientaci#n (normas y directrices), y herramientas (hardware, software, etc) est n disponibles para el equipo seg/n sea necesario. INCREMENTO % DESARROLLO DE AUP.Los equipos de *', suelen ofrecer versiones de desarrollo al final de cada iteraci#n en pre1 producci#n rea (s). 'na versi#n de desarrollo de una aplicaci#n es algo que podran ser liberados

en la producci#n si se ponen a trav s de su pre1producci#n de garanta de calidad (?*), las pruebas y los procesos de despliegue. La primera producci#n de liberaci#n a menudo toma ms tiempo para entregar versiones posteriores. La primera producci#n de liberaci#n puede tomar doce meses para entregar la segunda versi#n de nueve meses, y luego otras liberaciones se entregan cada seis meses. 'na de las primeras se centra en cuestiones de despliegue, no s#lo permite evitar los problemas, sino que tambi n permite tomar ventaja de sus experiencias durante el desarrollo. ,or ejemplo, cuando despliegue un software en su rea deber tomar notas de lo que funciona y lo que no, toma nota de que puede servir como la columna vertebral de su instalaci#n de scripts.

PRINCIPIOS DE LA AUP.La *', es gil, porque est basada en los siguientes principios% 8. El personal sabe lo que est haciendo. La gente no va a leer detallado el proceso de documentaci#n, pero algunos quieren una orientaci#n de alto nivel y @ o formaci#n de ve" en cuando. La *', producto proporciona enlaces a muchos de los detalles, si usted est interesado, pero no obliga a aquellos que no lo deseen. 9. -implicidad. 2odo se describe concisamente utili"ando un pu&ado de pginas, no miles de ellos. :. ;. *gilidad. Agil *..65* El ajuste a los valores y principios de la *lian"a Agil. $entrarse en actividades de alto valor. La atenci#n se centra en las actividades que se ve que son esenciales para el de desarrollo, no todas las actividades que suceden forman parte del proyecto. <. Berramienta de la independencia. 'sted puede usar cualquier conjunto de herramientas que usted desea con el gil ',. Lo aconsejable es utili"ar las herramientas que son las

ms adecuadas para el trabajo, que a menudo son las herramientas simples o incluso herramientas de c#digo abierto. =. *daptaci#n de este producto para satisfacer sus propias necesidades. La *', producto es de fcil acomodo com/n a trav s de cualquier herramienta de edici#n de B23L. 7o se necesita comprar una herramienta especial, o tomar un curso, para adaptar la *',. CONCLUSIONES.-i deseamos un m todo gil entre C, y .', tradicionales, que incluya explcitamente las actividades y las herramientas que estn acostumbrados, entonces la ms aconsejable es la *',. C, no muestra explcitamente c#mo crear algunos de las herramientas que la administraci#n quiere ver. En el otro extremo del espectro est .',, que es el gestor ms utili"ado de los desarrolladores, pero presenta una gran cantidad de herramientas. La *', en comparaci#n entre los dos, es la adopci#n de muchas de las t cnicas giles de C, y otros procesos giles que mantiene de las .',. El usuario final es el mejor jue" que determina se la *', es el m todo gil ms adecuado. En relaci#n al C,, el *', resulta ser un proceso muy pesado y en relaci#n al .', resulta ser un proceso muy simplificado, entonces, los desarrolladores debern decidir en% si desea buscar una forma de trabajo ligero esta C, y si desea trabajar con un proceso ms detallado esta .',.