EL PROCESO UNIFICADO RACIONAL (RUP)

RICARDO RAMIREZ NEGRETE

IVAN GUERRA REYES
KELLYS CHIMA GONZALEZ
YOELIS ARIZA GONZALEZ
LIC. JAIME HERNANDEZ
UNIVERSIDAD DE CORDOBA
FACULTAD DE EDUCACIN Y CIENCIAS HUMANAS
LICENCIATURA EN INFORMATICA Y MEDIOS AUDIOVISUALES
ELECTIVA DE PROFUNDIZACION
VIII- SEMESTRE
MONTERIA
200
EL PROCESO UNIFICADO RACIONAL (RUP)
RUP es una metodologa formal, a veces tambin llamada proceso, para
desarrollo de software, documentada en hipertexto para ser consultada a travs
de un navegador.
El RUP describe a gran detalle todas las actividades, roles, responsabilidades,
productos de trabajo herramientas para definir !uin hace !u en !u
momento en un proecto de desarrollo de software.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto necesidades de cada organi"aci#n.
P!"#$"%&'() C&!&$*(!+)*"$&)
El RUP es un producto de Rational $%&'(. )e caracteri"a por ser guiado por los
casos de uso, estar centrado en la ar!uitectura por ser iterativo e incremental.
%nclue artefactos $!ue son los productos tangibles del proceso como por ejemplo,
el modelo de casos de uso, el c#digo fuente, etc.( roles $papel !ue desempe*a
una persona en un determinado momento, una persona puede desempe*ar
distintos roles a lo largo del proceso(....
P!,$(), -"!"."-, %,! C&),) -( U),
)eg+n ,-ru../, los 0asos de Uso son una tcnica de captura de re!uisitos !ue
fuer"a a pensar en trminos de importancia para el usuario no s#lo en trminos
de funciones !ue seria bueno contemplar. )e define un 0aso de Uso como un
fragmento de funcionalidad del sistema !ue proporciona al usuario un valor
a*adido. 1os 0asos de Uso representan los re!uisitos funcionales del sistema.
En RUP los 0asos de Uso no son s#lo una herramienta para especificar los
re!uisitos del sistema. 2ambin guan su dise*o, implementaci#n prueba. 1os
0asos de Uso constituen un elemento integrador una gua del trabajo como se
muestra en la 3igura 4.
F"./!& 01 L,) C&),) -( U), "#*(.!&# (' *!&2&3,
1os 0asos de Uso no s#lo inician el proceso de desarrollo sino !ue proporcionan
un hilo conductor, permitiendo establecer tra"abilidad entre los artefactos !ue son
generados en las diferentes actividades del proceso de desarrollo.
0omo se muestra en la 3igura 5, bas6ndose en los 0asos de Uso se crean los
modelos de an6lisis dise*o, luego la implementaci#n !ue los lleva a cabo, se
verifica !ue efectivamente el producto implemente adecuadamente cada 0aso de
Uso. 2odos los modelos deben estar sincroni"ados con el modelo de 0asos de
Uso.
F"./!& 21 T!&4&2"'"-&- & %&!*"! -( ',) C&),) -( U),
C(#*!&-, (# '& A!5/"*($*/!&
A!5/"*($*/!&7 0onjunto de decisiones significativas acerca de la organi"aci#n de
un sistema software, la selecci#n de los elementos estructurales a partir de los
cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus
colaboraciones, su composici#n.
1a ar!uitectura de un sistema software se describe mediante diferentes vistas del
sistema en construcci#n.
El concepto de ar!uitectura software inclue los aspectos est6ticos din6micos
m6s significativos del sistema. 1a ar!uitectura es una vista del dise*o completo
con las caractersticas m6s importantes resaltadas, dejando los detalles de lado.
1os casos de uso la ar!uitectura est6n profundamente relacionados. 1os casos
de uso deben encajar en la ar!uitectura, a su ve" la ar!uitectura debe permitir el
desarrollo de todos los casos de uso re!ueridos, actualmente a futuro.
El ar!uitecto desarrolla la forma o ar!uitectura a partir de la comprensi#n de un
conjunto reducido de casos de uso fundamentales o crticos $usualmente no mas
del 8. 9 del total(. En forma resumida, podemos decir !ue el ar!uitecto7
: 0rea un es!uema en borrador de la ar!uitectura comen"ando por la parte no
especfica de los casos de uso $por ejemplo la plataforma( pero con una
comprensi#n general de los casos de uso fundamentales.
: ; continuaci#n, trabaja con un conjunto de casos de usos claves o
fundamentales. 0ada caso de uso es especificado en detalle reali"ado en
trminos de subsistemas, clases, componentes.
: ; medida !ue los casos de uso se especifican maduran, se descubre m6s de la
ar!uitectura, esto a su ve" lleva a la maduraci#n de m6s casos de uso.
Este proceso contin+a hasta !ue se considere !ue la ar!uitectura es estable.
I*(!&*"6, E I#$!(7(#*&'7 Es pr6ctico dividir el esfuer"o de desarrollo de un
proecto de software en partes m6s pe!ue*as o mini proectos.
0ada mini proecto es una iteraci#n !ue resulta en un incremento. 1as iteraciones
hace referencia a pasos en el flujo de trabajo, los incrementos a crecimientos en
el producto.
1as iteraciones deben estar controladas. Esto significa !ue deben seleccionarse
ejecutarse de una forma planificada.
1os desarrolladores basan la selecci#n de lo !ue implementar6n en cada iteraci#n
en dos cosas7 el conjunto de casos de uso !ue amplan la funcionalidad, en los
riesgos m6s importantes !ue deben mitigarse.
En cada iteraci#n los desarrolladores identifican especifican los casos de uso
relevantes, crean un dise*o utili"ando la ar!uitectura seleccionada como gua,
para implementar dichos casos de uso. )i la iteraci#n cumple sus objetivos, se
contin+a con la pr#xima. )ino deben revisarse las decisiones previas probar un
nuevo enfo!ue.
B(#(8"$",) -(' (#8,5/( "*(!&*"6,1
: 1a iteraci#n controlada reduce el riesgo a los costes de un solo incremento.
: Reduce el riesgo de retrasos en el calendario atacando los riesgos m6s
importantes primero.
: ;celera el desarrollo. 1os trabajadores trabajan de manera m6s eficiente al
obtener resultados a corto pla"o.
: 2iene un enfo!ue m6s realista al reconocer !ue los re!uisitos no pueden
definirse completamente al principio.
E' C"$', -( V"-& -(' P!,$(), U#"8"$&-,
El Proceso Unificado se repite a lo largo de una serie de ciclos !ue constituen la
vida de un sistema. 0ada ciclo constitue una 6(!)"9# del sistema.
F&)()1
0ada ciclo constas de cuatro fases7 inicio, elaboraci#n, construcci#n, transici#n.
I#"$",1 <urante la fase de inicio se define el modelo del negocio el alcance del
proecto. )e identifican todos los actores 0asos de Uso, se dise*an los 0asos
de Uso m6s esenciales $aproximadamente el 4.9 del modelo completo(. )e
desarrolla, un plan de negocio para determinar !ue recursos deben ser asignados
al proecto.
1os objetivos de esta fase son7
Establecer el 6mbito del proecto sus lmites.
Encontrar los 0asos de Uso crticos del sistema, los escenarios b6sicos !ue
definen la funcionalidad.
'ostrar al menos una ar!uitectura candidata para los escenarios
principales.
Estimar el costo en recursos tiempo de todo el proecto.
Estimar los riesgos, las fuentes de incertidumbre.
1os resultados de la fase de inicio deben ser7
Un documento de visi#n7 Una visi#n general de los re!uerimientos del
proecto, caractersticas clave restricciones principales.
'odelo inicial de 0asos de Uso $8.:4.9 completado(.
Un glosario inicial7 2erminologa clave del dominio.
El caso de negocio.
1ista de riesgos plan de contingencia.
Plan del proecto, mostrando fases e iteraciones.
'odelo de negocio, si es necesario
Prototipos exploratorios para probar conceptos o la ar!uitectura candidata.
;l terminar la fase de inicio se deben comprobar los criterios de evaluaci#n para
continuar7
2odos los interesados en el proecto coinciden en la definici#n del 6mbito
del sistema las estimaciones de agenda.
Entendimiento de los re!uisitos, como evidencia de la fidelidad de los
0asos de Uso principales.
1as estimaciones de tiempo, costo riesgo son crebles.
0omprensi#n total de cual!uier prototipo de la ar!uitectura desarrollado.
1os gastos hasta el momento se asemejan a los planeados.
)i el proecto no pasa estos criterios ha !ue plantearse abandonarlo o repensarlo
profundamente.
E'&2,!&$"9#1 El prop#sito de la fase de elaboraci#n es anali"ar el dominio del
problema, establecer los cimientos de la ar!uitectura, desarrollar el plan del
proecto eliminar los maores riesgos.
En esta fase se construe un prototipo de la ar!uitectura, !ue debe evolucionar en
iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe
contener los 0asos de Uso crticos identificados en la fase de inicio. 2ambin debe
demostrarse !ue se han evitado los riesgos m6s graves.
1os objetivos de esta fase son7
<efinir, validar cimentar la ar!uitectura.
0ompletar la visi#n.
0rear un plan fiable para la fase de construcci#n. Este plan puede
evolucionar en sucesivas iteraciones. <ebe incluir los costes si procede.
<emostrar !ue la ar!uitectura propuesta soportar6 la visi#n con un coste
ra"onable en un tiempo ra"onable.
;l terminar deben obtenerse los siguientes resultados7
Un modelo de 0asos de Uso completa al menos hasta el =.97 todos los
casos actores identificados, la maora de los casos desarrollados.
Re!uisitos adicionales !ue capturan los re!uisitos no funcionales
cual!uier re!uisito no asociado con un 0aso de Uso especfico.
<escripci#n de la ar!uitectura software.
Un prototipo ejecutable de la ar!uitectura.
1ista de riesgos caso de negocio revisados.
Plan de desarrollo para el proecto.
Un caso de desarrollo actuali"ado !ue especifica el proceso a seguir.
Un manual de usuario preliminar $opcional(.
En esta fase se debe tratar de abarcar todo el proecto con la profundidad
mnima. )#lo se profundi"a en los puntos crticos de la ar!uitectura o riesgos
importantes.
En la fase de elaboraci#n se actuali"an todos los productos de la fase de inicio.
1os criterios de evaluaci#n de esta fase son los siguientes7
1a visi#n del producto es estable.
1a ar!uitectura es estable.
)e ha demostrado mediante la ejecuci#n del prototipo !ue los principales
elementos de riesgo han sido abordados resueltos.
El plan para la fase de construcci#n es detallado preciso. 1as
estimaciones son crebles.
2odos los interesados coinciden en !ue la visi#n actual ser6 alcan"ada si
se siguen los planes actuales en el contexto de la ar!uitectura actual.
1os gastos hasta ahora son aceptables, comparados con los previstos.
)i no se superan los criterios de evaluaci#n !ui"6 sea necesario abandonar el
proecto o replante6rselo considerablemente.
C,#)*!/$$"9#7 1a finalidad principal de esta fase es alcan"ar la capacidad
operacional del producto de forma incremental a travs de las sucesivas
iteraciones. <urante esta fase todos los componentes, caractersticas
re!uisitos deben ser implementados, integrados probados en su
totalidad, obteniendo una versi#n aceptable del producto.
1os objetivos concretos son7
'inimi"ar los costos de desarrollo mediante la optimi"aci#n de recursos
evitando el tener !ue rehacer un trabajo o incluso desecharlo.
0onseguir una calidad adecuada tan r6pido como sea pr6ctico.
0onseguir versiones funcionales $alfa, beta, otras versiones de prueba(
tan r6pido como sea pr6ctico.
1os resultados de la fase de construcci#n deben ser7>>
'odelos 0ompletos $0asos de Uso, ;n6lisis, <ise*o, <espliegue e
%mplementaci#n(
;r!uitectura ntegra $mantenida mnimamente actuali"ada(
Riesgos Presentados 'itigados
Plan del Proecto para la fase de 2ransici#n.
'anual %nicial de Usuario $con suficiente detalle(
Prototipo ?peracional @ beta
0aso del Aegocio ;ctuali"ado
1os criterios de evaluaci#n de esta fase son los siguientes7
El producto es estable maduro como para ser entregado a la comunidad
de usuario para ser probado.
2odos los usuarios expertos est6n listos para la transici#n en la comunidad
de usuarios.
)on aceptables los gastos actuales versus los gastos planeados.
T!&#)"$"9#1 1a finalidad de la fase de transici#n es poner el producto en manos de
los usuarios finales, para lo !ue se re!uiere desarrollar nuevas versiones
actuali"adas del producto, completar la documentaci#n, entrenar al
usuario en el manejo del producto, en general tareas relacionadas con el
ajuste, configuraci#n, instalaci#n facilidad de uso del producto.
1os principales objetivos de esta fase son7
0onseguir !ue el usuario se valga por si mismo.
Un producto final !ue cumpla los re!uisitos esperados, !ue funcione
satisfaga suficientemente al usuario.
1os resultados de la fase de transici#n son7
Prototipo ?peracional
<ocumentos 1egales
0aso del Aegocio 0ompleto
1nea de &ase del Producto completa corregida !ue inclue todos los
modelos del sistema
<escripci#n de la ;r!uitectura completa corregida
1as iteraciones de esta fase ir6n dirigidas normalmente a conseguir una
nueva versi#n.
1os criterios de evaluaci#n de esta fase son los siguientes7
El usuario se encuentra satisfecho.
)on aceptables los gastos actuales versus los gastos planificados.
ESTRUCTURA EST:TICA DEL PROCESO. ROLES; ACTIVIDADES;
ARTEFACTOS Y FLUJOS DE TRABAJO
Un proceso de desarrollo de software define !uin hace !u, c#mo cu6ndo. RUP
define cuatro elementos los roles, !ue responden a la pregunta BCuinD, las
actividades !ue responden a la pregunta B0#moD, los productos, !ue responden a
la pregunta BCuD los flujos de trabajo de las disciplinas !ue responde a la
pregunta B0u6ndoD
R,'()1 Un rol define el comportamiento responsabilidades de un individuo, o de
un grupo de individuos trabajando juntos como un e!uipo. Una persona puede
desempe*ar diversos roles, as como un mismo rol puede ser representado por
varias personas.
1as responsabilidades de un rol son tanto el llevar a cabo un conjunto de
actividades como el ser el due*o de un conjunto de artefactos ,'';/.
RUP define grupos de roles, agrupados por participaci#n en actividades
relacionadas. Estos grupos son7
;nalistas7
;nalista de procesos de negocio.
<ise*ador del negocio.
;nalista de sistema.
Especificador de re!uisitos.
<esarrolladores7
;r!uitecto de software.
<ise*ador
<ise*ador de interfa" de usuario
<ise*ador de c6psulas.
<ise*ador de base de datos.
%mplementador.
%ntegrador.
Eestores7
Fefe de proecto
Fefe de control de cambios.
Fefe de configuraci#n.
Fefe de pruebas
Fefe de despliegue
%ngeniero de procesos
Revisor de gesti#n del proecto
Eestor de pruebas.
;poo7
<ocumentador tcnico
;dministrador de sistema
Especialista en herramientas
<esarrollador de cursos
;rtista gr6fico
Especialista en pruebas7
Especialista en Pruebas
;nalista de pruebas
<ise*ador de pruebas
A$*"6"-&-()1 Una actividad en concreto es una unidad de trabajo !ue una
persona !ue desempe*e un rol puede ser solicitado a !ue realice. 1as actividades
tienen un objetivo concreto, normalmente expresado en trminos de crear o
actuali"ar alg+n producto.
A!*(8&$*,)1 Un producto o artefacto es un tro"o de informaci#n !ue es producido,
modificado o usado durante el proceso de desarrollo de software. 1os productos
son los resultados tangibles del proecto, las cosas !ue va creando usando
hasta obtener el producto final.
Un artefacto puede ser cual!uiera de los siguientes7
Un documento, como el documento de la ar!uitectura del software.
Un modelo, como el modelo de 0asos de Uso o el modelo de dise*o.
Un elemento del modelo, un elemento !ue pertenece a un modelo como una
clase, un 0aso de Uso o un subsistema.
F'/3,) D( T!&2&3,1 0on la enumeraci#n de roles, actividades artefactos no se
define un proceso, necesitamos contar con una secuencia de actividades
reali"adas por los diferentes roles, as como la relaci#n entre los mismos. Un flujo
de trabajo es una relaci#n de actividades !ue nos producen unos resultados
observables. ; continuaci#n se dar6 una explicaci#n de cada flujo de trabajo.
M,-('&-, -(' #(.,$",1 0on este flujo de trabajo pretendemos llegar a un mejor
entendimiento de la organi"aci#n donde se va a implantar el producto.
1os objetivos del modelado de negocio son7
Entender la estructura la din6mica de la organi"aci#n para la cual el
sistema va ser desarrollado $organi"aci#n objetivo(.
Entender el problema actual en la organi"aci#n objetivo e identificar
potenciales mejoras.
;segurar !ue clientes, usuarios finales desarrolladores tengan un
entendimiento com+n de la organi"aci#n objetivo.
<erivar los re!uisitos del sistema necesarios para apoar a la organi"aci#n
objetivo.
R(5/")"*,)1 Este es uno de los flujos de trabajo m6s importantes, por!ue en l se
establece !u tiene !ue hacer exactamente el sistema !ue construamos. En
esta lnea los re!uisitos son el contrato !ue se debe cumplir, de modo !ue los
usuarios finales tienen !ue comprender aceptar los re!uisitos !ue
especifi!uemos.
1os objetivos del flujo de datos Re!uisitos es7
Establecer mantener un acuerdo entre clientes otros stakeholders sobre
lo !ue el sistema podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los re!uisitos del
sistema.
<efinir el 6mbito del sistema.
Proveer una base para la planeaci#n de los contenidos tcnicos de las
iteraciones.
Proveer una base para estimar costos tiempo de desarrollo del sistema.
<efinir una interfa" de usuarios para el sistema, enfocada a las necesidades
metas del usuario.
A#<'")") = D")(>,1 El objetivo de este flujo de trabajo es traducir los re!uisitos a
una especificaci#n !ue describe c#mo implementar el sistema.
1os objetivos del an6lisis dise*o son7
2ransformar los re!uisitos al dise*o del futuro sistema.
<esarrollar una ar!uitectura para el sistema.
;daptar el dise*o para !ue sea consistente con el entorno de
implementaci#n, dise*ando para el rendimiento.
El an6lisis consiste en obtener una visi#n del sistema !ue se preocupa de ver !u
hace, de modo !ue s#lo se interesa por los re!uisitos funcionales. Por otro lado el
dise*o es un refinamiento del an6lisis !ue tiene en cuenta los re!uisitos no
funcionales, en definitiva c#mo cumple el sistema sus objetivos.
I7%'(7(#*&$"9#1 En este flujo de trabajo se implementan las clases objetos en
ficheros fuente, binarios, ejecutables dem6s. ;dem6s se deben hacer las
pruebas de unidad7 cada implementador es responsable de probar las unidades
!ue produ"ca. El resultado final de este flujo de trabajo es un sistema ejecutable.
En cada iteraci#n habr6 !ue hacer lo siguiente7
Planificar !u subsistemas deben ser implementados en !ue orden deben
ser integrados, formando el Plan de %ntegraci#n.
0ada implementador decide en !ue orden implementa los elementos del
subsistema.
)i encuentra errores de dise*o, los notifica.
)e prueban los subsistemas individualmente.
)e integra el sistema siguiendo el plan.
1a estructura de todos los elementos implementados forma el modelo de
implementaci#n. 1a integraci#n debe ser incremental, es decir, en cada momento
s#lo se a*ade un elemento. <e este modo es m6s f6cil locali"ar fallos los
componentes se prueban m6s a fondo. En fases tempranas del proceso se
pueden implementar prototipos para reducir el riesgo. )u utilidad puede ir desde
ver si el sistema es viable desde el principio, probar tecnologas o dise*ar la
interfa" de usuario. 1os prototipos pueden ser exploratorios $desechables( o
evolutivos. Estos +ltimos llegan a transformarse en el sistema final.
P!/(2&)1 Este flujo de trabajo es el encargado de evaluar la calidad del producto
!ue estamos desarrollando, pero no para aceptar o recha"ar el producto al final
del proceso de desarrollo, sino !ue debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. )us objetivos son7
Encontrar documentar defectos en la calidad del software.
Eeneralmente asesora sobre la calidad del software percibida.
Provee la validaci#n de los supuestos reali"ados en el dise*o
especificaci#n de re!uisitos por medio de demostraciones concretas.
Gerificar las funciones del producto de software seg+n lo dise*ado.
Gerificar !ue los re!uisitos tengan su apropiada implementaci#n.
D()%'"(./(1 El objetivo de este flujo de trabajo es producir con xito
distribuciones del producto distribuirlo a los usuarios. 1as actividades implicadas
incluen7
Probar el producto en su entorno de ejecuci#n final.
Empa!uetar el software para su distribuci#n.
<istribuir el software.
%nstalar el software.
Proveer asistencia auda a los usuarios.
3ormar a los usuarios al cuerpo de ventas.
'igrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con maor intensidad en la fase de transici#n, a
!ue el prop#sito del flujo es asegurar una aceptaci#n adaptaci#n sin
complicaciones del software por parte de los usuarios. )u ejecuci#n inicia en fases
anteriores, para preparar el camino, sobre todo con actividades de planificaci#n,
en la elaboraci#n del manual de usuario tutoriales.
G()*"9# -(' %!,=($*,1 1a Eesti#n del proecto es el arte de lograr un balance al
gestionar objetivos, riesgos restricciones para desarrollar un producto !ue sea
acorde a los re!uisitos de los clientes los usuarios.
1os objetivos de este flujo de trabajo son7
Proveer un marco de trabajo para la gesti#n de proectos de software
intensivos.
Proveer guas pr6cticas reali"ar planeaci#n, contratar personal, ejecutar
monitorear el proecto.
Proveer un marco de trabajo para gestionar riesgos.
1a planeaci#n de un proecto posee dos niveles de abstracci#n7 un plan para las
fases un plan para cada iteraci#n.
C,#8"./!&$"9# = $,#*!,' -( $&72",)1 1a finalidad de este flujo de trabajo es
mantener la integridad de todos los artefactos !ue se crean en el proceso, as
como de mantener informaci#n del proceso evolutivo !ue han seguido.
E#*,!#,1 1a finalidad de este flujo de trabajo es dar soporte al proecto con las
adecuadas herramientas, procesos mtodos. &rinda una especificaci#n de las
herramientas !ue se van a necesitar en cada momento, as como definir la
instancia concreta del proceso !ue se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluen7
)elecci#n ad!uisici#n de herramientas
Establecer configurar las herramientas para !ue se ajusten a la
organi"aci#n.
0onfiguraci#n del proceso.
'ejora del proceso.
)ervicios tcnicos.