Tema 3: Proceso unificado (RUP)

Introducción

El Proceso Unificado (RUP) es un proceso de desarrollo de software aunque

según sus desarrolladores es todo un marco de trabajo genérico que puede
especializarse para gran cantidad de sistemas software, diferentes áreas de
aplicación, tipos de organizaciones, etc.

Está basado en componentes, lo que indica que el sistema a construir estará

formado por componentes software interconectados a través de interfaces. Usa
UML como lenguaje de modelado.

Los tres elementos clave que resumen el proceso unificado son:

• es dirigido por casos de uso,

• está centrado en la arquitectura,
• es iterativo e incremental.
Los objetivos de RUP son: proporcionar un marco de trabajo para gestionar
proyectos software; proporcionar guías prácticas para planificar, gestionar el
personal, ejecutar, realizar y seguir proyectos; y proporcionar un marco para
gestionar riesgos. No cubre otras cosas como el reclutamiento, formación, etc. de
personal; la gestión de presupuestos; o la gestión de contratos con proveedores y
usuarios.

Está enfocado hacia un proceso de desarrollo iterativo, gestionando los riesgos,

planificando el proyecto iterativo a través del ciclo de vida y planificando cada
iteración particular, y monitorizando el progreso del proyecto iterativo obteniendo
métricas.

El proceso de desarrollo de software debe estar adaptado al entorno, a las personas

y a los objetivos de las organizaciones que lo utilizan. Ningún proceso puede ser
adecuado a todas las organizaciones y por tanto un proceso debe ser adaptable y
configurable.

Algunos factores que se deben tener en cuenta para la adaptación del proceso son
el dominio de la aplicación, las personas y factores organizativos, los factores
relacionados con el ciclo de vida del producto, o los factores de proceso como el
cumplimiento de estándares.

El RUP consiste en una estructura estática de personas, actividades, artefactos y

flujos de trabajo, y una estructra dinámica de ciclos, fases, iteraciones, hitos y
relaciones entre ellos.

Una actividad es una unidad de trabajo que puede ejecutar uno o varios individuos
en un rol específico. Tiene un propósito claro expresado en términos de actualizar
un artefacto. La granularidad de una actividad es generalmente de horas o pocos
días. Ejemplos son planificar una iteración, encontrar casos de uso y actores, o
revisar el diseño.

Un artefacto es una pieza de información producida, modificada y utilizada en un

proceso, un producto tangible del proyecto. Se utiliza por los roles como entrada
para la realización de sus actividades, y también es el resultado de las actividades
que realizan. En el metamodelo, la clase "rol" tiene como métodos las actividades y
como parámetros los artefactos.

Un recurso humano puede desempeñar uno o más roles, que le permiten ejecutar
las actividades asociadas a tales roles.

Flujos de trabajo fundamentales

El ciclo de desarrollo del proceso unificado se divide en cuatro fases en las que los
distintos flujos de trabajo se desarrollan con distinta intensidad. Cada fase está
dividida en iteraciones. Estas cuatro fases son:

• Inicio (inception): define el ámbito del proyecto y desarrolla los casos de

negocio. Define los objetivos.
• Elaboración: se elabora el plan de proyecto, se especifican las características
y el marco de referencia de la arquitectura. Define la arquitectura.
• Construcción: se construye el proyecto. Define la funcionalidad inicial.
• Transición: se pasa el producto a los usuarios. Define la versión final del
producto.
Al final de cada iteración se dispone de una nueva versión de los entregables.

Los flujos de trabajo de ingeniería o de proceso son:

• modelado de negocio,
• requisitos,
• análisis y diseño,
• implementación,
• prueba,
• lanzamiento.
Los flujos de trabajo de apoyo o accesorios son:

• gestión de configuración,
• gestión del proyecto,
• entorno.
Los casos de uso van progresando a través de las fases. Al terminar la fase de
inicio, la mayoría del modelo de negocio ha sido terminado y la mayoría de los
casos de uso han sido identificados. Muy pocos se describen, se analizan, y mucho
menos se implementan. Al terminar la fase de elaboración el modelo de negocio
está terminado, la inmensa mayoría de casos de usos han sido identificados y
muchos de ellos han sido descritos. Algunos de ellos han sido analizados y apenas
ninguno ha sido diseñado, implementado y probado. Al terminar la fase de
construcción, todos los casos de usos tienen que haber sido identificados, descritos,
analizados, diseñados, implementados y probados.

Beneficios del desarrollo iterativo:

• Se produce una mitigación, en las capas iniciales, de los riesgos más críticos
(técnicos, requisitos, objetivos, facilidad de uso, etc.).
• El progreso es visible desde muy pronto.
• La realimentación temprana, la implicación del usuario y la adaptación
conducen a un sistema refinado que satisface más estrechamente las
necesidades reales de los "usuarios".
• La complejidad se gestiona, el equipo no se abruma por la "parálisis del
análisis" o por etapas muy grandes y complejas.
• El aprendizaje que se va obteniendo en cada iteración se puede utilizar
metódicamente para mejorar el proceso de desarrollo, iteración a iteración.
A medida que se avanza en el desarrollo de la ingeniería de software se debe definir
un modelo de proceso para soportar una evolución de los planes, requisitos y
arquitectura junto con puntos de sincronización bien definidos; una gestión de
requisitos y medidas objetivas de progreso y calidad; y una evolución de las
capacidades del sistema a través de demostraciones de funcionalidad incremental.

El ciclo de vida se divide en dos etapas. La etapa de ingeniería, con equipos más
pequeños, es donde se realizan actividades menos previsibles de diseño y síntesis.
La etapa de producción es donde se realizan las actividades más previsibles
relacionadas con construcción, prueba y lanzamiento, en un equipo más grande.

Aspecto del Énfasis durante etapa de Énfasis durante etapa de

ciclo de vida ingeniería producción

Reducción del Planificación, factibilidad

Coste
riesgo técnica

Línea base de la Líneas base de entregas

Productos
arquitectura de producto

Análisis, diseño,
Actividades Implementación, pruebas
planificación

Demostración, inspección,
Valoración Pruebas
análisis

Resolución de la Explotación de la
Economía
diseconomía de escala economía de escala
 Gestión Planificación Operaciones
La transición entre ingeniería y producción es un evento crucial para los
"stakeholders".

Los diez puntos fundamentales del RUP

• Desarrollar una visión

• Gestionar el plan
• Identificar y mitigar los riesgos
• Asignar y seguir características
• Examinar los casos de negocio
• Diseñar una arquitectura de componentes
• Construir de forma iterativa e incremental y probar el producto
• Verificar y evaluar resultados
• Gestionar y controlar los cambios
• Proporcionar apoyo a los usuarios

Modelos

Un modelo es una simplificación de la realidad con el objetivo de representar un

sistema grande y complejo que sería difícil de comprender al considerarlo
completamente. Un modelo no es la realidad sino una representación de ella. Un
modelo único no puede cubrir todos los aspectos del desarrollo de software. Se
necesitan múltiples modelos para cubrir todos ellos, coordinados de forma
adecuada.

Los modelos son representaciones completas y consistentes del sistema a construir.

Partimos de un modelo de casos de uso que modela los casos de uso y sus
relaciones con los actores. El modelo de casos de uso es especificado por un
modelo de análisis que refina los casos de uso y realiza una visión inical del
comportamiento del conjunto de objetos. Es realizado por un modelo de diseño
que define la estructura estática del sistema como subsistemas, clases e interfaces
y define los casos de uso como colaboraciones de subsistemas, clases e interfaces.
Es implementado por un modelo de implementación que incluye componentes
representados por su código fuente y la correspondencia entre clases y
componentes. Es distribuido por un modelo de despliegue que define los nodos
físicos y establece la correspondencia entre componentes y nodos. Es verificado por
un modelo de pruebas que describe los casos de prueba que verifican los casos de
uso.
Fase de inicio

Objetivos principales:

• Establecer el ámbito y los límites del proyecto, incluyendo conceptos

operativos y criterios de aceptación.
• Localizar los casos de uso críticos y los escenarios principales que dirigirán
los objetivos fundamentales del diseño.
• Comprobar al menos una arquitectura candidata frente a algunos de los
escenarios principales.
• Estimar el coste completo y la planificación temporal del proyecto completo.
• Estimar los riesgos potenciales.
Actividades esenciales:

• Formular el ámbito del proyecto.

• Sintetizar la arquitectura.
• Planificar y preparar un caso de negocio.
Algunos criterios de evaluación:

• ¿Coinciden los "usuarios" con la definición del ámbito y las estimaciones de

coste y tiempo?
• ¿Se han entendido totalmente los requisitos?
• ¿Son creíbles dichas estimaciones, así como las prioridades, los riesgos y el
proceso de desarrollo?
• ¿La profundidad y amplitud del prototipo arquitectónico demuestran el criterio
precedente?
De no cumplirse los criterios de evaluación habrá que replantear aquellos elementos
que no se han conseguido satisfacer en los puntos anteriores.

En la fase de inicio se establece la oportunidad y alcance del proyecto, incluyendo

conceptos operativos y criterios de aceptación. También se identifican todos los
actores externos con los que se tratan y se define la interacción a un alto nivel de
abstracción, identificando todos los casos de uso y localizando aquellos que son
críticos y los escenarios principales que dirigirán los objetivos fundamentales del
diseño.

La oportunidad de negocio incluye criterios de éxito, identificación de riesgos,

estimación de recursos necesarios, y plan de las fases incluyendo hitos.

Los productos resultantes de la fase de inicio son:

• Un documento de visión general con los requisitos generales del proyecto, las
características principales y las restricciones.
• Un modelo inicial de casos de uso con aproximadamente un 15% de ellos
listos.
• Un glosario inicial con la terminología clave del dominio.
 • Caso de negocio con un contexto, criterios de éxito y pronóstico financiero.
• Identificación inicial de riesgos.
• Plan de proyecto mostrando fases e iteraciones.
• Modelo de negocio si es necesario.
• Uno o más prototipos exploratorios para probar conceptos o la arquitectura
candidata.
El hito que marca el fin de la fase de inicio debe suponer el acuerdo entre las partes
interesadas sobre el alcance y la estimación de tiempo y coste, así como la
comprensión de los requisitos plasmados en casos de uso.

Fase de elaboración

Objetivos:

• Analizar el dominio del problema.

• Establecer una arquitectura base sólida.
• Desarrollar un plan de proyecto ajustado para la fase de construcción.
• Eliminar los elementos de mayor riesgo para el desarrollo exitoso del
proyecto.
Actividades esenciales:

• Elaborar la visión. Desarrollar los casos de uso a un nivel que dirija las
decisiones de la arquitectura o de planificación.
• Elaborar el proceso y la infraestructura.
• Elaborar la arquitectura y los componentes seleccionados.
Productos:

• Modelo de casos de uso prácticamente terminado con descripciones

detalladas.
• Otros requisitos no funcionales o no asociados a casos de uso.
• Descripción de la arquitectura del software.
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
La fase de elaboración es la más crítica del proceso. Al final de la misma, toda la
ingeniería "dura" está hecha y se puede decidir si vale la pena seguir adelante. A
partir de aquí, la arquitectura, planes de desarrollo y requisitos son estables. Ya hay
menos riesgos y se puede planificar con menos incertidumbre el resto del proyecto.
Se construye una arquitectura ejecutable que contemple los casos de uso críticos y
los riesgos identificados.

El hito que marca el fin de la fase de elaboración debe cumplir los siguientes
criterios de evaluación:
 • ¿Es estable la visión del proyecto?
• ¿Es estable la arquitectura?
• ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y
resueltos?
• ¿El plan de proyecto es algo realista?
• Las personas involucradas, ¿están de acuerdo con el plan?

Fase de construcción

Objetivos principales:

• Minimizar los costes de desarrollo optimizando los recursos e impidiendo la

realización del trabajo dos veces.
• Conseguir una calidad adecuada.
• Conseguir versiones estables.
Actividades esenciales:

• Gestión y control de los recursos y optimización del proceso.

• Desarrollo de componentes completos y prueba de los mismos frente a
criterios de evaluación.
• Valoración de las versiones de producto frente a los criterios de aceptación.
Algunos criterios de evaluación:

• ¿El producto es lo suficientemente estable y maduro como para ser

entregado al usuario? La existencia de algunos defectos o cambios
pendientes no son obstáculo para conseguir el propósito de la entrega en la
fase siguiente.
• ¿Están los usuarios dispuestos para la transición?
• ¿Los gastos actuales de recursos son aceptables todavía frente a los
planeados?
El hito que marca el fin de esta fase es la obtención de un producto beta y la
decisión sobre si ponerlo en ejecución sin mayores riesgos.

Fase de transición

Objetivos principales:

• Conseguir que el usuario sea capaz de mantener el producto.

• Conseguir la aceptación por el usuario (stakeholder) de que lo entregado es
completo y consistente con el criterio de evaluación fijado en la visión inicial
del proyecto.
• Conseguir un producto final tan rápido y eficiente respecto al coste como
práctico.
Actividades esenciales:
 • Sincronización e integración de los incrementos de construcción concurrentes
en líneas base de entrega consistente.
• Realizar una ingeniería específica de entrega (producción y
empaquetamiento comercial, plan de formación del personal, etc.).
• Valoración de las líneas base de entrega frente a la visión global y los
criterios de aceptación en el conjunto de requisitos.
Algunos criterios de evaluación:

• ¿El usuario está satisfecho?

• ¿La utilización de recursos actual es aceptable frente a la planificada?

Arquitectura

Visualizar, especificar, construir y documentar un sistema software precisa de una

visión del sistema desde distintos puntos de vista.

Cada actor implicado en el proceso mira al sistema desde una perspectiva diferente
a lo largo de la vida del proyecto. La arquitectura del sistema es uno de los
productos más importantes que se pueden utilizar para gestionar estos puntos de
vista y, por tanto, para controlar el desarrollo del sistema a través de su ciclo de
vida.

Una arquitectura del sistema abarca el conjunto de decisiones importantes sobre:

• la organización del sistema software,

• la selección de los elementos estructurales y sus interfaces,
• su comportamiento, especificado como colaboración entre los distintos
componentes,
• la composición de estos elementos (estructurales y de comportamiento) en
subsistemas cada vez más grandes,
• el estilo arquitectónico que guía las organizaciones.
Hay cinco vistas con sus respectivos diagramas que las representan:

• Vista de usuario, con diagramas de casos de uso. Los casos de uso

especifican la función, la arquitectura y la forma. Debe existir un balance
entre casos de uso y arquitectura. Esta vista es central a las otras cuatro.
• Vista estructural o de diseño, con diagramas de clases y objetos. Representa
clases, interfaces, colaboraciones.
• Vista de implementación, con diagramas de componentes. Representa
componentes.
• Vista de comportamiento o de proceso, con diagramas de secuencia, de
colaboración, de estados y de actividad. Representa clases activas.
• Vista del entorno o de lanzamiento, con diagramas de despliegue.
Representa nodos.
Desarrollo iterativo e incremental

Un proceso basado en casos de uso implica ajustarse a las necesidades reales del
usuario. Que esté centrado en la arquitectura quiere decir que el trabajo de
desarrollo se centra en obtener un patrón que dirigirá la construcción del sistema en
las primeras fases. La mejor forma de conseguir equilibrar casos de uso y
arquitectura, que es como equilibrar forma y función, es el desarrollo iterativo e
incremental. De esta forma se plantea una estrategia de desarrollo para productos
software basada en pequeños pasos manejables: se planifica poco, se especifica,
diseña e implementa un poco, se integra, prueba y ejecuta un poco en cada
iteración.

Si en cada paso el resultado es satisfactorio, se avanza. Además esto nos permite

ajustar los objetivos concretos en cada paso. Cada iteración tiene todo lo que debe
tener un proyecto de software: planificación, desarrollo de una serie de flujos y
preparación para la entrega. Pero una iteración no es algo totalmente
independiente, sino que es una etapa dentro de un proyecto.

Cada iteración permite avanzar en la comprensión de cuestiones relativas al

proyecto. Por ejemplo las primeras nos ayudan a comprender los riesgos,
determinar la viabilidad, etc.

En resumen, no hay un proceso universal. El proceso unificado está diseñado para

ser flexible y extensible, permitiendo una variedad de estrategias de ciclos de vida,
seleccionando qué artefactos producir, definiendo actividades y trabajadores, y
considerando los conceptos de los modelos.

Un white paper de Rational en 2011 considera que RUP facilita las siguientes
buenas prácticas para desarrollo de software:

1. Desarrollo de software iterativo.

2. Gestión de los requisitos.
3. Uso de arquitecturas basadas en componentes.
4. Modelado visual de software.
5. Verificación de la calidad del software.
6. Control de cambios del software.
Esto genera una serie de beneficios:

• Reducción temprana de los errores.

• Gestión de los cambios.
• Mayor nivel de reutilización.
• Evaluación y mejoras periódicas.
• Mejor calidad final.
El proceso unificado equilibra más el peso de cada una de las actividades del
proyecto que procesos convencionales como waterfall.
Las 10 mejores herramientas y software de modelado de datos en 2024 | Astera