1. PRACTICA
RATIONAL UNIFIED PROCESS (RUP- Proceso Racional Unificado)
Es un proceso de desarrollo de software y junto con 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
Ventajas:
• Un proceso de software hecho a la medida para ser publicado y hacerlo accesible para
todo el equipo del proyecto.
• Un proceso de software configurable, para satisfacer necesidades específicas de un
proyecto.
RUP se basa en la evolución de prototipos ejecutables o versiones del producto final que se
muestran a los usuarios e inversionistas del proyecto. Cada paso por el ciclo de vida produce una
versión del producto que incrementalmente se va refinando en las iteraciones de las diferentes
fases. Si llegado el final del ciclo de vida de RUP., el producto no cumple con los objetivos
planteados, se puede realizar un ciclo más para refinar, corregir y agregar funcionalidades.
Elementos Básicos De RUP
Con RUP, un proceso de desarrollo es representado usando un conjunto de elementos de
modelado, tales como: roles, actividades, artefactos y flujos de trabajo (workflows), entre otros. Un
rol expresa quién (individuo o grupo) hace un trabajo, una actividad describe cómo es hecho el
trabajo y un artefacto captura el trabajo realizado. En RUP se encuentran 4 elementos básicos: los
roles (el quién), las actividades (el cómo), los artefactos (el qué) y los flujos de trabajo (el cuándo).
La estructura estática de RUP maneja cómo los elementos del proceso (actividades, disciplinas,
artefactos y roles) están lógicamente agrupados dentro del corazón de las disciplinas del proceso.
RUP (Proceso Unificado de Racional)
RUP es un proceso para el desarrollo de un proyecto de
software que define las siguientes fases:
FASE DE INICIO
 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.
FASE DE ELABORACION
 propósito de la fase de elaboración es analizar el dominio del
problema.
 Establecer los cimientos de la arquitectura.
 D e s a r r o l l a r e l p l a n d e l p r o y e c t o y eliminar los mayores riesgos.
Pagina: 1

2. PRACTICA
FASE DE CONSTRUCCION
 La finalidad principal de esta fase es alcanzar la capacidad
o p e r a c i o n a l d e l producto de forma incremental a través de las sucesivas iteraciones.
FASE DE TRANSICION
 La finalidad de la fase de transición es poner el producto en manos de los usuarios f i n a l e s , p a r a l o
que se requiere desarrollar nuevas versiones actualizadas del producto.
NOTACIÓN DE LA METODOLOGÍA Y DISCIPLINAS.
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia
de pasos para la culminación de cada disciplina.
Modelado del negocio.
Esta disciplina tiene como objetivos comprender la estructura y
la dinámica de la organización.
Requerimientos.
Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer
(Especificar Requisitos), definir los límites del sistema, y una interfaz de
usuario, realizar una estimación del costo y tiempo de desarrollo.
Análisis y diseño.
Esta disciplina 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 en clases, y al
decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases
Implementación.
Esta disciplina tiene como objetivos implementar las clases de diseño como componentes (ej.
fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente.
Pruebas.
Esta disciplina tiene como objetivos 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.
Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente,
proceder a su entrega y recepción por el cliente.
Gestión y configuración de cambios.
Es esencial para controlar el número de artefactos producidos por la cantidad de personal que
trabajan en un proyecto conjuntamente.
Pagina: 2

3. PRACTICA
¿Cuándo Usar RUP?
RUP puede ser utilizado desde el principio de un proyecto de software y puede continuar usándose
en los subsecuentes ciclos de desarrollo del software después que
la fase inicial ha finalizado. Sin embargo, la manera en la cual se use RUP, necesita ser
trasformada para ajustarse a las necesidades. Existen algunas consideraciones que modifican el
cuándo y cómo se utilizarán las diferentes partes de RUP, éstas son:
• El ciclo de vida del proyecto (número de iteración, longitud de cada fase, el largo del
proyecto).
• Los objetivos de negocio del proyecto, visión, alcance y riesgos.
• El tamaño del esfuerzo para el desarrollo del software.
Aproximadamente 10.000 compañías están usando RUP. Estas compañías usan RUP en varios
dominios de aplicación, de una manera equilibrada en proyectos grandes o pequeños. Esto
muestra lo versátil de RUP y su amplia aplicabilidad. Algunos ejemplos de las industrias que usan
RUP son empresa de: telecomunicación, transporte, servicios financieros, manufacturas,
integradores de sistemas, entre otros.
Pagina: 3