METODOLOGIAS AGILES RUP

Se entiende como Desarrollo Ágil de Software a un paradigma de Desarrollo de Software basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

Es un marco de trabajo conceptual de la ingeniería 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 mayoría minimiza 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. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpenen 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 enfatizan que el software funcional es la primera medida del progreso. Combinado 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.

 HISTORIA

La definición moderna de desarrollo ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra los métodos de “peso pesado”, muy estructurado y estricto, extraídos del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente. Los métodos de desarrollos ágiles e iterativos pueden ser vistos como un retroceso a las prácticas de desarrollo observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías formales). Inicialmente, los métodos ágiles fueron llamados métodos de "peso liviano". En el año 2001, miembros prominentes de la comunidad se reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologías ágiles". Poco después, algunas de estas personas formaron la "alianza ágil", una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchos métodos similares al ágil fueron creados antes del 2000. Entre los más notables se encuentran: Scrum(1986), Crystal Clear (cristal transparente), programación extrema o XP (1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos(1995). Kent Beck creó el método de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del Sistema exhaustivo de compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese proyecto, el método fue refinado por Ron Jeffries.

METODOLOGIA RUP

Siempre que empezamos discutiendo métodos en la arena OO, inevitablemente salimos con el papel del Rational Unified Process. El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la Rational como el proceso complementario al UML. El RUP es un armazón de proceso y como tal puede acomodar una gran variedad de procesos. De hecho ésta es mi crítica principal al RUP - como puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice qué hacer en lugar de dar opciones infinitas.

Como resultado de esta mentalidad de armazón de procesos, el RUP puede usarse en un estilo muy tradicional de cascada o de una manera ágil. Como resultado usted puede usar el RUP como un proceso ágil, o como un proceso pesado - todo depende de cómo lo adapte a su ambiente.

Craig Larman es un fuerte defensor de usar el RUP de una manera ágil. Su excelente libro introductoriosobre desarrollo OO contiene un proceso que está muy basado en su pensamiento ligero del RUP. Su visión es que mucho del reciente empujón hacia los métodos ágiles no es nada más que aceptar desarrollo OO de la corriente principal que ha sido capturada como RUP. Una de las cosas que hace Craig es pasarse los primeros dos o tres días de una iteración mensual con todo el equipo usando el UML para perfilar el diseño del trabajo a hacerse durante la iteración. Esto no es un cianotipo del que no se pueda desviarse, sino un boceto que da una perspectiva sobre cómo pueden hacerse las cosas en la iteración.

Otra tachuela en el RUP ágil es el proceso dX de Robert Martin. El proceso dx es una versión totalmente dócil del RUP que simplemente es idéntico a la XP(voltear dX al revés para ver la broma). El dX está diseñado para gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la vez XP y RUP y por tanto un buen ejemplo del uso ágil del RUP.

Para mí, una de las cosas clave que necesita el RUP es que los líderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Más de una vez he oído a la gente que usa el RUP que están usando un proceso de desarrollo estilo cascada. Gracias a mis contactos en la industria, sé que Philippe Kruchten y su equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos principios y animando las versiones ágiles del RUP tales como los trabajos de Craig y de Robert tendrá un efecto importante.

El proceso de ciclo de vida de RUP se divide en cuatro fases bien conocidas llamadas Incepción, Elaboración, Construcción y Transición. Esas fases se dividen en iteraciones, cada una de las cuales produce una pieza de software demostrable. La duración de cada iteración puede extenderse desde dos semanas hasta seis meses. Las fases son:

Incepción. Significa “comienzo”, pero la palabra original (de origen latino y casi en desuso como sustantivo) es sugestiva y por ello la traducimos así. Se especifican los objetivos del ciclo de vida del proyecto y las necesidades de cada participante. Esto entraña establecer el alcance y las condiciones de límite y los criterios de aceptabilidad. Se identifican los casos de uso que orientarán la funcionalidad.

Se diseñan las arquitecturas candidatas y se estima la agenda y el presupuesto de todo el proyecto, en particular para la siguiente fase de elaboración. Típicamente es una fase breve que puede durar unos pocos días o unas pocas semanas.

Elaboración. Se analiza el dominio del problema y se define el plan del proyecto. RUP presupone que la fase de elaboración brinda una arquitectura suficientemente sólida junto con requerimientos y planes bastante estables. Se describen en detalle la infraestructura y el ambiente de desarrollo, así como el soporte de herramientas de automatización. Al cabo de esta fase, debe estar identificada la mayoría de los casos de uso y los actores, debe quedar descripta la arquitectura de software y se debe crear un prototipo de ella. Al final de la fase se realiza un análisis para determinar los riesgos y se evalúan los gastos hechos contra los originalmente planeados.

Construcción. Se desarrollan, integran y verifican todos los componentes y rasgos de la aplicación. RUP considera que esta fase es un proceso de manufactura, en el que se debe poner énfasis en la administración de los recursos y el control de costos, agenda y calidad. Los resultados de esta fase (las versiones alfa, beta y otras versiones de prueba) se crean tan rápido como sea posible. Se debe compilar también una versión de entrega. Es la fase más prolongada de todas.

Transición. Comienza cuando el producto está suficientemente maduro para ser entregado. Secorrigen los últimos errores y se agregan los rasgos pospuestos. La fase consiste en prueba beta, piloto, entrenamiento a usuarios y despacho del producto a mercadeo, distribución y ventas. Se produce también la documentación. Se llama transición porque se transfiere a las manos del usuario, pasando del entorno de desarrollo al de producción.

A través de las fases se desarrollan en paralelo nueve workflows o disciplinas: Modelado de Negocios, Requerimientos, Análisis & Diseño, Implementación, Prueba, Gestión de Configuración & Cambio, Gestión del Proyecto y Entorno. Además de estos workflows, RUP define algunas prácticas comunes:

Desarrollo iterativo de software. Las iteraciones deben ser breves y proceder por incrementos pequeños. Esto permite identificar riesgos y problemas tempranamente y reaccionar frente a ellos en consecuencia.

Administración de requerimientos. Identifica requerimientos cambiantes y postula una estrategia disciplinada para administrarlos.

Uso de arquitecturas basadas en componentes. La reutilización de componentes permite asimismo ahorros sustanciales en tiempo, recursos y esfuerzo.

Modelado visual del software. Se deben construir modelos visuales, porque los sistemas complejos no podrían comprenderse de otra manera. Utilizando una herramienta como UML, la arquitectura y el diseño se pueden especificar sin ambigüedad y comunicar a todas las partes involucradas.

Prueba de calidad del software. RUP pone bastante énfasis en la calidad del producto entregado.

Control de cambios y trazabilidad. La madurez del software se puede medir por la frecuencia y tipos de cambios realizados.

Aunque RUP es extremadamente locuaz en muchos respectos, no proporciona lineamientos claros de implementación que puedan compararse, por ejemplo, a los métodos Crystal, en los que se detalla la documentación requerida y los roles según diversas escalas de proyecto. En RUP esas importantes decisiones de dejan a criterio del usuario. Se asegura que RUP puede implementarse “sacándolo de la caja”, pero dado que el número de sus artefactos y herramientas es inmenso, siempre se dice que hay que recortarlo y adaptarlo a cada caso. El proceso de implementación mismo es complejo, dividiéndose en seis fases cíclicas.

Existe una versión recortada de RUP, dX de Robert Martin, en la cual se han tomado en consideración experiencias de diversos MAs, reduciendo los artefactos de RUP a sus mínimos esenciales y (en un gesto heroico) usando tarjetas de fichado en lugar de UML. Es como si fuera RUP imitando los principios de XP; algunos piensan que dX es XP de cabo a rabo, sólo que con algunos nombres cambiados [ASR+02]. RUP se ha combinado con Evo, Scrum, MSF y cualquier metodología imaginable. Dado que RUP es suficientemente conocido y su estructura es más amplia y compleja que el de cualquier otro método ágil, su tratamiento en este texto concluye en este punto.

IV.   Conclusiones  

· No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software.

· Las metodologías tradicionales históricamente han intentado abordar la mayor cantidad de situaciones del contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y de requisitos cambiantes.

· Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos.

· Las metodologías ágiles se caracterizan por su sencillez, tanto en su aprendizaje como en su aplicación; sin embargo, gozan tanto de ventajas como de inconvenientes.

· Las metodologías ágiles permiten a los pequeños grupos de desarrollo concentrarse en la tarea de construir software fomentando prácticas de fácil adopción y en un entorno ordenado que permiten que los proyectos finalicen exitosamente.

· Se pueden distinguir dos rangos distintos de conjuntos de metodologías ágiles. Por un lado están las metodologías más declarativas y programáticas como XP, Scrum, LD, entre otras; y por otro lado se encuentran las metodologías finamente elaboradas como DSDM, Cristal, etc.

·  XP es una de las metodologías ágiles más extendidas y populares, además es considerada como una metodología posmoderna cuyas grandes capacidades se generan a través de procesos emergentes.

·  Scrum implementa en sus prácticas de desarrollo una estrategia de caos controlado, permitiendo maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana.

· A pesar de las continuas criticas que las metodologías ágiles sufren, son usadas por muchas grandes empresas y se han utilizado en grandes sistemas, lo que hace prever que estas metodologías han llegado para quedarse.

Ver Documento Pdf        Ver Documento Ppt