Rational Unified Process (RUP)

Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodologa, caractersticas principales y estructura del proceso. RUP es un producto comercial desarrollado y comercializado por Rational Soft are, una compa!a de "#$.

Historia
%a &igura ' ilustra la historia de RUP. El antecedente m(s importante se ubica en ')*+ con la $etodologa Ericsson (Ericsson Approach) elaborada por ",ar -acobson, una apro.imaci/n de desarrollo basada en componentes, 0ue introdu1o el concepto de 2aso de Uso. Entre los a!os de ')3+ a '))4 -acobson fund/ la compa!a Objectory 5# y lanza el proceso de desarrollo Objectory (abre,iaci/n de Object Factory).

Figura 1: Historia de RUP Posteriormente en '))4 Rational Software Corporation ad0uiere Objectory AB y entre '))4 y '))+ se desarrolla Rational Objectory Process (R6P) a partir de Objectory 7.3 y del Enfo0ue Rational (Rational Approach) adoptando U$% como lengua1e de modelado. 8esde ese entonces y a la cabeza de 9rady #ooch, ",ar -acobson y -ames Rumbaugh, Rational Soft are desarroll/ e incorpor/ di,ersos elementos para e.pandir R6P, destac(ndose especialmente el flu1o de traba1o conocido como modelado del negocio. En 1unio del '))3 se lanza Rational Unified Process.

Caractersticas esenciales
- Dirigido por Casos de Uso %os 2asos de Uso son una t:cnica de captura de re0uisitos 0ue fuerza a pensar en t:rminos de importancia para el usuario y no s/lo en t:rminos de funciones 0ue seria bueno contemplar. Se define un 2aso de Uso como un fragmento de funcionalidad del sistema 0ue proporciona al usuario un ,alor a!adido. %os 2asos de Uso representan los re0uisitos funcionales del sistema. En RUP los 2asos de Uso no son s/lo una herramienta para especificar los re0uisitos del sistema. ;ambi:n guan su dise!o, implementaci/n y prueba. %os 2asos de Uso constituyen un elemento integrador y una gua del traba1o como se muestra en la &igura <.

Figura 2: Los Casos de Uso integran el trabajo %os 2asos de Uso no s/lo inician el proceso de desarrollo sino 0ue proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos 0ue son generados en las diferentes acti,idades del proceso de desarrollo. 2omo se muestra en la &igura 7, bas(ndose en los 2asos de Uso se crean los modelos de an(lisis y dise!o, luego la implementaci/n 0ue los lle,a a cabo, y se ,erifica 0ue efecti,amente el producto implemente adecuadamente cada 2aso de Uso. ;odos los modelos deben estar sincronizados con el modelo de 2asos de Uso.

Figura 3: Tra abilidad a !artir de los Casos de Uso

Proceso centrado en la arquitectura

%a ar0uitectura de un sistema es la organizaci/n o estructura de sus partes m(s rele,antes, lo 0ue permite tener una ,isi/n com=n entre todos los in,olucrados (desarrolladores y usuarios) y una perspecti,a clara del sistema completo, necesaria para controlar el desarrollo. En el caso de RUP adem(s de utilizar los 2asos de Uso para guiar el proceso se presta especial atenci/n al establecimiento temprano de una buena ar0uitectura 0ue no se ,ea fuertemente impactada ante cambios posteriores durante la construcci/n y el mantenimiento. 2ada producto tiene tanto una funci/n como una forma. %a funci/n corresponde a la funcionalidad refle1ada en los 2asos de Uso y la forma la proporciona la ar0uitectura. E.iste una interacci/n entre los 2asos de Uso y la ar0uitectura, los 2asos de Uso deben enca1ar en la ar0uitectura cuando se lle,an a cabo y la ar0uitectura debe permitir el desarrollo de todos los 2asos de Uso re0ueridos,

actualmente y en el futuro. Esto pro,oca 0ue tanto ar0uitectura como 2asos de Uso deban e,olucionar en paralelo durante todo el proceso de desarrollo de soft are. En la &igura > se ilustra la e,oluci/n de la ar0uitectura durante las fases de RUP. Se tiene una ar0uitectura m(s robusta en las fases finales del proyecto. En las fases iniciales lo 0ue se hace es ir consolidando la ar0uitectura por medio de baselines y se ,a modificando dependiendo de las necesidades del proyecto.

Inception

Elaboration

Construction

Transition

Architecture
tiempo

Figura ": #$oluci%n de la ar&uitectura del siste'a Es con,eniente ,er el sistema desde diferentes perspecti,as para comprender me1or el dise!o por lo 0ue la ar0uitectura se representa mediante ,arias ,istas 0ue se centran en aspectos concretos del sistema, abstray:ndose de los dem(s. Para RUP, todas las ,istas 1untas forman el llamado modelo >?' de la ar0uitectura, el cual recibe este nombre por0ue lo forman las ,istas l/gica, de implementaci/n, de proceso y de despliegue, m(s la de 2asos de Uso 0ue es la 0ue da cohesi/n a todas.

Proceso iterativo e incremental

El e0uilibrio correcto entre los 2asos de Uso y la ar0uitectura es algo muy parecido al e0uilibrio de la forma y la funci/n en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia 0ue se propone en RUP es tener un proceso iterati,o e incremental en donde el traba1o se di,ide en partes m(s pe0ue!as o mini proyectos. Permitiendo 0ue el e0uilibrio entre 2asos de Uso y ar0uitectura se ,aya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. 2ada mini proyecto se puede ,er como una iteraci/n (un recorrido m(s o menos completo a lo largo de todos los flu1os de traba1o fundamentales) del cual se obtiene un incremento 0ue produce un crecimiento en el producto. Una iteraci/n puede realizarse por medio de una cascada como se muestra en la &igura 4. Se pasa por los flu1os fundamentales (Re0uisitos, 5n(lisis, 8ise!o, "mplementaci/n y Pruebas), tambi:n e.iste una planificaci/n de la iteraci/n, un an(lisis de la iteraci/n y algunas acti,idades especficas de la iteraci/n. 5l finalizar se realiza una integraci/n de los resultados con lo obtenido de las iteraciones anteriores.

Figura (: Una iteraci%n RUP El proceso iterati,o e incremental consta de una secuencia de iteraciones. 2ada iteraci/n aborda una parte de la funcionalidad total, pasando por todos los flu1os de traba1o rele,antes y refinando la ar0uitectura. 2ada iteraci/n se analiza cuando termina. Se puede determinar si han aparecido nue,os re0uisitos o han cambiado los e.istentes, afectando a las iteraciones siguientes. 8urante la planificaci/n de los detalles de la siguiente iteraci/n, el e0uipo tambi:n e.amina c/mo afectar(n los riesgos 0ue a=n 0uedan al traba1o en curso. ;oda la retroalimentaci/n de la iteraci/n pasada permite rea1ustar los ob1eti,os para las siguientes iteraciones. Se contin=a con esta din(mica hasta 0ue se haya finalizado por completo con la ,ersi/n actual del producto. RUP di,ide el proceso en cuatro fases, dentro de las cuales se realizan ,arias iteraciones en n=mero ,ariable seg=n el proyecto y en las 0ue se hace un mayor o menor hincapi: en los distintas acti,idades %as primeras iteraciones las fases de "nicio y Elaboraci/n se enfocan hacia la comprensi/n del problema y la tecnologa, la delimitaci/n del (mbito del proyecto, la eliminaci/n de los riesgos crticos, y al establecimiento de una baseline de la ar0uitectura. 8urante la fase de inicio las iteraciones hacen ponen mayor :nfasis en acti,idades modelado del negocio y de re0uisitos. En la fase de elaboraci/n, las iteraciones se orientan al desarrollo de la baseline de la ar0uitectura, abarcan m(s los flu1os de traba1o de re0uerimientos, modelo de negocios (refinamiento), an(lisis, dise!o y una parte de implementaci/n orientado a la baseline de la ar0uitectura. En la fase de construcci/n, se lle,a a cabo la construcci/n del producto por medio de una serie de iteraciones. Para cada iteraci/n se selecciona algunos 2asos de Uso, se refina su an(lisis y dise!o y se procede a su implementaci/n y pruebas. Se realiza una pe0ue!a cascada para cada ciclo. Se realizan tantas iteraciones hasta 0ue se termine la implementaci/n de la nue,a ,ersi/n del producto. En la fase de transici/n se pretende garantizar 0ue se tiene un producto preparado para su entrega a la comunidad de usuarios. En cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina ,ara.

Otras prcticas
RUP identifica * best practices con las 0ue define una forma efecti,a de traba1ar para los e0uipos de desarrollo de soft are. 9esti/n de re0uisitos RUP brinda una gua para encontrar, organizar, documentar, y seguir los cambios de los re0uisitos funcionales y restricciones. Utiliza una notaci/n de 2aso de Uso y escenarios para representar los re0uisitos. 8esarrollo de soft are iterati,o 8esarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las acti,idades pero con distinto :nfasis, seg=n la fase del proyecto. 8esarrollo basado en componentes %a creaci/n de sistemas intensi,os en soft are re0uiere di,idir el sistema en componentes con interfaces bien definidas, 0ue posteriormente ser(n ensamblados para generar el sistema. Esta caracterstica en un proceso de desarrollo permite 0ue el sistema se ,aya creando a medida 0ue se obtienen o se desarrollan sus componentes. $odelado ,isual (usando U$%) U$% es un lengua1e para ,isualizar, especificar, construir y documentar el soft are. Utilizar herramientas de modelado ,isual facilita la gesti/n de dichos modelos, permitiendo ocultar o e.poner detalles cuando sea necesario. El modelado ,isual tambi:n ayuda a mantener la consistencia. En resumen, el modelado ,isual ayuda a me1orar la capacidad del e0uipo para gestionar la comple1idad del soft are. @erificaci/n continua de la calidad Es importante 0ue la calidad se e,al=e en ,arios puntos durante el proceso de desarrollo, especialmente al final de cada iteraci/n. En esta ,erificaci/n las pruebas 1uegan un papel fundamental y se integran a lo largo de todo el proceso. 9esti/n de los cambios El cambio es un factor de riesgo crtico en los proyectos de soft are. El soft are cambia no s/lo debido a acciones de mantenimiento posteriores a la entrega del producto, sino 0ue durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los re0uisitos. Por otra parte, otro gran desafo 0ue debe abordarse es la construcci/n de soft are con la participaci/n de m=ltiples desarrolladores, traba1ando a la ,ez en una release, y 0uiz(s en distintas plataformas. %a ausencia de disciplina r(pidamente conducira al caos. %a 9esti/n de 2ambios y de 2onfiguraci/n es la disciplina de RUP encargada de este aspecto.

Estructura del proceso

El proceso puede ser descrito en dos dimensiones o e1es A #je )ori ontal: Representa el tiempo y es considerado el e1e de los aspectos din(micos del proceso. "ndica las caractersticas del ciclo de ,ida del proceso e.presado en t:rminos de fases, iteraciones e hitos. Se puede obser,ar en la &igura * 0ue RUP consta de cuatro fasesA "nicio, Elaboraci/n, 2onstrucci/n y ;ransici/n. 2omo se mencion/ anteriormente cada fase se subdi,ide a la ,ez en iteraciones. #je $ertical: Representa los aspectos est(ticos del proceso. 8escribe el proceso en t:rminos de componentes de proceso, disciplinas, flu1os de traba1o, acti,idades, artefactos y roles.

Figura *: #structura de RUP

Estructura Dinmica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos 0ue constituyen la ,ida de un producto. 2ada ciclo concluye con una generaci/n del producto para los clientes. 2ada ciclo consta de cuatro fasesA "nicio, Elaboraci/n, 2onstrucci/n y ;ransici/n. 2ada fase se subdi,ide a la ,ez en iteraciones, el n=mero de iteraciones en cada fase es ,ariable. 2ada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones crticas y alcanzar las metas cla,e antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores 0ue podran ser los criterios aplicables a cada iteraci/n. %os hitos para cada una de las fases sonA "nicio B Lifecycle Objectives Elaboraci/n B Lifecycle Architect!re 2onstrucci/n B "nitial Operational Capability ;ransici/n B Product Release. %as fases y sus respecti,os hitos se ilustran en la &igura +.

Inception

Elaboration

Construction

Transition

Objetivos (Vision)

Arquitectura

Capacidad Operacional Inicial

Release del Producto

tiempo

Figura +: Fases e )itos en RUP

%a duraci/n y esfuerzo dedicado en cada fase es ,ariable dependiendo de las caractersticas del proyecto. Sin embargo, la &igura 3 ilustra porcenta1es frecuentes al respecto. 2onsecuente con el esfuerzo se!alado, la &igura ) ilustra una distribuci/n tpica de recursos humanos necesarios a lo largo del proyecto.

,nicio #sfuer o Tie'!o /edicado (1. -

#laboraci%n Construcci%n Transici%n 2. 3. *( (. 1.1.-

Figura 0: /istribuci%n t1!icas de esfuer o 2 tie'!o

Figura 3: /istribuci%n t1!ica de recursos )u'anos ,nicio 8urante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y 2asos de Uso, y se dise!an los 2asos de Uso m(s esenciales (apro.imadamente el <CD del modelo completo). Se desarrolla, un plan de negocio para determinar 0ue recursos deben ser asignados al proyecto.

%os ob1eti,os de esta fase sonA Establecer el (mbito del proyecto y sus lmites. Encontrar los 2asos de Uso crticos del sistema, los escenarios b(sicos 0ue definen la funcionalidad. $ostrar al menos una ar0uitectura candidata para los escenarios principales. Estimar el coste en recursos y tiempo de todo el proyecto. Estimar los riesgos, las fuentes de incertidumbre. %os resultados de la fase de inicio deben serA Un documento de ,isi/nA Una ,isi/n general de los re0uerimientos del proyecto, caractersticas cla,e y restricciones principales. $odelo inicial de 2asos de Uso ('CB<CD completado). Un glosario inicialA ;erminologa cla,e del dominio. El caso de negocio. %ista de riesgos y plan de contingencia. Plan del proyecto, mostrando fases e iteraciones. $odelo de negocio, si es necesario Prototipos e.ploratorios para probar conceptos o la ar0uitectura candidata. 5l terminar la fase de inicio se deben comprobar los criterios de e,aluaci/n para continuarA ;odos los interesados en el proyecto coinciden en la definici/n del (mbito del sistema y las estimaciones de agenda. Entendimiento de los re0uisitos, como e,idencia de la fidelidad de los 2asos de Uso principales. %as estimaciones de tiempo, coste y riesgo son crebles. 2omprensi/n total de cual0uier prototipo de la ar0uitectura desarrollado. %os gastos hasta el momento se aseme1an a los planeados. Si el proyecto no pasa estos criterios hay 0ue plantearse abandonarlo o repensarlo profundamente. Elaboraci/n El prop/sito de la fase de elaboraci/n es analizar el dominio del problema, establecer los cimientos de la ar0uitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. En esta fase se construye un prototipo de la ar0uitectura, 0ue debe e,olucionar en iteraciones sucesi,as hasta con,ertirse en el sistema final. Este prototipo debe contener los 2asos de Uso crticos identificados en la fase de inicio. ;ambi:n debe demostrarse 0ue se han e,itado los riesgos m(s gra,es. %os ob1eti,os de esta fase son A 8efinir, ,alidar y cimentar la ar0uitectura. 2ompletar la ,isi/n. 2rear un plan fiable para la fase de construcci/n. Este plan puede e,olucionar en sucesi,as iteraciones. 8ebe incluir los costes si procede. 8emostrar 0ue la ar0uitectura propuesta soportar( la ,isi/n con un coste razonable y en un tiempo razonable. 5l terminar deben obtenerse los siguientes resultados A Un modelo de 2asos de Uso completa al menos hasta el 3CDA todos los casos y actores identificados, la mayora de los casos desarrollados. Re0uisitos adicionales 0ue capturan los re0uisitos no funcionales y cual0uier re0uisito no asociado con un 2aso de Uso especfico.

8escripci/n de la ar0uitectura soft are. Un prototipo e1ecutable de la ar0uitectura. %ista de riesgos y caso de negocio re,isados. Plan de desarrollo para el proyecto. Un caso de desarrollo actualizado 0ue especifica el proceso a seguir. Un manual de usuario preliminar (opcional).

En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mnima. S/lo se profundiza en los puntos crticos de la ar0uitectura o riesgos importantes. En la fase de elaboraci/n se actualizan todos los productos de la fase de inicio. %os criterios de e,aluaci/n de esta fase son los siguientesA %a ,isi/n del producto es estable. %a ar0uitectura es estable. Se ha demostrado mediante la e1ecuci/n del prototipo 0ue los principales elementos de riesgo han sido abordados y resueltos. El plan para la fase de construcci/n es detallado y preciso. %as estimaciones son crebles. ;odos los interesados coinciden en 0ue la ,isi/n actual ser( alcanzada si se siguen los planes actuales en el conte.to de la ar0uitectura actual. %os gastos hasta ahora son aceptables, comparados con los pre,istos. Si no se superan los criterios de e,aluaci/n 0uiz( sea necesario abandonar el proyecto o replante(rselo considerablemente. Construcci%n %a finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a tra,:s de las sucesi,as iteraciones. 8urante esta fase todos los componentes, caractersticas y re0uisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una ,ersi/n aceptable del producto. %os ob1eti,os concretos incluyenA $inimizar los costes de desarrollo mediante la optimizaci/n de recursos y e,itando el tener 0ue rehacer un traba1o o incluso desecharlo. 2onseguir una calidad adecuada tan r(pido como sea pr(ctico. 2onseguir ,ersiones funcionales (alfa, beta, y otras ,ersiones de prueba) tan r(pido como sea pr(ctico. %os resultados de la fase de construcci/n deben serA $odelos 2ompletos (2asos de Uso, 5n(lisis, 8ise!o, 8espliegue e "mplementaci/n) 5r0uitectura ntegra (mantenida y mnimamente actualizada) Riesgos Presentados $itigados Plan del Proyecto para la fase de ;ransici/n. $anual "nicial de Usuario (con suficiente detalle) Prototipo 6peracional E beta 2aso del Fegocio 5ctualizado %os criterios de e,aluaci/n de esta fase son los siguientesA El producto es estable y maduro como para ser entregado a la comunidad de usuario para ser probado. ;odos los usuarios e.pertos est(n listos para la transici/n en la comunidad de usuarios.

Son aceptables los gastos actuales ,ersus los gastos planeados.

Transici%n %a finalidad de la fase de transici/n es poner el producto en manos de los usuarios finales, para lo 0ue se re0uiere desarrollar nue,as ,ersiones actualizadas del producto, completar la documentaci/n, entrenar al usuario en el mane1o del producto, y en general tareas relacionadas con el a1uste, configuraci/n, instalaci/n y facilidad de uso del producto. 5lgunas de las cosas 0ue puede incluir esta faseA Prueba de la ,ersi/n #eta para ,alidar el nue,o sistema frente a las e.pectati,as de los usuarios &uncionamiento paralelo con los sistemas legados 0ue est(n siendo sustituidos por nuestro proyecto. 2on,ersi/n de las bases de datos operacionales. Entrenamiento de los usuarios y t:cnicos de mantenimiento. ;raspaso del producto a los e0uipos de marGeting, distribuci/n y ,enta. %os principales ob1eti,os de esta fase sonA 2onseguir 0ue el usuario se ,alga por si mismo. Un producto final 0ue cumpla los re0uisitos esperados, 0ue funcione y satisfaga suficientemente al usuario. %os resultados de la fase de transici/n son A Prototipo 6peracional 8ocumentos %egales 2aso del Fegocio 2ompleto %nea de #ase del Producto completa y corregida 0ue incluye todos los modelos del sistema 8escripci/n de la 5r0uitectura completa y corregida %as iteraciones de esta fase ir(n dirigidas normalmente a conseguir una nue,a ,ersi/n. %os criterios de e,aluaci/n de esta fase son los siguientesA El usuario se encuentra satisfecho. Son aceptables los gastos actuales ,ersus los gastos planificados.

Estructura Esttica del proceso. Roles actividades arte!actos " !lu#os de tra$a#o
Un proceso de desarrollo de soft are define 0ui:n hace 0u:, c/mo y cu(ndo. RUP define cuatro elementos los roles, 0ue responden a la pregunta HIui:nJ, las acti,idades 0ue responden a la pregunta H2/moJ, los productos, 0ue responden a la pregunta HIu:J y los flu1os de traba1o de las disciplinas 0ue responde a la pregunta H2u(ndoJ (,er &igura 'C y '') .

Figura 1.: Relaci%n entre roles4 acti$idades4 artefactos

Roles Actividades

Arte actos

Figura 11: /etalle de un 5or6flo5 'ediante roles4 acti$idades 2 artefactos Roles Un rol define el comportamiento y responsabilidades de un indi,iduo, o de un grupo de indi,iduos traba1ando 1untos como un e0uipo. Una persona puede desempe!ar di,ersos roles, as como un mismo rol puede ser representado por ,arias personas. %as responsabilidades de un rol son tanto el lle,ar a cabo un con1unto de acti,idades como el ser el due!o de un con1unto de artefactos.

%i$liogra!ia $asica&
httpsAKKpid.dsic.up,.esK2'K$aterialKdefault.asp. httpAKKes. iGipedia.orgK iGiKProcesoLUnificadoLdeLRational httpAKK .redbooGs.ibm.comKredbooGsKpdfsKsg<>+7*<.pdf