El documento presenta información sobre el proceso RUP (Rational Unified Process). Describe que RUP es un marco de proyecto iterativo e incremental que define un conjunto de actividades y artefactos para construir procesos personalizados. RUP se divide en cuatro fases: inicio, elaboración, construcción y transición. La fase de inicio se enfoca en definir el alcance del proyecto, la fase de elaboración en el análisis y diseño, la fase de construcción en la implementación incremental, y la fase de transición en la entrega del producto.

1. INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
GESTIÓN DE PROYECTO
DESARROLLO DE
SOFTWARE
CARRERA: INGENIERIA DE SISTEMAS
ASIGNATURA: ANALISIS DE SISTEMAS
DOCENTE: DAVID ENRIQUE MENDOZA GUTIERREZ
GRUPO: A

2. HISTORIA
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).
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

3. 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.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

4. RUP
RATIONAL UNIFIED PROCESS
Forma disciplinada de asignar tareas y
responsabilidades en una empresa de desarrollo
(quién hace qué, cuándo y cómo).
METODO: pesado
COSTO DE CAMBIO: Un cambio en las etapas de vida del sistema
incrementaría notablemente el costo.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

5. ELEMENTOS
CENTRALES QUE
DEFINEN RUP
1) Un conjunto subyacente de filosofías
y principios para conseguir un
desarrollo de software correcto.
2) Una infraestructura de bloques de
construcción del proceso y
contenido del método reutilizables.
3) El método subyacente y el lenguaje
de definición del proceso.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

6. 1.-Conjunto subyacente de filosofías y principios
para conseguir un desarrollo de software
correcto.
Estas filosofías y principios son la
base sobre la que se ha desarrollado
RUP
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

7. 2.-Una infraestructura de bloques de construcción
del proceso y contenido del método reutilizables.
Definida y mejorada de forma
continuada por Rational Software, la
familia RUP de plug-ins de método
define una infraestructura de
método desde la que puede crear
sus propias configuraciones de
método y procesos personalizados.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

8. 3.-El método subyacente y el lenguaje de
definición del proceso.
La base es un metamodelo de
arquitectura de método
unificado. Este modelo
proporciona un lenguaje para
describir los procesos y el
contenido del método.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

9. RUP
Es un marco del proyecto
que describe una clase de
los procesos que son
iterativos e incrementales.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

10. Define un manojo entero
de las actividades y de los
artefactos que usted
necesita elegir para
construir sus propios,
proceso individual.
RUP
AUTOR:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

11. Es el proceso de desarrollo
más general de los
existentes actualmente.
Los procesos de RUP
estiman tareas y horario
del plan midiendo la
velocidad de iteraciones
concerniente a sus
estimaciones originales.
RUP
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

12. Las iteraciones tempranas de proyectos conducidos RUP se
enfocan fuertemente sobre arquitectura del software
la puesta en práctica rápida de características se
retrasa hasta que se ha identificado y se ha
probado una arquitectura firme.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

13. RUP proporciona muchas
ventajas sobre XP le da
énfasis en los requisitos y
el diseño
La ventaja principal de RUP
es que se basa todo en las
mejores prácticas que se
han intentado y se han
probado en el campo
RUP
XP
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

14. RUP SE DIVIDE EN
CUATRO FASES:
-I nicio (Define el alcance del
proyecto)
-Elab oración (definición,
análisis, diseño)
-Con stru cción
(implementación)
-Tran s ición (fin del proyecto
y puesta en producción)
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

15. 1.-INICIO
Durante la fase de inicio se
define el modelo del negocio y
el alcance del proyecto. Se
identifican todos los actores y
Casos de Uso, y se diseñan los
Casos de Uso más esenciales
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
OBJETIBOS DE
ESTA FACE
SON:
• Establecer el ámbito del proyecto y sus límites.
• Encontrar los Casos de Uso críticos del sistema
• Mostrar al menos una arquitectura candidata
• Estimar el coste en recursos y tiempo de todo el proyecto.
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

16. RESULTADOS DE
LA FASE DE
INICIO:
• Un documento de visión: Una visión general de los
requerimientos del proyecto, características clave y
restricciones principales.
• Modelo inicial de Casos de Uso (10-20% completado).
• Un glosario inicial: Terminología clave del dominio.
• El caso de negocio. • Lista de riesgos y plan de
contingencia
. • Plan del proyecto, mostrando fases e iteraciones.
• Modelo de negocio, si es necesario
• Prototipos exploratorios para probar conceptos o la
arquitectura candidata
• Estimar los riesgos, las fuentes de incertidumbre.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

17. AL TERMINAR LA FASE DE INICIO SE DEBEN COMPROBAR LOS
CRITERIOS DE EVALUACIÓN PARA CONTINUAR:
• Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las
estimaciones de agenda.
• Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso principales.
• Las estimaciones de tiempo, coste y riesgo son creíbles.
• Comprensión total de cualquier prototipo de la arquitectura desarrollado.
• Los gastos hasta el momento se asemejan a los planeados.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

18. 2.-ELABORACIÓN
El propósito de la fase de
elaboración es analizar el
dominio del problema,
establecer los cimientos de
la arquitectura, desarrollar
el plan del proyecto y
eliminar los mayores
riesgos
OBJETIBOS
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
• Definir, validar y cimentar la arquitectura.
• Completar la visión.
• Crear un plan fiable para la fase de construcción.
• Demostrar que la arquitectura propuesta soportará la visión
con un coste razonable y en un tiempo razonable.

19. AL TERMINAR DEBEN OBTENERSE LOS
SIGUIENTES RESULTADOS:
• Un modelo de Casos de Uso completa al menos hasta el 80%
• Requisitos adicionales
• Descripción de la arquitectura software.
• Un prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados.
• Plan de desarrollo para el proyecto.
• Un caso de desarrollo actualizado
• Un manual de usuario preliminar (opcional). En esta fase se debe tratar de abarcar todo el
proyecto con la profundidad mínima.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

20. Los criterios de evaluación de esta fase son los
siguientes:
• La visión del producto es estable.
• La arquitectura es estable.
• Se ha demostrado mediante la ejecución del prototipo que los principales elementos de
riesgo han sido abordados y resueltos.
• El plan para la fase de construcción es detallado y preciso.
• Todos los interesados coinciden en que la visión actual será alcanzada.
• Los gastos hasta ahora son aceptables, comparados con los previstos.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

21. 3.-CONTRUCCIÓN
La finalidad principal de
esta fase es alcanzar la
capacidad operacional del
producto de forma
incremental a través de las
sucesivas iteraciones
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
OBJETIBOS
• Minimizar los costes de desarrollo
• Conseguir una calidad adecuada
• Conseguir versiones funcionales (alfa, beta, y otras versiones
de prueba) tan rápido como sea práctico.

22. LOS RESULTADOS DE LA FASE DE CONSTRUCCIÓN
DEBEN SER:
• Modelos Completos
• Arquitectura íntegra
• Riesgos Presentados Mitigados
• Plan del Proyecto para la fase de Transición.
• Manual Inicial de Usuario
• Prototipo Operacional – beta
• Caso del Negocio Actualizado
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

23. 4.-TRANSICIÓN
La finalidad de la
fase de transición es
poner el producto
en manos de los
usuarios finales
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
LO QUE SE
PUEDE INCLUIR
• Prueba de la versión Beta
• Funcionamiento paralelo con los sistemas
• Conversión de las bases de datos operacionales.
• Entrenamiento de los usuarios y técnicos de mantenimiento.
• Traspaso del producto

24. PRINCIPALES
OBJETIBOS:
• Conseguir que el
usuario se valga por sí
mismo.
• Un producto final
que cumpla los
requisitos esperados
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
RESULTADOS
• Prototipo Operacional
• Documentos Legales
• Caso del Negocio Completo
• Línea de Base del Producto completa y corregida
• Descripción de la Arquitectura completa y
corregida
• Las iteraciones de esta fase irán dirigidas
normalmente a conseguir una nueva versión.

25. RUP DEFINE NUEVE DISCIPLINAS A REALIZAR EN
CADA FASE DEL PROYECTO:
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
Cada fase en RUP puede descomponerse en iteraciones.
Una iteración es un ciclo de desarrollo completo dando
como resultado una entrega de producto ejecutable
(interna o externa)

26. EL PROCESO DEFINE
UNA SERIE DE ROLES:
Los roles se distribuyen entre
los miembros del proyecto y
que definen las tareas de
cada uno y el resultado
(artefactos) que se espera de
ellos.
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

27. TODOS LOS MIEMBROS
DEL EQUIPO
COMPARTEN:
1 Base de conocimiento
1 Proceso
1 Vista de cómo desarrollar
software
1 Lenguaje de modelamiento
(UML)
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

28. RUP:
-Realiza un levantamiento exhaustivo
de requerimientos.
-Busca detectar defectos en las fases
iniciales.
-Intenta reducir al número de cambios
tanto como sea posible.
-Realiza el Análisis y diseño, tan
completo como sea posible.
-Diseño genérico, intenta anticiparse a
futuras necesidades.
-Las necesidades de clientes no son
fáciles de discernir.
-Existe un contrato prefijado con los
clientes. El cliente interactúa con el
equipo de desarrollo mediante
reuniones a diferencia de la
metodología XP que el cliente es parte
del equipo (in situ).
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ

29. CUANDO DEBO
UTILIZAR RUP
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
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
POR QUE:

30. INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ
POR QUE UTILIZAR RUP?
 Permite la publicación de un método personalizado de
Rational Method Composer y que éste sea accesible a
todo el equipo del proyecto.
 Permite que ese método se configure para satisfacer
las necesidades exclusivas de cada proyecto.
 Proporciona a cada usuario filtrado personalizado.

31. CONCLUCION
DEL USO DE RUP:
-RUP es un proceso de
ingeniería de software orientada
a objetos
-RUP captura varias de las
mejores practicas en el
desarrollo moderno de software
-RUP trabaja con el mejor
estándar de modelos UML
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
4.-Luis Miguel Garcia
ASIGNATURA: Análisis y diseño de sistemas
DOCENTE: David Enrique Mendoza Gutiérrez
5.-Ronny Sossa
6.-Bruno Alexander Loaiza
7.-Alan SancheZ