El Proceso Unificado de Rational o RUP (por
sus siglas en inglés de Rational Unified Process) es un proceso de desarrollo
de software desarrollado por la empresa Rational Software, actualmente
propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado (UML),
constituye la metodología estándar más utilizada para el análisis, diseño,
implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente
establecidos, sino un conjunto de metodologías adaptables al contexto y
necesidades de cada organización. También se conoce por este nombre al
software, también desarrollado por Rational, que incluye información
entrelazada de diversos artefactos y descripciones de las diversas actividades.
Está incluido en el Rational Method Composer (RMC), que permite la
personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y
de dominio público, el Proceso Unificado, y una especificación más detallada,
el Rational Unified Process, que se vendiera como producto independiente.
PROCESO DIRIGIDO POR CASOS DE USOS
Los casos de uso no son sólo una herramienta para
especificar los requisitos del sistema, sino que también guían su diseño,
implementación y prueba. Los casos de uso constituyen un elemento integrador y
una guía del trabajo.
Los casos de uso Inician el proceso de desarrollo y
proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos
que son generados en las diferentes actividades del proceso de desarrollo.
Basándose en los casos de uso, se crean los modelos de
análisis y diseño, luego la implementación que los lleva a cabo, y se verifica
que efectivamente el producto implemente adecuadamente cada caso de uso.
PROCESO CENTRADO EN LA ARQUITECTURA
La arquitectura de un sistema es
la organización o estructura de sus partes más relevantes, lo que permite tener
una visión común entre todos los involucrados (desarrolladores y usuarios) y
una perspectiva clara del sistema completo, necesaria para controlar el
desarrollo.
En el caso de RUP, además de
utilizar los casos de uso para guiar el proceso, se presta especial atención al
establecimiento temprano de una buena arquitectura que no se vea fuertemente
impactada ante cambios posteriores durante la construcción y el mantenimiento.
Existe una interacción entre los
casos de uso y la arquitectura, los casos de uso deben encajar en la
arquitectura cuando se llevan a cabo y la arquitectura debe permitir el
desarrollo de todos los casos de uso requeridos, actualmente y en el futuro.
La arquitectura dentro de RUP se
representa en varias vistas. Todas las vistas juntas forman el llamado modelo
4+1 de la arquitectura. Según Kruchten Philippe (1998) “el cual recibe este
nombre porque lo forman las vistas lógica, de implementación, de proceso y de
despliegue, más la de casos de uso que es la que da cohesión a todas”.
Al final de la fase de
elaboración se obtiene una “baseline” (base de referencia) de la arquitectura
donde fueron seleccionados una serie de casos de uso arquitectónicamente
relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos
que son los más importantes para el usuario y aquellos que cubran las funcionalidades
significativas).
El
equilibrio correcto entre los casos de uso y la arquitectura es muy parecido al
equilibrio de la forma y la función en el desarrollo de un producto, lo cual se
consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener
un proceso iterativo e incremental en donde el trabajo se divide en partes más
pequeñas o mini proyectos. Cada mini proyecto se puede ver como una iteración
(un recorrido más o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento en
el producto.
Cada
iteración aborda una parte de la funcionalidad total, pasando por todos los
flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se
analiza cuando se termina. Durante la planificación de los detalles de la
siguiente iteración, el equipo también examina cómo afectarán los riesgos que
aún quedan al trabajo en curso. Toda la retroalimentación de la iteración
pasada permite reajustar los objetivos para las siguientes iteraciones. Se
continúa con esta dinámica hasta que se haya finalizado por completo con la
versión actual del producto.
RUP
divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones (que son una cantidad variable) según el proyecto, y en las que se
hace un mayor o menor hincapié en los distintas actividades.
Las
primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de una
“baseline” (base de referencia) de la arquitectura.
Para
cada iteración se escogen algunos casos de uso, se refina su análisis y diseño,
y se procede a su implementación y pruebas. Se realizan tantas iteraciones
hasta que se termine la implementación de la nueva versión del producto.
En
la fase de transición se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios. Como se puede observar, en cada
fase participan todas las disciplinas, pero, dependiendo de la fase, es el
esfuerzo dedicado a una disciplina.
No hay comentarios:
Publicar un comentario