TRABAJO:

“METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS)”

CURSO:
Metodologías de Desarrollo de Software
DOCENTE:
Ing. Jorge Condori Chavez
INTEGRANTES:
Huanca Ramirez, Rosalinda
Apaza Choque, John Jesus
Quispe Cahui, Deicy Yanet
Vilca Arisaca, Alanis Elenni
SEMESTRE: IV
Puno – Perú
2022
 INDICE
INTRODUCCIÓN ........................................................................................................................................ 3
HISTORIA DE LA METODOLOGÍA RUP ........................................................................................................ 4
Rational Unified Process (RUP) ................................................................................................................. 5
DEFINICIÓN: ......................................................................................................................................... 5
ENTONCES ¿QUÉ ES LA METODOLOGÍA RUP? .................................................................................. 5
¿Cuándo se usa RUP? ....................................................................................................................... 5
¿Dónde se aplica el proceso unificado? ............................................................................................ 5
CARACTERÍSTICAS DEL PROCESO DE LA METODOLOGÍA RUP .................................................................... 6
Características esenciales del RUP ........................................................................................................ 6
Proceso Dirigido por el caso de Uso. ................................................................................................ 6
Proceso de Iterativo e incremental...................................................................................................6
Proceso Centrado en la Arquitectura................................................................................................ 7
FASES DE LA METODOLOGÍA RUP ............................................................................................................. 8
FASES ................................................................................................................................................... 8
Proceso: ........................................................................................................................................... 8
Soporte: ........................................................................................................................................... 8
COMPONENTES DEL RUP .......................................................................................................................... 9
FLUJOS DE TRABAJO DEL RUP ................................................................................................................... 9
Flujos de trabajo:..................................................................................................................................9
1.1 Modelado de Negocio .............................................................................................................. 10
1.2 Requerimientos ........................................................................................................................ 11
1.3 Análisis y Diseño ....................................................................................................................... 12
1.4 Implementación y pruebas ....................................................................................................... 13
1.5 Despliegue ............................................................................................................................... 15
1.6 Gestión y Configuración de Cambios ........................................................................................ 16
1.7 Gestión del proyecto y entornos .............................................................................................. 16
Artefactos de gestión y técnicos ............................................................................................................. 16
Artefactos .......................................................................................................................................... 16
Inicio .............................................................................................................................................. 17
Elaboración .................................................................................................................................... 17
Construcción .................................................................................................................................. 17
Vista Lógica .................................................................................................................................... 17
Vista de implementación................................................................................................................ 17
Vista conceptual............................................................................................................................. 17
Vista Física ..................................................................................................................................... 17
BIBLIOGRAFÍA ......................................................................................................................................... 17
 INTRODUCCIÓN
En el siguiente trabajo monografía tiene como principal objetivo dar a conocer la
metodología RUP que su abreviatura en inglés es (Rational Unitifited Process)
para el desarrollo de software y el correcto uso de los diversos modelos UML
(Lenguaje Unificado de Modelo) que van ayudar en el análisis y diseño. Conocer
el RUP es esencial para un estudiante de Ingeniería de Sistemas, pero en este
caso para estudiantes de la carrera de Computación e Informática. Uno de estos
es el caso ya mencionado RUP y el UML que te hacen más fácil el desarrollo de
un software con los famosos casos de uso, diagramas, y un sinfín de
herramientas. El trabajo se divide en tres grandes secciones que indican el cómo
se utiliza la metodología RUP. La primera sección muestra un poco de historia y
definición para un mejor entendimiento de lo que es el RUP, partes, dimensiones,
estructura, siglo de vida etc. La segunda parte nos muestra los pasos a realizarse
con una metodología RUP hasta llegar a la fase final del software que se ha
estado desarrollando y finalmente la tercera sección nos muestra las formas o
maneras de utilizar los diagramas UML para analizar cuales en verdad su calidad
de producto final que se llegó a desarrollar.
El Proceso Unificado es un proceso de desarrollo de software: “conjunto de
actividades necesarias para transformar los requisitos del usuario en un sistema
software”. RUP es un marco genérico que puede especializarse para una
variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de
organizaciones, niveles de aptitud y diferentes tamaños de proyectos.
RUP está basado en componentes, está formado por componentes software
interconectados a través de interfaces. RUP está dirigido por casos de uso,
centrado en la arquitectura, y es iterativo e incremental.
Por otro lado, RUP es el resultado de varios años de desarrollo y uso práctico en
el que se han unificado técnicas de desarrollo a través del UML, y trabajo de
muchas metodologías utilizadas por los clientes. La versión que se ha
estandarizado vió la luz en 1998 y se conoció en sus inicios como Proceso
Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este
proceso de desarrollo.
En la actualidad, la utilización de metodologías para el desarrollo de aplicaciones
es casi imposible omitirla, debido a la gran necesidad de control de variables que
conlleva el mismo desarrollo, y para la ordenada elaboración de las aplicaciones,
por lo tanto, seguir metodologías y estándares nos llevan a estar en
competitividad en todo momento. Es de suma importancia conocer el modo como
se interrelacionan metodologías con estándares y herramientas siguiendo un
único propósito, el cual consiste en la elaboración de aplicaciones de manera
eficiente, ordenada y con el menor número de defectos. La metodología RUP
nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se
podrá contar con guías para poder documentar e implementar de una manera
fácil y eficiente, todas las guías para un buen desarrollo, todo esto dentro de las
respectivas fases con las cuales cuenta.
 HISTORIA DE LA METODOLOGÍA RUP
Los orígenes de RUP se remontan al modelo espiral original que es de Barry
Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con
Boehm en la investigación. Y en el año de 1995 Rational Software compró una
compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por
haber incorporado los casos de uso a los métodos de desarrollo orientados a
objetos. El Rational Unified Process fue el resultado de una convergencia de
Rational Approach y Objectory (el proceso de la empresa Objectory AB). El
primer resultado de esta fusión fue el Rational Objectory Process, la primera
versión de RUP, fue puesta en el mercado en el año de 1998, siendo el arquitecto
en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado "The Unified Software
Development Process (ISBN 0-201-57169-2)" El Proceso Unificado de
Desarrollo de Software (ISBN 0-201-57169-2), y publicado en 1999 por Ivar
Jacobson, Grady Booch y James Rumbaugh.
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.
 Rational Unified Process (RUP)
DEFINICIÓN:
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado
de Racional) 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.
Según Jacaboson, I., Booch, G., Rumbaugh J.(1998) El nombre Proceso
Unificadose usa para describir el proceso genérico que incluye aquellos
elementos que son comunes a la mayoría de los refinamientos existentes.
También permite evitar problemas legales ya que Proceso Unificado de
Rationalo RUPson marcas registradas por IBM (desde su compra de Rational
Software Corporationen 2003).
Según Grady Booch(2000) un reflejo de lo que hemos visto en el trabajo con
literalmente decenas de miles de proyectos en los últimos 20 años, la
codificación de lo que funciona en las organizaciones exitosas y lo que está
notablemente ausente en los fallidos.
ENTONCES ¿QUÉ ES LA METODOLOGÍA RUP?
La metodología de desarrollo RUP por sus siglas en inglés ó Proceso de
Desarrollo Unificado 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.
¿Cuándo se usa RUP?
Primero, se puede utilizar RUP desde el principio de un nuevo proyecto de
software, y puede seguir utilizándolo en los ciclos de desarrollo subsiguientes
tiempo después de que el proyecto inicial haya terminado. No obstante, la forma
de utilizar RUP varía para ajustarse a sus necesidades.
Una de las preguntas más frecuentes es ¿Qué es RUP y scrum?
Scrum y RUP (Rational Unified Process) son consideradas metodologías ágiles.
En Scrum el alcance es definido en la Lista de Objetivos (Project Backlog) que
es reevaluado al fin de cada iteración (Sprint).
¿Dónde se aplica el proceso unificado?
El proceso unificado de desarrollo de software es un conjunto de actividades
usadas para transformar los requisitos de un usuario en un software; cuenta con
tres características clave: dirigido a casos de uso, centrado en la arquitectura,
iterativo e incremental (^Pereira^, ²⁰¹¹).
CARACTERÍSTICAS DEL PROCESO DE LA METODOLOGÍA RUP
Características esenciales del RUP
 Primero es un proceso dirigido por los Casos de Uso: El proceso utiliza
casos de uso para manejar el proceso de desarrollo desde la Incepción
hasta el Despliegue.
 Proceso Iterativo e Incremental: Se reconoce como el proceso
reconoce que es práctico dividir grandes proyectos en proyectos más
pequeños o mini-proyectos. Cada mini-proyecto comprende una iteración
que resulta en un incremento. Una iteración puede abarcar la totalidad de
los flujos del proceso. Las iteraciones son planificadas con base a los
casos de uso.
 Proceso Centrado en la Arquitectura: El proceso busca entender los
aspectos estáticos y dinámicos más significativos en términos de
arquitectura de software. La arquitectura se define en función de las
necesidades de los usuarios y se determina a partir de los Casos de Uso
base del negocio.
Proceso Dirigido por el caso de Uso.
En este caso como podemos observar la imagen primero requerimos capturar,
definir y validar los casos de uso las cuales vendrían a ser los requisitos, analizar
y diseño, implementación y pruebas.

Proceso de Iterativo e incremental

 El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables
que se muestran a los usuarios y clientes.
 En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida
en cascada a menor escala.
 Los objetivos de una iteración se establecen en función de la evaluación
de las iteraciones precedentes.
 Las actividades se encadenan en una mini-cascada con un alcance
limitado por los objetivos de la iteración.
 Mostrando en imagen dicho proceso:

Cada iteración comprende:

 Planificar la iteración (estudio de riesgos).
 Análisis de los Casos de Uso y escenarios.
 Diseño de opciones arquitectónicas.
 Codificación y pruebas. La integración del nuevo código con el
existente de iteraciones anteriores se hace gradualmente durante la
construcción.
Trazabilidad a partir de los casos de Uso:

Proceso Centrado en la Arquitectura

Arquitectura de un sistema es la organización o estructura de sus partes más
relevantes. Una arquitectura ejecutable es una implementación parcial del
sistema, construida para demostrar algunas funciones y propiedades.
RUP establece refinamientos sucesivos de una arquitectura ejecutable
construida como un prototipo evolutivo.
 FASES DE LA METODOLOGÍA RUP
Fases del Ciclo de Vida:
El ciclo de vida consiste en una serie de ciclos, cada una de las cuales produce
una nueva versión del producto. Cada ciclo está compuesto por fases y cada una
de estas fases está compuesta por un número de iteraciones.

FASES
 Establece oportunidad y alcance.
 Identifica las entidades externas o actores con las que se trata.
 Identifica los casos de uso.
RUP comprende 2 aspectos importantes por los cuales se establecen las
disciplinas:
Proceso:
Las etapas de esta sección son: (Revise nuevamente la gráfica)
 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 4
fases descritas anteriormente:
 Inicio (también llamado Incepción o Concepción).
 Elaboración.
 Desarrollo (también llamado Implementación, Construcción).
 Cierre (también llamado Transición).
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,
proponer una visión muy general de la arquitectura de software y producir el plan
de las fases y el de iteraciones posteriores.
Fase de elaboración: En la fase de elaboración se seleccionan los casos de
uso que permiten definir la arquitectura base del sistema y se desarrollaran en
esta fase, se realiza la especificación de los casos de uso seleccionados y el
primer análisis del dominio del problema, se diseña la solución preliminar.
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: 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. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el proyecto.

COMPONENTES DEL RUP

Como RUP es un proceso, en su modelación define como sus principales
elementos son 4 y estas son:
 Define el comportamiento y responsabilidades (rol) de un individuo, grupo
de individuos, sistema automatizado o máquina, que trabajan en conjunto
como un equipo. Ellos realizan las actividades y son propietarios de
elementos.
 Es una tarea que tiene un propósito claro, es realizada por un trabajador
y manipula elementos.
 Productos tangibles del proyecto que son producidos, modificados y
usados por las actividades. Pueden ser modelos, elementos dentro del
modelo, código fuente y ejecutables.
 Secuencia de actividades realizadas por trabajadores y que produce un
resultado de valor observable.

FLUJOS DE TRABAJO DEL RUP

Flujos de trabajo:
 Modelamiento del negocio: Describe los procesos de negocio,
identificando quiénes participan y las actividades que requieren
automatización.
 Requerimientos: Define qué es lo que el sistema debe hacer, para lo cual
se identifican las funcionalidades requeridas y las restricciones que se
imponen.
 Análisis y diseño: Describe cómo el sistema será realizado a partir de la
funcionalidad prevista y las restricciones impuestas (requerimientos), por
lo que indica con precisión lo que se debe programar.
 Implementación: Define cómo se organizan las clases y objetos en
componentes, cuáles nodos se utilizarán y la ubicación en ellos de los
componentes y la estructura de capas de la aplicación.
 Prueba (Testeo): Busca los defectos a lo largo del ciclo de vida.
 Instalación: Realiza actividades (empaque, instalación, asistencia a
usuarios, etc.) para entregar el software a los usuarios finales.
 Administración del proyecto: Involucra actividades con las que se
busca producir un producto que satisfaga las necesidades de los clientes.
  Administración de configuración y cambios: Describe cómo controlar
los elementos producidos por todos los integrantes del equipo de proyecto
en cuanto a la utilización/actualización concurrente de elementos, control
de versiones, etc.
 Ambiente: Contiene actividades que describen los procesos y
herramientas que soportarán el equipo de trabajo del proyecto, así como
el procedimiento para implementar el proceso en una organización.
1.1 Modelado de Negocio
El modelado del negocio es una técnica para comprender los procesos de
negocio de la organización. El modelado del negocio está soportado por dos
tipos de modelos de UML: el modelado de casos de usos y modelos de objetos.
Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la
organización donde se va a implantar el producto.
Los objetivos del modelado de negocio son:
 Entender la estructura y la dinámica de la organización para la cual el
sistema va a ser desarrollado (organización objetivo).
 Entender el problema actual en la organización objetivo e identificar sus
potenciales y mejoras.
 Asegurar que los clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.
 Derivar los requisitos del sistema necesarios para apoyar a la
organización objetivo.
Para lograr estos objetivos, el modelo de negocio describe cómo desarrollar una
visión de la nueva organización, basado en esta visión se definen procesos, roles
y responsabilidades de la organización por medio de un modelo de Casos de
Uso del negocio y un Modelo de Objetos del Negocio. Complementario a estos
modelos se desarrollan otras especificaciones, tales como un Glosario.
1.1.1 Describir y evaluar el estado del negocio. - Un Modelo de Casos de Uso
del Negocio describe los procesos de negocio de una empresa en términos de
casos de uso del negocio y actores del negocio que corresponden con los
procesos del negocio y con los clientes, respectivamente.
Al igual que el modelo de casos de uso para un sistema software, el modelo de
casos de uso del negocio presenta un sistema (en este caso, el negocio) desde
la perspectiva de su uso y esquematiza cómo proporciona valor a sus usuarios.
El modelo de casos de uso del negocio se describe mediante diagramas de
casos de uso.
Un modelo de objetos del negocio describe cómo cada caso de uso del negocio
es llevado a cabo por parte de un conjunto de trabajadores que utilizan un
conjunto de entidades del negocio y de unidades de trabajo.
Cada realización de un caso de uso del negocio puede mostrarse en diagramas
de interacción y diagramas de actividad.
Una entidad del negocio representa algo que los trabajadores toman, manipulan,
inspeccionan, producen o utilizan en un negocio.
Una unidad de trabajo es un conjunto de esas entidades que conforma un todo
reconocible para el usuario final.
1.1.2 Identificar procesos de negocio. - La técnica de modelado de negocio
identifica entidades y trabajadores que participan en la realización de los casos
de uso del negocio.
Los trabajadores identificados en el modelo de negocio se utilizan como punto
de partida para derivar un primer conjunto de actores y casos de uso del sistema.
1.2 Requerimientos
Este es uno de los flujos de trabajo más importantes, porque en él se establece
qué tiene que hacer exactamente el sistema que construyamos. En esta línea
los requisitos son el contrato que se debe cumplir, de modo que los usuarios
finales tienen que comprender y aceptar los requisitos que especifiquemos.
Los objetivos del flujo de datos Requisitos son:
 Establecer y mantener un acuerdo entre clientes y otros stakeholders
sobre lo que el sistema podría hacer.
 Proveer a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
 Definir el ámbito del sistema.
 Proveer una base para la planeación de los contenidos técnicos de las
iteraciones.
 Proveer una base para estimar costos y tiempo de desarrollo del sistema.
 Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales representan
la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso.
Los requisitos no funcionales representan aquellos atributos que debe exhibir el
sistema, pero que no son una funcionalidad específica. Por ejemplo, requisitos
de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.
Para capturar los requisitos es preciso entrevistar a todos los interesados en el
proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A partir de
ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se
diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen
prototipos de la interfaz gráfica de usuario que se contrastan con el usuario final.
1.2.1 Analizar el problema. - Muchos autores y expertos coinciden en que el
éxito de un sistema de información reside en el adecuado relevamiento o análisis
de los requerimientos de los usuarios y que deberá traducirse en un modelo
óptimo de qué se quiere del sistema.
El análisis de requerimientos comprende las siguientes actividades:
 Identificación del Modelo de Componentes o Subsistemas. Que
dependiendo del tamaño y complejidad del proyecto podrán ser varios
componentes.
 Conformación de los equipos de desarrollo. Es habitual en proyectos
grandes tener al menos 2 equipos de trabajo, con sus respectivos
analistas y programadores.
 Planificación del desarrollo de los componentes o subsistemas. Consiste
en determinar la prioridad y secuencia de desarrollo de los componentes
y su asignación a los equipos de desarrollo. Es importante hacer notar
que los equipos de desarrollo comenzarán simultáneamente a desarrollar
los módulos asignados, pero con sus respectivos cronogramas de
desarrollo, lo importante al momento de la asignación de los componentes
es que cada equipo de desarrollo tenga asignado componentes
complementarios o fuertemente relacionados y que tengan una
distribución de carga de trabajo lo más equitativa, de manera que para la
conclusión del proyecto todos los equipos de desarrollo vayan
concluyendo casi simultáneamente.
 Identificación de los requerimientos funcionales, operativos, ergonómicos,
de prueba y de rendimiento de cada componente. Esta tarea la realiza
cada equipo de desarrollo para cada componente asignado, por lo tanto,
si nos abstraemos al respecto, veremos que habrá tantas iteraciones
como componentes se definan.
 Identificación de los Casos de Uso.
 Definición del Modelo de Casos de Uso del Sistema.
1.3 Análisis y Diseño
El objetivo de este flujo de trabajo es traducir los requisitos a una especificación
que describe cómo implementar el sistema.
Los objetivos del análisis y diseño son:
 Transformar los requisitos al diseño del futuro sistema.
 Desarrollar una arquitectura para el sistema.
 Adaptar el diseño para que sea consistente con el entorno de
implementación, diseñado para el rendimiento.
El análisis consiste en obtener una visión del sistema que se preocupa de ver
qué hace, de modo que sólo se interesa por los requisitos funcionales. Por otro
lado, el diseño es un refinamiento del análisis que tiene en cuenta los requisitos
no funcionales, en definitiva, cómo cumple el sistema sus objetivos.
Al principio de la fase de elaboración hay que definir una arquitectura candidata:
crear un esquema inicial de la arquitectura del sistema, identificar clases de
análisis y actualizar las realizaciones de los Casos de Uso con las interacciones
de las clases de análisis. Durante la fase de elaboración se va refinando esta
arquitectura hasta llegar a su forma definitiva. En cada iteración hay que analizar
el comportamiento para diseñar componentes. Además, si el sistema usará una
base de datos, habrá que diseñarla también, obteniendo un modelo de datos.
El resultado final más importante de este flujo de trabajo será el modelo de
diseño. Consiste en colaboraciones de clases, que pueden ser agregadas en
paquetes y subsistemas.
Otro producto importante de este flujo es la documentación de la arquitectura de
software, que captura varias vistas arquitectónicas del sistema.
Análisis:
Durante el análisis, analizamos los requisitos que se describieron en la captura
de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es
conseguir una comprensión más precisa de los requisitos y una descripción de
los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema
entero, incluyendo su arquitectura.
El lenguaje que utilizamos en el análisis se basa en un modelo de objetos
conceptual, que llamamos modelo de análisis. El modelo de análisis nos ayuda
a refinar los requisitos.
Diseño:
Durante el diseño modelamos el sistema y su arquitectura para que soporte los
requisitos funcionales y no funcionales. Una entrada esencial al diseño es el
modelo de análisis.
1.4 Implementación y pruebas
1.4.1 Implementación:
En la implementación empezamos con el resultado del diseño e implementamos
el sistema en término de componentes, es decir, ficheros de código fuente,
scripts, ficheros de código binario, ejecutables y similares.
La implementación es el centro durante las iteraciones de construcción, aunque
también se lleva a cabo trabajo de implementación durante la fase de
elaboración, para crear la línea base ejecutable de la arquitectura, y durante la
fase de transición para tratar defectos tardíos.
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente,
binarios, ejecutables y demás. Además, se deben hacer las pruebas de unidad,
es decir, cada implementador es responsable de probar las unidades que
produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.
En cada iteración habrá que hacer lo siguiente:
 Planificar qué subsistemas deben ser implementados y en qué orden
deben ser integrados, formando el Plan de Integración.
 Cada implementador decide en qué orden implementa los elementos del
subsistema.
 Si encuentra errores de diseño, los notifica.
 Se prueban los subsistemas individualmente.
 Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados, forma el modelo de
implementación. La integración debe ser incremental, es decir, en cada momento
sólo se añade un elemento. De este modo, es más fácil localizar fallos y los
componentes se prueban más a fondo. En fases tempranas del proceso se
pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde
ver si el sistema es viable desde el principio, probar tecnologías o diseñar la
interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o
evolutivos. Estos últimos llegan a transformarse en el sistema final.
1.4.2 Pruebas:
Los objetivos de la prueba son:
 Planificar las pruebas necesarias en cada iteración, incluyendo las
pruebas de integración y las pruebas de sistema.
 Diseñar e implementar pruebas creando los casos de prueba (especifican
qué probar), procedimientos de prueba (especifican cómo realizar las
pruebas), creando componentes de prueba para automatizar las pruebas.
 Realizar las pruebas.
Este flujo de trabajo es el encargado de evaluar la calidad del producto que
estamos desarrollando, pero no para aceptar o rechazar el producto al final del
proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
 Encontrar y documentar defectos en la calidad del software.
 Generalmente asesora sobre la calidad del software percibida.
 Provee la validación de los supuestos realizados en el diseño y
especificación de requisitos por medio de demostraciones concretas.
 Verificar las funciones del producto de software según lo diseñado.
 Verificar que los requisitos tengan su apropiada implementación.
Las actividades de este flujo comienzan pronto en el proyecto con el plan de
prueba (el cual contiene información sobre los objetivos generales y específicos
de la prueba en el proyecto, así como las estrategias y recursos con que se
dotará a esta tarea) o incluso antes, con alguna evaluación durante la fase de
inicio y continuará, durante todo el proyecto.
El desarrollo del flujo de trabajo consistirá en planificar qué es lo que hay que
probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a
cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma
que la información obtenida nos sirva para ir refinando el producto a desarrollar.
1.5 Despliegue
El objetivo de este flujo de trabajo es producir con éxito distribuciones del
producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
 Probar el producto en su entorno de ejecución final.
 Empaquetar el software para su distribución.
 Distribuir el software.
 Instalar el software.
 Proveer asistencia y ayuda a los usuarios.
 Formar a los usuarios y al cuerpo de ventas.
 Migrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transición,
ya que el propósito del flujo es asegurar una aceptación y adaptación sin
complicaciones del software por parte de los usuarios. Su ejecución inicia en
fases anteriores, para preparar el camino, sobre todo con actividades de
planificación, en la elaboración del manual de usuario y tutoriales.
1.5.1 Vista General del flujo de trabajo de Despliegue. - Implica probar el
software en su ambiente operacional final, empacar el software para la entrega,
distribuir el software, instalar el software, entrenar a los usuarios finales y
convertir las bases de datos anteriores para la carga de datos. Hay tres maneras
de proveer del producto al usuario final:
 La instalación en el cliente.
 Se entrega un “instalador” (generado con algún producto de compresión
e instalación).
 Accesar al software por la Internet.
Cualquiera que sea el método escogido para entregar al cliente, la prueba del
producto ocurre en el site de desarrollo seguido por la prueba Beta y finalmente,
liberando el producto al cliente. El flujo de trabajo de Despliegue está relacionado
a otros del RUP, como sigue:
 Planificar el Despliegue.
 Desarrollar Material de Soporte.
Produce el material de soporte, el cual incluye instrucciones para instalación,
operación y mantenimiento para el sistema desplegado. También incluye el
material de entrenamiento para las diversas posiciones requeridas para usar el
sistema efectivamente:
 Manejar las Pruebas de Aceptación.
 Producir la Unidad de Despliegue.
 Empaquetar el Producto.
 Proveer Acceso al Site de Descarga.
 Producto en Beta.
1.6 Gestión y Configuración de Cambios
1.6.1 Configuración y control de cambios. - La finalidad de este flujo de trabajo
es mantener la integridad de todos los artefactos que se crean en el proceso, así
como de mantener información del proceso evolutivo que han seguido.
1.7 Gestión del proyecto y entornos
1.7.1 Gestión del proyecto. - La Gestión del proyecto es el arte de lograr un
balance al gestionar objetivos, riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios.
Los objetivos de este flujo de trabajo son:
 Proveer un marco de trabajo para la gestión de proyectos de software
intensivos.
 Proveer guías prácticas, realizar planeación, contratar personal, ejecutar
y monitorear el proyecto.
 Proveer un marco de trabajo para gestionar riesgos.
La planeación de un proyecto posee dos niveles de abstracción: un plan para las
fases y un plan para cada iteración.
1.7.2 Entorno. - La finalidad de este flujo de trabajo es dar soporte al proyecto
con las adecuadas herramientas, procesos y métodos. Brinda una especificación
de las herramientas que se van a necesitar en cada momento, así como definir
la instancia concreta del proceso que se va a seguir.
En concreto, las responsabilidades de este flujo de trabajo incluyen:
 Selección y adquisición de herramientas.
 Establecer y configurar las herramientas para que se ajusten a la
organización.
 Configuración del proceso.
 Mejora del proceso.
 Servicios técnicos.
El principal artefacto que se usa en este flujo de trabajo es el caso de desarrollo
que específica para el proyecto actual, en concreto, cómo se aplicará el proceso,
qué productos se van a utilizar y cómo van a ser utilizados. Además, se tendrán
que definir las guías para los distintos aspectos del proceso, como pueden ser el
modelado del negocio y los Casos de Uso para la interfaz de usuario, el diseño,
la programación y el manual de usuario.

Artefactos de gestión y técnicos

Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza
una serie de artefactos que sirven para comprender mejor tanto el análisis como
el diseño del sistema, estos artefactos son los siguientes:
Inicio
 Documento Visión
 Especificación de Requerimientos
Elaboración
 Diagramas de caso de uso
Construcción
 Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica
 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.

BIBLIOGRAFÍA
https://docplayer.es/1580077-Monografia-metodologia-rup-rational-unified-process.html

http://julian1978.blogspot.com/2013/07/metodologia-rup-fases-historia-y.html

http://rupequipo1.blogspot.com/2012/12/algo-de-historia.html

https://aleph.org.mx/que-es-la-metodologia-rup

https://silo.tips/download/monografia-metodologia-rup-rational-unified-process

http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro10/36_artefactos_de_gestin_y_tcnic
os.html

https://lean-management.site/rup/

http://rupmetodologia.blogspot.com/