PROGRAMACIÓN DE SOFTWARE BASADA EN

REQUERIMIENTOS

METODOLOGIA RUP

1
METODOLOGIA RUP

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado
Ralacional) es un producto del proceso de ingeniería de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización
del desarrollo.
Su meta es asegurar la producción del software de alta calidad que resuelve las
necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

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.

2
Objetivos del RUP

La metodología RUP consiste en una estructura de trabajo de proceso con el objetivo del
producto y por tanto basada en el modelo Unified Modeling Language (UML), cuando se
habla de programación orientada a objetos.
El UML compone un lenguaje para definir una secuencia de artefactos y ayudar en la
ejecución de las tareas del sistema a desarrollar, a través de diferentes tipos de diagramas.
Todas las técnicas y prácticas utilizadas en el modelo RUP están probadas en la industria
del software y la gestión de proyectos.
Aunque RUP se utiliza para proyectos complejos y con equipos extensos, permite realizar
actividades y artefactos de acuerdo con la elección del equipo y se puede adaptar
para agilizar el proceso .

El modelo se detalla desde tres

perspectivas:
•Dinámica
•Estático
•Práctica
3
Es en la perspectiva dinámica que compone el ciclo de vida del proyecto, en el que se divide
en 4 fases secuenciales, denominadas en: inicio, elaboración, construcción y transición.

Desde un punto de vista estático, el RUP se enfoca en las actividades que se llevan a cabo
durante el ciclo de vida del proyecto, estas actividades se denominan workflows.
Un workflow (flujo de trabajo) es un conjunto de actividades, orquestadas y repetibles,
que se realizan para alcanzar un requerimiento del negocio.

Finalmente, la visión práctica del proceso consta de buenas prácticas de proceso, que son las
recomendaciones del método para que todas las actividades se preparen de la mejor manera.

Para aclarar cómo funciona el desarrollo de un proyecto en el RUP, expliquemos qué se hace
en cada una de las 4 fases del RUP en el siguiente tema.

4
Las 4 fases del RUP

Como se indicó en el tema anterior, las fases del RUP están involucradas dentro de la
perspectiva del desarrollo dinámico .
Es en este momento que se le da planificación al proyecto, relevamiento de recursos,
implementación, pruebas, entre otros. A continuación, comprendamos un poco más sobre cada
paso, por separado.

Análisis Elaboración Construcción Transición

5
Comienzo o Análisis

Es en este momento que se elabora la planificación del proyecto con los stakeholders, son
ellos quienes han descrito los requisitos para el sistema a desarrollar.
La etapa se realiza en un corto período de tiempo. Guía al equipo para analizar la viabilidad
del proyecto y cómo empezar a definir los primeros pasos. Usando este concepto tenemos
una metodología llamada Lean Inception .

Lean Inception. Es útil cuando el equipo necesita desarrollar un Producto Mínimo Viable
(MVP) y evolucionar un producto de manera iterativa e incremental. La característica
principal del MVP es identificar si vale la pena continuar con la construcción del producto.

Por ejemplo: En una semana de trabajo colaborativo entenderemos los objetivos del
producto, identificaremos los usuarios principales y también las funcionalidades esenciales
del producto de tal manera que el proyecto pueda ser estimado.

6
Lean Inception(comienzo claro) es un taller colaborativo para alinear a un grupo de personas
sobre la propuesta de solución a construir, es decir, sobre el Producto Mínimo Viable
(MVP).
Este taller comprende una secuencia de actividades precisamente para promover la
alineación y definición de objetivos, estrategias y el alcance del producto.
En resumen, mientras Lean Inception se ocupa de la alineación de un equipo sobre el
producto, la solución a construir, otras metodologías ágiles ayudan a este equipo a ser
eficiente en su forma de trabajar.

En el mundo de los negocios, los stakeholders son aquellos individuos o grupos que
tienen interés e impacto en una organización y en los resultados de sus acciones. Algunos
de los ejemplos más comunes de stakeholders son los empleados, los accionistas, los
clientes, los proveedores, los gobiernos y las comunidades

7
En el mundo de los negocios,
los stakeholders (partes
interesadas) son aquellos
individuos o grupos que tienen
interés e impacto en una
organización y en los resultados
de sus acciones. Algunos de los
ejemplos más comunes de
stakeholders son los
empleados, los accionistas, los
clientes, los proveedores, los
gobiernos y las comunidades.

8
Elaboración

En la fase de elaboración, o elaboración, busca relevar casos, documentación, estudios base,

es decir, modelos para orientar el proyecto. Esto es para orientar cuál será la mejor manera de
acuerdo con las premisas de los interesados.
Tras todo este conocimiento, se elabora un plan de proyecto, con todas las características y
especificaciones, de la forma más detallada posible.

 Tanto la funcionalidad como el dominio del problema se

estudian en profundidad
 Se define una arquitectura básica
 Se planifica el proyecto considerando recursos disponibles

9
Construcción
Ahí es cuando se termina la construcción del proyecto, por eso tiene ese nombre. El principal
objetivo es la elaboración del producto. Dado que el método se basa en el desarrollo de
software, estamos hablando de crear códigos.
Además, es en esta etapa que se realizan las primeras pruebas para que se prepare la base
inicial para la etapa de transición.

 Gran parte del trabajo es programación y pruebas.

 Se documenta tanto el sistema construido como el manejo del mismo.
 Esta fase proporciona un producto construido junto con la documentación.

10
Transición

La transición se expresa como transición, es decir, la fase que pasa el proyecto desde el punto
de prueba hasta la implementación.
Después de todas las pruebas realizadas y con el objeto listo, llega el momento de ponerlo a
disposición del usuario final, es decir, la entrega del proyecto.
Además de la entrega, esta fase incluye la realización de capacitaciones y asegurar que el
objeto final resuelva todos los problemas de las partes interesadas.
Dadas todas las fases que componen un proyecto utilizando la metodología RUP, es importante
destacar que en el desarrollo de estas actividades todo el equipo necesita estar orientado a
algunas prácticas y realizar los artefactos de forma alineada.

 Se libera el producto y se entrega al usuario para un uso real.

 Se incluyen tareas de marketing, empaquetado atractivo, instalación,
configuración, entrenamiento, soporte, mantenimiento, etc.
 Los manuales de usuario se completan y refinan con la información
anterior.

11
Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el
contexto del usuario, cambios en la tecnología subyacente, reacción a la competición, etcétera. Los
ciclos evolutivos tienen típicamente fases de concepción y elaboración mucho más cortas, puesto
que la definición y la arquitectura básicas del producto son determinadas por los ciclos de desarrollo
anteriores. Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un
producto significativo o una redefinición arquitectónica.

Análisis Elaboración Construcción Transición

ARQUITECTURA

12
13
14
Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia
para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso
como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de
Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema.
También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y
una guía del trabajo.

Un Caso de Uso es una secuencia de pasos a seguir para la realización de un fin o propósito, y se
relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que
conlleva la realización e implementación de un Requerimiento planteado por el Cliente. Desde el punto de
vista del desarrollo lo podemos llamar “Algoritmo de Programación”.

15
Importancia de los diagramas de casos de uso
Como ya se ha mencionado, los diagramas de casos de uso se utilizan para reunir los requisitos
de uso de un sistema. Dependiendo de sus necesidades, puede utilizar esos datos de diferentes
maneras. A continuación se presentan algunas formas de usarlas.

•Identificarlas funciones y la forma en que los roles interactúan con ellas – El propósito
principal de los diagramas de casos de uso.
•Para una visión de alto nivel del sistema – Especialmente útil cuando se presenta a los
administradores o a las partes interesadas. Se pueden destacar los papeles que interactúan con
el sistema y la funcionalidad proporcionada por el sistema sin profundizar en el funcionamiento
interno del sistema.
•Identificar los factores internos y externos – Esto puede parecer simple pero en grandes
proyectos complejos un sistema puede ser identificado como una función externa en otro caso de
uso.

16
Usar los objetos del Diagrama de Caso

Los diagramas de caso de uso consisten objetos.

•Actor
•Caso de uso
•Sistema

17
Actor

El actor en un diagrama de caso de uso de es cualquier entidad que

desempeñe un papel en un sistema determinado. Puede ser una
persona, una organización o un sistema externo y normalmente se
dibuja como el esqueleto que se muestra a continuación.

18
Caso de uso

Un caso de uso representa una función o una acción dentro del

sistema. Está dibujado como un óvalo y nombrado con la función. Case.
El símbolo del caso de uso en el diagrama es una elipse con su nombre
dentro, tal como se muestra a continuación:

Calcular IVAliminar
Transacción

19
 Relación Descripción Notación
Asociación Línea de comunicación entre un actor
y un caso de uso en el que participa
Una relación entre un caso de
uso general y un caso de uso
Generalización más específico, que hereda y
añade propiedades al caso de
uso base
Inserción de comportamiento
Inclusión adicional en un caso de uso base,
«include»
que describe explícitamente la
inserción -------------->
Inserción de comportamiento
Extensión adicional en un caso de uso base
«extend»
que no tiene conocimientos obre él
-------------->
Realización Establece una relación entre el caso
de uso y los diagramas que
describen la funcionalidad del caso
de uso

20
21
Sistema

El sistema se utiliza para definir el alcance del caso de uso y se dibuja como un rectángulo.
Este es un elemento opcional pero útil cuando se visualizan sistemas grandes. Por ejemplo,
puede crear todos los casos de uso y luego utilizar el objeto del sistema para definir el
alcance que abarca su proyecto. O incluso puedes usarlo para mostrar las diferentes áreas
cubiertas en los diferentes lanzamientos.
Rectángulo que
limita al Sistema

22
¿QUÉ ES UN INCLUDE?
Cuando relacionamos dos casos de uso con un "include", estamos
diciendo que el primero (el caso de uso base) incluye al segundo (el caso Venta en Caja
de uso incluido). Es decir, el segundo es parte esencial del primero. Sin
<<Include>>
el segundo, el primero no podría funcionar bien, pues no podría cumplir
su objetivo. Para una venta en caja, la venta no puede considerarse
completa si no se realiza el proceso para cobrarla en ese momento.
Cobrar Producto

¿QUÉ ES UN EXTENDS?
Una de las diferencias básicas es que en el caso del "extend" hay
situaciones en que el caso de uso de extensión no es indispensable que
ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo Venta en Caja
original del caso de
uso base.
<<extend>>
<<Include>>

Cobrar Producto
Despacho
23
Ejemplo de Casos de Uso

24
25
26
27