Metodología RUP

https://metodoss.com/metodologia-rup/

La metodología RUP, abreviatura de Rational Unified Process (o Proceso Unificado

Racional), es un proceso propietario de la ingeniería de software creado por Rational
Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una
abreviatura Rational Unified Process y lo que es una marca en el área de software,
proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de
software con el fin de aumentar su productividad en el proceso de desarrollo.

La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está

diseñado y documentado el uso de la notación UML (Unified Modeling Language) para
ilustrar los procesos en acción. Utiliza técnicas y prácticas probadas comercialmente.

Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de

desarrollo y grandes proyectos, pero el hecho de que es ampliamente personalizable que
permite adaptarse a proyectos de cualquier escala.

Para la gestión del proyecto, la metodología RUP proporciona una solución disciplinada

como las tareas y responsabilidades señaladas dentro de una organización de desarrollo
de software.
RUP es, en sí, un producto de software. Es modular y automatizado, y toda su
metodología se apoya en varias herramientas de desarrollo integradas y vendidos por IBM
a través de sus «Suites racional.»

Los métodos de la competencia en el campo de la ingeniería de software incluyen » salas

blancas » (considerado pesado) y ágil (luz) como Extreme Programming (Programación
XP-Extreme), Scrum , FDD y otros.

Directrices de la metodología RUP

RUP define las siguientes líneas maestras y los esqueletos (plantillas) para los miembros
del personal de un ciclo de producción: parte del cliente, y una evaluación de los avances
del proyecto por su gestión. Ayuda a los desarrolladores para mantener la concentración
en el proyecto.

Requisitos de gestión

La documentación apropiada es esencial para cualquier proyecto de gran envergadura; en

cuenta que RUP describe cómo documentar la funcionalidad, las limitaciones del sistema,
restricciones de diseño y requisitos de negocio.

Los casos de uso (en Inglés Casos de uso ) y los escenarios son ejemplos de artefactos
de proceso dependiente, que se han considerado mucho más eficaz en la captura de
requisitos funcionales.

El uso de una arquitectura basada en componentes

La arquitectura basada en componentes crea un sistema que puede ser fácilmente

extensible, promoviendo la reutilización y el software una comprensión intuitiva. Un
componente se refiere normalmente a un objeto en la programación orientada a objetos.

RUP proporciona una manera sistemática para construir este tipo de sistema,
centrándose en la producción de una arquitectura ejecutable en las primeras etapas del
proyecto, es decir, antes de comprometer recursos a gran escala.

Estos componentes se incluyen normalmente en las infraestructuras existentes, tales

como CORBA y COM (Component Object Model).

El uso de modelos visuales de software en la metodología RUP

Al abstraer la programación de su código y representarla utilizando bloques de

construcción gráficas, RUP puede una manera eficaz de conseguir una visión general de
una solución.

El uso de modelos visuales también puede permitir que los individuos menos perfil técnico
(como clientes) tienen una mejor comprensión de un problema dado, y así estar más
involucrados en el proyecto en su conjunto.
El lenguaje de modelado UML se ha convertido en un estándar de la industria para
representar los proyectos, y es ampliamente utilizado por RUP!

Comprobar la calidad del software

No asegura la calidad del software es el fallo más común en todos los proyectos de
sistemas informáticos. Por lo general, uno piensa en la calidad del software después de la
finalización de los proyectos, o la calidad es la responsabilidad de un equipo de desarrollo
de equipo diferente.

RUP tiene como objetivo ayudar en el control de la planificación de la calidad,

comprobando que en la construcción de todo el proceso y la participación de todos los
miembros del equipo de desarrollo.

Software de gestión y de cambio de control

En todos los proyectos de software de la existencia del cambio es inevitable. RUP define
métodos para controlar y vigilar los cambios. Como un pequeño cambio puede afectar a
las aplicaciones de maneras totalmente impredecibles, el control de cambio es esencial
para el éxito de un proyecto.

RUP también define las áreas de trabajo y seguridad , lo que garantiza un programador
que cambia en otro sistema no afectará a su sistema.

Fases de la metodología RUP

Hasta ahora estas líneas guía son generales, para ser adherido a pasar por la vida de un
ciclo de proyecto. Las fases (ver figura abajo) indican el énfasis se da en el proyecto en
un instante dado. Para capturar la dimensión temporal de un proyecto, RUP divide el
proyecto en cuatro fases diferentes:

 Iniciación o Diseño: énfasis en el alcance del sistema;

 Preparación: énfasis en la arquitectura;
 Construcción: énfasis en el desarrollo;
 Transición: énfasis en la aplicación.
 RUP se basa también en las 4 Ps:

 Personas
 Diseño
 Producto
 Proceso

Las capas se componen de iteraciones. Estas son ventanas de tiempo y han definido
término como las fases son objetivas.

Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y
permitirán documentar el proyecto y un mejor seguimiento.

Fase de diseño

La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el acuerdo
de las partes interesadas con los objetivos, la arquitectura y la planificación del proyecto.
Si estos actores tienen un buen conocimiento, no será necesario analizar. De lo contrario,
se requiere un análisis más elaborado.

En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso.
El objetivo no es para cerrarlas en absoluto, sino sólo las que sean necesarias para dar
forma a la opinión.

El paso es generalmente corto y se utiliza para definir si es factible para continuar con el
proyecto y definir los riesgos y el coste de la última. Un prototipo se puede hacer para que
el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones, las cuales deben
estar bien definidas en cuanto a su importe y objetivos.

Fase de elaboración

La preparación será para el diseño del sistema, como complemento de la encuesta y / o

documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de
negocio para el proyecto e iniciar la versión del manual del usuario.

Fase de construcción

En la fase de construcción, el desarrollo físico del software se inicia, códigos de

producción, pruebas alfa, pruebas beta se llevaron a cabo al inicio de la fase de
transición.

Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema son
«línea de base».

Fase de transición

En esta fase es la entrega («despliegue») de software, que se lleva a cabo el plan de

despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos,
las versiones) se van a entregar, y coloque la satisfacción del cliente. Esta etapa también
se lleva a cabo la formación de los usuarios.

Disciplinas de la metodología RUP

Seis Disciplinas de Ingeniería de Software

La disciplina modelado de negocio

Las organizaciones dependen cada vez más de los sistemas de TI, por lo que es
imperativo que los ingenieros de sistemas de información sepan cómo se integran las
aplicaciones en el desarrollo de la organización. Las empresas invierten en TI, que
entienden la ventaja competitiva del valor añadido por la tecnología.

El objetivo de modelado de negocio es establecer primero una mejor comprensión y

comunicación entre ingeniería de negocios y la ingeniería de software.

Comprender el negocio significa que los ingenieros de software deben entender la

estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de la
organización y las posibles mejoras. También deben asegurar una comprensión común de
la organización de destino entre los clientes, usuarios finales y desarrolladores.

El modelado de negocios explica cómo describir la visión de una organización en la que

se implementará el sistema y cómo utilizar esta visión como base para describir los
procesos, funciones y responsabilidades.

Análisis y Diseño de la disciplina («Diseño»)

El propósito del análisis y diseño es mostrar cómo se llevará a cabo el sistema. El objetivo
es construir un sistema que:

Ejecutar en un entorno de ejecución específica, las tareas y las funciones especificadas

en las descripciones de casos de uso

Satisfacer todas sus necesidades

Es fácil de mantener cuando no son cambios en los requisitos funcionales, los resultados
del proyecto en un modelo de análisis y diseño tiene opcionalmente un modelo de
análisis. El modelo de diseño sirve como una abstracción del código fuente, es decir, el
proyecto sirve como modelo de «retroalimentación» de la forma en que el código fuente
está estructurado y escrito.

El modelo de diseño consta de clases de diseño estructurados en paquetes y subsistemas

con interfaces bien definidas, en representación de lo que se convertirá componentes de
la aplicación. También contiene descripciones de cómo los objetos de estas clases
colaboran para llevar a cabo el diseño de casos de uso.
La disciplina Implementación

Los efectos de la aplicación son:

 Para configurar el código de la organización en términos de subsistemas de

aplicación organizados en capas
 Para llevar a cabo las clases y objetos en términos de componentes (archivos de
código fuente, binarios, ejecutables, etc.)
 Para probar los componentes desarrollados como unidades
 Incorporar los resultados producidos por los ejecutores individuales (o equipos), en
un sistema ejecutable

Los sistemas se logran a través de los componentes de la aplicación. El proceso describe

cómo reutilizar componentes existentes o implementar nuevos componentes con
responsabilidades bien definidas, haciendo que el sistema sea más fácil de mantener y
aumentar las posibilidades de reutilización.

Prueba de disciplina

Los fines de disciplina prueba son:

Comprobar la interacción entre los objetos. Comprobar la correcta integración de todos los
componentes de software

Compruebe que todos los requisitos han sido ejecutadas correctamente

Identificar y asegurar que los defectos se tratan antes de la implementación de software
Asegúrese de que todos los defectos son corregidos, revisados y cerrados

El Rational Unified Process propone un enfoque iterativo, lo que significa que debería
estar probando el proyecto en su totalidad. Esto le permite encontrar defectos tan pronto
como sea posible, lo que reduce drásticamente el costo de reparar el defecto.

Las pruebas se realizan a lo largo de cuatro dimensiones de la calidad: fiabilidad,

funcionalidad, rendimiento de las aplicaciones y el rendimiento del sistema. Para cada una
de estas dimensiones de la calidad, el proceso se describe cómo a pasar la prueba de la
planificación, diseño, implementación, ejecución y evaluación.

La disciplina Implementación

El propósito del despliegue es producir lanzamientos de productos exitosos y entregar el

software a los usuarios finales. Abarca una amplia gama de actividades, incluyendo la
producción de versiones de software externos, el envase de aplicaciones de software y de
negocios, distribución de software, instalación de software y proporcionar ayuda y
asistencia a los usuarios.

Aunque las actividades de despliegue se centran principalmente en torno a la transición,

muchas de las actividades se deben incluir en las etapas anteriores para preparar la
aplicación, al final de la fase de construcción. Los procesos ( «flujos de trabajo») de
«Implementación y Medio Ambiente» RUP contienen menos detalles que otros flujos de
trabajo.
Tres Disciplinas Soporte / Servicio de la metodología RUP

Disciplina para el Medio Ambiente

El medio ambiente se centra en las actividades necesarias para configurar el proceso

para un proyecto. En él se describen las actividades necesarias para desarrollar
directrices para apoyar un proyecto.

Esto se hizo inicialmente de forma manual, es decir, un documento «caso del complejo»
escrito que especifica el proceso de refinado para ser utilizado. Más tarde, IBM producto
Compositor Método Racional fue creado para ayudar a hacer este paso simple, ingenieros
de proceso y los directores de proyectos podría más fácilmente personalizar el RUP para
sus necesidades del proyecto.

Muchas de las variaciones posteriores de las regiones ultraperiféricas, incluidas OpenUP /

Basic, el código abierto, versión ligera de RUP, se presentan ahora como procesos
separados en su propio derecho, y atender a los diferentes tipos y tamaños de proyectos,
tendencias y tecnologías de desarrollo de software.

Históricamente, como el RUP es a menudo la medida para cada proyecto por un experto
en procesos RUP, el éxito global del proyecto puede ser algo dependiente de la
capacidad de esta persona.

Configuración de la disciplina y de la gestión

La disciplina de la gestión del cambio en el negocio con RUP abarca tres tratamientos
específicos: configuración, solicitudes de cambio, y el estado y de medida.

La gestión de configuración: gestión de la configuración es responsable de la

estructuración sistemática de productos. Los artefactos tales como documentos y modelos
necesitan estar bajo el control de versiones y estos cambios deben ser visibles. También
realiza un seguimiento de las dependencias entre los artefactos de manera que todos los
artículos relacionados se actualizan cuando se realizan cambios

La gestión del cambio de solicitud: Durante el proceso de desarrollo del sistema con
muchos artefactos que existen varias versiones. El CRM realiza un seguimiento de los
cambios propuestos

El estado y la medición de la gestión: las solicitudes de cambio tienen los estados:

nuevo, conectado, aprobado, asignado y completa . La solicitud de cambio también tiene
atributos como la causa raíz, o la naturaleza (como el incumplimiento y recuperación),
prioridad, etc.

Estos estados y atributos se almacenan en la base de datos para producir informes

útiles sobre el progreso del proyecto. Racional también tiene un producto para mantener
las solicitudes de cambio llamados ClearQuest . Esta actividad tiene procedimientos a
seguir

Proyecto de Gestión de la disciplina

La planificación del proyecto en el RUP se produce en dos niveles. Hay un grano fino o
planes de fase que describe el proyecto en su totalidad, y un número de alta granularidad
o planes de iteración que describe los pasos iterativos.

Este curso se centra principalmente en los aspectos importantes de un proceso de

desarrollo iterativo: La gestión de riesgos; La planificación de un proyecto iterativo a
través del ciclo de vida y para una iteración en particular; Y el proceso de seguimiento de
un proyecto iterativo, la métrica. Sin embargo, esta disciplina de RUP no pretende cubrir
todos los aspectos de la gestión de proyectos.

Por ejemplo, no cubre cuestiones tales como:

 Gestión de personas: contratación, formación, etc.

 Presupuesto general: definición, asignación, etc.
 Gestión de contratos: con los proveedores, clientes, etc.

Principios y las mejores prácticas de la metodología RUP

La metodología RUP se basa en un conjunto de principios de desarrollo de software y las

mejores prácticas, por ejemplo:

1. Desarrollo de software iterativo

2. La gestión de requisitos
3. El uso de una arquitectura basada en componentes
4. Software de modelado visual
5. La verificación de la calidad del software
6. Control de cambios en el software

Desarrollo iterativo

Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticada,

no se puede definir el problema y construir software en un solo paso. Los requisitos
cambiarán a menudo en el curso del desarrollo del proyecto , debido a las restricciones de
la arquitectura , las necesidades del usuario o para una mayor comprensión del problema
original.

Los cambios permiten que el proyecto para estar constantemente refinada, y la señal a los
elementos del proyecto de alto riesgo como las tareas de mayor prioridad. Idealmente, al
final de cada iteración habrá una versión ejecutable , lo que ayuda a reducir el riesgo de
configuración de diseño, que permite una mayor respuesta de los usuarios y ayudar al
desarrollador a permanecer centrado.

RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:

 La integración se hace paso a paso durante el proceso de desarrollo, cada paso

se limita a unos pocos elementos
 La integración es menos complejo, reduciendo el coste y aumentar la eficiencia
diseño de las piezas por separado y / o implementación pueden ser fácilmente
identificados para su posterior reutilización
 Requisitos cambios son registrados y pueden ser acomodados
  Los riesgos se abordan en el comienzo del desarrollo y cada iteración permite la
verificación de riesgos ya percibidas y la identificación de nuevos
 Para la arquitectura de software se mejora a través de un repetidor scrutinize

El uso de iteraciones, un proyecto tendrá un plan general, así como varios planes de
iteración. La participación de las partes interesadas a menudo se alienta a cada entrega.
En esta forma, las entregas sirven como una manera de conseguir el compromiso de los
involucrados, mientras que también promueve una comparación constante entre las
necesidades y el desarrollo de la organización a los conflictos que surjan.

La gestión de requisitos

La gestión de requisitos en RUP se centra en encontrar el final – el usuario necesita para

la identificación y especificación de lo que necesita y la identificación de lo que debe ser
cambiado. Esto trae los siguientes beneficios:

La corrección de los requisitos genera la corrección del producto, por lo que se satisfacen
las necesidades de los usuarios.
se incluirán las características requeridas, lo que reduce el costo de los acontecimientos
posteriores.

RUP sugiere que la administración de requerimientos tiene que seguir las actividades:

 Análisis de los problemas es que de acuerdo con el problema y crear medidas

que probarán su valor para la organización
 La comprensión de las necesidades de sus grupos de interés es para
compartir el problema y los valores con los principales interesados y elevar lo que
las necesidades están involucrados en el desarrollo de la idea
 La definición del problema es la definición de las características de las
necesidades y el diseño de los casos de uso , actividades que mostrarán
fácilmente los requisitos de alto nivel y el esquema modelo de uso del sistema
 Administrar el alcance del sistema es el alcance de los cambios que se
comunica con base en el progreso y los resultados seleccionados en el orden en
que los diagramas de flujo de los casos de uso son atacados
 Refinar los ajustes del sistema de ofertas con los detalles de los diagramas de
flujo de casos de uso con las partes interesadas con el fin de crear una
especificación de las aplicaciones de software que puede servir como un contrato
entre su grupo y el cliente y puede guiar las actividades de ensayo y proyecto
 Los requisitos de gestión del cambio es la forma de identificar las llegadas de
los cambios en las aplicaciones en un proyecto que ya ha comenzado

El uso de una arquitectura basada en componentes

La arquitectura basada en componentes crea un sistema que es fácilmente extensible,

intuitiva y fácil de entender y promueve la reutilización de software.

Un componente de frecuencia asociado con un conjunto de objetos en objetos –

programación orientada.
Arquitectura de software aumenta en importancia cuando un sistema se hace más grande
y más compleja. RUP se centra en la producción de arquitectura básica en los primeros
pocos iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos iniciales de
desarrollo.

La arquitectura desarrollada en cada iteración para convertirse en la arquitectura final del

sistema. RUP también propuso reglas de diseño y limitaciones para capturar normas de
arquitectura. Para el desarrollo iterativo es posible para identificar gradualmente
componentes que a continuación se pueden desarrollar o comprado reutilizada. Estos
componentes se construyen a menudo en las infraestructuras existentes, tales como
CORBA y COM o Java EE, o PHP

Software de modelado visual

Haciendo abstracción de su programación de su código y representarla por medio de

bloques de construcción gráficas constituye una forma eficaz de obtener una visión
general de una solución. El uso de esta representación, los recursos técnicos pueden
determinar la mejor manera de poner en práctica un conjunto dado de interdependencias
lógicas.

Esto también crea una capa intermedia entre el proceso de negocio y el código necesario
a través de tecnología de la información. Un modelo en este contexto es una pantalla y al
mismo tiempo una simplificación de un diseño complejo. RUP especifica qué modelos son
necesarios y por qué.

El Lenguaje de Modelado Unificado (UML) se puede utilizar para el modelado de casos

de uso, diagramas de clases y otros objetos. RUP también analiza otras formas de
construir estos modelos.

Software de control de calidad

Aseguramiento de la calidad del software es el punto de fallo más común en los

proyectos de software, ya que esto es a menudo algo que no se había pensado
anteriormente y, a veces es tratado por diferentes equipos. RUP ayuda en la planificación
del control de calidad y se encarga de su construcción en todos los procesos de
participación de todos los miembros del equipo.

No es una tarea está dirigida específicamente a la calidad ; RUP supone que cada
miembro del equipo es responsable de la calidad durante todo el proceso. El proceso se
centra en el descubrimiento del nivel esperado de la calidad y proporciona pruebas en los
procesos para medir este nivel.

Control de cambios en el software

En todos los proyectos de software, los cambios son inevitables. RUP define métodos
para controlar, seguir y supervisar estos cambios. RUP define también el trabajo seguro
de espacios (espacios de trabajo seguros en inglés), lo que garantiza que un sistema de
ingeniería de software no se ve afectada por los cambios en otros sistemas. Este
concepto es pegar bien con arquitecturas de software basados en componentización.