archivo

Archivo de la etiqueta: Rational Unified Process

Los problemas del ciclo de vida clásico o en cascada empiezan con los cambios de requisitos en fases posteriores al análisis y estos son inevitables salvo que el sistema que se desarrolle sea pequeño.

Cuando estos cambios ocurren, salvo que el presupuesto sea muy holgado, empieza el desgaste entre proveedor, área técnica del cliente y los usuarios que dará lugar finalmente a un producto y a un proyecto que probablemente no dejará totalmente contento a nadie, ya sea por los costes, los plazos y/o por la calidad final.

El carácter predictivo que tiene este tipo de desarrollos, provoca, sobre todo si ya tienes una cierta experiencia, respeto a los usuarios a la hora de definir los requisitos y a los desarrolladores de ejecutarlos con éxito.

El ciclo de vida del proceso unificado (como por ejemplo RUP) o los ciclos de vida de las metodologías ágiles son adaptativos, están orientados probar soluciones, si no gusta se intenta otra, si solo requiere cambios parciales, estos se llevan a cabo. Hay que perder el miedo a especificar requisitos y a ejecutar soluciones, de esta forma es como se consigue que las funcionalidades, que los módulos se ajusten cada vez más a las expectativas del usuario.

Esto tiene su coste, la diferencia es repercutir parte del coste de mantenimiento en el propio proceso de desarrollo, al final, este mayor presupuesto en el desarrollo saldrá barato, ya que no es lo mismo evolucionar sistemas complejos ya en producción, que ir madurando poco a poco los mismos.

El hecho de RUP siga un ciclo de vida que se puede considerar iterativo e incremental no implica que se le pueda considerar una metodología ágil y eso que sobre el papel podría considerarse que verifica los principios del manifiesto ágil.

Por ese motivo quien considere que RUP es ágil tienen una buena coartada. Se esté o no de acuerdo con que se considere una metodología ágil, lo que no deja dudas es que se trata de una metodología de carácter adaptativo, fruto de su vocación iterativa, incremental y unificada.

¿Por qué no lo considero una metodología ágil? Principalmente porque el marco de trabajo que define, implica liberaciones muy tardías en entornos de producción. Es cierto que en la etapa de construcción en cada iteración se pueden liberar versiones en entornos de desarrollo (o incluso preproducción) y que en las etapas finales de la construcción se pueden incluso hacer implantaciones en producción (si bien esta es la responsabilidad principal de la siguiente, la de transición).

Es decir, los usuarios seleccionados para participar en el proyecto de desarrollo de software, pueden proporcionar feedback en todas las etapas, siendo el más importante el que pueden proporcionar cuando están probando/trabajando con el sistema. Sin embargo, este feedback cuando resulta realmente valioso es cuando se está haciendo un uso real del sistema en un entorno de producción.

Esta característica, junto al hecho de que RUP plantea un marco de trabajo donde el proceso cobra una importancia especial, hace que la respuesta al cambio no sea ágil, ya que principalmente en la etapa de transición es donde se itera sobre el producto para ir adaptando el sistema a las necesidades y expectativas del usuario en aquellos aspectos en los que no se ha acertado en fases anteriores o como consecuencia de cambios en el negocio que se hayan producido durante el proceso de desarrollo.

Estas iteraciones se hacen sobre la versión del producto en la que se ha trabajado durante el ciclo de vida RUP, por lo que el esfuerzo necesario para hacer las modificaciones es mayor y en consecuencia el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de producción.

También se puede plantear el desarrollo como una secuencia de RUP, de manera que el proceso de desarrollo sea más liviano, de esta forma sí que se acercaría más a las metodologías ágiles, sin embargo, soy de la opinión de que RUP en origen tenía un enfoque más tipo big bang, orientándose a la entrega de una versión finalista del producto.

RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de software y después en función de la naturaleza del mismo haces las adaptaciones oportunas (sin salirte de las fronteras que te marca la metodología porque de lo contrario estaríamos hablando de algo que no sería RUP).

RUP sigue principios de ingeniería del software para la obtención de sistemas de información de calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se obtengan caigan en los aspectos que caracterizan a la crisis del software (todavía muy presente en nuestros días).

RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto peculiar, como vamos a ver a continuación.

El ciclo de vida RUP se divide en 4 fases: Iniciación, Elaboración, Construcción y Transición.

En cada fase se realizan una o más iteraciones (con el objeto de ir perfeccionando los objetivos, mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente. Por regla general, la fase en la que se realizan más iteraciones es la Contrucción.

En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo o objetivos de la fase, por ejemplo, en la fase de construcción se pueden modificar, añadir o eliminar requisitos, casos de uso, etc… lo que tiene un impacto en lo obtenido en fases anteriores, acercándonos cada vez más a un sistema que satisfaga las necesidades de los usuarios.

En cada fase y en cada iteración se realiza un ciclo de vida en cascada con las siguientes etapas: Análisis, Diseño, Construcción (las tareas de programación que se realizan, sobre todo las fases de Construcción y Transición son perfectamente compatibles con la utilización de técnicas de integración continua y análisis estático de código), Pruebas/Integración/Implantación. El alcance del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un ciclo de vida en cascada en la fase de Iniciación, lo más probable es que no se llegue a construir nada o se llegue a algún a hacer algún prototipo de muy alto nivel.

Los objetivos que se persiguen en cada fase son los siguientes:

– Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.

– Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.

– Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.

– Transición: Refinamiento de los objetivos de las fases anteriores e implantación del sistema de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).

Por tanto, como se comentó anteriormente, en cada etapa y en cada iteración se perfeccionan los productos previos que hayan requerido algún cambio, todo eso mientras se intentan conseguir los objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de desarrollo de software.

De esta forma, el reparto de esfuerzos entre actividades varían de una fase a otra.

Fuente del gráfico: Wikipedia.

Una característica importante del RUP es que todo el proceso está guiado por los casos de uso, algo que resulta lógico cuando hablamos de modelos incrementales, ya que están orientados al usuario y como tal es importante tener siempre presente el esquema de interacción usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.

RUP pretende la obtención de productos de muy alta calidad (extendiéndose esta no solo al cumplimiento de las expectativas del usuario, sino a la obtención de productos con una deuda técnica aceptable), si bien sus características: varias fases, múltiples iteraciones por fases, pueden provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequeña escala, aunque el hecho de que siga un esquema incremental permitiría dar flexibilidad en el caso de que fuera necesario.

Personalmente prefiero la aplicación de ciclos de vida iterativos incrementales de una forma más directa, sin aplicar múltiples iteraciones para liberar una nueva versión del producto, si bien el ciclo de vida RUP es muy potente y sigue la misma estrategia, es decir, aproximarse al proceso real de desarrollo de software en el cual el producto va creciendo conforme los usuarios van comprendiendo cómo queda el sistema.

Pero, ¿se puede considerar ágil RUP?, en este otro artículo, indico los motivos por los que no considero ágil a esta metodología.