INDICE

PROCESO UNIFICADO RACIONAL .................................................................................................. 4

HISTORIA: .................................................................................................................................. 4
DEFINICIONES: ........................................................................................................................... 4
CARACTERÍSTICAS:..................................................................................................................... 4
PRINCIPIOS DE DESARROLLO: ................................................................................................... 5
Adaptar el proceso: ............................................................................................................... 5
Equilibrar prioridades ............................................................................................................ 5
Demostrar valor iterativamente ........................................................................................... 5
Colaboración entre equipos .................................................................................................. 6
Enfocarse en la calidad .......................................................................................................... 6
BLOQUES DE CONSTRUCCIÓN RUP: .......................................................................................... 6
Roles ...................................................................................................................................... 6
Los productos de trabajo ...................................................................................................... 6
Tareas .................................................................................................................................... 6
FASES: ........................................................................................................................................ 6
FASE DE INICIO: ..................................................................................................................... 7
FASE DE ELABORACION: ........................................................................................................ 8
FASE DE CONSTRUCCION: ................................................................................................... 10
LA FASE DE TRANSICION:..................................................................................................... 11
CICLO DE VIDA: ........................................................................................................................ 12
Estructura del proceso ........................................................................................................ 12
Ventajas ................................................................................................................................... 12
Desventajas ............................................................................................................................. 13
CONCLUSIONES ........................................................................................................................... 14
E- GRAFÍA..................................................................................................................................... 15

2
 INTRODUCION

Uno de los retos iniciales para el desarrollo de software es inclinarse o adoptar una
metodología que se adapte a las necesidades u objetivos que se plantean para la creación
de aplicaciones.

RUP (Proceso Unificado Racional) es una muy buena opción para que se tome
como referencia, unas fuentes lo definen como un conjunto de metodologías, también
como proceso y otros simplemente una metodología, cual sea el caso RUP está dirigido
por los casos de usos, centrados en la arquitectura, iterativo e incremental.

“En lo referente a dirigido por los casos de uso, significa que los requerimientos
están enfocado a dar valor al cliente y que el proceso debe garantizar que todo el
desarrollo, pruebas, planeación, documentación, está orientado a cubrir estas
expectativas del cliente y asegurar que los requerimientos de valor se ponen en
producción.

En lo referente a centrado en arquitectura, significa que hay un énfasis a diseñar

una arquitectura de calidad, y es la arquitectura también la que guía la forma cómo se
debe planear y hacer el desarrollo.

En lo referente a iterativo e incremental, significa que el proyecto se divide en

varios ciclos de vida (llamadas iteraciones) que deben dar como resultado un ejecutable.
Por cada una de las iteraciones se va agregando requerimientos y sobre todo valor al
cliente; por este motivo es incremental”.

Considerando el logro de esta metodología es importante mencionar que su fama

y buen desempeño se debe a que se integran mas metodologías como el espiral y
cascada, combinado con prototipos.

3
 PROCESO UNIFICADO RACIONAL
Rational Unified Process
RUP
HISTORIA:

“El antecedente más importante se ubica en 1967 con la Metodología Ericsson

(Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo
basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de
1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo
Objectory (abreviación de Object Factory).”

“Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm.

Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de
uso a los métodos 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 fusión fue el Rational Objectory
Process, la primera versión 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.”

DEFINICIONES:
- Es un proceso de desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM.

- Es una metodología cuyo fin es entregar un producto de software, además de

que se estructuran todos los procesos y se mide la eficiencia de la organización.

- Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de

modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.

- Es un conjunto de metodologías adaptables al contexto y necesidades de cada

organización.

- En realidad RUP no es sólo un proceso, sino un Framework con guías para

implementar buenas y ágiles prácticas de desarrollo, las cuales se adaptan o
customizan a la empresa.

CARACTERÍSTICAS:

- Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo
unos pasos para su realización.

- Se centra en la producción y mantenimiento de modelos del sistema.

4
 - Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)

- Pretende implementar las mejores prácticas en Ingeniería de Software

- Desarrollo iterativo

- Administración de requisitos

- Uso de arquitectura basada en componentes

- Control de cambios

- Modelado visual del software

- Verificación de la calidad del software

- Orientado a los casos de uso

- Proceso centrado en la arquitectura

- Proceso iterativo e incremental

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

Adaptar el proceso:

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante
interactuar con él. Las características propias del proyecto. El tamaño del mismo, así
como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico.
También se deberá tener en cuenta el alcance del proyecto.

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 podrán corregir desacuerdos que surjan en el
futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y
se refina la dirección del proyecto así como también los riesgos involucrados.

5
Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe
haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones,
planes, resultados.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los
aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.

BLOQUES DE CONSTRUCCIÓN RUP:

RUP se basa en un conjunto de bloques de construcción y elementos de contenido,

describiendo lo que se va a producir, las habilidades necesarias y la explicación paso a
paso describiendo cómo específica objetivos de desarrollo se quieren lograr.
Los principales bloques de construcción, o elementos de contenido, son los siguientes:

Roles (quien) - Un rol define un conjunto de habilidades relacionadas,

competencias y responsabilidades.

Los productos de trabajo (qué) - Un producto de trabajo representa algo que

resulta de una tarea, incluyendo todos los documentos y modelos producidos
mientras se trabaja a través del proceso.

Tareas (cómo) - Una tarea describe una unidad de trabajo asignada a una
función que proporciona un resultado significativo.

Dentro de cada iteración, las tareas se clasifican en nueve disciplinas:

- Seis disciplinas de la ingeniería (Proceso)
· Modelado de negocios
· Requerimientos
· Análisis y diseño
· Implementación
· Prueba
· Despliegue

- Tres disciplinas de apoyo (Soporte)

· Gestión de la configuración y el cambio
· Gestión de proyectos
· Medio ambiente (entorno)

FASES:

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas
anteriormente:

6
· Inicio (también llamado Incepción o Concepción).
· Elaboración.
· Desarrollo (también llamado Implementación, Construcción).
· Cierre (también llamado Transición).

FASE DE INICIO:

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de

modelado del negocio y de requisitos.
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más
esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de
negocio para determinar que recursos deben ser asignados al proyecto.

- Documento Visión
- Diagramas de caso de uso
- Especificación de Requisitos
- Diagrama de Requisitos

Los objetivos de esta fase son:

- Establecer el ámbito del proyecto y sus límites.
- Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que
definen la funcionalidad.
- Mostrar al menos una arquitectura candidata para los escenarios principales.
- Estimar el coste en recursos y tiempo de todo el proyecto.
- Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase de inicio deben ser:

- Un documento de visión: Una visión general de los requerimientos del proyecto,
características clave y restricciones principales.
- Modelo inicial de Casos de Uso (10-20% completado).
- Un glosario inicial: Terminología clave del dominio.
- El caso de negocio.
- Lista de riesgos y plan de contingencia.
- Plan del proyecto, mostrando fases e iteraciones.
- Modelo de negocio, si es necesario
- Prototipos exploratorios para probar conceptos o la arquitectura candidata.

7
Al terminar la fase de inicio se deben comprobar los criterios de evaluación para
continuar:
- Todos los interesados en el proyecto coinciden en la definición del ámbito del
sistema y las estimaciones de agenda.
- Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de
Uso principales.
- Las estimaciones de tiempo, coste y riesgo son creíbles.
- Comprensión total de cualquier prototipo de la arquitectura desarrollado.
- Los gastos hasta el momento se asemejan a los planeados.

Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo

profundamente.

FASE DE ELABORACION:

En la fase de elaboración, las iteraciones se orientan al desarrollo de la línea de

base de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de
negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la
baseline (línea base) de la arquitectura.
Se seleccionan los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso
seleccionados y el primer análisis del dominio del problema, se diseña la solución
preliminar.

El propósito de la fase de elaboración es analizar el dominio del problema,

establecer los cimientos de la arquitectura, desarrollar el plan del proyecto. En esta fase
se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones
sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos
de Uso críticos identificados en la fase de inicio. También debe demostrarse que se han
evitado los riesgos más graves.

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

o Diagrama de clases
o Modelo E-R (Si el sistema así lo requiere)

Vista de Implementación

o Diagrama de Secuencia
o Diagrama de estados
o Diagrama de Colaboración

8
Vista Conceptual

o Modelo de dominio
Vista física

o Mapa de comportamiento a nivel de hardware.

o Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
o Pruebas de los casos de uso desarrollados, que demuestran que la
arquitectura documentada responde adecuadamente a requerimientos
funcionales y no funcionales.

Los objetivos de esta fase son:

- Definir, validar y cimentar la arquitectura.
- Completar la visión.
- Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en
sucesivas iteraciones. Debe incluir los costes si procede.
- Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.

Al terminar deben obtenerse los siguientes resultados:

- Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y
actores identificados, la mayoría de los casos desarrollados.
- Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso específico.
- Descripción de la arquitectura software.
- Un prototipo ejecutable de la arquitectura.
- Lista de riesgos y caso de negocio revisados.
- Plan de desarrollo para el proyecto.
- Un caso de desarrollo actualizado que 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

mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos
importantes.
En la fase de elaboración se actualizan todos los productos de la fase de inicio.
Los criterios de evaluación de esta fase son los siguientes:
- La visión del producto es estable.
- La arquitectura es estable.
- Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
- El plan para la fase de construcción es detallado y preciso. Las estimaciones son
creíbles.
- Todos los interesados coinciden en que la visión actual será alcanzada si se
siguen los planes actuales en el contexto de la arquitectura actual.

9
 - Los gastos hasta ahora son aceptables, comparados con los previstos.

Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto o

replanteárselo considerablemente.

FASE DE CONSTRUCCION:

Aquí se lleva a cabo la construcción del producto por medio de una serie de
iteraciones. Para cada iteración se seleccionan algunos Casos de Uso, se refinan su
análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación
de la nueva versión del producto.
El propósito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto
Se alcanza la capacidad operacional del producto de forma incremental a través de
las sucesivas iteraciones. Durante esta fase todos los componentes, características y
requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo
una versión aceptable del producto.

- Especificación de requisitos faltantes

- Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación
iterativa
- Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el
caso

Los objetivos concretos según incluyen:

- Minimizar los costes de desarrollo mediante la optimización de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
- Conseguir una calidad adecuada tan rápido como sea práctico.
- Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan
rápido como sea práctico.

Los resultados de la fase de construcción deben ser:

- Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e
Implementación)
- Arquitectura íntegra (mantenida y mínimamente actualizada)
- Riesgos Presentados Mitigados
- Plan del Proyecto para la fase de Transición.
- Manual Inicial de Usuario (con suficiente detalle)
- Prototipo Operacional – beta
- Caso del Negocio Actualizado

Los criterios de evaluación de esta fase son los siguientes:

10
 - El producto es estable y maduro como para ser entregado a la comunidad de
usuario para ser probado.
- Todos los usuarios expertos están listos para la transición en la comunidad de
usuarios.
- Son aceptables los gastos actuales versus los gastos planeados.

LA FASE DE TRANSICION:

Se pretende garantizar que se tiene un producto preparado para su entrega a la

comunidad de usuarios.
El propósito de esta fase es asegurar que el software esté disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación,
capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el
producto cumpla con las especificaciones entregadas por las personas involucradas en el
proyecto.
Se pone el producto en manos de los usuarios finales, para lo que se requiere
desarrollar nuevas versiones actualizadas del producto, completar la documentación,
entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el
ajuste, configuración, instalación y facilidad de uso del producto.

- Pruebas finales de aceptación

- Puesta en producción
- Estabilidad

En se citan algunas de las cosas que puede incluir esta fase:

- Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas
de los usuarios
- Funcionamiento paralelo con los sistemas legados que están siendo sustituidos
por nuestro proyecto.
- Conversión de las bases de datos operacionales.
- Entrenamiento de los usuarios y técnicos de mantenimiento.
- Traspaso del producto a los equipos de marketing, distribución y venta.
Los principales objetivos de esta fase son:
- Conseguir que el usuario se valga por si mismo.
- Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario.
Los resultados de la fase de transición son:
- Prototipo Operacional
- Documentos Legales
- Caso del Negocio Completo
- Línea de Base del Producto completa y corregida que incluye todos los modelos
del sistema
- Descripción de la Arquitectura completa y corregida

11
 - Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión.

Los criterios de evaluación de esta fase son los siguientes:

- El usuario se encuentra satisfecho.
- Son aceptables los gastos actuales versus los gastos planificados.

CICLO DE VIDA:
Estructura del proceso
El proceso puede ser descrito en dos dimensiones o ejes:
Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos
dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado
en términos de fases, iteraciones e hitos. Se puede observar en la Figura 8 que RUP
consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se
mencionó anteriormente cada fase se subdivide a la vez en iteraciones.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso
en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades,
artefactos y roles.

Ventajas

RUP posee un amplio y potente Framework de desarrollo, el cual tiene tres

características principales: Esta orientado a los casos de uso, está centrado en la
arquitectura y es iterativo e incremental.
- RUP es un proceso ampliamente difundido y usado en la industria del Software.
- Existe compatibilidad entre la ISO/IEC 12207 y RUP.
- Está basada totalmente en mejoras practicas de la metodología:
- Reduce riesgos del proyecto.

12
 - Incorpora fielmente el objetivo de calidad.
- Integra desarrollo con mantenimiento.

Desventajas

A pesar de poseer un amplio y potente framework de desarrollo de software,

RUP está enfocado sólo a este proceso en sí. No contempla procesos de adquisición, ni
compra, los cuales son procesos principales dentro de Gauss Global.
- Pretende prever y tener todo el control de antemano:
- Modelo genera trabajo adicional.
- Genera muchos costos.
- No recomendable para proyectos pequeños.

13
 CONCLUSIONES

- El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto

de metodologías adaptables al contexto y necesidades de cada organización.
- Conlleva trabajo extra en controlar que la metodología lleve un orden lógico y se
vea el avance en el proyecto a desarrollar.
- Para implementar esta metodología es necesario conocer otras que influyen
como el método de cascada, espiral, prototipos.
- No se sugiera para proyectos pequeños.

14
 E- GRAFÍA

- http://www.extremeprogramming.org/

- http://es.tldp.org/Presentaciones/200211hispalinux/gregorio2/progm-ext-soft-

libre-html/

- http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

- https://pid.dsic.upv.es

15