Universidad Nacional del Callao
Facultad de Ingeniería Industrial y Sistemas
Proyecto de Investigación
“Metodología de desarrollo de software RUP (Rational
Unified Process)”
Presentado por:
Cesar Jackson, Sánchez Casas
Alessandra, Ramos Arias
Profesora: Ortega Rojas, Yesmi Katia
Callao
2020
INDICE
CAPITULO I INTRODUCCIÓN.........................................................................................................3
1.1 Antecedentes.....................................................................................................................3
1.1.1 Breve Historia de RUP..................................................................................................3
1.1.2 Investigaciones Realizadas en el Perú..........................................................................3
1.2 Planteamiento del problema..............................................................................................3
1.2.1 Definición del tema.....................................................................................................3
1.3 Justificación........................................................................................................................3
1.4 Objetivos............................................................................................................................3
1.4.1 Objetivo general..........................................................................................................3
1.4.2 Objetivos específicos...................................................................................................3
1.5 Alcances.............................................................................................................................3
1.6 Limitantes...........................................................................................................................3
1.7 Delimitantes.......................................................................................................................3
CAPITULO II MARCO DE REFERENCIA...........................................................................................3
2.1 Marco Teórico....................................................................................................................3
2.1.1 Metodología de Desarrollo de software orientada a objetos......................................3
2.1.2 RUP (Rational Unified Process)....................................................................................3
2.1.3 Impulsado por casos de uso........................................................................................3
2.1.4 Centrado a la arquitectura..........................................................................................3
2.1.5 Interactivo e Incremental............................................................................................3
2.2 Metodología de Investigación............................................................................................3
CAPITULO III INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE...................................................3
3.1 Introducción.......................................................................................................................3
3.2 Conceptos básicos..............................................................................................................3
3.2.1 ¿Qué es Ingeniería de Software?.................................................................................4
3.2.2 ¿Qué es software de calidad?......................................................................................4
CAPITULO IV PROCESOS DE DESARROLLO DE SOFTWARE............................................................4
4.1 Introducción.......................................................................................................................4
4.2 Etapas del proceso de desarrollo de software....................................................................4
4.2.1 Análisis de requisitos...................................................................................................4
4.2.2 Principios de especificación.........................................................................................4
4.2.3 Diseño y arquitectura..................................................................................................4
4.2.4 Programación..............................................................................................................4
4.2.5 Prueba.........................................................................................................................4
4.2.6 Documentación...........................................................................................................4
4.2.7 Mantenimiento...........................................................................................................4
4.3 Modelos del ciclo de vida...................................................................................................4
4.3.1 Modelo en cascada......................................................................................................4
4.3.2 Modelo de desarrollo Evolutivo..................................................................................4
4.3.3 Modelo de prototipado de Requerimientos................................................................4
4.3.4 Modelo de desarrollo basado en reutilización............................................................4
4.3.5 Modelo de desarrollo en espiral..................................................................................4
4.3.6 Modelo de desarrollo incremental..............................................................................4
CAPITULO V Rational Unified Process (RUP) Proceso Unificado de Rational................................4
5.1 Introducción.......................................................................................................................4
5.2 Características de RUP........................................................................................................4
5.3 Principio de desarrollo........................................................................................................5
5.3.1 Adaptar el proceso......................................................................................................5
5.3.2 Balancear prioridades..................................................................................................5
5.3.3 Demostrar valor iterativamente..................................................................................5
5.3.4 Elevar el nivel de abstracción......................................................................................5
5.3.5 Enfocarse en la calidad................................................................................................5
5.4 Ciclo de vida de RUP...........................................................................................................5
5.5 Proceso...............................................................................................................................5
5.6 Fases...................................................................................................................................5
5.7 Fases...................................................................................................................................5
5.7.1 Fase de Inicio...............................................................................................................5
5.7.2 Fase de Elaboración.....................................................................................................5
5.7.3 Fase de Construcción...................................................................................................5
5.7.4 Fase de Transición.......................................................................................................5
5.8 Grado de conocimiento del Método RUP en el Perú..........................................................5
CAPITULO VI ELEMENTOS DE RUP................................................................................................6
6.1 Elementos de RUP..............................................................................................................6
6.2 Actividad.............................................................................................................................6
6.3 Trabajador (ROL)................................................................................................................6
6.4 Artefactos...........................................................................................................................6
6.5 Actividades Primarias y secundarias o de apoyo................................................................6
CAPITULO VII CASO PRACTICO EMPLEANDO RUP........................................................................6
7.1 Introducción.......................................................................................................................6
7.2 Caso VOLVO IT....................................................................................................................6
7.2.1 Experiencia con los proyectos RUP..............................................................................6
7.2.2 Efectos de usar RUP.....................................................................................................6
BIBLIOGRAFIA...............................................................................................................................6
GLOSARIO.....................................................................................................................................6
ANEXOS........................................................................................................................................6
Índice de Figuras
Figura 1. Historia de la metodología RUP....................................................................................6
Figura 2. Ingeniería de Software................................................................................................13
Figura 3. Modelo de calidad de software....................................................................................15
CAPITULO I INTRODUCCIÓN
El presente trabajo de investigación cubre el tema del Proceso unificado racional (más
conocido por sus siglas RUP), que se puede definir como un proceso de ingeniería de
software para producir software de alta calidad que cumpla con los entandares globales
y brinde elasticidad en términos y presupuestos. Debido a la combinación de las mejores
prácticas en ingeniería de software, tales como: gestión de requisitos, uso de
arquitectura de componentes, modelo visual, verificación continua de calidad y control
de cambios, etc., hace del RUP uno de los estándares mas utilizados para examinar,
efectuar y evidenciar sistemas orientados a objetos.
Comprender RUP es esencial para los estudiantes que se especializan en la carrera de
Ingeniería de Sistemas. Un verdadero ingeniero de sistemas no es alguien que tiene el
titulo para colgarlo en la pared y decir soy profesional, por el contrario, el ser ingeniero
de sistemas es conocer la diversidad existente de metodologías de investigación de
software.
La importancia de investigar este método es que las grandes empresas requieren un alto
nivel de calidad de software. RUP se puede usar independientemente del tamaño y el
rubro de la organización, pero debido a la complejidad y escala del sistema, RUP se usa
cada vez mas en grandes empresas.
1.1 Antecedentes
1.1.1 Breve Historia de RUP1
El precedente mas importante es la metodología de Ericsson, desarrollada por Iván
Jacobson en 1967.
Figura 1Historia de la metodología RUP
En la figura 1 se puede visualizar un breve resumen de la historia de RUP representado
en una línea de tiempo.
Este es un método de desarrollo basado en componentes que introduce el concepto de
casos de uso. Entre 1987 y 1995, Jacobson fundó Objetory AB y comenzó el proceso de
desarrollo de Objetory (abreviatura de Object Factory). Posteriormente, en 1995,
Rational Software Corporation adquirió el Objetory AB, y entre 1995 y 1997, el
Rational Objetory Process (ROP) se desarrollo a partir del Objectory 3.8 y el Rational
Approach utilizando UML como lenguaje de modelado.
Desde entonces, Rational Software bajo el liderazgo de Grady Booch, Ivar Jacobson y
James Rumbaugh, ha desarrollado e integrado varios elementos para extender RUP,
particularmente centrándose en un flujo de trabajo llamado modelado empresarial. El
proceso unificado racional se lanzo en junio de 1998.
1
https://es.slideshare.net/bernardolimachi/metodologia-rup-14288208
1.2 Planteamiento del problema
Actualmente en el Perú, no hay suficiente información sobre los métodos de desarrollo
de software RUP, y muchos profesionales y estudiantes en el campo de la informática
no conocen el termino RUP o creen desfasado este método. Debido al auge
internacional en el desarrollo de aplicaciones comerciales, y considerando que algunas
de las empresas de nuestro país que se especializan en tecnología de la información han
comenzado a adoptar este enfoque, todos los informáticos deben conocer las últimas
tecnologías tanto de desarrollo de software como de programas de aplicación.
1.2.1 Definición del tema
Realizar un trabajo de investigación para explorar los conceptos, la lógica de operación
y ejemplos prácticos de la metodología de desarrollo de software RUP implementada en
VOLVO IT de manera general; conocer también sus ventajas y desventajas.
1.3 Justificación
La Universidad Nacional del Callao ha considerado encontrar y adoptar herramientas
que puedan mejorar y ampliar el conocimiento de los estudiantes. El actual proyecto de
investigación del Rational Unified Procces (RUP) tiene como objetivo promover la
investigación de los últimos métodos de desarrollo de software por parte de estudiantes
y/o profesionales en el campo de la informática, todo ello con el fin de crear
profesionales integrales listos para enfrentar nuevas tecnologías y paradigmas de
trabajo. Se espera que este trabajo sirva de base para futuras investigaciones. Teniendo
en cuenta que este contenido ha sido incluido en la agenda del curso de “Ingeniería de
Software” impartido en la Universidad Nacional del Callao, y debido a que hay muchas
historias de éxito, esta es actualmente una de las herramientas mas utilizadas.
1.4 Objetivos
1.4.1 Objetivo general
Escribir un trabajo de investigación sobre RUP (Rational Unified Process) que presente
el concepto, los elementos, el ciclo de vida, las historias de éxito y la compresión de las
empresas internacionales (como VOLVO IT) que adoptan este método. Así como
también conocer las opiniones de los profesionales en el campo de la informática del
país sobre este tema, con el propósito que esta investigación sirva como base para
futuras investigaciones de los estudiantes de la Universidad Nacional del Callao sobre
RUP, metodología de desarrollo de software y técnicas de Ingeniería de Software.
1.4.2 Objetivos específicos
a) Crear un documento que describa los conceptos generales de ingeniería de
software y métodos de desarrollo de software.
b) Obtener una comprensión general del grado de conocimiento y uso del RUP en
nuestro país.
c) Explicar la importancia de usar estos métodos en un entorno de trabajo real.
d) Describir los componentes de la metodología RUP, los componentes básicos de
RUP, el ciclo de vida de la metodología.
e) Presentar un estudio del caso de VOLVO IT que utiliza este método en el
proceso de desarrollo de software.
1.5 Alcances
Presentar los conceptos básicos de la metodología de desarrollo de software, los
componentes básicos de RUP, el ciclo de vida de la metodología y los ejemplos
prácticos de aplicación de las empresas latinoamericanas, la situación de VOLVO IT se
demostrará en este proyecto.
1.6 Limitantes
Para la realización del presente trabajo de investigación no se encontró limitantes para
llevarlo a cabo, ya que es una metodología que ya tiene una trayectoria, y podemos
obtener información en la red con facilidad.
1.7 Delimitantes
El estudio de este trabajo de investigación solo incluirá aspectos teóricos de la
metodología RUP, así como ejemplos de empresas que la han incluido en su desarrollo
de software, como VOLVO IT. El proyecto no profundizará en el diseño y la
programación del sistema RIP desarrollado por IBM.
CAPITULO II MARCO DE REFERENCIA
2.1 Marco Teórico
2.1.1 Metodología de Desarrollo de software orientada a objetos
2.1.2 RUP (Rational Unified Process)
RUP las siglas en inglés significa Rational Unified Process, es un producto del proceso
de ingeniería de software que puede proporcionar un método óptimo estandarizado para
asignar tareas y responsabilidades dentro de la organización. desarrollo de. Su objetivo
es garantizar la producción de software de alta calidad, Resolver las necesidades de los
usuarios dentro del presupuesto y tiempo establecidos. ayudar en el análisis y diseño de
lo mencionado anteriormente hace más fácil el desarrollo de un software con los
famosos casos de uso, diagramas, y un sinfín de herramientas.
RUP esta dividido en dos dimensiones, el eje horizontal que representa el tiempo e
ilustra todos los aspectos del ciclo de vida el proceso del proyecto y el eje vertical que
representa la disciplina, que define la actividad naturalmente.
La primera dimensión representa el aspecto dinámico del proceso, expresado como
Etapas, iteraciones y condiciones para completar la etapa. La segunda dimensión
representa el aspecto estático del proceso: cómo describirlo. En términos de
composición de procesos, disciplinas, actividades y procesos. Empleos, artefactos y
roles.
La Figura 2 muestra cómo cambia el enfoque de cada disciplina bajo circunstancias
específicas Tiempo y cada etapa. Por ejemplo, en la iteración Al principio, pasamos más
tiempo en los requisitos y la última iteración Pasamos más tiempo implementando el
proyecto en sí.
Figura 2 Disciplinas, fases, iteraciones del RUP
2.1.3 Impulsado por casos de uso
Según Kruchten, P. (2000), un caso de uso es una técnica de captura. Requisitos
que te obligan a pensar en la importancia. Usuarios, no solo en términos de funciones
que pueden considerarse. Los casos de uso se definen como parte de la función Un
sistema que brinda a los usuarios un valor agregado. Así mismo representan los
requisitos funcionales del sistema. En RUP, los casos de uso son más que una
herramienta designada Requisitos del sistema. También guían su diseño,
implementación y prueba.
Los casos de uso constituyen un elemento general y una guía El método de trabajo se
muestra en la figura 2.
Figura 3 Los Casos de Uso integran el trabajo
2.1.4 Centrado a la arquitectura
La estructura del sistema es la organización o estructura de su parte más relevante, lo
que permite que todo el personal relevante tenga una visión común y una perspectiva
clara del sistema completo necesario para controlar el desarrollo. La arquitectura
involucra los aspectos estáticos y dinámicos más importantes del sistema y está
relacionada con la toma de decisiones que dicta cómo se debe construir el sistema y
ayuda a determinar el orden en el que proceder. Además, la definición de la arquitectura
debe considerar los elementos de calidad del sistema, rendimiento, capacidad de
reutilización y capacidad de evolución, por lo que debe ser flexible durante todo el
proceso de desarrollo. La arquitectura se ve afectada por la plataforma de software, el
sistema operativo, el administrador de la base de datos, el protocolo, las consideraciones
de desarrollo como en los sistemas antiguos. Muchas de estas restricciones constituyen
requisitos del sistema no funcionales.
La figura 5 ilustra la evolución de la arquitectura en esta etapa. De RUP. Habrá una
arquitectura más robusta al final de las siguientes fases sequía. En la etapa inicial, lo que
hay que hacer es consolidar Determine la arquitectura mediante evaluación comparativa
y modifíquela según los requisitos del proyecto.
Figura 4 Evolución de la arquitectura del sistema
2.1.5 Interactivo e Incremental
2.2 Metodología de Investigación
CAPITULO III INTRODUCCIÓN A LA INGENIERÍA DE
SOFTWARE
3.1 Introducción
No podemos comenzar a hablar sobre la metodología de análisis de software sin saber
primero cual es la etapa general del desarrollo de software de manera general. Como
todo sabemos, los sistemas informáticos consisten en hardware y software. En cuanto al
hardware, su producción se lleva a cabo de manera sistemática, y la base de
conocimiento para desarrollar esta actividad esta claramente definida. En principio, la
confiabilidad del hardware es comparable a cualquier otra maquina artificial. A
diferencia del software, el cual su arquitectura y resultados han sido cuestionados
históricamente debido a problemas relacionados. Entre ellos, podemos enfatizar los
siguientes puntos: el sistema no puede responde a las expectativas del usuario, el
programa “falló” a una frecuencia determinada y los costes del software son difíciles de
predecir y a menudo se superan las estimaciones, por lo que modificar el software es
una tarea difícil y costosa.
Los proyectos de software a gran escala requieren herramientas estables y completas,
que pueden proporcionar medios en todas las etapas del desarrollo del proyecto. El
Rational Unified Process (RUP) es una herramienta que ofrece una gran cantidad de
ventajas, la más importante es el involucramiento de todos los participantes en el
desarrollo del proyecto, mejorando así la comunicación entre usuarios y programadores,
reduciendo así los problemas de malentendido, evitando posibles defectos en el sistema
y descubriéndolos rápidamente; debido a estas ventajas y muchas otras ventajas, RUP se
ha convertido en una opción tentadora por empresas productoras de software.
3.2 Conceptos básicos
3.2.1 ¿Qué es Ingeniería de Software?
Esta ingeniería involucra campos muy diversos de la informática y de las ciencias de la
computación, como la construcción de compiladores, sistemas operativos, o el
desarrollo de intranet/internet, abordando todas las fases del ciclo vital del desarrollo de
cualquier tipo de sistema de información. Y aplicar a campos (negocios, investigación
científica, medicina, producción, logística, banca, control de tráfico, meteorología,
derecho, internet e intranet, etc.) (Blanco, 2015).
En la figura 2, podemos visualizar de manera esquemática simple que contempla la
ingeniería de software.
Figura 5. Ingeniería de Software
Con el tiempo, algunos autores han dado algunas definiciones:
“Ingeniería de Software es el estudio de los principios y metodologías para el
desarrollo y mantenimiento de sistemas software” (Zelkovitz, 1979)
“Ingeniería del Software es el establecimiento y uso de principios solidos de
ingeniería a fin de obtener software de modo rentable, que sea fiable y
trabaje en máquinas reales” (Bauer, 1972).
“Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento del software; es decir, la aplicación de
la ingeniería al software” (IEEE, 1993).
Con todo lo anterior mencionado, podemos decir que de los cuatro autores describieron
los objetivos principales de la ingeniería de software de manera diferente, el cual es la
base para establecer e implementar principios y métodos. Estos principios y métodos
nos guiaran para llevar a cabo un desarrollo efectivo desde todas las etapas del
desarrollo del software, desde el inicio hasta la implementación y mantenimiento.
3.2.2 ¿Qué es software de calidad?
Rafael Gómez Blanes en su blog personal nos dice que:
“Lejos de plantear una definición demasiado académica y siendo pragmáticos, se puede
decir que un software de calidad no solo tiene la capacidad de definir correctamente las
funciones requeridas, sino que también, se considera de mejor calidad cuando el coste
de su mantenimiento es bajo y la dificultad de introducir nuevos cambios (nuevos
requisitos) también es baja o insignificante”
El usuario final mide la calidad del software de acuerdo con los resultados que este le
proporcione, a fin de cumplir con el propósito de su creación, optimizar los recursos
utilizados y su comportamiento a lo largo del tiempo. De lo que estamos hablando es de
un software que es fácil de adaptar a los cambios y mejoras, en este sentido, la calidad
del software depende de quién juzgará. Existen métodos de evaluación de software más
objetivos, que incluyen: métricas, estadísticas, etc.
¿Qué estándares deben seguirse al gestionar la certificación de procesos de software?
ISO 9000, CMMI.
3.2.2.1 Medición del software
A través de la medición, podemos monitorear y controlar el desarrollo del producto y la
evolución del proceso. A través de la medición, podemos evaluar que producto o
proceso es mejor. Otro punto clave en el desarrollo de software es predecir desde una
perspectiva de planificación. (Gómez, 2012).
3.2.2.2 Conceptos básicos
Medida
Las medidas proporcionan una indicación cuantitativa del grado, cantidad, tamaño,
capacidad y tamaño de ciertos atributos de un proceso o producto2.
Métrica
Medida cuantitativa del grado en que un sistema, componente o proceso tiene un
atributo dado. (IEEE, 1993).
2
https://laingenieriaderequerimientos.wordpress.com/la-determinacion-de-metricas-de-la-ingenieria-de-
requerimientos/#:~:text=Dentro%20del%20contexto%20de%20la,acto%20de%20determinar%20una
%20medida.
Indicador
Métrica o combinación de métricas que proporcionan una visión profunda, del proceso
de software, del proyecto de software o del producto en sí. (Ragland, 1995).
3.2.2.3 Tipos de indicadores
Indicadores de procesos
Brindan una comprensión mas profunda de la efectividad de los procesos existentes. Se
recopilan durante un largo periodo de tiempo de todos los proyectos de la organización
para obtener mejoras a largo plazo en el proceso del software.
Indicadores de proyecto
Permiten:
Evaluar el estado del proyecto en curso.
Rastrear riesgos potenciales.
Descubrir los problemas críticos antes de que ocurran.
Ajustar el flujo de trabajo y las tareas.
Evaluar la capacidad del equipo del proyecto para controlar la calidad del
proyecto.
Indicadores de producto
Permiten evaluar su calidad.
En la figura 3 se muestra el modelo de calidad de software.
Figura 6. Modelo de calidad de software
CAPITULO IV PROCESOS DE DESARROLLO DE
SOFTWARE
4.1 Introducción
4.2 Etapas del proceso de desarrollo de software
4.2.1 Análisis de requisitos
4.2.2 Principios de especificación
4.2.3 Diseño y arquitectura
4.2.4 Programación
4.2.5 Prueba
4.2.6 Documentación
4.2.7 Mantenimiento
4.3 Modelos del ciclo de vida
4.3.1 Modelo en cascada
4.3.2 Modelo de desarrollo Evolutivo
4.3.3 Modelo de prototipado de Requerimientos
4.3.4 Modelo de desarrollo basado en reutilización
4.3.5 Modelo de desarrollo en espiral
4.3.6 Modelo de desarrollo incremental
CAPITULO V Rational Unified Process (RUP) Proceso
Unificado de Rational
5.1 Introducción
5.2 Características de RUP
5.3 Principio de desarrollo
5.3.1 Adaptar el proceso
5.3.2 Balancear prioridades
5.3.3 Demostrar valor iterativamente
5.3.4 Elevar el nivel de abstracción
5.3.5 Enfocarse en la calidad
5.4 Ciclo de vida de RUP
5.5 Proceso
5.6 Fases
5.7 Fases
5.7.1 Fase de Inicio
5.7.2 Fase de Elaboración
5.7.3 Fase de Construcción
5.7.4 Fase de Transición
5.8 Grado de conocimiento del Método RUP en el Perú
CAPITULO VI ELEMENTOS DE RUP
6.1 Elementos de RUP
6.2 Actividad
6.3 Trabajador (ROL)
6.4 Artefactos
6.5 Actividades Primarias y secundarias o de apoyo
CAPITULO VII CASO PRACTICO EMPLEANDO RUP
7.1 Introducción
7.2 Caso VOLVO IT
7.2.1 Experiencia con los proyectos RUP
7.2.2 Efectos de usar RUP
BIBLIOGRAFIA
Blanco, A. (2015). Definición de Ingeniería de Software. Ingeniería de Software.
https://trabajosoftware.webcindario.com/unidad-1/el-proceso/defenicion-de-ingenieria-
software.html
Zelkovitz, M. V., Shaw, A. C. y Gannon J. D. (1979). Principles of Software
Engineering and Design. Englewoods Clif, NJ, USA: Prentice – Hall.
Bauer, F. L. (1972). “Software Engineering” in Informaction Processing 71:
Proceedings of IFIP Congress 71, Ljubljana, Yugoslavia.
IEEE, IEEE Standard Glossary of Software Engineering Terminology (IEEE Std
610.12-1990). USA: IEEE, 1990.
Gomez Blanes, R. (2018). Que es calidad del software. Site profesional de Rafa G.
Blanes. https://www.rafablanes.com/blog/elpdpa-que-es-la-calidad-del-software
Gomez, J. (2012). ¿Por qué se debe medir el software?. El laboratorio de las TI.
https://www.laboratorioti.com/2012/11/12/por-que-se-debe-medir-el-
software/#:~:text=La%20medici%C3%B3n%20nos%20permite%20el,de%20vista
%20de%20la%20planificaci%C3%B3n.
IEEE Software Engineering Standards. Standard 610.12-1990, 1993
Ragland, B. (1995). Measure, Metric or Indicator: What ́s the Difference?, Crosstalk, 8
(3), 29-30.
GLOSARIO
ANEXOS
