Rational Unified Process (RUP)
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) 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. 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.
Meta principal
Tiene como objetivo ordenar y estructurar el desarrollo de software, en la cual se tienen un conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema.
Fases del ciclo de vida
 |
| Fases y disciplinas de RUP |
• Fase de inicio.
Tiene como objetivos:
- 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 productos de la fase de inicio deben ser:
- Visión del negocio: Describe los objetivos y restricciones a alto nivel.
- Modelo de casos de uso.
- Especificación adicional: requisitos no funcionales.
- Glosario: Terminología clave del dominio.
- Lista de riesgos y planes de contingencia.
- Prototipos exploratorios para probar conceptos o la arquitectura candidata.
- Plan de iteración para la primera iteración de la fase de elaboración.
- Plan de fases.
• Fase de elaboración.
- 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.
- Modelo de casos de uso.
- Especificación adicional: requisitos no funcionales.
- Glosario: Terminología clave del dominio.
- Lista de riesgos y planes de contingencia.
- Prototipos exploratorios para probar conceptos o la arquitectura candidata.
- Plan de iteración para la primera iteración de la fase de elaboración.
- Plan de fases.
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 y eliminar los mayores riesgos. Cuando termina esta fase se llega al punto de no retorno 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ítico identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves, bien con este prototipo.
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 productos:
- 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.
- 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.
- Posiblemente un manual de usuario preliminar.
La forma de aproximarse a esta fase debe ser 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 el glosario, el caso de negocio, el ROI (Return Of Invest), etcétera.
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.
- Los gastos hasta ahora son aceptables, comparados con los previstos.
• Fase de construcción.
La finalidad principal de esta fase es alcanzar 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, que no lo hayan sido hecho hasta ahora, han de ser implementados, integrados y testeados, obteniendo se una versión del producto que se pueda poner en manos de los usuarios (una versión beta). El énfasis en esta fase se pone controlar las operaciones realizadas, administrando los recursos eficientemente, de tal forma que se optimicen los costes, los calendarios y la calidad.
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 practico.
- Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea practico.
Los productos de la fase de construcción segú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.
• Fase de transición.
La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo que típicamente se requerirá 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 usabilidad del producto.
En concreto se citan algunas de las cosas que puede incluir esta fase:
- Testeo 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 sí mismo.
- Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.
Los productos de la fase de transición segú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.
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión. Las actividades a realizar durante las iteraciones dependerán de su finalidad, si es corregir algún error detectado, normalmente será suficiente con llevar a cabo los flujos de trabajo de implementación y test, sin embargo, si se deben añadir nuevas características, la iteración será similar a la de una iteración de la fase de construcción. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organización en la que deba implantarse.
A continuación se muestra el siguiente video, en el cual se explican estas fases. (Ver del minuto 0:59 - 3:01)
Cuándo se utiliza RUP
Características
• 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.
¿A quién está orientado?
Disciplinas
Roles
• Analista de procesos de negocio.
• Diseñador del negocio.
• Analista de sistema.
• Especificador de requisitos.
Desarrolladores: Este rol se encarga de diseñar y desarrollar el software, se comienza a trabajar en el proyecto y escribir el código utilizando la información previamente proporcionada por los analistas.
• Arquitecto de software.
• Diseñador.
• Diseñador de interfaz de usuario.
• Diseñador de cápsulas.
• Diseñador de base de datos.
• Implementador.
• Integrador.
• 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.
• Documentador técnico.
• Administrador de sistema.
• Especialista en herramientas.
• Desarrollador de cursos.
• Artista gráfico.
• Especialista en Pruebas (tester).
• Analista de pruebas.
• Diseñador de pruebas.
• Stakeholders.
• Revisor.
• Coordinación de revisiones.
• Revisor técnico.