Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Rational Unified Process (RUP)

Este documento presenta un resumen de Rational Unified Process ( UP!. Se descri"e la #istoria de la metodolo$%a& caracter%sticas principales y estructura del proceso. UP es un producto comercial desarrollado y comerciali'ado por ational Soft(are& una compa)%a de I*+.

1 Historia
,a -i$ura . ilustra la #istoria de UP. El antecedente ms importante se u"ica en ./01 con la +etodolo$%a Ericsson (Ericsson Approach! ela"orada por Ivar 2aco"son& una apro3imacin de desarrollo "asada en componentes& 4ue introdu5o el concepto de Caso de Uso. Entre los a)os de ./61 a .//7 2aco"son fund la compa)%a Objectory 8* y lan'a el proceso de desarrollo Objectory (a"reviacin de Object Factory!.

Figura 1: Historia de RUP Posteriormente en .//7 Rational Software Corporation ad4uiere Objectory AB y entre .//7 y .//1 se desarrolla Rational Objectory Process ( 9P! a partir de Objectory :.6 y del Enfo4ue ational ( Rational Approach! adoptando U+, como len$ua5e de modelado. Desde ese entonces y a la ca"e'a de ;rady *ooc#& Ivar 2aco"son y 2ames um"au$#& ational Soft(are desarroll e incorpor diversos elementos para e3pandir 9P& destacndose especialmente el flu5o de tra"a5o conocido como modelado del ne$ocio. En 5unio del .//6 se lan'a Rational Unified Process.

Caractersticas esenciales
,os autores de UP destacan 4ue el proceso de soft(are propuesto por UP tiene tres caracter%sticas esenciales< est diri$ido por los Casos de Uso& est centrado en la ar4uitectura& y es iterativo e incremental.

1.1 Proceso dirigido por Casos de Uso

Se$=n >?ru@@A& los Casos de Uso son una tcnica de captura de re4uisitos 4ue fuer'a a pensar en trminos de importancia para el usuario y no slo en trminos de funciones 4ue seria "ueno contemplar. Se define un Caso de Uso como un fra$mento de funcionalidad del sistema 4ue proporciona al usuario un valor a)adido. ,os Casos de Uso representan los re4uisitos funcionales del sistema. En UP los Casos de Uso no son slo una #erramienta para especificar los re4uisitos del sistema. Bam"in $u%an su dise)o& implementacin y prue"a. ,os Casos de Uso constituyen un elemento inte$rador y una $u%a del tra"a5o como se muestra en la -i$ura C.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Figura 2: Los Casos de Uso integran el traba o ,os Casos de Uso no slo inician el proceso de desarrollo sino 4ue proporcionan un #ilo conductor& permitiendo esta"lecer tra'a"ilidad entre los artefactos 4ue son $enerados en las diferentes actividades del proceso de desarrollo. Como se muestra en la -i$ura :& "asndose en los Casos de Uso se crean los modelos de anlisis y dise)o& lue$o la implementacin 4ue los lleva a ca"o& y se verifica 4ue efectivamente el producto implemente adecuadamente cada Caso de Uso. Bodos los modelos de"en estar sincroni'ados con el modelo de Casos de Uso.

Figura !: "ra#abilidad a partir de los Casos de Uso

1.2 Proceso centrado en la ar$uitectura

,a ar4uitectura de un sistema es la or$ani'acin o estructura de sus partes ms relevantes& lo 4ue permite tener una visin com=n entre todos los involucrados (desarrolladores y usuarios! y una perspectiva clara del sistema completo& necesaria para controlar el desarrollo >?ru@@A. ,a ar4uitectura involucra los aspectos estticos y dinmicos ms si$nificativos del sistema& est relacionada con la toma de decisiones 4ue indican cmo tiene 4ue ser construido el sistema y ayuda a determinar en 4u orden. 8dems la definicin de la ar4uitectura de"e tomar en consideracin elementos de calidad del sistema& rendimiento& reutili'acin y capacidad de evolucin por lo 4ue de"e ser fle3i"le durante todo el proceso de desarrollo. ,a ar4uitectura se ve influenciada por la plataforma soft(are& sistema operativo& $estor de "ases de datos& protocolos& consideraciones de desarrollo como sistemas #eredados. +uc#as de estas restricciones constituyen re4uisitos no funcionales del sistema.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC C

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

En el caso de UP adems de utili'ar los Casos de Uso para $uiar el proceso se presta especial atencin al esta"lecimiento temprano de una "uena ar4uitectura 4ue no se vea fuertemente impactada ante cam"ios posteriores durante la construccin y el mantenimiento. Cada producto tiene tanto una funcin como una forma. ,a funcin corresponde a la funcionalidad refle5ada en los Casos de Uso y la forma la proporciona la ar4uitectura. E3iste una interaccin entre los Casos de Uso y la ar4uitectura& los Casos de Uso de"en enca5ar en la ar4uitectura cuando se llevan a ca"o y la ar4uitectura de"e permitir el desarrollo de todos los Casos de Uso re4ueridos& actualmente y en el futuro. Esto provoca 4ue tanto ar4uitectura como Casos de Uso de"an evolucionar en paralelo durante todo el proceso de desarrollo de soft(are. En la -i$ura E se ilustra la evolucin de la ar4uitectura durante las fases de UP. Se tiene una ar4uitectura ms ro"usta en las fases finales del proyecto. En las fases iniciales lo 4ue se #ace es ir consolidando la ar4uitectura por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.

Inception

Ela"oration

Construction

Bransition

8rc#itecture
tiempo

Figura %: &'oluci(n de la ar$uitectura del siste)a Es conveniente ver el sistema desde diferentes perspectivas para comprender me5or el dise)o por lo 4ue la ar4uitectura se representa mediante varias vistas 4ue se centran en aspectos concretos del sistema& a"strayndose de los dems. Para UP& todas las vistas 5untas forman el llamado modelo EF. de la ar4uitectura >?ru/7A& el cual reci"e este nom"re por4ue lo forman las vistas l$ica& de implementacin& de proceso y de desplie$ue& ms la de Casos de Uso 4ue es la 4ue da co#esin a todas.

Figura *: Los )odelos se co)pletan+ la ar$uitectura no ca)bia dr,stica)ente

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC :

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC E

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

8l final de la fase de ela"oracin se o"tiene una baseline1 de la ar4uitectura donde fueron seleccionados una serie de Casos de Uso ar4uitectnicamente relevantes (a4uellos 4ue ayudan a miti$ar los ries$os ms importantes& a4uellos 4ue son los ms importantes para el usuario y a4uellos 4ue cu"ran las funcionalidades si$nificativas! Como se o"serva en la -i$ura 7& durante la construccin los diversos modelos van desarrollndose #asta completarse (se$=n se muestra con las formas rellenas en la es4uina superior derec#a!. ,a descripcin de la ar4uitectura sin em"ar$o& no de"er%a cam"iar si$nificativamente (a"a5o a la derec#a! de"ido a 4ue la mayor parte de la ar4uitectura se decidi durante la ela"oracin. Se incorporan pocos cam"ios a la ar4uitectura (indicados con mayor densidad de puntos en la fi$ura inferior derec#a! >2* @@A.

1.! Proceso iterati'o e incre)ental

Se$=n >2* @@A el e4uili"rio correcto entre los Casos de Uso y la ar4uitectura es al$o muy parecido al e4uili"rio de la forma y la funcin en el desarrollo del producto& lo cual se consi$ue con el tiempo. Para esto& la estrate$ia 4ue se propone en UP es tener un proceso iterativo e incremental en donde el tra"a5o se divide en partes ms pe4ue)as o mini proyectos. Permitiendo 4ue el e4uili"rio entre Casos de Uso y ar4uitectura se vaya lo$rando durante cada mini proyecto& as% durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo lar$o de todos los flu5os de tra"a5o fundamentales! del cual se o"tiene un incremento 4ue produce un crecimiento en el producto. Una iteracin puede reali'arse por medio de una cascada como se muestra en la -i$ura 0. Se pasa por los flu5os fundamentales ( e4uisitos& 8nlisis& Dise)o& Implementacin y Prue"as!& tam"in e3iste una planificacin de la iteracin& un anlisis de la iteracin y al$unas actividades espec%ficas de la iteracin. 8l finali'ar se reali'a una inte$racin de los resultados con lo o"tenido de las iteraciones anteriores.

Figura -: Una iteraci(n RUP El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracin a"orda una parte de la funcionalidad total& pasando por todos los flu5os de tra"a5o relevantes y refinando la ar4uitectura. Cada iteracin se anali'a cuando termina. Se puede determinar si #an aparecido nuevos re4uisitos o #an cam"iado los e3istentes& afectando a las iteraciones si$uientes. Durante la planificacin de los detalles de la si$uiente iteracin& el e4uipo tam"in e3amina cmo afectarn los ries$os 4ue a=n 4uedan al tra"a5o en curso. Boda la retroalimentacin de la iteracin pasada permite rea5ustar los o"5etivos para las si$uientes iteraciones. Se contin=a con esta dinmica #asta 4ue se #aya finali'ado por completo con la versin actual . Una "aseline es una instantnea del estado de todos los artefactos del proyecto& re$istrada para efectos de $estin de confi$uracin y control de cam"ios.
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC 7

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

del producto. UP divide el proceso en cuatro fases& dentro de las cuales se reali'an varias iteraciones en n=mero varia"le se$=n el proyecto y en las 4ue se #ace un mayor o menor #incapi en los distintas actividades. En la -i$ura 1 se muestra cmo var%a el esfuer'o asociado a las disciplinas se$=n la fase en la 4ue se encuentre el proyecto UP.

Figura .: &sfuer#o en acti'idades seg/n fase del pro0ecto ,as primeras iteraciones (en las fases de Inicio y Ela"oracin! se enfocan #acia la comprensin del pro"lema y la tecnolo$%a& la delimitacin del m"ito del proyecto& la eliminacin de los ries$os cr%ticos& y al esta"lecimiento de una baseline de la ar4uitectura. Durante la fase de inicio las iteraciones #acen ponen mayor nfasis en actividades modelado del ne$ocio y de re4uisitos. En la fase de ela"oracin& las iteraciones se orientan al desarrollo de la baseline de la ar4uitectura& a"arcan ms los flu5os de tra"a5o de re4uerimientos& modelo de ne$ocios (refinamiento!& anlisis& dise)o y una parte de implementacin orientado a la baseline de la ar4uitectura. En la fase de construccin& se lleva a ca"o la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se selecciona al$unos Casos de Uso& se refina su anlisis y dise)o y se procede a su implementacin y prue"as. Se reali'a una pe4ue)a cascada para cada ciclo. Se reali'an tantas iteraciones #asta 4ue se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende $aranti'ar 4ue se tiene un producto preparado para su entre$a a la comunidad de usuarios. Como se puede o"servar en cada fase participan todas las disciplinas& pero 4ue dependiendo de la fase el esfuer'o dedicado a una disciplina var%a.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC 0

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

1tras pr,cticas
UP identifica 0 best practices con las 4ue define una forma efectiva de tra"a5ar para los e4uipos de desarrollo de soft(are.

2esti(n de re$uisitos
UP "rinda una $u%a para encontrar& or$ani'ar& documentar& y se$uir los cam"ios de los re4uisitos funcionales y restricciones. Utili'a una notacin de Caso de Uso y escenarios para representar los re4uisitos.

3esarrollo de soft4are iterati'o

Desarrollo del producto mediante iteraciones con #itos "ien definidos& en las cuales se repiten las actividades pero con distinto nfasis& se$=n la fase del proyecto.

3esarrollo basado en co)ponentes

,a creacin de sistemas intensivos en soft(are re4uiere dividir el sistema en componentes con interfaces "ien definidas& 4ue posteriormente sern ensam"lados para $enerar el sistema. Esta caracter%stica en un proceso de desarrollo permite 4ue el sistema se vaya creando a medida 4ue se o"tienen o se desarrollan sus componentes.

5odelado 'isual (usando U5L)

U+, es un len$ua5e para visuali'ar& especificar& construir y documentar los artefactos de un sistema soft(are. Es un estndar de la 9+; (#ttp<GG(((.om$.or$!. Utili'ar #erramientas de modelado visual facilita la $estin de dic#os modelos& permitiendo ocultar o e3poner detalles cuando sea necesario. El modelado visual tam"in ayuda a mantener la consistencia entre los artefactos del sistema< re4uisitos& dise)os e implementaciones. En resumen& el modelado visual ayuda a me5orar la capacidad del e4uipo para $estionar la comple5idad del soft(are.

6erificaci(n continua de la calidad

Es importante 4ue la calidad de todos los artefactos se eval=e en varios puntos durante el proceso de desarrollo& especialmente al final de cada iteracin. En esta verificacin las prue"as 5ue$an un papel fundamental y se inte$ran a lo lar$o de todo el proceso. Para todos los artefactos no e5ecuta"les las revisiones e inspecciones tam"in de"en ser continuas.

2esti(n de los ca)bios

El cam"io es un factor de ries$o cr%tico en los proyectos de soft(are. ,os artefactos soft(are cam"ian no slo de"ido a acciones de mantenimiento posteriores a la entre$a del producto& sino 4ue durante el proceso de desarrollo& especialmente importantes por su posi"le impacto son los cam"ios en los re4uisitos. Por otra parte& otro $ran desaf%o 4ue de"e a"ordarse es la construccin de soft(are con la participacin de m=ltiples desarrolladores& posi"lemente distri"uidos $eo$rficamente& tra"a5ando a la ve' en una release& y 4ui's en distintas plataformas. ,a ausencia de disciplina rpidamente conducir%a al caos. ,a ;estin de Cam"ios y de Confi$uracin es la disciplina de UP encar$ada de este aspecto.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC 1

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

&structura del proceso

El proceso puede ser descrito en dos dimensiones o e5es > SC/6A< & e 7ori#ontal: epresenta el tiempo y es considerado el e5e de los aspectos dinmicos del proceso. Indica las caracter%sticas del ciclo de vida del proceso e3presado en trminos de fases& iteraciones e #itos. Se puede o"servar en la -i$ura 6 4ue UP consta de cuatro fases< Inicio& Ela"oracin& Construccin y Bransicin. Como se mencion anteriormente cada fase se su"divide a la ve' en iteraciones. & e 'ertical: epresenta los aspectos estticos del proceso. Descri"e el proceso en trminos de componentes de proceso& disciplinas& flu5os de tra"a5o& actividades& artefactos y roles.

Figura 8: &structura de RUP

1.% &structura 3in,)ica del proceso. Fases e iteraciones

UP se repite a lo lar$o de una serie de ciclos 4ue constituyen la vida de un producto. Cada ciclo concluye con una $eneracin del producto para los clientes. Cada ciclo consta de cuatro fases< Inicio& Ela"oracin& Construccin y Bransicin. Cada fase se su"divide a la ve' en iteraciones& el n=mero de iteraciones en cada fase es varia"le.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC 6

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

ciclo de desarrollo

ciclo de evolucin

release
(producto al final de una iteracin)

base line
(release asociada a un hito)

generacin
(release final de un ciclo de desarrollo)

Figura 9: Ciclos+ releases+ baseline Cada fase se concluye con un #ito "ien definido& un punto en el tiempo en el cual se de"en tomar ciertas decisiones cr%ticas y alcan'ar las metas clave antes de pasar a la si$uiente fase& ese #ito principal de cada fase se compone de #itos menores 4ue podr%an ser los criterios aplica"les a cada iteracin. ,os #itos para cada una de las fases son< Inicio H Lifecycle Objecti es! Ela"oracin H Lifecycle Architect"re! Construccin H #nitial Operational Capability! Bransicin H Product elease. ,as fases y sus respectivos #itos se ilustran en la -i$ura .@.

Inception

Ela"oration

Construction

Bransition

9"5etivos (Vision!

8r4uitectura

Capacidad 9peracional Inicial

elease del Producto

tiempo
Figura 1:: Fases e 7itos en RUP

,a duracin y esfuer'o dedicado en cada fase es varia"le dependiendo de las caracter%sticas del proyecto. Sin em"ar$o& la -i$ura .. ilustra porcenta5es frecuentes al respecto. Consecuente con el esfuer'o se)alado& la -i$ura .C ilustra una distri"ucin t%pica de recursos #umanos necesarios a lo lar$o del proyecto.

;nicio &sfuer#o "ie)po 3edicado *< 1: <

&laboraci(n 2: < !: <

Construcci(n -* < *: <

"ransici(n 1:< 1:<

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC /

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Figura 11: 3istribuci(n tpicas de esfuer#o 0 tie)po

Figura 12: 3istribuci(n tpica de recursos 7u)anos

;nicio
Durante la fase de inicio se define el modelo del ne$ocio y el alcance del proyecto. Se identifican todos los actores y Casos de Uso& y se dise)an los Casos de Uso ms esenciales (apro3imadamente el C@I del modelo completo!. Se desarrolla& un plan de ne$ocio para determinar 4ue recursos de"en ser asi$nados al proyecto. ,os o"5etivos de esta fase son >? U@@A< Esta"lecer el m"ito del proyecto y sus l%mites. Encontrar los Casos de Uso cr%ticos del sistema& los escenarios "sicos 4ue definen la funcionalidad. +ostrar al menos una ar4uitectura candidata para los escenarios principales. Estimar el coste en recursos y tiempo de todo el proyecto. Estimar los ries$os& las fuentes de incertidum"re. ,os resultados de la fase de inicio de"en ser > SC/6A< Un documento de visin< Una visin $eneral de los re4uerimientos del proyecto& caracter%sticas clave y restricciones principales. +odelo inicial de Casos de Uso (.@HC@I completado!. Un $losario inicial< Berminolo$%a clave del dominio. El caso de ne$ocio. ,ista de ries$os y plan de contin$encia. Plan del proyecto& mostrando fases e iteraciones. +odelo de ne$ocio& si es necesario Prototipos e3ploratorios para pro"ar conceptos o la ar4uitectura candidata. 8l terminar la fase de inicio se de"en compro"ar los criterios de evaluacin para continuar< Bodos los interesados en el proyecto coinciden en la definicin del m"ito del sistema y las estimaciones de a$enda. Entendimiento de los re4uisitos& como evidencia de la fidelidad de los Casos de Uso principales. ,as estimaciones de tiempo& coste y ries$o son cre%"les. Comprensin total de cual4uier prototipo de la ar4uitectura desarrollado. ,os $astos #asta el momento se aseme5an a los planeados. Si el proyecto no pasa estos criterios #ay 4ue plantearse a"andonarlo o repensarlo profundamente.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .@

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

&laboraci(n
El propsito de la fase de ela"oracin es anali'ar el dominio del pro"lema& esta"lecer los cimientos de la ar4uitectura& desarrollar el plan del proyecto y eliminar los mayores ries$os. En esta fase se construye un prototipo de la ar4uitectura& 4ue de"e evolucionar en iteraciones sucesivas #asta convertirse en el sistema final. Este prototipo de"e contener los Casos de Uso cr%ticos identificados en la fase de inicio. Bam"in de"e demostrarse 4ue se #an evitado los ries$os ms $raves. ,os o"5etivos de esta fase son >? U@@A< Definir& validar y cimentar la ar4uitectura. Completar la visin. Crear un plan fia"le para la fase de construccin. Este plan puede evolucionar en sucesivas iteraciones. De"e incluir los costes si procede. Demostrar 4ue la ar4uitectura propuesta soportar la visin con un coste ra'ona"le y en un tiempo ra'ona"le. 8l terminar de"en o"tenerse los si$uientes resultados > SC/6A< Un modelo de Casos de Uso completa al menos #asta el 6@I< todos los casos y actores identificados& la mayor%a de los casos desarrollados. e4uisitos adicionales 4ue capturan los re4uisitos no funcionales y cual4uier re4uisito no asociado con un Caso de Uso espec%fico. Descripcin de la ar4uitectura soft(are. Un prototipo e5ecuta"le de la ar4uitectura. ,ista de ries$os y caso de ne$ocio revisados. Plan de desarrollo para el proyecto. Un caso de desarrollo actuali'ado 4ue especifica el proceso a se$uir. Un manual de usuario preliminar (opcional!. En esta fase se de"e tratar de a"arcar todo el proyecto con la profundidad m%nima. Slo se profundi'a en los puntos cr%ticos de la ar4uitectura o ries$os importantes. En la fase de ela"oracin se actuali'an todos los productos de la fase de inicio. ,os criterios de evaluacin de esta fase son los si$uientes< ,a visin del producto es esta"le. ,a ar4uitectura es esta"le. Se #a demostrado mediante la e5ecucin del prototipo 4ue los principales elementos de ries$o #an sido a"ordados y resueltos. El plan para la fase de construccin es detallado y preciso. ,as estimaciones son cre%"les. Bodos los interesados coinciden en 4ue la visin actual ser alcan'ada si se si$uen los planes actuales en el conte3to de la ar4uitectura actual. ,os $astos #asta a#ora son acepta"les& comparados con los previstos. Si no se superan los criterios de evaluacin 4ui' sea necesario a"andonar el proyecto o replanterselo considera"lemente.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC ..

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Construcci(n
,a finalidad principal de esta fase es alcan'ar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos los componentes& caracter%sticas y re4uisitos de"en ser implementados& inte$rados y pro"ados en su totalidad& o"teniendo una versin acepta"le del producto. ,os o"5etivos concretos se$=n >? U@@A incluyen< +inimi'ar los costes de desarrollo mediante la optimi'acin de recursos y evitando el tener 4ue re#acer un tra"a5o o incluso desec#arlo. Conse$uir una calidad adecuada tan rpido como sea prctico. Conse$uir versiones funcionales (alfa& "eta& y otras versiones de prue"a! tan rpido como sea prctico. ,os resultados de la fase de construccin de"en ser > SC/6A<JJ +odelos Completos (Casos de Uso& 8nlisis& Dise)o& Desplie$ue e Implementacin! 8r4uitectura %nte$ra (mantenida y m%nimamente actuali'ada! ies$os Presentados +iti$ados Plan del Proyecto para la fase de Bransicin. +anual Inicial de Usuario (con suficiente detalle! Prototipo 9peracional K "eta Caso del Le$ocio 8ctuali'ado ,os criterios de evaluacin de esta fase son los si$uientes< El producto es esta"le y maduro como para ser entre$ado a la comunidad de usuario para ser pro"ado. Bodos los usuarios e3pertos estn listos para la transicin en la comunidad de usuarios. Son acepta"les los $astos actuales versus los $astos planeados.

"ransici(n
,a finalidad de la fase de transicin es poner el producto en manos de los usuarios finales& para lo 4ue se re4uiere desarrollar nuevas versiones actuali'adas del producto& completar la documentacin& entrenar al usuario en el mane5o del producto& y en $eneral tareas relacionadas con el a5uste& confi$uracin& instalacin y facilidad de uso del producto. En >? U@@A se citan al$unas de las cosas 4ue puede incluir esta fase< Prue"a de la versin *eta para validar el nuevo sistema frente a las e3pectativas de los usuarios -uncionamiento paralelo con los sistemas le$ados 4ue estn siendo sustituidos por nuestro proyecto. Conversin de las "ases de datos operacionales. Entrenamiento de los usuarios y tcnicos de mantenimiento. Braspaso del producto a los e4uipos de marMetin$& distri"ucin y venta. ,os principales o"5etivos de esta fase son< Conse$uir 4ue el usuario se val$a por si mismo. Un producto final 4ue cumpla los re4uisitos esperados& 4ue funcione y satisfa$a suficientemente al usuario. ,os resultados de la fase de transicin son > SC/6A< Prototipo 9peracional Documentos ,e$ales Caso del Le$ocio Completo ,%nea de *ase del Producto completa y corre$ida 4ue incluye todos los modelos del sistema Descripcin de la 8r4uitectura completa y corre$ida ,as iteraciones de esta fase irn diri$idas normalmente a conse$uir una nueva versin. ,os criterios de evaluacin de esta fase son los si$uientes<
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .C

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

El usuario se encuentra satisfec#o. Son acepta"les los $astos actuales versus los $astos planificados.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .:

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

2 &structura &st,tica del proceso. Roles+ acti'idades+ artefactos 0 flu os de traba o

Un proceso de desarrollo de soft(are define 4uin #ace 4u& cmo y cundo. UP define cuatro elementos los roles& 4ue responden a la pre$unta NOuinP& las actividades 4ue responden a la pre$unta NCmoP& los productos& 4ue responden a la pre$unta NOuP y los flu5os de tra"a5o de las disciplinas 4ue responde a la pre$unta NCundoP (ver -i$ura .: y .E! > SC/6A.

Figura 1!: Relaci(n entre roles+ acti'idades+ artefactos

oles 8ctividades

8rtefactos

Figura 1%: 3etalle de un 4or=flo4 )ediante roles+ acti'idades 0 artefactos

Roles
Un rol define el comportamiento y responsa"ilidades de un individuo& o de un $rupo de individuos tra"a5ando 5untos como un e4uipo. Una persona puede desempe)ar diversos roles& as% como un mismo rol puede ser representado por varias personas. ,as responsa"ilidades de un rol son tanto el llevar a ca"o un con5unto de actividades como el ser el due)o
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .E

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

de un con5unto de artefactos >++8A.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .7

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

UP define $rupos de roles& a$rupados por participacin en actividades relacionadas. Estos $rupos son > SC@CA< 8nalistas< 8nalista de procesos de ne$ocio. Dise)ador del ne$ocio. 8nalista de sistema. Especificador de re4uisitos. Desarrolladores< 8r4uitecto de soft(are. Dise)ador Dise)ador de interfa' de usuario Dise)ador de cpsulas. Dise)ador de "ase de datos. Implementador. Inte$rador. ;estores< 2efe de proyecto 2efe de control de cam"ios. 2efe de confi$uracin. 2efe de prue"as 2efe de desplie$ue In$eniero de procesos evisor de $estin del proyecto ;estor de prue"as. 8poyo< Documentador tcnico 8dministrador de sistema Especialista en #erramientas Desarrollador de cursos 8rtista $rfico Especialista en prue"as< Especialista en Prue"as (tester! 8nalista de prue"as Dise)ador de prue"as 9tros roles< Sta$eholders. evisor Coordinacin de revisiones evisor tcnico Cual4uier rol

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .0

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

>cti'idades
Una actividad en concreto es una unidad de tra"a5o 4ue una persona 4ue desempe)e un rol puede ser solicitado a 4ue realice. ,as actividades tienen un o"5etivo concreto& normalmente e3presado en trminos de crear o actuali'ar al$=n producto.

>rtefactos
Un producto o artefacto es un tro'o de informacin 4ue es producido& modificado o usado durante el proceso de desarrollo de soft(are. ,os productos son los resultados tan$i"les del proyecto& las cosas 4ue va creando y usando #asta o"tener el producto final >++8A. Un artefacto puede ser cual4uiera de los si$uientes > SC@CA<

Un documento& como el documento de la ar4uitectura del soft(are. Un modelo& como el modelo de Casos de Uso o el modelo de dise)o. Un elemento del modelo& un elemento 4ue pertenece a un modelo como una clase& un Caso de Uso o un su"sistema.

Flu os de traba o
Con la enumeracin de roles& actividades y artefactos no se define un proceso& necesitamos contar con una secuencia de actividades reali'adas por los diferentes roles& as% como la relacin entre los mismos. Un flu5o de tra"a5o es una relacin de actividades 4ue nos producen unos resultados o"serva"les. 8 continuacin se dar una e3plicacin de cada flu5o de tra"a5o. 5odelado del negocio Con este flu5o de tra"a5o pretendemos lle$ar a un me5or entendimiento de la or$ani'acin donde se va a implantar el producto. ,os o"5etivos del modelado de ne$ocio son > SC@CA<

Entender la estructura y la dinmica de la or$ani'acin para la cual el sistema va ser desarrollado (or$ani'acin o"5etivo!. Entender el pro"lema actual en la or$ani'acin o"5etivo e identificar potenciales me5oras. 8se$urar 4ue clientes& usuarios finales y desarrolladores ten$an un entendimiento com=n de la or$ani'acin o"5etivo. Derivar los re4uisitos del sistema necesarios para apoyar a la or$ani'acin o"5etivo.

Para lo$rar estos o"5etivos& el modelo de ne$ocio descri"e como desarrollar una visin de la nueva or$ani'acin& "asado en esta visin se definen procesos& roles y responsa"ilidades de la or$ani'acin por medio de un modelo de Casos de Uso del ne$ocio y un +odelo de 9"5etos del Le$ocio. Complementario a estos modelos& se desarrollan otras especificaciones tales como un ;losario. Re$uisitos Este es uno de los flu5os de tra"a5o ms importantes& por4ue en l se esta"lece 4u tiene 4ue #acer e3actamente el sistema 4ue construyamos. En esta l%nea los re4uisitos son el contrato 4ue se de"e cumplir& de modo 4ue los usuarios finales tienen 4ue comprender y aceptar los re4uisitos 4ue especifi4uemos. ,os o"5etivos del flu5o de datos e4uisitos es > SC@CA<

Esta"lecer y mantener un acuerdo entre clientes y otros sta$eholders so"re lo 4ue el sistema podr%a #acer. Proveer a los desarrolladores un me5or entendimiento de los re4uisitos del sistema. Definir el m"ito del sistema. Proveer una "ase para la planeacin de los contenidos tcnicos de las iteraciones. Proveer una "ase para estimar costos y tiempo de desarrollo del sistema.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .1

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Definir una interfa' de usuarios para el sistema& enfocada a las necesidades y metas del usuario.

,os re4uisitos se dividen en dos $rupos. ,os re4uisitos funcionales representan la funcionalidad del sistema. Se modelan mediante dia$ramas de Casos de Uso. ,os re4uisitos no funcionales representan a4uellos atri"utos 4ue de"e e3#i"ir el sistema& pero 4ue no son una funcionalidad espec%fica. Por e5emplo re4uisitos de facilidad de uso& fia"ilidad& eficiencia& porta"ilidad& etc. Para capturar los re4uisitos es preciso entrevistar a todos los interesados en el proyecto& no slo a los usuarios finales& y anotar todas sus peticiones. 8 partir de ellas #ay 4ue descu"rir lo 4ue necesitan y e3presarlo en forma de re4uisitos. En este flu5o de tra"a5o& y como parte de los re4uisitos de facilidad de uso& se dise)a la interfa' $rfica de usuario. Para ello #a"itualmente se construyen prototipos de la interfa' $rfica de usuario 4ue se contrastan con el usuario final. >n,lisis 0 3ise?o El o"5etivo de este flu5o de tra"a5o es traducir los re4uisitos a una especificacin 4ue descri"e cmo implementar el sistema. ,os o"5etivos del anlisis y dise)o son > SC@CA< Bransformar los re4uisitos al dise)o del futuro sistema. Desarrollar una ar4uitectura para el sistema. 8daptar el dise)o para 4ue sea consistente con el entorno de implementacin& dise)ando para el rendimiento. El anlisis consiste en o"tener una visin del sistema 4ue se preocupa de ver 4u #ace& de modo 4ue slo se interesa por los re4uisitos funcionales. Por otro lado el dise)o es un refinamiento del anlisis 4ue tiene en cuenta los re4uisitos no funcionales& en definitiva cmo cumple el sistema sus o"5etivos. 8l principio de la fase de ela"oracin #ay 4ue definir una ar4uitectura candidata< crear un es4uema inicial de la ar4uitectura del sistema& identificar clases de anlisis y actuali'ar las reali'aciones de los Casos de Uso con las interacciones de las clases de anlisis. Durante la fase de ela"oracin se va refinando esta ar4uitectura #asta lle$ar a su forma definitiva. En cada iteracin #ay 4ue anali'ar el comportamiento para dise)ar componentes. 8dems si el sistema usar una "ase de datos& #a"r 4ue dise)arla tam"in& o"teniendo un modelo de datos. El resultado final ms importante de este flu5o de tra"a5o ser el modelo de dise)o. Consiste en cola"oraciones de clases& 4ue pueden ser a$re$adas en pa4uetes y su"sistemas. 9tro producto importante de este flu5o es la documentacin de la ar4uitectura de soft(are& 4ue captura varias vistas ar4uitectnicas del sistema. ;)ple)entaci(n En este flu5o de tra"a5o se implementan las clases y o"5etos en fic#eros fuente& "inarios& e5ecuta"les y dems. 8dems se de"en #acer las prue"as de unidad< cada implementador es responsa"le de pro"ar las unidades 4ue produ'ca. El resultado final de este flu5o de tra"a5o es un sistema e5ecuta"le. En cada iteracin #a"r 4ue #acer lo si$uiente< Planificar 4u su"sistemas de"en ser implementados y en 4ue orden de"en ser inte$rados& formando el Plan de Inte$racin. Cada implementador decide en 4ue orden implementa los elementos del su"sistema. Si encuentra errores de dise)o& los notifica. Se prue"an los su"sistemas individualmente. Se inte$ra el sistema si$uiendo el plan. ,a estructura de todos los elementos implementados forma el modelo de implementacin. ,a inte$racin de"e ser incremental& es decir& en cada momento slo se a)ade un elemento. De este modo es ms fcil
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC .6

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

locali'ar fallos y los componentes se prue"an ms a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el ries$o. Su utilidad puede ir desde ver si el sistema es via"le desde el principio& pro"ar tecnolo$%as o dise)ar la interfa' de usuario. ,os prototipos pueden ser e3ploratorios (desec#a"les! o evolutivos. Estos =ltimos lle$an a transformarse en el sistema final. Pruebas Este flu5o de tra"a5o es el encar$ado de evaluar la calidad del producto 4ue estamos desarrollando& pero no para aceptar o rec#a'ar el producto al final del proceso de desarrollo& sino 4ue de"e ir inte$rado en todo el ciclo de vida. Esta disciplina "rinda soporte a las otras disciplinas. Sus o"5etivos son > SC@CA< Encontrar y documentar defectos en la calidad del soft(are. ;eneralmente asesora so"re la calidad del soft(are perci"ida. Provee la validacin de los supuestos reali'ados en el dise)o y especificacin de re4uisitos por medio de demostraciones concretas. Verificar las funciones del producto de soft(are se$=n lo dise)ado. Verificar 4ue los re4uisitos ten$an su apropiada implementacin. ,as actividades de este flu5o comien'an pronto en el proyecto con el plan de prue"a (el cual contiene informacin so"re los o"5etivos $enerales y espec%ficos de las prue"a en el proyecto& as% como las estrate$ias y recursos con 4ue se dotar a esta tarea!& o incluso antes con al$una evaluacin durante la fase de inicio& y continuar durante todo el proyecto. El desarrollo del flu5o de tra"a5o consistir en planificar 4ue es lo 4ue #ay 4ue pro"ar& dise)ar cmo se va a #acer& implementar lo necesario para llevarlos a ca"o& e5ecutarlos en los niveles necesarios y o"tener los resultados& de forma 4ue la informacin o"tenida nos sirva para ir refinando el producto a desarrollar. 3espliegue El o"5etivo de este flu5o de tra"a5o es producir con 3ito distri"uciones del producto y distri"uirlo a los usuarios. ,as actividades implicadas incluyen<

Pro"ar el producto en su entorno de e5ecucin final. Empa4uetar el soft(are para su distri"ucin. Distri"uir el soft(are. Instalar el soft(are. Proveer asistencia y ayuda a los usuarios. -ormar a los usuarios y al cuerpo de ventas. +i$rar el soft(are e3istente o convertir "ases de datos.

Este flu5o de tra"a5o se desarrolla con mayor intensidad en la fase de transicin& ya 4ue el propsito del flu5o es ase$urar una aceptacin y adaptacin sin complicaciones del soft(are por parte de los usuarios. Su e5ecucin inicia en fases anteriores& para preparar el camino& so"re todo con actividades de planificacin& en la ela"oracin del manual de usuario y tutoriales. 2esti(n del pro0ecto ,a ;estin del proyecto es el arte de lo$rar un "alance al $estionar o"5etivos& ries$os y restricciones para desarrollar un producto 4ue sea acorde a los re4uisitos de los clientes y los usuarios. ,os o"5etivos de este flu5o de tra"a5o son< Proveer un marco de tra"a5o para la $estin de proyectos de soft(are intensivos. Proveer $u%as prcticas reali'ar planeacin& contratar personal& e5ecutar y monitorear el proyecto. Proveer un marco de tra"a5o para $estionar ries$os. ,a planeacin de un proyecto posee dos niveles de a"straccin< un plan para las fases y un plan para cada iteracin. Configuraci(n 0 control de ca)bios
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC ./

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

,a finalidad de este flu5o de tra"a5o es mantener la inte$ridad de todos los artefactos 4ue se crean en el proceso& as% como de mantener informacin del proceso evolutivo 4ue #an se$uido. &ntorno ,a finalidad de este flu5o de tra"a5o es dar soporte al proyecto con las adecuadas #erramientas& procesos y mtodos. *rinda una especificacin de las #erramientas 4ue se van a necesitar en cada momento& as% como definir la instancia concreta del proceso 4ue se va a se$uir. En concreto las responsa"ilidades de este flu5o de tra"a5o incluyen< Seleccin y ad4uisicin de #erramientas Esta"lecer y confi$urar las #erramientas para 4ue se a5usten a la or$ani'acin. Confi$uracin del proceso. +e5ora del proceso. Servicios tcnicos. El principal artefacto 4ue se usa en este flu5o de tra"a5o es el caso de desarrollo 4ue especifica para el proyecto actual en concreto& como se aplicar el proceso& 4ue productos se van a utili'ar y como van a ser utili'ados. 8dems se tendrn 4ue definir las $u%as para los distintos aspectos del proceso& como pueden ser el modelado del ne$ocio y los Casos de Uso& para la interfa' de usuario& el dise)o& la pro$ramacin& el manual de usuario.

Una configuraci(n RUP para pro0ecto pe$ue?o

En este apartado se descri"e una posi"le confi$uracin de UP para un proyecto pe4ue)o. Por las caracter%sticas del proyecto& se #an incluido muy pocos artefactos& roles y actividades de la metodolo$%a& manteniendo los ms esenciales. Dic#a confi$uracin est "asada en la si$uiente seleccin de artefactos< &ntregables del pro0ecto 8 continuacin se descri"en "revemente cada uno de los artefactos 4ue se $enerarn y usarn durante el proyecto. 1. Flu os de "raba o Se utili'arn Dia$ramas de 8ctividad para modelar los -lu5os de Bra"a5o ((orMflo(s! del rea pro"lema& tanto los actuales (previos a la implantacin de nuevo sistema! como los propuestos& 4ue sern soportados por el sistema desarrollado 2. Caractersticas del Producto @oft4are Es una lista de las caracter%sticas principales del producto& desea"les desde una perspectiva de las necesidades del cliente. !. 2losario Es un documento 4ue define los principales trminos usados en el proyecto. Permite esta"lecer una terminolo$%a consensuada. %. 5odelo de Casos de Uso El modelo de Casos de Uso presenta la funcionalidad del sistema y los actores 4ue #acen uso de ella. Se representa mediante Dia$ramas de Casos de Uso. *. &specificaciones de Casos de Uso Para los casos de uso 4ue lo re4uieran (cuya funcionalidad no sea evidente o 4ue no "aste con una simple descripcin narrativa! se reali'a una descripcin detallada utili'ando una plantilla de documento& donde se incluyen< precondiciones& postcondiciones& flu5o de eventos& re4uisitos noHfuncionales asociados. -. 5odelo de >n,lisis 0 3ise?o Este modelo esta"lece la reali'acin de los casos de uso en clases y pasando desde una
Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC C@

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

representacin en trminos de anlisis (sin incluir aspectos de implementacin! #acia una de dise)o (incluyendo una orientacin #acia el entorno de implementacin!. Est constituido esencialmente por un Dia$rama de Clases y al$unos Dia$ramas de Estados para las clases 4ue lo re4uieran. .. 5odelo L(gico Relacional Previendo 4ue la persistencia de la informacin del sistema ser soportada por una "ase de datos relacional& este modelo descri"e la representacin l$ica de los datos persistentes& de acuerdo con el enfo4ue para modelado relacional de datos. Para e3presar este modelo se utili'a un Dia$rama de Ba"las donde se muestran las ta"las& claves& etc. 8. 5odelo de ;)ple)entaci(n Este modelo es una coleccin de componentes y los su"sistemas 4ue los contienen. Estos componentes incluyen< fic#eros e5ecuta"les& fic#eros de cdi$o fuente& y todo otro tipo de fic#eros necesarios para la implantacin y desplie$ue del sistema. 9. 5odelo de Pruebas Para cada Caso de Uso se esta"lecen prue"as de 8ceptacin 4ue validarn la correcta implementacin del Caso de Uso. Cada prue"a es especificada mediante un documento 4ue esta"lece las condiciones de e5ecucin& las entradas de la prue"a& y los resultados esperados. 1:. 5anual de ;nstalaci(n Este documento incluye las instrucciones para reali'ar la instalacin del producto. 11. 5aterial de Usuario Corresponde a un con5unto de documentos y facilidades de uso del sistema. 12. Producto Bodos los fic#eros fuente y e5ecuta"le del producto.

2.1 &s$ue)a de tra#abilidad

,a -i$ura .7 ilustra las relaciones de tra'a"ilidad entre artefactos del proyecto& y se$=n la confi$uracin antes mencionada.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC C.

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Figura 1*. "ra#abilidad entre artefactos.

Bomado de a p$ina de la Universidad de Valencia. D P.,etelier . Se puede usar material de otros autores sin autori'acin con fines academicos D, 6CC CC

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

,as relaciones de tra'a"ilidad son enlaces entre artefactos 4ue esta"lecen cmo se $eneran unos a partir de otros. Esto permite por e5emplo ase$urar la co"ertura de los re4uisitos o determinar el posi"le impacto de los cam"ios. En la -i$ura .7 se ilustran los modelos y artefactos utili'ados& indicando las relaciones de tra'a"ilidad entre ellos& lo cual se resume a continuacin< Se modelarn los procesos de ne$ocio de la situacin actual utili'ando Dia$ramas de 8ctividad para representar -lu5os de Bra"a5o 8ctuales. Esto se complementar mediante un ;losario 4ue esta"lecer la terminolo$%a. El modelo de procesos de la solucin propuesta incluir -lu5os de Bra"a5o Propuestos 5unto con una lista de Caracter%sticas del Producto Soft(are. ,os re4uisitos sern esta"lecidos mediante un +odelo de Casos de Uso 4ue incluir Dia$ramas de Casos de Uso& Prototipos de Interfaces de Usuario y Especificaciones de Casos de Uso. El +odelo de Prue"as incluir las Prue"as de 8ceptacin esta"lecidas para cada Caso de Uso. El +odelo de 8nlisis y Dise)o esta"lecer el particionamiento interno del sistema. Estar compuesto por un Dia$rama de Clases y al$unos Dia$ramas de Estados. ,as clases determinarn la estructura y las operaciones necesarias para implementar las funcionalidades descritas en los Casos de Uso. ,os Dia$ramas de Estados detallarn el comportamiento para las clases 4ue lo re4uieran. 8 partir del Dia$rama de Clases& y considerando las clases 4ue re4uieran persistencia& se derivar el +odelo ,$ico elacional& representado mediante Dia$ramas de Ba"las. En el +odelo de Implementacin se or$ani'arn las operaciones de las clases en trminos de componentes de dic#a ar4uitectura. Esto se representar mediante Dia$ramas de Componentes. ,a implementacin del +odelo ,$ico elacional y de los componentes de la aplicacin constituirn el Producto& el cual se complementar con el +anual de Instalacin y el +anual de Usuario.

Referencias

D P.,etelier #ttps<GGpid.dsic.upv.es

C: