RUP (Resumen)

Curso de Metodologías de desarrollo de software
RUP ( Proceso Racional Unificado)
Carreño Garavito Victor Manuel
UPIICSA
Teoría Informática
1cv12

INDICE
•INTRODUCCION
•ANTECENDENTES HISTORICOS
•TEORIA
•EJERCICIOS
•CONCLUSION

¿Qué es RUP (Rational Unified Process)
RUP es un proceso de desarrollo de software
y junto con el Lenguaje Unificado de
Modelado UML, constituye la metodología
estándar más utilizada para el análisis,
implementación y documentación de
sistemas orientados a objetos.
El RUP es un producto de Rational (IBM). Se
caracteriza por ser iterativo e incremental,
estar centrado en la arquitectura y guiado por
los casos de uso.
Incluye artefactos (que son los productos
tangibles del proceso como por ejemplo, el
modelo de casos de uso, el código fuente, etc.)
y roles (papel que desempeña una persona en
un determinado momento, una persona puede
desempeñar distintos roles a lo largo del
proceso).

Principales características
• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
• Pretende implementar las mejores
prácticas en Ingeniería de Software
• Desarrollo interactivo
• Administración de requisitos

Principales características
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software

¿Quien creo RUP?
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.

Funcionalidades a través del tiempo
Su funcionalidad parte de una serie de
métodos los cuales se puede comentar,
el método Ericsson, 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
ModelingTechnique) 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.

Funcionalidades a través del tiempo
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 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.

Principios de desarrollo
• Adaptar el proceso: El proceso deberá adaptarse a las
necesidades del cliente ya que es muy importante interactuar con
él.
• Equilibrar prioridades: Los requisitos de los diversos
participantes pueden ser diferentes, contradictorios o
disputarse recursos limitados.
• Demostrar valor iterativamente: Los proyectos se entregan,
aunque sea de un modo interno, en etapas iteradas.
El RUP está basado en 6 principios clave que son los
siguientes:

• Colaboración entre equipos: El desarrollo de software no lo
hace una única persona sino múltiples equipos.
• Elevar el nivel de abstracción: Este principio dominante motiva el uso de
conceptos reutilizables tales como patrón del software, marcos de referencia
(frameworks) por nombrar algunos.
• Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada
iteración, sino en todos los aspectos de la producción.
Principios de desarrollo

Fases
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: En esta parte nos encontramos
con las siguientes etapas:
• Gestión del cambio y configuraciones
• Gestión del proyecto
• Entorno

• Fase de Inicio:
• Esta fase tiene como propósito definir y acordar
el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto,
producir el plan de las fases y el de iteraciones
posteriores. “detalles muy generales de la
arquitectura de software”
• Fase de Elaboración:
• En la fase de elaboración se diseña la solución
preliminar , se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y
se desarrollaran en esta fase, y el primer análisis
del dominio del problema.
Fases
La estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4
fases descritas anteriormente:

Fase de Desarrollo:
El propósito de esta fase es completar
la funcionalidad del sistema, paraello
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.
Fase de transición(cierre)
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.
Fases

Artefactos
RUP en cada una de sus fases realiza una serie de artefactos
que sirven para comprender mejor tanto el análisis como el
diseño del sistema .
Inicio:
• Documento Vision
• Especificación de Requisitos
Elaboración:
• Diagramas de caso de uso

• Construcción: Documento Arquitectura que trabaja con las siguientes
vistas:
• Vista Lógica
• Diagrama de clases
• Modelo E-R (Si el sistema así lo requiere)
• Vista de Implementación
• Diagrama de Secuencia
• Diagrama de estados
• Diagrama de Colaboración
• Vista Conceptual
• Modelo de dominio
• Vista física
• Mapa de comportamiento a nivel de hardware.
Artefactos

Ciclo de vida
• Las primeras iteracionesen las fases de
Inicio y Elaboración) se enfocan
hacia la comprensión del problema y
la tecnología ( Durante la fase de
inicio las iteraciones hacen mayor
énfasis en actividades de modelado
del negocio y de requisitos )
• En la fase de elaboración, las
iteraciones se orientan al desarrollo de
la baseline de la arquitectura, abarcan
más los flujos de trabajo de requisitos,
modelo de negocios (refinamiento),
análisis, diseño y una parte de
implementación orientado a la baseline
de la arquitectura.

• En la fase de transición se
pretende garantizar que se
tiene un producto
preparado para su entrega
a la comunidad de
usuarios
• En la fase de construcción, se lleva a
cabo la construcción del producto por
medio de una serie de iteraciones.(Para
cada iteración se seleccionan algunos
Casos de Uso)
Ciclo de vida

Comprobante de Gasto
En una organización gubernamental, cada vez que se debe registrar un gasto, se ingresa un comprobante de
gastos, que de acuerdo a la disponibilidad de presupuesto que tengamos va a permitir o no su ingreso. Luego, de
ser aprobado el comprobante de gastos, se emite un comprobante de pago. El CG puede ser ingresado de dos
maneras, en forma borrador o en forma completa. El CG luego de ser ingresado en forma completa, pasa por un
proceso de firmas por el cual se realizaran distintas autorizaciones, hasta que llegue a la última autorización, y
pase a estado Autorizado.
Se puede grabar como Borrador o en forma completa. Se permite modificar no cambiando el estado. También se
permite grabar en forma completa estando en borrador, y viceversa. Dichos comprobantes en cualquiera de los
dos estados se pueden anular. Antes de ser autorizado totalmente, pasa por autorizaciones intermedias. Al
rechazar una autorización pasa al estado anterior (grabado en forma completa). Al ir autorizando el CG, se puede
también dejarlo en observación.
Cuando un CG esta en observación, puede rechazarse y volver a ingresado, o volver al proceso de autorización, o
si es la ultima autorización, pasar a ser un CG autorizado. Una vez autorizado el CG se le puede modificar ciertos
atributos. Una vez que el comprobante este autorizado, pueden ocurrir tres cosas:
• Que se desautorice, anulando la Comprobante de Pago;
• Que se cancele;
• Que se de por cumplido, luego de haber hecho la liquidación de gastos.
• Salvo el primero, los otros se pueden revertir.

stm DTE_GS_00_Comprobante de Gastos
Inicial
Ingresado borrador
Ingresado
Proceso de Firm a
para Autorizar
Autorizado
Anulado
Final
Final
Observado para
Autorizar
Cancelado CumplidoDesautorizado
Este DT E no aplica a los Comprobantes
de Gastos Liquidables ni de Modificación
Modificar
despues de
autorizado
Revertir
Cumplimiento
Modificar
despues de
autorizado
Revertir
Cancelación
Autorizar [T iene nivel
de autorización
intermedia]
Autorizar [T iene nivel de
autorización definitiva
(última firma)]
Rechazar Firma
Modificar
despues de
autorizado
Cumplir
Desautorizar Cancelar
autorización intermedia]
Revertir autorización
propia
Rechazar Firma
Sacar de la Firma
[comprobante sin
firmas]
autorización definitiva
(última firma)]
Observar
Anular
Poner a la Firma
/Aviso a
Responsables
Jerarquia 1
Modificar
Modificar
[graba como
borrador]
Anular
Modificar
[graba como
completo]
Modificar [graba como
borrador]
Ingresar
[completo]
Ingresar
[borrador]

Hotel
Un nuevo cliente en la empresa para la cual trabajamos es dueño del futuro hotel
“Estrellita de Mar” y nos comenta su problema de no poder encontrar un software en el
mercado que cubra todas sus necesidades. Luego de haber realizado un par de reuniones,
y de realizada la propuesta, y aprobada por el cliente, podemos identificar los siguientes
requerimientos:
Ingresar las habitaciones, según su tipo (simple, doble y matrimonial) y comodidades
(frigobar, TV, y DVD).
Consultar las habitaciones disponibles y poder reservar habitaciones en su hotel. El hotel
posee dos tipos de clientes: habituales y esporádicos. Una reserva almacena datos del
cliente, de la habitación reservada, la fecha de comienzo y el número de días que será
ocupada la habitación.

El recepcionista del hotel debe poder hacer las siguientes operaciones:
· Obtener un listado de las habitaciones disponible de acuerdo a su tipo.
· Preguntar por el precio de una habitación de acuerdo a su tipo.
· Preguntar por el descuento ofrecido a los clientes habituales.
· Preguntar por el precio total para un cliente dado, especificando su número de reserva, tipo de
habitación y número de noches.
· Dibujar en pantalla la foto de una habitación de acuerdo a su tipo.
· Reservar una habitación especificando el número de la pieza, reserva y nombre del cliente.
· Eliminar una reserva especificando el número de la habitación.
El administrador puede usar el programa para:
· Cambiar el precio de una habitación de acuerdo a su tipo.
· Cambiar el valor del descuento ofrecido a los clientes habituales.
· Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses
tienen treinta días).
El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a
su vez permitir agregar nuevas consultas.
También, nuestro cliente, quiere realizar un portal en la web, en donde, los visitantes puedan reservar
una o las habitaciones que desee (si el mismo posee tarjeta de crédito). Este debe registrarse al
Portal, por el cual el sistema deberá reconocer el tipo de cliente.

Actividades:
1. Leer atentamente el enunciado y actividades.
2. Realizar todas las consultas que crean necesarias.
3. Realizar el Diagrama de Casos de Uso. Opcional: Realizar
previamente un listado con todos los requerimientos, del cual
se van a derivar los casos de uso.
4. Realizar dos Casos de Uso críticos y que no representen
funcionalidad de consulta.
5. Realizar los Casos de Prueba de los dos casos de uso
anteriores.
6. Realizar el Diagrama de Clases.
7. Realizar el Diagrama de Actividad de alta de reserva.
8. Realizar el Diagrama de Estado de la reserva de una
Habitación (en esta actividad puede utilizar supuestos).

Diagrama Casos de Uso
ud Diagrama de Casos de Uso
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
Sistema
Recepcionista
Administrador
Cliente
Listado Hab.
disponibles
Consultar $
Habitacion
Consulta $ Total
Cliente
Obtener Foto
Habitacion
Consulta
descuento Cliente
Eliminar Reserva
Crear Reserva
Cambio $
Habitacion
Cambio Descuento
Cliente
Calcular Ganancia
Crear nueva
consulta
Alta Cliente
Validar Tarjeta
Credito
Reservar
Habitacion
«use»
«include»

Casos de Uso
Caso de Uso Crear Reserva
Actores Recepcionista
Proposito Registrar una reserva para una habitación.
Descripcion Un cliente solicita una habitación de ‘x’ tipo para un periodo determinado
de tiempo. El recepcionista comprueba la disponibilidad, toma los datos del
cliente y genera la reserva.
Referencias -
Precondiciones El recepcionista debe estar previamente autenticado en la aplicación.
No funcionales -
Curso Normal de los
Acontecimientos
1. El cliente solicita un periodo y un tipo de habitación para su reserva.
2. El recepcionista ingresa al sistema los datos de la estadía
3. El sistema valida su disponibilidad.
4. El recepcionista ingresa los datos personales del cliente
5. El sistema crea un huésped.
6. El sistema realiza la reserva.
Observaciones:
Faltaría un poco más de detalle, como por ejemplo que campos se detallan, que
atributos se cargan.
Es muy pobre la cantidad de validaciones (solamente una).
Curso Alternativo 1. El sistema notifica sobre la falta de disponibilidad.

Caso de Uso Eliminar Reserva
Actores Recepcionista
Proposito Eliminar una reserva previamente generada.
Descripcion Un cliente solicita la cancelación de una reserva que ha
efectuado con antelación.
Referencias -
Precondiciones El recepcionista debe estar previamente autenticado en la
aplicación.
No funcionales -
Curso Normal de los
Acontecimientos
1. El cliente solicita la cancelación de su reserva.
2. El recepcionista ingresa los datos de la reserva
3. El sistema verifica su existencia.
4. El recepcionista elimina la reserva
5. El sistema elimina la reserva y libera la habitación para futuras reservas.
Curso Alternativo 3.1 El sistema notifica que la reserva no existe.
Casos de Uso

Casos de Prueba
Nº
Test
Nombre Precondiciones Pasos a realizar Resultado Esperado Éxito
Fallo
1 Registración
de Reserva
Debe existir
disponibilidad
del tipo de
habitación y
para el periodo
seleccionado.
1. El recepcionista ingresa
al sistema con su clave y
usuario.
2. Selecciona el botón
“ABM Reservas”.
desde y hasta fecha de la
reserva; selecciona el tipo
de habitación y
selecciona el botón
“Grabar Reserva”.
 La habitacion
reservada cambia
su estado a
reservada.
 Queda registrado
en la base de
datos la reserva
de la habitación y
los datos del
cliente.
 El sistema
devuelve un
mensaje con el
nro de reserva
Caso
Positivo

Nº
Test
Fallo
2 Registración
de Reserva 2
No debe existir
disponibilidad
del tipo de
habitación y
para el periodo
seleccionado.
al sistema con su clave y
usuario.
“ABM Reservas”.
desde y hasta fecha de la
reserva; seleccióna el
tipo de habitación y
presiona el botón
“Grabar Reserva”.
 No se realiza
registración de la
reserva en la base
de datos.
 El sistema
devuelve un
mensaje
“habitación no
disponible”.
Caso
negati
vo
Casos de Prueba

Nº
Test
Fallo
3 Eliminar
de Reserva
1
Debe existir la
reserva
previamente
ingresada al
sistema.
1. El recepcionista ingresa al
sistema con su clave y
usuario.
2. Selecciona el botón “ABM
Reservas”
“Buscar Reservas”
4. Ingresa en el formulario de
búsqueda de reservas los
datos de la reserva a buscar,
y selecciona el botón
“Buscar”
5. Selecciona la reserva
buscada, y presiona el
botón “Eliminar Reserva”.
6. Selección a “Continuar”
ante el aviso del sistema
informando que va a
eliminar una reserva.
 Se eliminar de la base
de datos la reserva. Y
se libera la habitación
para reservas futuras.
 Se debe mostrar un
mensaje con el aviso
de que se está por
eliminar una reserva,
y dar la posibilidad
de cancelar la acción.
 Mensaje final de
reserva eliminada.
Se puede especificar que
mensaje a mostrar o
utilizar una referencia al
mensaje a utilizar.
Caso
positivo
Casos de Prueba

Nº
Test
Fallo
4 Eliminar
de Reserva
2
No debe existir
la reserva
previamente
ingresada al
sistema.
1. El recepcionista ingresa al
sistema con su clave y
usuario.
“ABM Reservas”
“Buscar Reservas”
4. Ingresa en el formulario
de búsqueda de reservas
los datos de la reserva a
buscar, y selecciona el
botón “Buscar”
 Mensaje del sistema
avisando que no
existe reserva.
 No se realizan
modificaciones en la
base de datos.
Caso
negativ
o
Casos de Prueba

Diagrama de Clases
cd Diagrama de Clases•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
Cliente
- Id: int
- Nombre: char
- Direccion: char
- NroTarjetaCredito: char
+ CrearCliente() : void
+ ModificarCliente() : void
+ EliminarCliente() : void
+ ValidarTarjeta() : void
Habitacion
- Nro: int
- Tipo: char
- Precio_Noche: double
+ CrearHabitacion() : void
+ ModificarHabitacion() : void
+ EliminarHabitacion() : void
+ ImprimirFoto() : void
+ ObtenerPrecio() : void
Reserva
- Id_Reserva: int
- Cliente: Cliente
- Habitacion: Habitacion
- FechaDesde: datetime
- FechaHasta: datetime
+ CrearReserva() : void
+ EliminarReserva() : void
+ CalcularPrecioTotal() : void
CLI_Habitual
- Descuento: double
+ ObtenerDescuento() : void
Hotel
- Habitaciones: Habitacion
+ ConsultarDisponibilidad() : void
+ CalcularGanancias() : void
+ CrearConsultas() : void
0..*
1..*
1
0..
*
1
1..*

Diagrama de Actividades
ad Diagrama de Activ idad
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• •••••••••••••••••••••••••• ••••••••••••••••••••••••••
Existe Tipo Habitacion
Ingresa Fechas de la
reserv a
Ingresa Otro tipo de Hab.
Ingresa datos del Cliente
Creacion de la Reserv a
Mensaje con el Nro de
reserv a
Disponibilidad de Fechas
Ingresa Nuevas Fechas
Mensaje "Desea elegir
otras fechas?"
[SI]
[SI]
[SI]

Diagrama de Estado
sm Diagrama de Estado
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
•••••••••••••••••••••••••• ••••••••••••••••••••••••••
Disponible
Reservada
Ocupada
Fuera de servicio
Huesped ocupa la hab
Se reserva
Se cancela reserva
Check-Out

Ventajas
Está basada totalmente en mejoras practicas de la
metodología:
• Reduce riesgos del proyecto.
• Incorpora fielmente el objetivo de calidad.
• Integra desarrollo con mantenimiento.

Desventajas
• Pretende prever y tener todo el control de antemano:
• Modelo genera trabajo adicional.
• Genera muchos costos.
• No recomendable para proyectos pequeños.

RUP (Resumen)

Más contenido relacionado

La actualidad más candente (18)

Similar a RUP (Resumen) (20)

Más de Victor Manuel Carreño Garavito (11)

Último (20)

RUP (Resumen)