archivo

Archivo de la etiqueta: ciclo de vida RUP

David (Dave) Lorge Parnas es un profesional canadiense pionero en el campo de la ingeniería del software de la cual ha sido un ferviente defensor a lo largo de su carrera. Ha recibido numerosos premios a lo largo de su carrera y ha sido profesor en universidades de diferentes países del mundo.

El desarrollo de software se realiza para organizaciones que están en continuo movimiento: puede cambiar el mercado, los procesos, los usuarios, los responsables técnicos, etc…, a lo que hay que sumar que se intentan abstraer procesos que se realizan en el mundo real a un programa de ordenador y no es nada fácil ese proceso porque los que definen el sistema no tienen claro, por regla general, lo que quieren realmente (tienen una idea, pero hasta que no la ven reflejada, no terminan por matizarla).

La naturaleza del software es adaptativa, mediante aproximaciones y evoluciones se consiguen alcanzar productos que satisfacen las necesidades del usuario, a través del feedback que se obtiene de los mismos una vez que hacen uso del sistema. Los principios ágiles definen ese marco (que también se tiene en cuenta en metodologías del proceso unificado como RUP), si bien, nuestra propia experiencia personal nos dirigirá de alguna u otra forma y de forma paulatina hacia enfoques iterativos e incrementales en lugar de ciclos de vida clásico o en cascada.

Dave Parnas, sobre este tema realiza la siguiente reflexión (traducción libre): “Por regla general, los sistemas software no funcionan adecuadamente hasta que han sido utilizados y han fallado repetidamente en entornos reales”.

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.