Metodología Rup

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.

 Originalmente se diseñó un proceso genérico y de dominio público, el Proceso

Unificado, y una especificación más detallada, el R U P, que se vendiera como
producto independiente.

Principios de desarrollo

El RUP está basado en 6 principios clave que son los siguientes:

 Adaptar el proceso: El proceso deberá adaptarse a las necesidades del cliente ya

que es muy importante interactuar con él.
 Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser
diferentes, contradictorios o disputarse recursos limitados.
 Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un
modo interno, en etapas iteradas.

Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino
múltiples equipos.

 Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos

reutilizables tales como patrón del software, marcos de referencia (frameworks) por
nombrar algunos.
 Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada
iteración, sino en todos los aspectos de la producción. El ciclo de vida RUP es una
implementación del Desarrollo en espiral. Fue creado ensamblando los elementos
en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e
iteraciones.

Principales 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
 Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e

incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye
artefactos (que son los

Productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) Y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).

Fases RUP comprende dos aspectos importantes por los cuales se establecen las
disciplinas: Proceso:

 Modelado de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
 Despliegue Soporte: En esta parte nos encontramos con las siguientes etapas:
 Gestión del cambio y configuraciones
 Gestión del proyecto
 Entorno
 La estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las cuatros
fases descritas anteriormente:
 Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
producir el plan de las fases y el de iteraciones posteriores. “detalles muy
generales de la arquitectura de software”
 Fase de Elaboración: En la fase de elaboración se diseña la solución preliminar, se
seleccionan los casos de uso que permiten definir la arquitectura base del sistema
y se desarrollaran en esta fase, y el primer análisis del dominio del problema.
 Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del
sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios
de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras
para el proyecto.

Fase de Transición (cierre) El propósito de esta fase es asegurar que el software esté
disponible para los usuarios finales, ajustar los errores y defectos encontrados en las
pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario.

Ciclo de vida

 Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología ( Durante la fase de inicio las iteraciones
hacen mayor énfasis en actividades de modelado del negocio y de requisitos )
 En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de
la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la
baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de

una serie de iteraciones. (Para cada iteración se seleccionan algunos Casos de Uso)

 En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios

Artefactos

 RUP en cada una de sus fases realiza una serie de artefactos que sirven para
comprender mejor tanto el análisis como el diseño del sistema Inicio:
 Documento Visión
 Especificación de Requisitos Elaboración:
 Diagramas de caso de uso

Construcción: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lógica o
Diagrama de clases o Modelo E-R (Si el sistema así lo requiere) Vista de Implementación
o Diagrama de Secuencia o Diagrama de estados o Diagrama de Colaboración Vista
Conceptual o Modelo de dominio Vista física o Mapa de comportamiento a nivel de
hardware.

Fases y artefactos

Ventajas

Está basada totalmente en mejoras prácticas de la metodología:

Reduce riesgos del proyecto.

Incorpora fielmente el objetivo de calidad.

Integra desarrollo con mantenimiento.

Desventajas

 Pretende prever y tener todo el control de antemano:

 Modelo genera trabajo adicional.
 Genera muchos costos.
 No recomendable para proyectos pequeños.

ARTEFACTOS EN RUP

En Rup en cada una de sus fases realizan una serie de artefactos para saber mejor la
función y estructura de un programa.

Un artefacto puede ser:

 Un documento: como un Caso de Negocio o un documento de la arquitectura del

Software.
 Un modelo: como un modelo de caso de uso.
 Un elemento de un modelo: como una sola clase de todo el Diagrama de Clases.

Cada artefacto sirven para cada paso para la elaboración del programa estos artefactos
son los siguientes Etapas:
1. INICIO:

 Documento Visión
 Especificación de Requerimientos

2. ELABORACIÓN:

 Diagramas de caso de uso

3. CONSTRUCCIÓN:

Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LOGICA:

 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)

VISTA DE IMPLEMENTACIÓN:

 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración

VISTA CONCEPTUAL:
  Modelo de dominio

VISTA FÍSICA:

 Mapa de comportamiento a nivel de hardware.

 Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos.
 Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.
 Especificación de requisitos faltantes.
 Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación
iterativa.
 Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el
caso

4. TRANSICIÓN:

 Pruebas finales de aceptación.

 Puesta en producción.
 Estabilización

LOS ROLES EN RUP:

Analistas:

 Analista de procesos de negocio.

  Diseñador del negocio.

 Analista de sistema.

 Especificador de requisitos.

Desarrolladores:

 Arquitecto de software.

 Diseñador

 Diseñador de interfaz de usuario

 Diseñador de cápsulas.

 Diseñador de base de datos.

 Implementador.

 Integrador.

Gestores:

 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.

Apoyo:

 Documentador técnico

 Administrador de sistema
  Especialista en herramientas

 Desarrollador de cursos

 Artista gráfico

Especialista en pruebas:

 Especialista en Pruebas (tester)

 Analista de pruebas

 Diseñador de pruebas

Otros roles:
 Stakeholders.

 Revisor

 Coordinación de revisiones

 Revisor técnico

 Cualquier rol

Para grandes organizaciones con un números equipos de ingenieros y la comunicación

entre cada equipo es crítica por lo tanto es necesario que los artefactos sean completos y
bastante comprensivos.
En tanto que para pequeños proyectos no es recomendable presentarse tanto rigor en las
preparaciones de los artefactos, la eficiencia del proceso depende más de las habilidades
de cada trabajador
Casos de Uso

Principalmente la metodología Rup se centra en los casos de uso por que se centra en la
funcionalidad que el sistema debe poseer para las necesidades de un usuario, además es
el conductor que orienta las actividades de desarrollo por que los caso de uso son una
serie de eventos desde la perspectiva de usuario

Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones

entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es
iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores,
intercambia datos o control con el sistema, participando de ese caso de uso.

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente

por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los
casos de uso se representan con un óvalo, con el nombre del caso en su interior. Es
importante notar que el nombre del caso siempre está expresado desde el punto de vista
del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se
llama Recibiendo información de pedidos y no Generando información de pedidos.

Los casos de uso tienen las siguientes características:

1) Están expresados desde el punto de vista del actor.

2) Se documentan con texto informal.

3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con
él, aunque el énfasis está puesto en la interacción.

4) Son iniciados por un único actor.

5) Están acotados al uso de una determinada funcionalidad claramente diferenciada del

sistema.

El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que
todo sistema tiene un único caso de uso Usando el Sistema. Sin embargo, la
especificación resultante sería de poco utilidad para entenderlo; sería como implementar
un gran sistema escribiendo un único programa.
La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por
ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los
pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos? Si
bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en
principio la respuesta a todas estas preguntas es que son todos casos de uso distintos.

Lamentablemente, si en la programación los criterios para dividir la funcionalidad en

programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en
casos de uso son aún más difusos, y por esto se hace importante usar el sentido común
en estas decisiones.

En principio podríamos decir que la regla general es: una función del sistema es un caso
de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función.
Por ejemplo, si uno quiere dar de alta un pedido, accederá a la funcionalidad de alta de
pedidos del sistema. Sin embargo, si uno quiere dar de alta un campo del pedido, no debe
indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un pedido es
una función que forma parte de un caso de uso mayor: dar de alta un pedido.

Esta regla, si bien puede ser útil, no debe seguirse al pie de la letra, ya que se puede
prestar a confusiones. Por ejemplo, supongamos que uno quiere especificar un sistema en
el cual los usuarios pueden ver un pedido, y tienen disponibles funciones para ver el
siguiente pedido, el anterior, el último y el primero. El actor debe indicar al sistema que
quiere acceder a cada una de esas funciones, y según nuestra regla serían todas ellas
casos de uso distintos. Sin embargo, en esta situación es mucho más práctico definir un
único caso de uso navegando pedidos, que especificarlos todos como casos de uso
distintos.

Cuando pensamos en el grado de detalle de la división de los casos de uso también

resulta útil imaginar que uno está escribiendo el manual del usuario del sistema. A nadie
se le ocurriría escribir un manual de usuario con un solo capítulo en el que se describe
toda su funcionalidad. De la misma forma, no se debe escribir una especificación con un
solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
cantidad de capítulos del manual es variable dependiendo de la persona que lo escriba.
Para dar una idea aproximada del nivel de detalle de la división de los casos de uso en
casos menores, también podemos pensar que un trabajo práctico de Ingeniería del
Software I debiera tener alrededor de 8 casos de uso primarios.