ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

PROCESO UNIFICADO DE
DESARROLLO (RUP)
El Proceso Unificado es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente
propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML,
constituye la metodologa estndar ms utilizada para el anlisis,
diseo, implementacin y documentacin de sistemas orientados a
objetos.
HISTORIA.
Los orgenes de RUP se remontan al modelo en espiral original de
Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP
colabor con Boehm en la investigacin. En 1995 Rational Software
compr una compaa sueca llamada Objectory AB, fundada por Ivar
Jacobson, famoso por haber incorporado los casos de uso a los
mtodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y
Objectory (el proceso de la empresa Objectory AB). El primer
resultado de esta fusin fue el Rational Objectory Process, la primera
versin de RUP, fue puesta en el mercado en 1998, siendo el
arquitecto en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado "The Unified
Software Development Process (ISBN 0-201-57169-2)" El Proceso
Unificado de Desarrollo de Software (ISBN 0-201-57169-2), y
publicado en 1999 por Ivar Jacobson, Grady Booch y James
Rumbaugh.

CICLO DE VIDA.
El Proceso Unificado es un proceso de software genrico que puede
ser utilizado para una gran cantidad de tipos de sistemas de software,
para diferentes reas de aplicacin, diferentes tipos de
organizaciones, diferentes niveles de competencia y diferentes
tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y
responsabilidades dentro de una organizacin de desarrollo. Su meta
es asegurar la produccin de software de muy alta calidad que
satisfaga las necesidades de los usuarios finales, dentro de un
calendario y presupuesto predecible.
El ciclo de vida del RUP organiza las tareas en dos dimensiones:

ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

Un eje horizontal que representa el tiempo y muestra los

aspectos del ciclo de vida del proceso a lo largo de su
desenvolvimiento
Un eje vertical que representa las disciplinas, las cuales
agrupan actividades de una manera lgica de acuerdo a su
naturaleza.
La primera dimensin representa el aspecto dinmico del proceso
conforme se va desarrollando, se expresa en trminos de fases,
iteraciones e hitos (milestones).
La segunda dimensin representa el aspecto esttico del proceso:
cmo es descrito en trminos de componentes del proceso,
disciplinas, actividades, flujos de trabajo, artefactos y roles.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en nmero variable segn el proyecto y en las que
se hace un mayor o menor hincapi en las distintas actividades. En la
Figura muestra cmo vara el esfuerzo asociado a las disciplinas
segn la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se
enfocan hacia la comprensin del problema y la tecnologa, la
delimitacin del mbito del proyecto, la eliminacin de los riesgos
crticos, y al establecimiento de una baseline (Lnea Base) de la
arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en
actividades de modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de
la baseline de la arquitectura, abarcan ms los flujos de trabajo de
requisitos, modelo de negocios (refinamiento), anlisis, diseo y una
parte de implementacin orientado a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del
producto por medio de una serie de iteraciones. Para cada iteracin
se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y
se procede a su implementacin y pruebas. Se realiza una pequea
cascada para cada ciclo. Se realizan iteraciones hasta que se termine
la implementacin de la nueva versin del producto.
En la fase de transicin se pretende garantizar que se tiene un
producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas,
pero dependiendo de la fase el esfuerzo dedicado a una disciplina
vara.

ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

PRINCIPIOS DE DESARROLLO
El RUP est basado en 6 principios clave que son los siguientes:

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

1. ADAPTAR EL PROCESO: El proceso de la adaptacin del

software.
2. EQUILIBRAR PRIORIDADES: Los requisitos de los diversos
participantes pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un equilibrio
que satisfaga los deseos de todos. Gracias a este equilibrio se
podrn corregir desacuerdos que surjan en el futuro.
3. DEMOSTRAR VALOR ITERATIVAMENTE: Los proyectos se
entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la
estabilidad y calidad del producto, y se refina la direccin del
proyecto as como tambin los riesgos involucrados.
4. COLABORACIN ENTRE EQUIPOS: El desarrollo de software
no lo hace una nica persona sino mltiples equipos. Debe
haber una comunicacin fluida para coordinar requisitos,
desarrollo, evaluaciones, planes, resultados, etc.
5. ELEVAR EL NIVEL DE ABSTRACCIN: Este principio
dominante motiva el uso de conceptos reutilizables tales como
patrn del software, lenguajes 4GL o marcos de referencia
(frameworks) por nombrar algunos. Esto evita que los
ingenieros de software vayan directamente de los requisitos a la
codificacin de software a la medida del cliente, sin saber con
certeza qu codificar para satisfacer de la mejor manera los
requisitos y sin comenzar desde un principio pensando en la
reutilizacin del cdigo. Un alto nivel de abstraccin tambin
permite discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con el
lenguaje UML.
6. ENFOCARSE EN LA CALIDAD: El control de calidad no debe
realizarse al final de cada iteracin, sino en todos los aspectos
de la produccin. El aseguramiento de la calidad forma parte
del proceso de desarrollo y no de un grupo independiente.
CARACTERSTICAS RELEVANTES DEL RUP
DIRIGIDO POR CASOS DE USO (USE-CASE DRIVEN).
Un sistema de software se crea para servir a sus usuarios. Por lo
tanto, para construir un sistema exitoso se debe conocer qu es
lo que quieren y necesitan los usuarios prospectos. El trmino
usuario se refiere no solamente a los usuarios humanos, sino a
otros sistemas. En este contexto, el trmino usuario representa
algo o alguien que interacta con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que
le da al usuario un resultado de valor. Los casos de uso capturan
los requerimientos funcionales. Todos los casos de uso juntos

ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

constituyen el modelo de casos de uso el cual describe la

funcionalidad completa del sistema. Este modelo reemplaza la
tradicional
especificacin
funcional
del
sistema.
Una
especificacin funcional tradicional se concentra en responder
la pregunta: Qu se supone que el sistema debe hacer? La
estrategia de casos de uso puede ser definida agregando tres
palabras al final de la pregunta: por cada usuario? Estas tres
palabras tienen una implicacin importante, nos fuerzan a
pensar en trminos del valor a los usuarios y no solamente en
trminos de las funciones que sera bueno que tuviera. Sin
embargo, los casos de uso no son solamente una herramienta
para especificar los requerimientos del sistema, tambin dirigen
su diseo, implementacin y pruebas, esto es, dirigen el
proceso de desarrollo.
An y cuando los casos de uso dirigen el proceso, no son
elegidos de manera aislada. Son desarrollados a la par con la
arquitectura del sistema, esto es, los casos de uso dirigen la
arquitectura del sistema y la arquitectura del sistema influencia
la eleccin de los casos de uso. Por lo tanto, la arquitectura del
sistema y los casos de uso maduran conforme avanza el ciclo
de vida.
CENTRADO EN LA ARQUITECTURA (ARCHITECTURECENTRIC).
El concepto de arquitectura de software involucra los aspectos
estticos y dinmicos ms significativos del sistema. La
arquitectura surge de las necesidades de la empresa, tal y
como las interpretan los usuarios y otros stakeholders (personas
o entidades interesadas en la realizacin de un proyecto o
tarea), y tal y como estn reflejadas en los casos de uso. Sin
embargo, tambin est influenciada por muchos otros factores,
tales como la plataforma de software en la que se ejecutar, la
disponibilidad de componentes reutilizables, consideraciones de
instalacin, sistemas legados, requerimientos no funcionales. La
arquitectura es la vista del diseo completo con las
caractersticas ms importantes hechas ms visibles y dejando
los detalles de lado. Ya que lo importante depende en parte del
criterio, el cual a su vez viene con la experiencia, el valor de la
arquitectura depende del personal asignado a esta tarea. Sin
embargo, el proceso ayuda al arquitecto a enfocarse en las
metas correctas, tales como claridad (understandability),
flexibilidad en los cambios futuros (resilience) y reuso.
He aqu donde surge la pregunta: Cmo se relacionan los casos
de uso con la arquitectura?, cada producto tiene funcin y
forma. Uno slo de los dos no es suficiente. Estas dos fuerzas
deben estar balanceadas para obtener un producto exitoso. En
este caso funcin corresponde a los casos de uso y forma a la
arquitectura. Existe la necesidad de intercalar entre casos de

ALUMNO: Antonio Banda Corona

MATERIA: Fundamentos de Ingeniera de Software

SECUENCIA: 2NM41
FECHA: 19-Febrero-14

uso y arquitectura. Por una parte, los casos de uso deben,

cuando son realizados, acomodarse en la arquitectura, y del
mismo modo la arquitectura debe proveer espacio para la
realizacin de todos los casos de uso, hoy y en el futuro. En la
realidad, ambos arquitectura y casos de uso deben evolucionar
en paralelo.
ITERATIVO E INCREMENTAL.
Desarrollar un producto de software comercial es una tarea
enorme que puede continuar por varios meses o aos, es por
eso que se considera ms prctico dividir el trabajo en
pequeos pedazos o mini-proyectos, a los cuales se les conoce
como iteracin y que finalizan en un incremento. Las iteraciones
se refieren a pasos en el flujo de trabajo, los incrementos se
refieren a crecimiento en el producto. Para ser ms efectivo, las
iteraciones deben estar controladas, esto es, deben ser
seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su seleccin de qu van a
implementar en una iteracin en dos factores. Primero, la
iteracin trata con un grupo de casos de uso que en conjunto
extienden la usabilidad del producto. Segundo, la iteracin trata
con los riesgos ms importantes. Las iteraciones sucesivas
construyen los artefactos del desarrollo a partir del estado en el
que fueron dejados en la iteracin anterior.
En cada iteracin, los desarrolladores identifican y especifican
los casos de uso relevantes, crean el diseo usando la
arquitectura como gua, implementan el diseo en
componentes y verifican que los componentes satisfagan los
casos de uso. Si una iteracin cumple sus metas el desarrollo
contina con la siguiente iteracin. Cuando la iteracin no
cumple con sus metas, los desarrolladores deben revisar sus
decisiones previas y probar un nuevo enfoque.
CONCLUSIN
Finalmente se puede concluir que las caractersticas del RUP (casos
de uso, centrado en arquitectura, desarrollo iterativo e incremental),
son igual de importantes, ya que la arquitectura provee la estructura
sobre la cual guiar el trabajo en iteraciones, mientras que los casos
de uso definen las metas y dirigen el trabajo en cada iteracin. De
este modo nos damos cuenta que remover cualquiera de estos 3
conceptos reducir severamente el valor del RUP.