RUP

(Proceso Unificado de Racional (Rational Unified Process))

RUP

Es un producto de Rational (IBM)

Sus principales caracteristicas son:
• Es iterativo e incremental
• Es centrado en la arquitectura (basado en componentes)
• Esta guiado por los casos de uso
• Control de cambios
• Verificación de la calidad del software
Incluye artefactos: Son los productos tangibles del proceso, por ejemplo: modelo de casos de
uso, código fuente, etc.
Incluye roles: papel que desempeña una persona en un determinado momento, una persona
puede desempeñar distintos roles a lo largo del proceso.

RUP se basa en componentes (component-based), lo que significa que el sistema en construcción

está hecho de componentes de software interconectados por medio de interfaces bien definidas
(well-defined interfaces).
RUP usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema.
Los aspectos distintivos de RUP están capturados en tres conceptos clave: dirigido por casos de uso
(use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto
es lo que hace único al Proceso Unificado.
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 iteración.

El Proceso Unificado es dirigido por casos de uso

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
constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema.
Los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema,
también dirigen su diseño, implementación y prueba
Aún 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 elección de los casos de uso. Por
lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

Proceso Unificado está centrado en la arquitectura

La arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está
siendo construido.
El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más
significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las
interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso. Sin
embargo, también está influenciada por muchos otros factores, tales como la plataforma de
software en la que se ejecutará, la disponiblidad de componentes reutilizables, consideraciones de
instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad).
La arquitectura es la vista del diseño completo con las características más importantes hechas más
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 , flexibilidad en los cambios futuros y reuso.

El Proceso Unificado es Iterativo e Incremental

Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es una
iteración que finaliza 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 más efectivo, las iteraciones
deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera
planeada.
Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que
fueron dejados en la iteración anterior.
En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el
diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los
componentes satisfacen los casos de uso. Si una iteración cumple sus metas el desarrollo continúa
con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben
revisar sus decisiones previas y probar un nuevo enfoque.

Como filosofia, RUP maneja 6 principios básicos, en los que está basado:

• Adaptar el proceso: El proceso deberá adaptarse a las necesidades del cliente ya que es
muy importante interactura con él. Las caracteristicas propias del proyecto u
organización, tamaño, tipo, regulaciones que lo condicionesn, ya que influirán en su
diseño en especifico.
• 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 tambien
los riesgos involucrados.
• 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, etc.
• Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos
reutilizables tales como patrón 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 codificación 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 reutilización del código. Un alto nivel de
abstracción también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la
arquitectura, por ejemplo con el lenguaje UML.
• 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.
 CICLO DE VIDA

El ciclo de vida organiza las tareas en fases e iteraciones.

Fases

Proceso: Las etapas de esta sección son:

• 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
Iteraciones

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

• 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: 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.
Fase de Elaboración: 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: 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 Cierre: 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.

DESCRIPCIÓN DE LAS ACTIVIDADES

Dependiendo de las iteración del proceso el equipo de desarrollo puede realizar 7 tipos de
actividades en este:

FASE DE INICIO
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado
del negocio y de requisitos.

Modelado del negocio

En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus
procesos.
• Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado
• Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
• Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la
organización objetivo.

Requisitos

En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales
tienen que comprender y aceptar los requisitos que especifiquemos.
• Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema
podría hacer.
• Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
• Definir el ámbito del sistema.
• Proveer una base para estimar costos y tiempo de desarrollo del sistema.
• Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario

FASE DE ELABORACIÓN

En la fase de elaboración, las iteraciones se orientan al desarrollo de labaseline de laarquitectura,

abarcan más los flujos de trabajo de requerimientos, modelo de negocios(refinamiento), análisis,
diseño y una parte de implementación orientado a labas eline de laarquitectura.
Análisis y Diseño
En esta actividadse especifican los requerimientos y se describen sobre como se van a implementar
en el sistemas
• Transformar los requisitos al diseño delsistema.
• Desarrollar una arquitectura para el sistema.
• Adaptar el diseño para que sea consistente con el entorno de implementación

}
FASE DE CONSTRUCCIÓN

Implementación
Seimplementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado
final es un sistema ejecutable.
• Planificar qué subsistemas deben ser implementados y en que orden deben ser integrados,
formando el Plan de Integración.
• Cada implementador decide en que orden implementa los elementos del subsistema.
• Si encuentra errores de diseño, los notifica.
• Se integra el sistema siguiendo el plan.

Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando,
pero no para aceptar o rechazar el producto al final del proceso de desarrollo,sino que debe ir
integrado en todo el ciclo de vida.
• Encontrar y documentar defectos en la calidad del software.
• Generalmente asesora sobre la calidad del software percibida.
• Provee la validación de los supuestos realizados en el diseño y especificación de
requisitos por medio de demostraciones concretas.
• Verificar las funciones del producto de software según lo diseñado.
• Verificar que los requisitos tengan su apropiada implementación

Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los
usuarios. Las actividades implicadas incluyen:
• Probar el producto en su entorno de ejecución final.
• Empaquetar el software para su distribución.
• Distribuir el software.
• Instalar el software.
• Proveer asistencia y ayuda a los usuarios.
• Formar a los usuarios y al cuerpo de ventas.
• Migrar el software existente o convertir bases de datos
DURANTE TODO EL PROYECTO

Gestión del proyecto

Se vigila el cumplimiento delos objetivos, gestión de riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios.
• Proveer un marco de trabajo para la gestión de proyectos de software intensivos.
• Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el
proyecto.
• Proveer un marco de trabajo para gestionar riesgos.

Configuración y control de cambios

El control de cambios permite mantener la integridad de todos los artefactos que se crean en el
proceso, así como de mantener información del proceso evolutivo que han seguido.

Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas,procesos y
métodos. Brinda una especificación de las herramientas que se van a necesitar encada momento, así
como definir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
• Selección y adquisición de herramientas
• Establecer y configurar las herramientas para que se ajusten a la organización.
• Configuración del proceso.
• Mejora del proceso.
• Servicios técnicos
 ROLES

Analistas:
• Analista de procesos de negocio.
• Diseñador del negocio.
• Analista de sistema.
• Especificador de requisitos.

Desarrolladores:
• Arquitecto de software.
• Diseñador
• Diseñador de interfaz de usuario
• Diseñador de cápsulas.
• Diseñador de base de datos.
• Implementador.
• Integrador.

Gestores:
• Jefe de proyecto
• Jefe de control de cambios.
• Jefe de configuración.
• Jefe de pruebas
• Jefe de despliegue
• Ingeniero de procesos
• Revisor de gestión del proyecto
• Gestor de pruebas.

Apoyo:
• Documentador técnico
• Administrador de sistema
• Especialista en herramientas
• Desarrollador de cursos
• Artista gráfico

Especialista en pruebas:
• Especialista en Pruebas (tester)
• Analista de pruebas
• Diseñador de pruebas

Otros roles:
• Stakeholders.
• Revisor
• Coordinación de revisiones
• Revisor técnico
• Cualquier rol
 ARTEFACTOS

Los artefactos son los entregables que son producidos durante y al final del proyecto. Los artefactos
pueden ser:
• Un documento: Como un documento de la arquitectura de software, etc.
• Un modelo: Como el modelo de casos de uso, o el modelo de diseño.
• Un elemento del modelo: Es un elemento en el modelo, como una clase o un subsistema.

RUP en cada una de sus fases realiza una serie de artefactos que sirven para comprender mejor
tanto el análisis como el diseño del sistema (entre otros).

RUP proporciona una serie de templates o artefactos a seguir, y los cuales se pueden implementar
en las faces, estos artefactos son los siguientes:

Business
Nombre
Business Vision
Business Architecture Document
Business Glossary
Bill of Materials
Business Modeling Guidelines
Business Rules
Business Use-Case Specification
Supplementary Business Specification
Business Use-Case Realization Specification
Business Case
Target-Organization Assessment
Project Management
Nombre
Vision
Vision (Small Project)
Software Development Plan
Software Development Plan (Small Project)
Glossary
Development Case
Development-Organization Assessment
Risk List
Risk Management Plan
Iteration Plan
Iteration Assessment
Measurement Plan
Status Assessment
Problem Resolution Plan

Requirements
Nombre
Requirements Management Plan
Software Requirements Specification for Subsystem
Software Requirements Specification For Subsystem or Feature
Use-Case-Modeling Guidelines
Use-Case Specification
Use-Case-Realization Specification
Supplementary Specification

Development
Nombre
Design Guidelines
Programming Guidelines
Software Architecture Document
Integration Build Plan
Testing and Quality
Nombre
Test Evaluation Summary
Test Guidelines
Iteration or Master Test Plan
Quality Assurance Plan
Test Case

Deployment
Nombre
Product Acceptance Plan
Configuration Management Plan
Deployment Plan
Release Notes

Los artefctos que se propone implementar como minímo en cada una de las fases (entre otros) son
los siguientes:

Inicio:
• Documento Visión
• Especificación de Requisitos

Elaboración:
• Diagramas de caso de uso

Desarrollo:
• Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

• Diagrama de clases
• Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación

• Diagrama de secuencia
• Diagrama de estados
• Diagrama de colaboración

Vista Conceptual

• Modelo de dominio

Vista física

• Mapa de comportamiento a nivel de hardware.