COMANDO GENERAL DEL EJÉRCITO

ESCUELA MILITAR DE INGENIERIA

“MCAL. ANTONIO JOSE DE SUCRE”
BOLIVIA

TECNICAS DE
RECOPILACION

Estudiante : Kathia Naira Choquehuanca Ulo 8346561

Daniela Fernanda Blacutt Chávez 6947254
Henry Clares Apaza 10913552
Dennis Vladimir Echalar Conde 9101770
Leo Beltran Sacari Quispe 9201596
Carrera : Ingeniería de Sistemas
Materia : Análisis y Diseño de Sistemas II
Semestre : Sexto

2018
Contenido
Historia ___________________________________________________________________________________________________ 1
Modelo ____________________________________________________________________________________________________ 3
Proceso del desarrollo ___________________________________________________________________________________ 7
Fases _____________________________________________________________________________________________________ 12
Notación _________________________________________________________________________________________________ 15
 Historia
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.

El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson

Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes,
que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la
compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object
Factory).

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y

1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque
Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde ese entonces y
a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e
incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo
conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

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

Página 1
 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

Página 2
 Modelo
Rational Unified Process (RUP) es una metodología de desarrollo de software orientado a objeto que
establece las bases, plantillas, y ejemplos para todos los aspectos y fases de desarrollo del software. RUP es
herramientas de la ingeniería de software que combinan los aspectos del proceso de desarrollo (como
fases definidas, técnicas, y prácticas) con otros componentes de desarrollo (como documentos, modelos,
manuales, código fuente, etc.) dentro de un framework unificado. RUP establece cuatro fases de desarrollo
cada una de las cuales esta organizada en varias iteraciones separadas que deben satisfacer criterios
definidos antes de emprender la próxima fase

Características de la metodología

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características
esenciales: está dirigido por los Casos de Uso, esta centrado en la arquitectura y es iterativo e incremental.

RUP identifica las seis mejores prácticas con las que define una forma efectiva de trabajar para los equipos
de desarrollo de software .

 La administración de requerimientos
 El desarrollo iterativo
 La arquitectura basada en componentes
 El modelo visual
 La verificación continua de la calidad
 La administración del cambio
Estas seis prácticas orientan el modelo y con ellas se pretende solucionar muchos de los problemas
asociados al software. Adicionalmente hay muchos aspectos de diseño que son bien conocidos, pero que en
realidad han sido muy poco implementados en los proyectos de software; estos son: facilidad de uso,
modularidad, encapsulamiento y facilidad de mantenimiento. Es necesario entonces definir una
arquitectura sólida basada en componentes, para construir mejores y más flexibles soluciones de software
para las necesidades organizacionales.

Los cambios en un proyecto no pueden ser detenidos dado que la evolución del entorno de cada
organización es continua, pero sí pueden ser administrados de manera que su impacto pueda ser estimado
para determinar si dicho cambio se incluye o no y si el proyecto debe ser reajustado.

Cada cambio en el proyecto debe tener especificado cuándo y cómo se va a realizar, quién lo va a hacer y
qué productos se ven involucrados en ese cambio. En ese punto es donde el control de cambios y la
trazabilidad de los componentes a través de los diversos modelos adquieren una gran importancia.

Página 3
 La administración de requerimientos
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

Página 4
 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

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 arquitectura basada en componenetes

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

Página 5
 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.

El modelo 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.

La verificación continua de la 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 de el nivel esperado de la calidad y proporciona pruebas en los procesos para
medir este nivel.

Administracion del cambio

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.

Página 6
 Proceso del desarrollo
Características de la metodología

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características
esenciales: está dirigido por los la arquitectura y es iterativo e incremental

Proceso dirigido a casos de uso

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. No solo inician como se muestra en la Figura 1.

Figura 1: Los Casos de Uso integran el trabajo

Los Casos de Uso no sólo inician el proceso de desarrollo sino establecen la transacción entre los distintos
artefactos que son generados en las diferentes actividades del proceso de desarrollo. Basándose en los
Casos de Uso se crean los modelos de análisis y diseño, posteriormente se genera la implementación que
los lleva a cabo, ayuda a verificar la adecuada implementación de cada caso de uso en el producto final.

Página 7
 Proceso centrado en la arquitectura

La arquitectura de un sistema es la organización relevante, lo que permite tener una visión

(desarrolladores y usuarios), así como una perspectiva clara del sistema completo, necesaria para
controlar el desarrollo.

La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está
relacionada con la toma de decisiones que indican la forma de construcción del sistema. La arquitectura se
ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen
requisitos no funcionales del sistema.

RUP presta especial atención al establecimiento temprano de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar en la
arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los casos de uso
requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como casos de uso deban
evolucionar en paralelo durante todo el proceso de desarrollo de software.

En la Figura 2 se muestra la evolución de la arquitectura durante las fases de RUP. Se tiene una
arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir
consolidando la arquitectura por medio de baselines y se va modificando dependiendo de las necesidades
del proyecto.

Figura 2. Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la
arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema,
abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la
arquitectura, el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso
y de despliegue, más la de casos de uso que es la que da cohesión a todas.

Durante la construcción, los diversos modelos van desarrollándose hasta completarse. La descripción de la
arquitectura sin embargo, no debería cambiar significativamente debido a que la mayor parte de la
arquitectura se decidió durante la elaboración, incorporando pocos cambios a la arquitectura, Figura 3.

Página 8
 Figura 3. Proceso de madurez de la arquitectura

Proceso iterativo e incremental

RUP propone tener un proceso en partes más pequeñas o mini proyectos, permitiendo generar un
equilibrio entre casos de uso y arquitectura. Cada mini proyecto se puede ver como una iteración (un
recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se
obtiene un incremento que produce un crecimiento en el producto.

Una iteración puede realizarse por medio de una cascada como se muestra en la Figura 4. la cual pasa por
los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una
planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al
finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

Figura 4: Iteración de RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte
de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura.

Página 9
 Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han
cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la
siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en
curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes
iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual
del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En
la Grafica se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre
el proyecto RUP.

Grafica Propia de la metodología RUP

Página 10
 El RUP tiene dos dimensiones:

 La primera dimensión (eje horizontal) representa el aspecto dinámico del proceso y se expresa en
términos de fases, iteraciones y la finalización de las fases.
 La segunda dimensión (eje vertical) representa el aspecto estático del proceso: cómo se describe
en términos de componentes de proceso, disciplinas, actividades, flujos de trabajo, artefactos, y los
roles.

Página 11
 Fases
ESPECIFICACIÓN DE LAS 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:

• Modelado de negocio
• Requisitos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue

SOPORTE:

• Gestión del cambio y configuraciones

• Gestión del proyecto
• Entorno

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número variable
según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.

Página 12
 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.

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.

Página 13
 CONSTRUCCIÓN

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.

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.

Página 14
 Notación
El Proceso RUP se representa utilizando cuatro elementos básicos de modelado:

1. Roles: Un rol define el comportamiento y las responsabilidades de una persona trabajando en el

proyecto.
2. Actividades: Una actividad representa una unidad de trabajo desempeñada por un determinado rol. El
propósito de la actividad es crear artefactos.
3. Artefactos: Un artefacto es una pieza de información que se produce, modifica, o usa por un proceso. Es
el producto tangible del proyecto que puede ser:

a) Un modelo o elemento de modelo, tal como Modelo de Casos de Uso,

b) Un documento, tal como el documento de la Arquitectura del Sistema,
c) Una Pieza Hardware o un Programa Ejecutable del Sistema.
4. Flujos de trabajos: Un flujo de trabajo es una secuencia de actividades que produce resultados
observables. Se representan dos tipos de flujos de trabajo:
a. Flujo de Trabajo Principal: Es una colección de actividades relacionadas, que representa un
componente del proceso de desarrollo RUP.
b. Flujo de Trabajo Detallado: Representan el desglosamiento de las actividades que se muestran en
el flujo de trabajo principal en otro grupo de actividades más pequeñas que interactuan con roles
y artefactos.

Roles

Página 15
 Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos
trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol
puede ser representado por varias personas. RUP define grupos de roles, agrupados por participación en
actividades relacionadas. Estos grupos son:

Analistas:

• Analista de procesos de negocio.

• Diseñador del negocio.
• Analista de sistema.
• Especificador de requisitos.

Desarrolladores:

• Arquitecto de software.
• 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.

Página 16
 Especialistas 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.

Actividades

Una actividad es una unidad de trabajo que es asignado a un rol específico. Las actividades tienen un
objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.

Artefactos

Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el

proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va
creando y usando hasta obtener el producto final.

Página 17
 Unidades de información creadas, producidas, cambiadas o utilizadas en el proceso de desarrollo. Los
artefactos son en muchos casos análogos al término general "entregables" en otras metodologías de
gestión y desarrollo de proyectos, y son el "que" (el producto final ideal) de los procesos.

Los artefactos se usan como entradas por otros trabajadores para desempeñar una actividad, y son el
resultado de otras actividades. Algunos ejemplos comunes de artefactos son:

• Un modelo, como los modelos de casos de uso, entidad relación o modelo de diseño.
• Un elemento de un modelo, como una clase, un caso de uso individual, o un subsistema.
• Un documento como un caso de negocios o un documento de arquitectura de software.
• Código fuente.
• Ejecutables.

Flujos de trabajo

Un flujo de trabajo es una secuencia de actividades que producen un resultado de valor observable. Los
flujos RUP tienen nombres parecidos a los de las etapas del desarrollo de cascada, pero pueden usarse
tanto en procesos de cascada como en procesos iterativos.

En esencia, un flujo de trabajo es un algoritmo, y por lo tanto se puede representar de muchas formas,
desde diagramas de flujo hasta diagramas de secuencia o de actividades UML. Es común usar diagramas de
actividades.

Página 18
 No todas las actividades deben o pueden ser diagramadas, pero de acuerdo a la metodología RUP hay flujos
de trabajo particularmente importantes que deben representarse siempre que sea posible. Estos se llaman
"flujos de trabajo de procesos núcleo" y se dividen en seis flujos de "ingeniería" y tres flujos de "apoyo":

Un flujo de trabajo es una relación de actividades que nos producen unos resultados observables. RUP
determina los siguientes flujos de trabajo:

• Modelado de negocio.
• Requisitos.
• Análisis y diseño.
• Implementación.
• Pruebas.
• Despliegue.
• Gestión del proyecto.
• Configuración y control de cambio.
• Ambiente.

Página 19