EL PROCESO RACIONAL UNIFICADO (RUP)

The Rational Unified Process - RUP para abreviar - fue desarrollado por Philippe Kruchten, Ivar Jacobsen y otros en Rational Corporation para complementar UML (Lenguaje de Modelado Unificado), un mtodo de modelado estndar de la industria del software. RUP es un enfoque iterativo para sistemas orientados a objetos, y abarca fuertemente casos de uso para el modelado de los requisitos y la construccin de las bases para un sistema. RUP se inclina hacia el desarrollo orientado a objetos. No excluye implcitamente a otros mtodos, aunque el mtodo de modelado propuesto, UML, es particularmente adecuado para el desarrollo OO (Jacobsen et al. 1994). Proceso La vida til de un proyecto RUP se divide en cuatro fases llamadas Iniciacin, Elaboracin, Construccin y Transicin (vase la Figura 10). Estas fases se dividen en iteraciones, cada una con el propsito de producir una pieza demostrable de software. La duracin de una iteracin puede variar a partir de dos semanas o menos hasta seis meses.

En el siguiente, se introducen las fases RUP, como se describe en (Krutchen 2000):

En la fase inicial, se consideran los objetivos del ciclo de vida de todas las partes interesadas (por ejemplo, usuario final, el comprador, o el contratista). Esto implica, por ejemplo, el establecimiento de las condiciones de alcance, los lmites y criterios de aceptacin del proyecto. Se identifican casos de uso crtico es decir, aquellos que impulsar la funcionalidad del sistema. Se conciben arquitecturas candidatas para el sistema, as tambin se calcula el calendario y el costo para todo el proyecto. Adems, se realizan estimaciones para la siguiente fase de elaboracin. La fase de elaboracin, es donde se acentuaron las bases de la arquitectura de software. Se analiza el dominio del problema, teniendo en cuenta todo el sistema que est siendo

construido. El plan del proyecto se define en esta fase - fase si se tom la decisin de proceder a las prximas etapas en absoluto. Con el fin de ser capaz de tomar esa decisin,

RUP asume que la fase de elaboracin producir una arquitectura suficientemente slida junto con los requisitos y planes suficientemente estables. El proceso, la infraestructura y el entorno de desarrollo se describen en detalle. Como RUP destaca la automatizacin de herramientas, tambin se establece el apoyo a la misma en la fase de elaboracin. Despus de la fase la mayora de casos de uso y todos los actores han sido identificados, la arquitectura del software se describe, y un prototipo ejecutable de la arquitectura es creada. Al final de la fase de elaboracin, se realiza un anlisis para determinar la realizacin de los riesgos, la estabilidad de la visin de lo que el producto es convertido, la
estabilidad de la visin de que el producto va a ser, la estabilidad de la arquitectura y el gasto de recursos frente a lo que se plane inicialmente.

En la fase de construccin, se desarrollan todos los dems componentes y caractersticas de la aplicacin y se integran en el producto y es probado. RUP considera la fase de construccin como un proceso de fabricacin, donde se pone nfasis en la gestin de los recursos y el control de costos, horarios y calidad. Los resultados de la fase de construccin (alfa, beta, y otras versiones de prueba) se crean tan rpidamente como sea posible, sin dejar de lograr una calidad adecuada. Se realizan una o ms versiones durante la fase de construccin, antes de proceder a la fase final de la transicin. La fase de transicin, cuando el producto es lo suficientemente maduro (determinado, por ejemplo, mediante el control de la velocidad del sistema de solicitudes de cambio) pasa a ser entregado a la comunidad de usuarios. Con base en la respuesta del usuario, se revisan las versiones posteriores para corregir los problemas pendientes, o para terminar las funciones aplazadas. La fase de transicin consiste en pruebas beta, pilotaje, la formacin de los usuarios y mantenimiento del sistema, y rodando el producto a la comercializacin, la distribucin y los equipos de venta. Varias iteraciones se hacen a menudo, con las versiones beta y libera la disponibilidad general. Documentacin del usuario (manuales, material del curso) tambin se produce. A lo largo de las fases, nueve flujos de trabajo (Kruchten 2000), se llevan a cabo en paralelo. Cada iteracin, ms o menos extensamente, se dirige a todos los nueve flujos de trabajo. Los flujos de trabajo son los Modelos de Negocios, Requisitos, Anlisis y diseo, implementacin, prueba, Configuracin y Gestin del Cambio, Gestin de Proyectos, y Medio Ambiente. La mayora de ellos son evidentes. Dos de ellos, sin embargo, se ven con menos frecuencia en otros procesos de software, por lo que se describen con ms detalle en el siguiente. Modelos de negocios se utiliza para asegurar que las necesidades de negocio del cliente

sean atendidos. Mediante el anlisis de la organizacin del cliente y los procesos de negocio, se gana una mejor comprensin de las estructuras y la dinmica de los negocios. El modelo de negocio se construye como un modelo de caso de uso empresarial, formado por los casos de uso y actores empresariales. La importancia del modelado de negocio depende enteramente de la finalidad para la que se construye el software, y la fase puede omitirse por completo si no se considera necesario. El modelo de negocios se realiza con mayor frecuencia durante el inicio y las fases de elaboracin. El flujo de trabajo de Medio Ambiente se ha diseado exclusivamente para apoyar el trabajo de desarrollo. Las actividades de este flujo de trabajo incluyen la implementacin y configuracin de RUP, la seleccin y adquisicin de herramientas necesarias, el desarrollo de herramientas internas, el suministro de software y mantenimiento de hardware y capacitacin. Prcticamente todo el trabajo en el entorno de flujo de trabajo se realiza durante la fase inicial. ROLES Y RESPONSABILIDADES La forma de asignar roles en RUP es impulsando una actividad, de modo que hay un papel para cada actividad. RUP define treinta papeles, llamados (workers) trabajadores. El casting es bastante convencional (por ejemplo, arquitecto, diseador, colaborador de diseo, Administrador de configuracin), con la excepcin de las funciones definidas en el modelado de negocio y flujos de trabajo de Medio Ambiente. En continua colaboracin con los miembros de la organizacin empresarial, un Analista de Proceso de Negocios lidera y coordina la definicin de los casos de uso comercial, que describen los procesos y actores importantes (por ejemplo, clientes) de la organizacin. As forma una abstraccin de alto nivel del negocio que se est modelando, en la forma de un modelo del caso del uso comercial, y tambin define el modelo del objeto comercial, que describe cmo los procesos y los actores se relacionan, y crea un glosario que pone en una lista los trminos importantes usados en el negocio. El modelo de casos de uso de negocio se divide en partes, cada una de las cuales se elaboran en un caso de uso profesional de una visita del diseador de negocios. Al hacerlo, se identifica y documenta los roles y las entidades dentro de la organizacin. Un crtico de modelos de negocios revisa todos los artefactos producidos por el Analista de Proceso de Negocios y el Diseador de negocios.

El flujo de trabajo de Medio Ambiente tiene dos roles interesantes: Course Developer un desarrollador de curso que produce material de curso (diapositivas, tutoriales, ejemplos, etc.) para los usuarios finales del sistema que se encuentra en desarrollo. Un Toolsmith (persona que crea programas de utilidad) desarrolla herramientas internas para apoyar el desarrollo, para mejorar la automatizacin de tareas tediosas, la repeticin y mejorar la
integracin entre las herramientas.

El nmero de personas necesarias en un proyecto RUP vara considerablemente, dependiendo del alcance en el que se implementan los flujos de trabajo. Por ejemplo, el flujo de trabajo de modelado de negocio (junto con las funciones correspondientes) puede ser omitido por completo, si el modelo de negocio no tiene ninguna importancia en el producto final. 3.5.3. Prcticas

Los pilares de RUP se pueden incluir en seis prcticas que se encuentran debajo de la estructura de fase del flujo de trabajo y los roles de RUP. Las prcticas se enumeran en la Tabla 3.

Tabla 3. Prcticas de RUP (Kruchten 2000).

Prcticas RUP Desarrollo de software iterativo Gestion de requisitos Descripcin El software se desarrolla en pequeos incrementos e iteraciones cortas, lo que permite la identificacin de los riesgos y problemas desde el principio, y reaccionar a ellos adecuadamente. Identificar los requisitos de un sistema de software que cambian con el tiempo, y los requisitos que tienen el mayor impacto en los objetivos del proyecto es un proceso continuo. Se requiere un enfoque disciplinado para la gestin de requisitos, donde se pueden priorizar los requisitos, filtrarlos y rastrearlos. Las inconsistencias pueden entonces ser ms fcilmente identificables. La comunicacin tiene ms posibilidades de xito cuando se basan en requisitos claramente definidos.

Uso de componentes basados La arquitectura de software se puede hacer ms flexible mediante el uso en arquitectura de componentes - aquellas partes del sistema que tienen ms probabilidades de cambiar se pueden aislar y manejadas ms fcilmente. Adems, la construccin de componentes reutilizables potencialmente puede ahorrar una cantidad sustancial de esfuerzo de desarrollo futuro. Modelo visual de Software Los modelos se construyen, ya que los sistemas complejos son imposibles de comprender en su totalidad. Mediante el uso de un mtodo de visualizacin comn (como UML) entre el equipo de desarrollo, la arquitectura y el diseo del sistema se pueden capturar sin ambigedades, y se comunicarn a todas las partes interesadas. Verificacin de la calidad del Al poner a prueba durante cada iteracin, los defectos pueden ser software identificados antes en el ciclo de desarrollo, lo que reduce considerablemente el costo de la fijacin de ellos. Control de cambios del Cualquier cambio en los requisitos deben ser administrados, y su efecto software sobre el software deben ser trazables. La madurez del software tambin se puede medir con eficacia por la frecuencia y los tipos de los cambios realizados.

3.5.4 . Adopcin y experiencias

(Kruchten 2000) afirma que RUP menudo puede adoptarse, en su totalidad o en parte, "fuera de la caja". En muchos casos, sin embargo, una configuracin a fondo, es decir, la modificacin de RUP, se sugiere antes de su aplicacin. La configuracin produce un caso de desarrollo, que enumera todas las desviaciones que tienen que ser hecho con respecto a una RUP completa. El proceso de adopcin es un programa de seis pasos, que se repite iterativamente, hasta que el nuevo proceso se ha implementado por completo - que es, en esencia, un ciclo planificar-hacer-verificar-actuar. Cada incremento trae nuevas prcticas para implementar, y se ajusta a las prcticas agregadas anteriormente. Con base en la retroalimentacin del ciclo anterior, el caso de desarrollo se actualiza si es necesario. Pilotar el proceso por primera vez en un proyecto es adecuado. Sin embargo, a pesar de la necesidad de una amplia adaptacin, RUP se ha aplicado en muchas organizaciones. El xito de RUP tambin puede ser, en cierta medida, debido al hecho de que el Software Racional vende herramientas populares para apoyar las fases

RUP, por ejemplo, Rational Rose, una herramienta de modelado UML, y ClearCase, una herramienta de gestin de configuracin de software.

3.5.5 . Alcance del uso

RUP generalmente no se considera particularmente "gil". El mtodo fue desarrollado originalmente para atender a todo el proceso de produccin de software, y por lo tanto contiene amplias directrices para las fases de proceso que estn al lado de irrelevante en un ambiente que es probable que exija un enfoque gil. Estudios recientes (Martin 1998, Smith 2001) Sin embargo, hemos examinado el potencial de RUP por el mtodo de una manera gil. Parece que la fase de adopcin es la clave para ajustar RUP hacia agilidad. El RUP completo enumera ms de cien artefactos que se producen en las distintas fases del proceso, que requiere de investigacin riguroso, por el que se adoptan slo los esenciales. Sin embargo, uno de los principales inconvenientes de RUP es que no proporciona ninguna directriz clara de aplicacin en la lnea, por ejemplo, Crystal, la cual enumera la documentacin y los papeles necesarios con respecto a la criticidad del software y el tamao del proyecto. RUP sale de la adaptacin al usuario por completo, lo que plantea la cuestin de cmo gran parte de la RUP se puede dejar fuera, con el proceso resultante an puede ser "RUP"?

3.5.6. La investigacin actual

dX de Robert Martin, es una versin mnima de RUP, en el que se tienen en cuenta los puntos de vista giles de desarrollo de software, despojando a las actividades RUP hasta sus ms esencial (Martin 1998). Con el fin de sealar la maleabilidad de RUP, dX imita deliberadamente los principios de XP, pero las actividades de RUP como medida (aparte de que significa "un pequeo cambio", "DX" es "XP" al revs).

Los modelos agiles (Ambler 2002a) es un nuevo enfoque (ver detalles en 3.9.1), que en RUP se puede utilizar para el modelado de negocios, que definen los requisitos y fases de anlisis y diseo.