METODOLOGÍA

RUP
P R E S E N TA D O P O R : A N D R E S F E L I P E C O R T E S
VA L E N C I A
HISTORIA RUP
RUP fue creado por Grady Booch (creador del método Booch), Ivar Jacobson y James Jacobson
(Creador de la Técnica de Modelado de Objetos), la misma aparece en Junio de 1998 con el acrónimo
RUP 5.0 y puesto a la disposición del publico a inicios de 1999 y su funcionamiento se centraba en las
personas, los procesos y las herramientas
Su funcionalidad parte de una serie de métodos los cuales se puede comentar,
el método ericcson, método utilizado por la compañía del mismo nombre para el proceso unificado
de desarrollo, a este proceso se le anexa un proceso denominado Objetory creado por Jacobson. En
el año 1995 se anexa el enfoque Rational dando paso a ROP 4.0 (Rational Objetory Process) que
junto a la OMT (Objects Modeling Technique) de Rumbaugh y Booch lo que permitió dar origen a
UML, esta herramienta fortaleció mucho mas a ROP en el empleo de caso de usos. Para el año 1996,
surge ROP 4.1 con la integración de actividades SQA (Software Quality Assurance, Software de
Control de Calidad por sus siglas en ingles), esto permitía el aseguramiento de un software de calidad
que se adapte a las necesidades del usuario final por medio de la actualización de UML. Para 1998 se
lanza al mercado una fase de prueba, con un UML fortalecido y la integración de los enfoques de
la ingeniería de Negocios y la Ingeniería de Datos a partir de aquí nace RUP, con los lineamientos y
vertientes que hoy día conocemos.
POR CUANTO TIEMPO SE UTILIZA RUP
• El plato de utilización es de 4 meses en adelante, si el desarrollo del proyecto es de menos
tiempo no te sirve utilizar la metodología rup
DIMENSIONES

• Eje horizontal representa tiempo y demuestra los aspectos del ciclo del proceso
• Eje vertical representa las disciplinas, que agrupan actividades definidas lógicamente por la
naturaleza
EVOLUCIÓN DEL RUP
• Objectory Process 1.0-3.8 (1987-1995)
1. Metodología de Ericsson
• Rational Objectory Process 4.1 (1996-1997)
1. Metodología de Rational
2. UML 1.1
• Rational Unified Process 5.0 (1998)
1. Pruebas de Ejecución
2. Administración de requerimientos
3. Administracion de configuración y cambios
4. Ingeniería de negocios
5. Diseño de Interfaz con el usuario
6. UML 1.2
• Rational Unified Process 5.5 (1999)
1. Desarrollo basado en Web Sistemas de Tiempo Real
2. UML 1.3
• Rational Unified Process (2000)
METODOLOGÍA 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
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.
EJEMPLOS DONDE SE UTILIZA LA RUP
• Visión general del proyecto
En el siguiente caso de ejemplo se describe un proyecto de la empresa ABC, denominado Proyecto X. Proyecto X es un equipo que consta
de un gestor de proyectos, Jill, y cuatro programadores, Angus, David, Susan y Philip. La duración del proyecto es de cuatro meses.
Jill está considerando utilizar RUP como base para el proceso de desarrollo de software de su proyecto. Instala RUP, que instala por
omisión la configuración de proceso "RUP clásico". Revisa las partes de RUP clásico que son relevantes para la personalización de un
proceso en un proyecto.
• Empieza por evaluar las necesidades de proceso que tiene el proyecto, en colaboración con su equipo. Sus conclusiones son las
siguientes:
• El proceso y las herramientas existentes para la gestión de la configuración están funcionando bien, por lo que no hace falta cambiar
este aspecto del proceso.
• El equipo tiene alguna experiencia con guiones de uso y arquitecturas de componentes, pero le vendría bien algo más de guía en estas
áreas.
• El proyecto se beneficiaría de un enfoque de desarrollo iterativo, como medio de reducir rápidamente los riesgos más importantes del
proyecto.
• Los interesados tienen unas buenas relaciones informales de trabajo con el equipo de desarrollo, y no los contratos formales y las
revisiones no son necesarios. Los interesados tiene una visibilidad continuada durante el desarrollo. El equipo está altamente
cualificado y es muy disciplinado, y en el pasado ha producido productos de calidad sin apenas proceso formal.
• Dado el breve plazo de tiempo para este proyecto, sólo se aplicarán cambios menores al conjunto de herramientas.
• Se iniciará una actividad paralela distinta para investigar las ventajas de las herramientas, reutilizar las oportunidades y perfeccionar el
proceso para proyectos futuros.
• Personalización general
Empaquetado de los activos específicos del proyecto en un plug-in.
El proceso de RUP existente se parece bastante a lo que necesita el proyecto, pero no lo suficiente. Jill continúa el
perfeccionamiento del proceso creando un plug-in específico del proyecto que contiene activos específicos del
proyecto aplicables.
Concretamente, Jill inicia Rational Method Composer (RMC) y crea un nuevo plug-in de método que contiene:
• directrices para las herramientas que van a utilizarse en el proyecto
• directrices reutilizadas de un proyecto similar anterior, incluidas las directrices de diseño y la de gestión de
cambios y configuración
• directrices para la revisión y la valoración.
Además de asociar esta guía a los elementos de método RUP adecuados, también perfecciona las vistas de
procesos de RUP existentes para que incluyan esta guía.
También añade una página de "Introducción al proceso del Proyecto X" a la vista Cómo empezar RUP, en la que
describe la filosofía básica del proceso configurado. Por ejemplo, indica que las plantillas incluidas sirven como guía
para el contenido, pero el formato es opcional. También indica dónde se encuentran las versiones actuales de los
productos de trabajo clave para el proyecto.
Para obtener información sobre cómo crear un plug-in de método utilizando RMC, consulte Guía de la
herramienta: Crear un plug-in de método utilizando Rational Method Composer. Para obtener información sobre
cómo rellenar el plug-in, consulte la Guía de la herramienta: Desarrollar contenido del método utilizando Rational
Method Composer.
• Definición de una configuración y publicación específicas del proceso
Ahora que Jill ha empaquetado los activos específicos del proyecto en un plug-in, puede desarrollar
una configuración de RUP que incluya el plug-in específico del proyecto.
Jill inicia Rational Method Composer (RMC) y selecciona la configuración de un proyecto pequeño
como punto de inicio. Copia la la configuración de un proyecto pequeño en una nueva configuración a
la que denomina "Proyecto X de ABC".
Jill abre la nueva configuración y selecciona y deselecciona algunos de los paquetes de métodos y plug-
ins para llevara a cabo una primera configuración poco detallada de la configuración que en realidad
desea. Por ejemplo, deselecciona el paquete del método "Diseño de base de datos", puesto que el
equipo no va a hacer ningún modelado de datos en este proyecto, y selecciona el plug-in específico del
proyecto creado en la sección anterior.
A continuación, Jill crea un nuevo proceso de entrega en su plug-in de método utilizando el proceso
de entrega que proporciona la configuración de un proyecto pequeño como punto de inicio. Edita el
nuevo proceso de entrega, añade algunas tareas a cada fase y suprime otras. A continuación, publica los
resultados.
Para obtener información sobre cómo desarrollar procesos utilizando RMC, consulte Guía de la
herramienta: Desarrollar procesos utilizando Rational Method Composer. Para obtener información
sobre cómo publicar procesos utilizando RMC, consulte la Guía de la herramienta: Publicar
configuraciones del método utilizando Rational Method Composer.
• Roles y ciclo vital
El Proyecto X tiene un equipo pequeño, por lo que cada persona es responsable de varios roles
de RUP. Jill describe las responsabilidades de cada persona en el plan de desarrollo de software.
Por ejemplo, en el Proyecto X, Jill es responsable de los roles de gestor de proyectos y de
ingeniero de proceso.
• Revisión
Jill proporciona un borrador de configuración de RUP y el plan de desarrollo de software al
equipo y a otros interesados para que lo revisen. El equipo empieza a seguir el proceso. Se
cometen algunos errores y se perfecciona el proceso. Finalmente, el proyecto tiene éxito y el
equipo consigue un proceso adecuadamente afinado que puede aplicarse a proyectos futuros.
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. Iteraciones son ventanas de tiempo; iteraciones han definido término
como las fases son objetivos.
Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y documentar el proyecto y permite
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 – interesados – 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
definida 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.