El Rational Unified Process (RUP) es un marco de proceso de ingeniería de software que provee un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un cronograma y presupuesto predecible.

1. *
Universidad Abierta Interamericana
Ing. Luis Alberto Perdomo
2011

2. “The Rational Unified Process® is a
Software Engineering Process. It provides a
disciplined approach to assigning tasks and
responsibilities within a development
organization. Its goal is to ensure the
production of high-quality software that meets
the needs of its end-users, within a predictable
schedule and budget”
IBM - Rational
*

3. * Mejora en al productividad del equipo: provee
un acceso a una base de
conocimiento, obteniendo un lenguaje
común, procesos y vistas de cómo desarrollar
el software.
* Creación y mantenimiento de modelos:
representaciones semánticas del sistema en
desarrollo (UML + CASE tools).
* Define un marco de proceso configurable: es
adaptable tanto en equipos grandes como en
equipos pequeños.
*

4. * 1) Desarrollo iterativo del software: permite
entender de forma incremental mediante la
ejecución de iteraciones que arrojan
refinamientos que ayudan a crecer al software.
Permite enfocarse en los riesgos de la iteración
y a su vez producir releases de las cuales se
obtiene el feedback del cliente. Ayuda a
reajustar estrategias de planeamiento y
afrontar cambios en los requerimientos.
*

5. * 2) Administración de requerimientos: describe
cómo obtener, organizar y documentar las
funcionalidades requeridas y las restricciones,
realizar el seguimiento de dichos documentos y
facilitar la comunicación de los requerimientos
de negocio. La noción de casos de uso proveen
una excelente forma de capturar
requerimientos funcionales.
*

6. * 3) Uso de arquitecturas basadas en
componentes: se define componente a un
módulo no trivial o subsistemas que cumplen
una función bien definida. Una arquitectura
basada en componentes resulta
flexible, adaptable a los cambios y promueve
la reutilización de elementos de software.
Todos los componentes son ensamblados en
dicha arquitectura que resulta un componente
de infraestructura (ej.
Internet, CORBA, REST, etc.)
*

7. * 4) Modelado visual del software: permite
ocultar detalles específicos y evitar escribir
código mediante el uso de editores basados en
abstracciones visuales. Permite una visión de
integración y utiliza el estándar industrial
conocido como Unified Modeling Language
(UML) el cual define una notación para la
representación de elementos de software.
*

8. * 5) Verificación de la calidad del software:
ejecución de pruebas de funcionalidad,
performance, tiempos de respuesta.
Verificación de la alineación de las
funcionalidades del sistema a los
requerimientos de negocio identificados.
*

9. * 6) Controles de los cambios del software: cómo
controlar, realizar el seguimiento y monitorear
los cambios para asegurar el éxito en el
proceso de desarrollo iterativo. Establecer
lugares aislados para cada desarrollador y
permitir unificar el trabajo del equipo en una
única unidad integrada automática mente
(merge).
*

10. Fases
Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Prueba
Implantación
Flujos de Trabajo de Soporte
Admin. Configuración
Admin. de Proyectos
Ambiente o Entorno
Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminar #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones
*

11. * Fase 1 (Inicio):
* Visión del proyecto: requerimientos “core”,
funcionalidades y restricciones principales.
* Definición de actores y casos de uso (10-20 %).
* Un glosario de términos del dominio.
* Análisis inicial de riesgos.
* Plan del proyecto, identificando fases e
iteraciones.
* Modelo de negocio y otros prototipos necesarios.
*

12. * Fase 2 (Elaboración):
* Definición de actores y casos de uso (al menos el
80% ya definido).
* Captura de requerimientos no funcionales.
* Descripción de la arquitectura de software.
* Un prototipo ejecutable de la arquitectura.
* Plan de desarrollo con evaluaciones y criterios.
* Manual de usuario preliminar (opcional).
*

13. * Fase 3 (Construcción):
* Producto de software integrado a las plataformas
adecuadas.
* Manuales de usuario.
* Descripción del release actual.
*

14. * Fase 4 (Transición):
* Beta testing para la validación del nuevo sistema
según las expectativas.
* Operación en paralelo con sistemas legacy a
reemplazar.
* Conversión de bases de datos operacionales.
* Entrenamiento de usuarios.
* Roll-out del producto a marketing, distribución,
etc.
*

15. Fases
Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Prueba
Implantación
Flujos de Trabajo de Soporte
Admin. Configuración
Admin. de Proyectos
Ambiente o Entorno
Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminar #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones
*

16. * Rational Unified Process: best Practices for
software development teams
* Wikipedia
* Sparx UML Tutorial
*