1. ELABORADO POR:
ARMANDO DÍAZ CONDE
ROSARIO REYES LÓPEZ

2. Metodología
El Proceso Unificado Racional (RUP) es un
producto de ingeniería de software que
proporciona en 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 tiempos
establecidos.

3. El proceso puede ser descrito en dos dimensiones o ejes como se muestra en
la figura.
El eje horizontal.- Representa la línea del tiempo y es considerado el eje de los
aspectos dinámicos del proceso. Indica las características del ciclo de vida
del proceso, representado en fases (Inicio, Elaboración, Construcción y
Transición), iteraciones e hitos.
Eje vertical.- Representa los aspectos estáticos del proceso. Describe el
proceso en términos de componentes de proceso, disciplinas o flujos de
trabajo , artefactos, roles y actividades.
Estructura General
del Proceso RUP

4. Características
• Proceso dirigido por Caso de uso
• Proceso centrado en la arquitectura
• Proceso iterativo e incremental

5. Proceso Dirigido por Caso de
Uso
Con esto se refiere a la utilización de los Casos de Uso
para el desenvolvimiento y desarrollo de las disciplinas
con los artefactos, roles y actividades necesarias. Los
Casos de Uso son la base para la implementación de las
fases y disciplinas del RUP. 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

6. Ejemplo de Diagrama de
Caso de Uso de negocios.
Caso de Negocios:
Modelar la
Empresa
(como funciona la
empresa a la que se le va a
desarrollar el software)

7. Proceso Centrado de
Arquitectura
La arquitectura de un sistema es la organización o estructura
de sus partes más relevantes, lo que permite tener una visión
común entre todos los involucrados (desarrolladores y
usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.

8. Administrador
Base de Datos
Líder de
Proyecto
Analista
Diseñador/
Desarrollador
Ingeniero de
Desempeño
Pruebas
Administrador de
Configuración
Incremento de la
Productividad en Equipo

9. Proceso Iterativo e Incremental
Durante todo el proceso de desarrollo se producen versiones
incrementales (que se acercan al producto terminado) del producto en
desarrollo. Es práctico dividir el esfuerzo de desarrollo de un proyecto de
software en partes mas pequeñas o mini proyectos, permitiendo que el
equilibrio entre casos de uso y la arquitectura vayan logrando una
iteración. Cada mini proyecto es una iteración que resulta en un
incremento.
Desarrollo Iterativo
Requerimientos Análisis y Diseño
Implementación
Pruebas
Evaluación
Cada iteración
produce un
producto
ejecutable
Una
Iteración
RUP
Además incluye:
• La planificación de la
iteración
• El análisis de la Iteración
• Actividades Especificas

10. Fases del RUP
En cada extremo de una fase se realiza una evaluación (actividad:
Revisión del ciclo de vida de la finalización de fase) para
determinar si los objetivos de la fase se han cumplido. Una
evaluación satisfactoria permite que el proyecto se mueva a la
próxima fase.

11. El ciclo de vida de RUP, como se conoce al trazado de las actividades
de desarrollo en el tiempo, está dividido en 4 fases: Inicio, Elaboración,
Construcción y Transición, que corresponden a los 4 hitos principales
de RUP.
En términos de habilidades y conocimiento, el RUP esta dividido
en principios clave. Cada uno de ellos corresponde a distintos
aspectos del desarrollo de software que generalmente requieren
habilidades específicas; esto se refleja en los roles y las actividades
definidas para cada principio.
Ciclo de vida RUP

12. Ciclo de vida RUP
Cada fase cambia el foco del equipo de trabajo para alcanzar cada
uno de los hitos y es llevada a cabo en forma iterativa. Esto quiere
decir que la fase se fragmenta en pequeños proyectos que recorren
todas las disciplinas y producen un ejecutable en el sentido de
software. Dicho producto es la forma más efectiva de verificar el
progreso del proyecto y de reducir los riesgos inherentes.

13. Fase Inicio
Alcanzar un acuerdo entre todos los interesados respecto a los
objetivos del ciclo de vida para el proyecto, generando el ámbito
del proyecto.
Propósito
• Establecer casos de negocios
• Síntesis de arquitectura
• Especificar el alcance del proyecto
Resultado:
• Visión general de los requerimientos del proyecto
• Un caso de negocios inicial, incluyendo (Evaluación inicial de
riesgos y Una estimación de los recursos requeridos).

14. Fase Elaboración
Propósito
• Analizar el problema.
• Establecer la arquitectura.
• Desarrollar un plan comprensivo.
Resultado
• Un modelo del dominio 80% completo.
• Requerimientos suplementarios.
• Una lista de riesgos revisada.

15. Fase Construcción
• El producto se desarrolla a través de iteraciones donde cada
iteración involucra tareas de análisis, diseño e implementación.
• Las fases de inicio y elaboración sólo dieron una arquitectura
básica que es aquí refinada de manera incremental conforme
se construye (se permiten cambios en la estructura).
• 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 .

16. Fase Transición
• 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
• Estas tareas se realizan también en iteraciones.
• Se han alcanzado los objetivos fijados en la fase de
Inicio. - El usuario está satisfecho.

17. Todas las fases no son idénticas en términos de tiempo y
esfuerzo. Aunque esto varía considerablemente dependiendo
del proyecto, un ciclo de desarrollo inicial típico para un
proyecto de tamaño mediano debe anticipar la distribución
siguiente el esfuerzo y horario

18. En un ciclo evolutivo, las fases de inicio y elaboración
serían considerablemente pequeñas. Algunas
herramientas pueden automatizar una cierta porción del
esfuerzo de la fase de Construcción pueden atenuar
esto, haciendo que la fase de construcción sea mucho
más pequeña que las fases de inicio y elaboración
juntas. Este es precisamente el objetivo del trabajo.
Cada paso con las cuatro fases produce una generación
del software. A menos que el producto "muera", se
desarrollará nuevamente repitiendo la misma secuencia
las fases de inicio, elaboración, construcción y transición,
pero con diversos énfasis cada fase.

19. Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una
secuencia de pasos para la culminación de cada disciplina, estas
disciplinas se dividen en dos grupos:
Las primarias para la realización de un proyecto de software:
• Modelado del Negocio
• Requerimientos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue.
Las de apoyo sirve como apoyo a las primarias y especifican otras
características en la realización del proyecto estas son:
• Entorno
• Gestión del Proyecto
• Gestión de Configuración y Cambios

20. Organización y elementos en RUP
Ya conociendo varias partes del RUP nos concentraremos
ahora en los elementos que lo componen, entre estos se tienen:
Flujos de Trabajo, Detalle de los Flujos de Trabajo, Actores,
Actividades y Artefactos

21. Actores o roles
Son los personajes encargados de la realización de las
actividades definidas dentro de los flujos de trabajo de cada una
de las disciplinas del RUP, estos actores se dividen en varias
categorías:
• Analistas
• Desarrolladores
• Probadores
• Encargados
• Otros actores

22. Artefactos
Los artefactos son el resultado parcial o final que es producido y
usado por los actores durante el proyecto. Son las entradas y
salidas de las actividades, realizadas por los actores, los cuales
utilizan y van produciendo estos artefactos para tener guías. Un
artefacto puede ser un documento, un modelo o un elemento de
modelo.

23. a) Modelado del negocio
b) Requerimientos
c) Análisis y diseño del sistema
d) Implementación
e) Pruebas
f) Despliegue
g) Administración del proyecto
h) Administración de cambios y configuración
i) Entorno o ambiente
Conjuntos de artefactos
Se tiene un conjunto de artefactos definidos en cada una de las
disciplinas y utilizadas dentro de ellas por los actores para la
realización de las mismas, a continuación se enlistan cada una de
estas categorías o grupos de artefactos dentro de las disciplinas
del RUP

24. Grado de finalización de
artefactos
Consiste en cuanto hemos finalizado del artefacto propuesto, es decir
los lineamientos que necesita para ser completado, por lo tanto con
grado de finalización nos referimos a cuantos de esos lineamientos del
artefacto hemos completado o llenado en cada una de las disciplinas,
de acuerdo a la fase en que se encuentre.

25. Introducción al UML
Desarrollo de UML, con sus versiones
UML surge como respuesta al
problema de contar con un
lenguaje estándar para escribir
planos de software. Muchas
personas han creído ver UML
como solución para todos los
problemas sin saber en muchos
casos de lo que se trataba en
realidad. El Lenguaje Unificado
de Modelado, UML es una
notación estándar para
modelado sistemas software,
resultado propuesta
estandarización promovida por
el consorcio OMG (Object
Management Group), del cual
forman parte las empresas más
importantes que se dedican al
desarrollo de software

26. Descripción del lenguaje UML
Es un lenguaje de propósito general para el modelado orientado
a objetos, que combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows).

27. Diagramas
Varios modelos aportan diferentes vistas de un sistema
los cuales nos ayudan a comprenderlo desde varios
frentes. Así, UML recomienda la utilización de nueve
diagramas que, para representar las distintas vistas de
un sistema. Estos diagramas de UML.
Diagramas, partes de un modelo

28. Metodología del RUP, para
análisis y diseño
El RUP propone la utilización de los modelos para la implementación
completa de todas sus fases respectivamente con sus disciplinas:
• Modelo de Casos de Uso del Negocio
• Modelo de Objetos del Negocio
• Modelo de Casos de Uso
• Modelo de Análisis
• Modelo de Diseño
• Modelo de Despliegue
• Modelo de Datos
• Modelo de Implementación
• Modelo de Pruebas
Estos modelos representan los diagramas que propone el UML para el
desarrollo de modelado de un proyecto de software, con los cuales
se puede representar propuestos por UML mediante la metodología
RUP utilizando las herramientas que esta provee para la
implementación fácil, clara y estructurada de los diagramas
utilizados.

29. Metodología del RUP, para
análisis y diseño
El RUP propone la utilización de los modelos para la implementación
completa de todas sus fases respectivamente con sus disciplinas:
• Modelo de Casos de Uso del Negocio
• Modelo de Objetos del Negocio
• Modelo de Casos de Uso
• Modelo de Análisis
• Modelo de Diseño
• Modelo de Despliegue
• Modelo de Datos
• Modelo de Implementación
• Modelo de Pruebas
Estos modelos representan los diagramas que propone el UML para el
desarrollo de modelado de un proyecto de software, con los cuales
se puede representar propuestos por UML mediante la metodología
RUP utilizando las herramientas que esta provee para la
implementación fácil, clara y estructurada de los diagramas
utilizados.

30. Conclusión
En en cuanto a la investigación podemos determinar que
dentro de las metodologías diseñadas para hacer más fácil el
desarrollo de software alguno de ellas se caracterizan por ser
más adaptable para proyectos de largo plazo como lo es la
metodología de RUP.
El RUP es una metodología completa y extensa que intenta
abarcar todo el mundo del desarrollo software, tanto para
pequeños proyectos, como proyectos más ambiciosos de varios
años de duración. Por lo que existe una gran cantidad de
documentación sobre el mismo, tanto en libros como en la red,
eso sí en inglés. Es sin embargo difícil empezar a aplicar esta
metodología en una organización.