Proyecto 2 Metodología 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
METODOLOGÍA RUP
CARRERA: INGENIERIA DE SISTEMAS
ASIGNATURA: ANALISIS DE SISTEMAS
DOCENTE: DAVID ENRIQUE MENDOZA GUTIERREZ
GRUPO: A

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

RUP SE DIVIDE EN
CUATRO FASES:
-I n ic io (Define el alcance del
proyecto)
-Elab o rac ió n (definición,
análisis, diseño)
-Co n stru c c ió n
(implementación)
-Tran s ic ió n (fin del proyecto
y puesta en producción)
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
5.-Ronny Sossa
7.-Alan SancheZ

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
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
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
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.

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
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.

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
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

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
5.-Ronny Sossa
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.

RUP DEFINE NUEVE DISCIPLINAS A REALIZAR EN
CADA FASE DEL PROYECTO:
INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
5.-Ronny Sossa
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)

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ

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
5.-Ronny Sossa
7.-Alan SancheZ
POR QUE:

INTEGRANTES:
1.-Jose Ali Alvis
2.-Andrez Mendoza
3.-Ariel Juruquita
5.-Ronny Sossa
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.

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
5.-Ronny Sossa
7.-Alan SancheZ

Proyecto 2 Metodología RUP

Recomendados

Recomendados

Más contenido relacionado

Similar a Proyecto 2 Metodología RUP

Similar a Proyecto 2 Metodología RUP (20)

Último

Último (20)

Proyecto 2 Metodología RUP