RATIONAL UNIFIED PROCESS (RUP)

PROCESO UNIFICADO RATIONAL

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro
de una organización de desarrollo.
Fases
Las cuatro fases del ciclo de vida son:
Ø Concepción
Ø Elaboración
Ø Construcción
Ø Transición

Ventajas
Ø Evaluación en cada fase que permite cambios de objetivos
Ø Funciona bien en proyectos de innovación.
Ø Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
Ø Seguimiento detallado en cada una de las fases.

Desventajas
Ø La evaluación de riesgos es compleja
Ø Excesiva flexibilidad para algunos proyectos
Ø Estamos poniendo a nuestro cliente en una situación que puede ser muy incómoda para él.
Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance
del proyecto con él.
Modelo RUP
¿Qué es RUP?
Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las
tareas y responsabilidades de una organización que desarrolla software.
Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades
de los usuarios, con una planeación y presupuesto predecible.

¿Para quién es RUP?

Diseñado para:
–Profesionales en el desarrollo de software.
–Interesados en productos de software.
–Profesionales en la ingeniería y administración de procesos de software.

¿Por qué usar RUP?

–Provee un entorno de proceso de desarrollo configurable, basado en estándares.
–Permite tener claro y accesible el proceso de desarrollo que se sigue.
–Permite ser configurado a las necesidades de la organización y del proyecto.
–Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto.

Características
 Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el
comportamiento deseado del sistema
 Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar y
evolucionar el sistema en desarrollo
 Iterativo e Incremental:
–Maneja una serie de entregas ejecutables
–Integra continuamente la arquitectura para producir nuevas versiones mejoradas
 Conceptualmente amplio y diverso
 Enfoque orientado a objetos
 En evolución continua
 Adaptable
 Repetible
 Permite mediciones:
–Estimación de costos y tiempo, nivel de avance, etc.

Ciclo de Vida y sus Faces

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con
un producto intermedio.
Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la
misma.
Las fases son:
 Inicio (Inception)
 Elaboración
 Construcción
 Transición.

Inicio (Inception)
 El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los
objetivos del proyecto.
 Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar
los riesgos relacionados con el negocio y requerimientos.
 Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la
viabilidad de desarrollar el proyecto.

Elaboración
 El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables
para el esfuerzo de diseño e implementación en la siguiente fase.
 La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una
evaluación del riesgo.

Construcción
 El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el
desarrollo del sistema basados en la arquitectura base.
 Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la
administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.

Transición
 Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.
 Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el
entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el
usuario.
 En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones,
instalación y aspectos sobre utilización.
¿Cuándo usar RUP?

 RUP puede utilizarse:

–En proyectos de nuevos productos de software
–En ciclos de desarrollo subsecuentes
 Consideraciones que alteran cuándo y cómo usar partes de RUP:
–El ciclo de vida del proyecto
–Los objetivos del negocio, la visión, el alcance y los riesgos
–El tamaño del esfuerzo de desarrollo
Metodología de Desarrollo Tradicional
RUP
El Proceso Unificado de Rational o RUP (por sus siglas en inglés de Rational Unified
Process) es un proceso de desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM.1 Junto con el Lenguaje Unificado de
Modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño,
implementación y documentación de sistemas orientados a objetos.
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. También se conoce
por este nombre al software, también desarrollado por Rational, que incluye información
entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido
en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las
necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y
una especificación más detallada, el Rational Unified Process, que se vendiera como
producto independiente.

Principios de desarrollo[editar]
La Filosofía del RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso[editar]
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[editar]
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe poder encontrarse un equilibrio que satisfaga los deseos de todos.
Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro. Al igual esta
metodología está acorde con UML, Unificado Modelo Lenguajes'

Demostrar valor iterativamente[editar]

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.

Colaboración entre equipos[editar]

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, etc.
Enfocarse en la calidad[editar]
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, también es una estrategia de desarrollo de software.

Elevar el nivel de abstracción[editar]

Artículo principal: Abstracción (informática)

Este principio dominante motiva el uso de conceptos reutilizables tales como patrones de
diseño del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Estos se
pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

Ciclo de vida[editar]

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan pocas pero
grandes y formales iteraciones en número variable según el proyecto. En la Figura
muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se
encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una baseline (línea base)2 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 elaboración, las iteraciones se orientan al desarrollo de la baseline 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 de la
arquitectura.
En la fase de construcción, 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.
En la fase de transición 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 varía.

Principales características[editar]
 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
 Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se
adapte a cualquier proyecto
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).

Fases[editar]
 Establece oportunidad y alcance
 Identifica las entidades externas o actores con las que se trata
 Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
Proceso
Las etapas de esta sección son: (revisar nuevamente la gráfica)

 Modelado de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
 Despliegue
Soporte
En esta parte nos encontramos con las siguientes etapas:

 Gestión del cambio y configuraciones

 Gestión del proyecto
 Entorno
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 cuatro
fases descritas anteriormente:

1. Inicio (también llamado Incepción o Concepción).

2. Elaboración.
3. Desarrollo (también llamado Implementación, Construcción).
4. Cierre (también llamado Transición).
Fase de Inicio[editar]
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores o alumnos de un proyecto en el cual tenemos que, 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.

Fase de Elaboración[editar]
En la fase de elaboración 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.

Fase de Desarrollo[editar]
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.

Fase de Transición[editar]
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.

Artefactos[editar]
RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una
serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño
del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio[editar]
 Documento Visión.
 Diagramas de caso de uso.
 Especificación de Requisitos.
 Diagrama de Requisitos.
Elaboración[editar]
 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
Vista Conceptual

o Modelo de dominio
Vista física

o Mapa de comportamiento a nivel de hardware.

 Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
 Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.
Construcción[editar]
 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
Transición[editar]
 Pruebas finales de aceptación
 Puesta en producción
 Estabilización

Historia[editar]
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
Process3
En 2006, IBM creó un subconjunto de RUP ajustado para proyectos de desarrollo
ágil - publicado como un método libre, llamado OpenUP a través del sitio de Eclipse.4
Comentarios sobre Método[editar]
Por otro lado, en lo que se refiere a la metodología esta comprende tres principios
claves: Dirigido por los casos de uso, centrado en la arquitectura, iterativo e
incremental.
En lo referente a "dirigido por los casos de uso", significa que los requerimientos están
enfocados a dar valor al cliente y que el proceso debe garantizar que todo el
desarrollo, pruebas, planificación, documentación, etc., 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..
Introducción
¿Qué es una metodología?
Es un conjunto de métodos, principios y reglas que permiten enfrentar de manera sistemática el
desarrollo de un programa que resuelve un problema algorítmico. Estas metodologías
generalmente se estructuran como una secuencia de pasos que parten de la definición del
problema y culminan con un programa que lo resuelve.
Rational Unified Process (RUP)
Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado
para asignar tareas y responsabilidades dentro de una organización del desarrollo. Su meta es
asegurar la producción del software de alta calidad que resuelve las necesidades de los usuarios
dentro de un presupuesto y tiempo establecidos.

Dimensiones del RUP

El RUP tiene dos dimensiones:

 La primera dimensión (eje horizontal) representa el aspecto dinámico del proceso
y se expresa en términos de fases, iteraciones y la finalización de las fases.
La segunda dimensión (eje vertical) representa el aspecto estático del proceso:
cómo se describe en términos de componentes de proceso, disciplinas,
actividades, flujos de trabajo, artefactos, y los roles.

Características principales
El RUP contiene tres características principales:

Proceso dirigido por Casos de Uso

Según Kruchten Philippe (2000), “los Casos de Uso son una técnica de captura
de requisitos que fuerza a pensar en términos de importancia para el usuario y no
sólo en términos de funciones que sería bueno contemplar.
Se define un caso de uso como un fragmento de funcionalidad del sistema que
proporciona al usuario un valor añadido. Los Casos de Uso representan los
requisitos funcionales del sistema”.

Los casos de uso no son sólo una herramienta para especificar los requisitos del
sistema, sino que también guían su diseño, implementación y prueba. Los casos
de uso constituyen un elemento integrador y una guía del trabajo.

Los casos de uso Inician el proceso de desarrollo y proporcionan un hilo

conductor, permitiendo establecer trazabilidad entre los artefactos que son
generados en las diferentes actividades del proceso de desarrollo.
Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego
la implementación que los lleva a cabo, y se verifica que efectivamente el producto
implemente adecuadamente cada caso de uso.

Proceso centrado en la arquitectura

La arquitectura de un sistema es la organización o estructura de sus partes más
relevantes, lo que permite tener una visión común entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.

En el caso de RUP, además de utilizar los casos de uso para guiar el proceso, se
presta especial atención al establecimiento temprano de una buena arquitectura
que no se vea fuertemente impactada ante cambios posteriores durante la
construcción y el mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso
deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe
permitir el desarrollo de todos los casos de uso requeridos, actualmente y en el
futuro.
La arquitectura dentro de RUP se representa en varias vistas. Todas las vistas
juntas forman el llamado modelo 4+1 de la arquitectura. Según Kruchten Philippe
(1998) “el cual recibe este nombre porque lo forman las vistas lógica, de
implementación, de proceso y de despliegue, más la de casos de uso que es la
que da cohesión a todas”.

Al final de la fase de elaboración se obtiene una “baseline” (base de referencia) de

la arquitectura donde fueron seleccionados una serie de casos de uso
arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más
importantes, aquellos que son los más importantes para el usuario y aquellos que
cubran las funcionalidades significativas).

Proceso iterativo e incremental

El equilibrio correcto entre los casos de uso y la arquitectura es muy parecido al
equilibrio de la forma y la función en el desarrollo de un producto, lo cual se
consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener
un proceso iterativo e incremental en donde el trabajo se divide en partes más
pequeñas o mini proyectos. Cada mini proyecto se puede ver como una iteración
(un recorrido más o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento en
el producto.

Cada iteración aborda una parte de la funcionalidad total, pasando por todos los
flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza
cuando se termina. Durante la planificación de los detalles de la siguiente
iteración, el equipo también examina cómo afectarán los riesgos que aún quedan
al trabajo en curso. Toda la retroalimentación de la iteración pasada permite
reajustar los objetivos para las siguientes iteraciones. Se continúa con esta
dinámica hasta que se haya finalizado por completo con la versión actual del
producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones (que son una cantidad variable) según el proyecto, y en las que se
hace un mayor o menor hincapié en los distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una “baseline” (base
de referencia) de la arquitectura.

Para cada iteración se escogen algunos casos de uso, se refina su análisis y

diseño, y se procede a su implementación y pruebas. Se realizan tantas
iteraciones hasta que se termine la implementación de la nueva versión del
producto.

En la fase de transición 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, es el esfuerzo
dedicado a una disciplina.
 Fases
El ciclo de vida del software del RUP se descompone en cuatro fases
secuenciales. En cada extremo de una fase se realiza una evaluación para
determinar si los objetivos de la fase se han cumplido. Una vez que la evaluación
obtiene los resultados deseados, se procede a la siguiente fase.

Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce
una nueva versión del producto, cada ciclo está compuesto por fases y cada fase
está compuesta por un número de iteraciones.

1.- Concepción, Inicio o Estudio de oportunidad

Define el ámbito y objetivos del proyecto, además de la funcionalidad y
capacidades del producto.

2.- Elaboración
Tanto la funcionalidad como el dominio del problema se estudian a profundidad.
Se define una arquitectura básica y se planifica el proyecto considerando recursos
disponibles.

3.- Construcción
El producto se desarrolla a través de iteraciones donde cada iteración involucra
tareas de análisis, diseño e implementación Las fases de concepción y
elaboración sólo dieron una arquitectura básica que es refinada aquí de manera
incremental conforme se construye (se permiten cambios en la estructura). Gran
parte del trabajo es programación y pruebas, se documenta tanto el sistema
construido como el manejo del mismo En esta fase se hace una documentación
junto con el producto.

4.- Transición
Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas
de mercadotecnia, empaquetado atractivo, instalación, configuración,
entrenamiento, soporte, mantenimiento, etc.

Los manuales de usuario se completan y refinan con la información anterior.

Ninguna fase es idéntica en términos de tiempo y esfuerzo. Aunque esto varía

significativamente dependiendo del proyecto, un ciclo de desarrollo inicial típico
para un proyecto de tamaño mediano debe anticipar la distribución siguiente del
esfuerzo y horario:
Conforme un proyecto avanza y se intenta mejorar, llega un momento en que el
ciclo (las cuatro fases) debe repetirse. Estos ciclos subsecuentes se llaman los
ciclos de la evolución. Mientras que el producto pasa durante varios ciclos, se
producen las nuevas generaciones.

Esfuerzo respecto de los flujos de trabajo (o disciplinas)

En la imagen posterior del documento se muestra el porcentaje el esfuerzo que se
tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos
porcentajes que se muestran de forma horizontal son para todo el proyecto.

Se puede observar que para la obtención de requisitos en la fase de concepción

se empiezan a conseguir, en la fase de elaboración tiene su auge, y va declinando
en la fase de construcción. Con las demás sucede algo similar en distintas
iteraciones.

Esfuerzo respecto de las fases

 Disciplinas
Las disciplinas son los flujos del trabajo, los cuales son una secuencia de pasos
para la culminación de cada disciplina, estas disciplinas se dividen en dos
grupos: las primarias y las de apoyo. Las primarias son las necesarias para la
realización de un proyecto de software, aunque para proyectos no muy grandes se
pueden omitir algunas; entre ellas se tienen: modelado del negocio,
requerimientos, análisis y diseño, implementación, pruebas y despliegue. Las de
apoyo son las que complementan y brindan mejoras a las primarias y especifican
otras características en la realización de un proyecto de software; entre estas se
tienen: entorno, gestión del proyecto, gestión de configuración y cambios.

Modelado del negocio

Tiene como objetivos comprender la estructura y la dinámica de la organización,
comprender problemas actuales e identificar posibles mejoras, comprender los
procesos del negocio.

Requerimientos
Sus objetivos son: establecer lo que el sistema debe hacer, se definen los límites
del sistema, y una interfaz de usuario. También realiza una estimación del costo y
tiempo de desarrollo.

Análisis y diseño
Define la arquitectura del sistema y tiene como objetivos trasladar requisitos en
especificaciones de implementación, al decir análisis se refiere a transformar CU
(casos de uso) en clases, y al decir diseño se refiere a refinar el análisis para
poder implementar los diagramas de clases de análisis de cada CU, los diagramas
de colaboración de cada CU, el de clases de diseño de cada CU, el de secuencia
de diseño de CU, el de estados de las clases, etc.

Implementación
Tiene como objetivos implementar las clases de diseño como componentes,
asignar los componentes a los nodos, probar los componentes individualmente
(pruebas unitarias) e integrar los componentes en un sistema ejecutable.

Pruebas
Verificar la integración de los componentes (prueba de integración), verificar que
todos los requisitos han sido implementados (pruebas del sistema), asegurar que
los defectos detectados han sido resueltos antes de la distribución.

Despliegue
Sus objetivos son asegurar que el producto está preparado para el cliente, para
proceder a su entrega y recepción por el cliente. En esta disciplina se realizan las
actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo,
distribuirlo e instalarlo, así como la tarea de enseñar al usuario.

Gestión y configuración de cambios

Éste es esencial para controlar el número de artefactos producidos por la cantidad
de personal que trabajan en un proyecto conjuntamente. Los controles sobre los
cambios son de mucha ayuda ya que evitan confusiones costosas, como la
compostura de algo que ya se había arreglado.

Entorno
Esta disciplina se enfoca sobre las actividades necesarias para configurar el
proceso que engloba el desarrollo de un proyecto y describe las actividades
requeridas para el desarrollo de las pautas que apoyan un proyecto.
Su propósito es proveer a la organización que desarrollará el software, un
ambiente en el cual basarse, el cual provee procesos y herramientas para poder
desarrollar el software.

Organización y elementos del RUP

Ya conociendo varias partes del RUP nos concentraremos ahora en los elementos
que lo componen, entre estos se tienen: flujos de trabajo, detalle de los flujos de
trabajo, actores, actividades (o acciones) y artefactos.
Actores o roles
Son los personajes encargados de la realización de las actividades definidas
dentro de los flujos de trabajo de cada una de las disciplinas del RUP

Analistas
- Analista del Proceso del Negocio.
- Diseñador del Negocio.
- Revisor del Modelo del Negocio.
- Revisor de Requerimientos.
- Analista del Sistema.
- Especificador de Casos de Uso.
- Diseñador de Interfaz del Usuario.

Desarrolladores
- Arquitecto.
- Revisor de la Arquitectura.
- Diseñador de Cápsulas.
- Revisor del Código y Revisor del Diseño.
- Diseñador de la Base de Datos.
- Diseñador.
- Implementador y un Integrador.

Probadores Profesionales
- Diseñador de Pruebas.
- Probador.

Encargados
- Encargado de Control del Cambio.
- Encargado de la Configuración.
- Encargado del Despliegue.
- Ingeniero de Procesos.
- Encargado de Proyecto.
- Revisor de Proyecto.
Otros
- Cualquier trabajador.
- Artista Gráfico.
- Stakeholder.
- Administrador del Sistema.
- Escritor técnico.
- Especialista de Herramientas.

Artefactos
Los artefactos son el resultado parcial o final que es producido y usado por los
actores durante el proyecto. Son las entradas y salidas de las actividades,
realizadas por los actores, los cuales utilizan y van produciendo estos artefactos
para tener guías. Un artefacto puede ser un documento, un modelo o un elemento
de modelo.

Conjunto de artefactos:
1.- Modelado del negocio
Capturan y presentan el contexto del negocio del sistema. Los artefactos del
modelado del negocio sirven como entrada y como referencia para los requisitos
del sistema.

2.- Requerimientos
Capturan y presentan la información usada en definir las capacidades requeridas
del sistema.

3.- Análisis y diseño del sistema

Capturan y presenta la información relacionada con la solución a los problemas
que se presentaron en los requisitos fijados.

4.- Implementación
Capturan y presentan la realización de la solución presentada en el análisis y
diseño del sistema.

5.- Pruebas
Los artefactos desarrollados como productos de las actividades de prueba y de la
evaluación son agrupadas por el actor responsable, con el cual se lleva un
conjunto de documentos de información sobre las pruebas realizadas y las
metodologías de pruebas aplicadas.

6.- Despliegue
Capturan y presentan la información relacionada con la transitividad del sistema,
presentada en la implementación en el ambiente de la producción.

7.- Administración del proyecto

Capturan los artefactos asociados con el proyecto, el planeamiento y a la
ejecución del proceso.

8.- Administración de cambios y configuración

Capturan y presentan la información relacionada con la disciplina de configuración
y administración del cambio.
9.- Entorno o ambiente
Presenta los artefactos que se utilizan como dirección a través del desarrollo del
sistema para asegurar la consistencia de todos los artefactos producidos.

Grado de finalización de artefactos

Con grado de finalización nos referimos a cuántos de esos lineamientos del
artefacto hemos completado o llenado, esto en cada una de las disciplinas, de
acorde a la fase en que se. En la fase de concepción, en la disciplina de
implementación del sistema los artefactos tienen una poca finalización y van
aumentando progresivamente en cada fase hasta llegar a su culminación en la
fase de transición.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada

disciplina en la fase dada, teniendo una idea un poco más amplia sobre el
desenvolvimiento del proyecto hablando en términos de sus artefactos.

Desventajas de la metodología:
No capturar un caso de uso a tiempo puede causar una reconstrucción parcial de
la arquitectura.
La falta de especificaciones en los requisitos por parte del usuario puede causar
ciertas discrepancias.

Se requiere mucho personal (dependiendo del proyecto).

Ventajas de la metodología:
Es el proceso de desarrollo más general de los existentes actualmente.
Es una forma disciplinada de asignar tareas y responsabilidades en una empresa
de desarrollo (quién hace qué, cuándo y cómo).
Reutilización

El diseñador piensa en términos del comportamiento de objetos y no

en detalles de bajo nivel

Confiabilidad, Integridad y Estabilidad.

Mantenimiento más sencillo. Modificaciones locales.

Conclusión
La planeación de un proyecto de programación que pretende dar un beneficio en
algún servicio ya existente o en uno nuevo requiere definitivamente de una buena
organización. RUP es eficaz para atacar los asuntos de organización y de
ejecución de un sistema de desarrollo de software. Ayuda a percibir el problema
desde distintos puntos de vista y ahorra el tiempo de demora para un proyecto que
tenga alguna continuidad y necesite modificaciones o adiciones.
 RESUMEN METODOLOGÍA RUP

Nombre
Proceso Racional Unificado
constituye la metodología estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.
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.
Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las
tareas y responsabilidades de una organización que desarrolla software.
Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades
de los usuarios, con una planeación y presupuesto predecible.
de dónde nace
La Figura 1 ilustra la historia de RUP. 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).

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y

1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque
Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde ese entonces y
a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e
incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo
conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

Características (tiene 3 características esenciales, explicarlas)

 Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el
comportamiento deseado del sistema
 Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir,
administrar y evolucionar el sistema en desarrollo
 Iterativo e Incremental:
–Maneja una serie de entregas ejecutables
–Integra continuamente la arquitectura para producir nuevas versiones mejoradas
 Conceptualmente amplio y diverso
 Enfoque orientado a objetos
 En evolución continua
 Adaptable
 Repetible
 Permite mediciones:
–Estimación de costos y tiempo, nivel de avance, etc.
 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
 Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se
adapte a cualquier proyecto
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).

para qué tipo de proyectos se recomienda

 RUP puede utilizarse:
–En proyectos de nuevos productos de software
–En ciclos de desarrollo subsecuentes
 Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de
desarrollo y grandes proyectos , pero el hecho de que es ampliamente personalizable
que permite adaptarse a proyectos de cualquier escala.
https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

http://masteringenieriasoft.blogspot.com/2012/04/metodologias-
de-desarrollo-de-software.html
https://softwarerecopilation.wordpress.com/modelo-rup/

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesRUP.pdf

VOLVER A ABRIR:

http://oa.upm.es/44208/3/TFM_RODRIGO_ANTONIO_LOPEZ_ROSCIANO_JOSE_ALFREDO_PECH_
MONTEJO.pdf

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesRUP.pdf