lOMoARcPSD|5717404

Documentación proyecto software final

Ingeniería de Software I (Universidad Popular del Cesar)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por Luis Huancas Ojeda ([email protected])
 lOMoARcPSD|5717404

PROYECTO DE INGENIERIA DE SOFTWARE

HOTELES EN LINEA

UNIVERSIDAD POPULAR DEL CESAR

INGENIERIA DE SOFTWARE I

VALLEDUPAR CESAR

2018

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

TABLA DE CONTENIDO

1 TITULO DEL PROYECTO................................................................................................

2 AUTORES Y DOCENTE……………………………………………………………...
3 LINEA DE INVESTIGACION............................................................................................
4 ESTADO DEL ARTE........................................................................................................
5 DESCRIPCION DEL PROBLEMA...................................................................................
6 JUSTIFICACION...............................................................................................................
7 OBJETIVOS DE LA INVESTIGACION............................................................................
7.1 OBJETIVO GENERAL.............................................................................................
7.2 OBJETIVOS ESPECIFICOS....................................................................................
8 ASPECTOS METODOLOGICOS.....................................................................................
9 BIBLIOGRAFIA................................................................................................................
10 ESPECIFICACION DE ROLES……………………………………………………...
11 MODELADO DEL NEGOCIO………………………………………………………..
12 FORMATO DE ENTREVISTA……………………………………………………….
13 REQUERIMIENTOS FUNCIONALES………………………………………………
14 CASOS DE USO………………………………………………………………………
15 HISTORIAS DE USUARIO…………………………………………………………..
16 DIAGRAMA ENTIDAD RELACION (LOGICO)…………………………………...
17 MODELO RELACIONAL…………………………………………………………….
18 DICCIONARIO DE DATOS………………………………………………………….
19 DIAGRAMA CLASES………………………………………………………………..
20 DIAGRAMA DE CASOS DE USOS………………………………………………..
21 DESCRIPCION DE CASOS DE USOS……………………………………………
22 DIAGRAMA DE ACTIVIDADES……………………………………………………
23 DIAGRAMA DE SECUENCIAS…………………………………………………….

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

1. TITULO DEL PROYECTO

“SISTEMA PARA LA GESTION DE RESERVAS Y HABITACIONES

DISPONIBLES DE LOS HOTELES DE LA CIUDAD DE VALLEDUPAR”

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

2. AUTORES Y DOCENTE
El proyecto está conformado por los siguientes integrantes:
-CARLOS CAMARGO OÑATE
-DANIEL DIAZ DIAZ
-RAMIRO MARTINEZ JIMENEZ
-LAURA HERNANDEZ RAMIREZ
Y es dirigido por el Profesor:
- LUIS CARLOS ROSADO

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

3. LINEA DE INVESTIGACION

AREA
Ingeniería de software
SUBLINEA
Desarrollo de Aplicaciones web
En los últimos años aplicaciones web con grandes capacidades han sido de gran
provecho a sus usuarios, ya que sus servicios han ido aumentando
considerablemente para que cualquier persona con una movilidad continua tenga
muchas ventajas, por lo tanto las empresas tomen esto a su favor y también
tengan un papel importante para poder brindar sus servicios a todos los clientes
con una mayor claridad y eficacia.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

4. ESTADO DEL ARTE

La implementación de sistema de reservas de habitaciones de hoteles es un

proyecto con grandes referencias internacionales, ya que no solo ha ayudado a
mejorar la producción a las empresas hoteleras sino que también ha facilitado la
vida a usuarios de todo tipo, desde empresarios que viajan constantemente a
diferentes lugares por exigencia de trabajo hasta aquellas personas que están
buscando nuevas experiencias para sus vacaciones, por eso que es necesario
para el buen desarrollo de este proyecto, que tomemos ejemplo de las siguientes
referencias que han tenido éxito en este mismo ámbito.

INTERNACIONAL

Booking.com: La historia de booking.com empezó en 1996, aunque no se

consagró como una web de referencia hasta que pasó a formar parte del gigante
estadounidense priceline.com. Esta web nació con una vocación comercial para
ofrecer tarifas rebajadas en hoteles y vuelos a sus usuarios. Priceline no ofrecía
directamente estos servicios, sino que facilitaba su reserva poniendo en contacto
al proveedor y al cliente.[1]

Esta filosofía es la que se transmitió a booking.com. Además, gracias a la

popularidad que ha ido adquiriendo puede garantizar los precios más bajos de la
red. Booking ofrece a los hoteles una plataforma que recibe cada día millones de
visitas y a cambio les pide que garanticen unos precios muy competitivos. Eso
hace que en julio de 2013 booking.com cuente con una cartera de casi 325.000
hoteles en 184 países. Estas cifras incluyen alojamientos rurales y urbanos, de
playa y de interior, y de un amplio abanico de precios y categorías. [1]

Aunque está inscrita en la ciudad neerlandesa de Ámsterdam, booking.com está

compuesta por un equipo de más de 5.500 personas que trabajan en más de 100
ciudades de casi 60 países. De hecho, existen versiones de la web traducidas a
41 idiomas. Todas estas cifras nos dan una idea de la magnitud de este gigante de
la planificación turística. Pero más allá de fríos números está la experiencia de
millones de personas. Lo importante es que booking.com se ha convertido en un

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

referente del sector. Igual que cuando una persona necesita aspirinas va a la
farmacia, son miles los que acuden automáticamente a booking.com para planear
sus vacaciones. [1]

NACIONAL

SISTEMA DE ADMINISTRACIÓN HOTELERA ZEUS. FRONT DESK: Zeus

Tecnología ha desarrollado esta herramienta que brinda en forma rápida confiable
y segura información, que facilitara a los funcionarios del Hotel la realización de
sus labores, agilizando las funciones de administración y control, generando
oportunamente información para la toma de decisiones, puesto que se pueden
emitir reportes de tipo financiero y estadístico, que permiten evaluar las
transacciones y rendimientos de las áreas operativas del Hotel en cualquier
momento. Zeus Hoteles, es un Software Visual, desarrollado en tecnología Cliente
– Servidor y Bases de Datos relacionales SQL, listo para operar de manera
amigable sobre plataforma Windows. En el módulo de reservas Zeus brinda las
herramientas necesarias para realizar las reservaciones de habitaciones, tanto a
nivel individual como de grupos, además dispone de facilidades para la
elaboración de reservas. Este módulo permite realizar entre otros, depósitos a las
reservas así como los procesos de devoluciones, transferencias y aplicaciones de
los mismos. Este software fue creado por 20 ingenieros de desarrollo y soporte los
cuales trabajan para una Empresa Colombiana afiliada a Fedesoft. Además Zeus
es un producto 100% Colombiano con oficinas en Cartagena y Bogotá. [2]

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

5. DEFINICION DEL PROBLEMA

La ciudad de Valledupar cuenta con una población aproximada de 294.731

habitantes según el último censo; es concurrida por turistas en diferentes épocas
del año, en especial para el festival vallenato, desde grupos familiares dispuestos
a pasar sus vacaciones en la ciudad, hasta empresarios y artistas reconocidos,
debido a la alta población de turistas en este tipo de fechas se requiere un
sistema que facilite información relevante a hospedaje tales como disponibilidad
en los hoteles, costos, reputación y ubicación.. De acuerdo con lo anterior
podemos identificar que el problema actual de la ciudad de Valledupar en este
aspecto es que actualmente no cuenta con un sistema que proporcione
información al usuario sobre los distintos hoteles que están ubicados en la ciudad,
asequibilidad y disponibilidad de sus habitaciones como consecuencia de esto
tenemos la alta dificultad y la poca seguridad a la hora de encontrar alojamiento lo
que causa la cantidad de turistas que llega a la ciudad no sea de mayor
proporción.
En concordancia con lo anterior se propone el desarrollo de un aplicativo web
para la gestión de reservas en los hoteles de la ciudad de Valledupar y que facilite
al usuario contar con un listado de habitaciones, tipo, costo y disponibilidad de los
mismos.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

6. JUSTIFICACION
Con este aplicativo se pretende mejorar el funcionamiento de los hoteles online
para lograr seguridad y eficiencia en los procesos de registro y reservas de los
huéspedes,
Cabe agregar que con el diseño y desarrollo del sistema de reservas de hoteles
online se pretende satisfacer las necesidades de la población de Valledupar en su
totalidad, brindando una mejor interfaz e información constantemente actualizada
de los hoteles de esta misma ciudad, así mismo se pretende brindar toda la
información que los funcionarios de los hoteles requieran para desempeñar mejor
sus labores.
Hay que destacar que la implementación de este aplicativo puede ser de suma
importancia para mejorar el desarrollo turístico de la ciudad ofreciendo así una
menor dificultad para los visitantes a la hora de encontrar alojamiento.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

7. OBJETIVOS DE LA INVESTIGACION

7.1 OBJETIVO GENERAL

-Desarrollar un aplicativo web que logre facilitar y agilizar los procesos de registro
y reservas de los huéspedes dentro de los hoteles online.

7.2 OBJETIVOS ESPECÍFICOS

-Analizar los procesos actuales para el proceso de reserva realizado por los
hoteles rey de Reyes, Tativan y el Sonesta.

-Diseñar la base de datos para el almacenamiento y accesibilidad a la información.

-Desarrollar los módulos: cliente, reserva, usuarios, habitaciones, hoteles y pagos.

- Codificar el aplicativo basado en el patrón de diseño MVC.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

8. ASPECTOS METODOLOGICOS

La metodología utilizada para la realización de este proyecto es la metodología

ágil SCRUM que consiste en abordar proyectos complejos desarrollados en
entornos dinámicos y cambiantes de un modo flexible. Está basada en entregas
parciales y regulares del producto final con base al valor y prioridades de los
clientes. Como complemento a la etapa de análisis y diseño se utilizó Uml a
través de la especificación de diagramas de casos de uso, actividades, secuencias
y diagrama de clases.
-Posteriormente se realizó el diseño del sistema, definiendo módulos y
componentes del mismo, donde se especifica cada uno de los campos a
acompañado del diseño y la interfaz.
-En la etapa de implementación se trabajó con las siguientes herramientas Python,
HTML5, Javascript, CSS3, Bootstrap, Django, Trello, Git y Pychram. Luego se
validó y verifico el sistema con pruebas como cuestionarios y entrevistas a sus
clientes para medir la calidad y satisfacción que dejo la aplicación.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

9. BIBLIOGRAFIAS

1. http://www.booking.com/index.es.html?aid=340290;label=metatrivago-
hotel-298063_xqdz-02fe78702804c34b0290db088e7aa740_los-1_nrm-
1_gstadt-2_gstkid-0_curr-eur_lang-
es;sid=98587ad0344180044283dc0f927b3886;click_from_logo=1

2. http://www.zeustecnologia.com/zeuswebsite/public/products.aspx?
cd_type=Front

3. http://reservashoteleras.com.co/public/default.asp

4. http://zeusfrontweb.blogspot.com.co/2013/06/video-reservando-con-
zeus-hoteles-web.html

5. http://www.theblendedmarketing.com/2011/06/como-funciona-booking-
los-chanchullos-de-un-negocio-muy-rentable/

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

10. ESPECIFICACIÓN DE ROLES

Persona Contacto Rol

Daniel Díaz 3102460388 Scrum master, analista
Laura Hernandez 3123978639 Diseño
Carlos Camargo 3039134102 Tester, programador
Ramiro Martínez 3003525838 Analista, documentador

11. MODELADO DEL NEGOCIO

Actualmente en Valledupar no se cuenta con un sistema que facilite la gestión de

hoteles, en la cual brinde una búsqueda rápida de habitaciones con las
características que se necesita y tener una mayor experiencia en pagar un
servicio; Por lo cual el siguiente modelo permite visualizar las descripciones de
todos los procesos actuales que realiza la empresa y deben sistematizarse.

 REGISTRO DE CLIENTE
Permite recopilar y actualizar la información personal (nombres, dirección, cedula,
teléfono) de todos los usuarios que buscan un mejor servicio para satisfacer su
necesidad.

 REGISTRO DE EMPRESA
Permite el registro y actualización de todos los datos de los hoteles como su
nombre, dirección, categoría, precios, servicios y tipos de habitación que tienen
disponible para brindar un buen servicio a todos los usuarios.

 DISPONIBILIDAD
Este módulo permite revisar o tener un listado de todos los hoteles que brinden
sus servicios con las características y filtros que necesitan o estén buscando el
cual son precio, popularidad, distancia, calificación, comentarios, servicios para
así poder ofrecer al cliente.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

 RESERVAS
Este formato permite realizar acciones tales como realizar, anular y actualizar
reservas de habitaciones, pagos y fechas del servicio que estemos solicitando.
 INFORMES
En este módulo se encuentra la disponibilidad de observar varios informes o
estadística con el fin de comparar y sacar conclusiones como por ejemplo de la
empresa, habitación y servicios más solicitados.
 GESTION DE HABITACIONES
En este módulo se realiza la supervisión, estado técnico, mantenimiento y algo
muy importante la limpieza de las habitaciones con el objetivo de tener un control
muy bueno de ellas.
 ADMINISTRATIVO
Permite realizar funciones administrativas tales como aplicar descuentos, realizar
facturas, aplicar impuestos, gestionar pagos, por lo cual se ahorra tiempo y se
optimiza posibles errores.

12. FORMATO DE ENTREVISTA

Ítem Fecha Entrevistado Objetivo de la entrevista.

01 30/09/201 Empleado Obtener información de los
6 procesos manejados en el hotel
Rey de Reyes y así analizar el
grado de conformidad de los
empleados con el sistema
actual
02 02/10/201 Clientes Analizar las preferencias de un
6 cliente a la hora de buscar un
hotel y obtener información
sobre qué tipo de hoteles se
pueden adaptar a sus
necesidades.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

FORMATO DE ENCUESTA PARA EMPLEADO DEL HOTEL:

1) ¿En la actualidad que herramientas utilizan para la gestión de procesos?

2) ¿Cuáles son los procesos que actualmente se realizan en el hotel?
3) ¿Considera usted importante sistematizar los procesos?
4) ¿Cree que el sistema utilizado actualmente cubre las necesidades del hotel?
5) ¿Qué le mejoraría al proceso de reservas actual?
6) ¿Qué desventajas tiene el sistema de reservas actual?
7) ¿Qué calificación le da al sistema de reservas utilizado por el hotel?
8) ¿Qué información se le pide al cliente a la hora de hacer la reserva?
9) ¿Qué tipo de habitaciones maneja el hotel?
10) ¿Qué tipo de productos consumibles se le ofrece al cliente?

FORMATO DE ENCUESTA PARA CLIENTES:

1) ¿Al momento de seleccionar un hotel que criterios tiene en cuenta?

2) ¿Considera importante visualizar las habitaciones previo a la reserva?
3) ¿Puede marcar diferencia en la descripción de los servicios?
4) ¿Son importantes los comentarios de los anteriores clientes?
5) ¿Qué método utiliza para hacer su reserva?
6) ¿Cree que la implementación de un software de reservas optimizaría los
procesos de reserva?
7) ¿Qué características debería ofrecer un sistema de gestión hotelera para
cubrir sus necesidades?

13. REQUERIMIENTOS FUNCIONALES

N° REQUERIMIENTO DESCRIPCIÓN PRIORIDAD

A-01 Disponibilidad de El Aplicativo deberá mostrar al Alta
habitaciones usuario la disponibilidad de las
aplicaciones y el tipo de
habitaciones.
A-02 Registro de Clientes El Cliente deberá registrarse con Alta
sus datos personales (Cedula de
Ciudadanía, Nombres y
Apellidos, Fecha de Nacimiento,
Sexo, Correo Electrónico y
teléfono) en la página del
aplicativo para poder acceder al

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

sistema y así ver la disponibilidad

de las habitaciones
A-03 Registro de El sistema deberá contar con un Alta
Administradores administrador el cual se deberá
registrar en el aplicativo para
controlar todas las actividades de
reservas que se hagan en el
aplicativo
A-04 Consumo del El aplicativo deberá almacenar Media
cliente los diferentes consumos hechos
por el cliente durante su estadía
en el hotel.
A-05 Categorías de El aplicativo deberá almacenar Media
habitaciones los diferentes tipos de
aplicaciones que hay en el hotel y
de acuerdo a eso mostrar una
breve descripción de las
diferentes categorías
A-06 Codificación de El aplicativo deberá almacenar Baja
servicios prestados cada uno de los servicios
por el hotel prestados por el hotel con un
código y la descripción del
servicio
A-07 Facturas y Reportes El aplicativo deberá generar una Alta
factura o un reporte en el cual
deberá mostrar todos los
consumos hechos por el cliente
así mismo el sistema deberá
permitir la impresión de dicha
factura o reporte
A-08 Registro de Hoteles En el aplicativo se deberán Alta
registrar los diferentes hoteles de
la ciudad de Valledupar y así
mismo registrar las habitaciones
y el tipo de habitaciones que
maneja el hotel
A-09 Registro de En el aplicativo se deberán Alta
Habitaciones registrar las diferentes
habitaciones que posee un hotel
especificando tipo y ubicación de
estas mismas.
A-10 Mantener la El Aplicativo deberá realizar Alta
integridad de la backups para asegurarse de
información guardar con seguridad las
reservas que se hagan por día y
el registro de las ventas.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

A-11 Comparación de El aplicativo deberá mostrar el Media

precios de precio de las habitaciones en los
habitaciones diferentes hoteles de la ciudad de
Valledupar y de acuerdo a eso el
cliente podrá escoger el hotel que
más se adapte a sus
necesidades

14. CASOS DE USO

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

15. HISTORIAS DE USUARIO

A continuación, se presenta las historias de usuario identificadas en la primera
iteración del desarrollo del sistema para la gestión y optimización de procesos
para los hoteles en la ciudad de Valledupar. Cada una de las historias de usuario
se ha identificado de forma general para abstraer las funcionalidades más
relevantes para este sistema.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

HISTORIA DE USUARIO
Número: 1 Usuario: Cliente
Nombre de historia: Registro de clientes
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 2 días Iteración asignada: 1
Programador responsable: Carlos Camargo
Descripción:
El cliente (usuario) debe entregar al sistema sus datos (nombres, cédula,
dirección, teléfono, correo) para registrarse en el sistema.
Validaciones:
 El sistema debe validar los datos para el registro del cliente.

HISTORIA DE USUARIO
Número: 2 Usuario: Cliente
Nombre de historia: Verificar disponibilidad
Prioridad en negocio: Media Riesgo en desarrollo: Media
Puntos estimados: 1 día Iteración asignada: 2
Programador responsable: Carlos Camargo
Descripción:
El cliente puede buscar las habitaciones que se encuentran disponible en el
hotel escogido.
Validaciones:
 Verificar si los patrones de consulta no afectan la base de datos.

HISTORIA DE USUARIO
Número: 3 Usuario: Cliente
Nombre de historia: Tipo de habitación
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 1 día Iteración asignada: 2
Programador responsable: Carlos Camargo
Descripción:
Este es uno de los parámetros de consulta para encontrar el tipo de habitación
que quiere un cliente. Los tipos de habitaciones pueden ser: sencillas,
matrimoniales, dobles, tipo estudio, tipo suite, triples, entre otros.
Validaciones:
 Verificar si el tipo de habitación que quiere el cliente se encuentra
disponible.
HISTORIA DE USUARIO
Número: 4 Usuario: Cliente
Nombre de historia: Realizar reserva
Prioridad en negocio: Riesgo en desarrollo: Media
Puntos estimados: 2 día Iteración asignada: 3
Programador responsable: Carlos Camargo
Descripción:

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Permite que el cliente pueda realizar su reserva ingresando el tipo de habitación,

número de días, fecha, tipo de pago.
Validaciones:
 Verificar que los datos proporcionados por el cliente, no afecten la
integridad de la base de datos.

HISTORIA DE USUARIO
Número: 5 Usuario: Recepcionista
Nombre de historias: Eliminar reserva
Prioridad en negocio: Media Riesgo en desarrollo: Medio
Puntos estimados: 1 día. Iteración asignada: 4
Programador responsable: Carlos Camargo
Descripción:
Permite cancelar una reserva hecha por un cliente a través del sistema, esto
puede presentarse cuando no se establece una comunicación con el cliente
para llegar a un acuerdo o si el cliente no se presenta en el hotel antes de la
fecha de la reserva de la habitación.
Validaciones:
 Solo las reservas que no sean confirmadas o validadas pueden ser
borradas.

HISTORIA DE USUARIO
Número: 6 Usuario: Recepcionista
Nombre de historia: Consultar datos de la reserva.
Prioridad en negocio: Media Riesgo en desarrollo: Medio
Puntos estimados: 1 día. Iteración asignada: 3
Programador responsable: Carlos Camargo
Descripción:
Permite que el recepcionista pueda ver la información detallada de una reserva.
Validaciones:
 Validar que los datos para la consulta sean válidos.

HISTORIA DE USUARIO
Número: 7 Usuario: Recepcionista
Nombre de historia: Consultar datos del cliente.
Prioridad en negocio: Media Riesgo en desarrollo: Medio
Puntos estimados: 2 días Iteración asignada: 3
Programador responsable: Carlos Camargo
Descripción:

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Permite que el recepcionista pueda ver la información detallada del cliente, en

caso tal que se quiera comunicar con él para llegar a un acuerdo, necesite
confirmar algún dato o que solo quiera revisar la información registrada.
Validaciones:
 Verificar que el cliente este registrado en el sistema.

HISTORIA DE USUARIO
Número: 8 Usuario: Recepcionista
Nombre de historia: Validar reserva
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 1 día. Iteración asignada: 4
Programador responsable: Carlos Camargo
Descripción:
Permite confirmar la reserva de la habitación una vez que se haya llegado a un
acuerdo con el cliente.
Validaciones:
 Verificar que los datos proporcionados por el cliente, no afecten la
integridad de la base de datos.

HISTORIA DE USUARIO
Número: 9 Usuario: Recepcionista
Nombre de historia: Registrar pago
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 3 días. Iteración asignada: 4
Programador responsable: Carlos Camargo
Descripción:
Permite que el recepcionista registre el pago de una reserva, cuando se acuerda
la forma de pago o si se hace un descuento.
Validaciones:
 Verificar que los datos proporcionados al sistema, no afecten la integridad
de la base de datos.

HISTORIA DE USUARIO
Número: 10 Usuario: Recepcionista
Nombre de historia: Listado de habitaciones
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 1 día. Iteración asignada: 1
Programador responsable: Carlos Camargo
Descripción:

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Permite que el recepcionista pueda obtener el listado de las habitaciones con

datos básicos como precio y disponibilidad, con la finalidad de que se pueda
informar a un cliente que quiera hacer una reserva de forma presencial.
Validaciones:
 Ninguna, el sistema proporciona los datos solo con un clic del usuario.

HISTORIA DE USUARIO
Número: 11 Usuario: Administrador
Nombre de historia: Registrar habitación
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 2 días. Iteración asignada: 1
Programador responsable: Carlos Camargo
Descripción:
Permite que el administrador pueda registrar las habitaciones disponibles de su
hotel, con la finalidad de que los clientes pueden hacer reservas en estas
habitaciones.
Validaciones:
 Verificar que los datos proporcionados al sistema, no afecten la integridad
de la base de datos.

HISTORIA DE USUARIO
Número: 12 Usuario: Recepcionista
Nombre de historia: Registrar descuentos
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 1 día. Iteración asignada: 1
Programador responsable: Carlos Camargo
Descripción:
Permite que el recepcionista registre los descuentos que se han establecido a
los clientes al momento de realizar el pago de una reserva.
Validaciones:
 Verificar que el cliente haya realizado una reserva.

HISTORIA DE USUARIO
Número: 13 Usuario: Administrador
Nombre de historias: Informes
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Puntos estimados: 4 días. Iteración asignada: 5
Programador responsable: Carlos Camargo
Descripción:

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Permite que el administrador pueda generar una serie de informes, con el fin de
conocer información, como por ejemplo el mes de más reservas confirmadas,
mejores clientes, mejores vendedores, calidad del servicio, etc.
Validaciones:
 Ninguna, el sistema proporciona la información sin que el usuario o
administrador le entrega datos para obtener los informes.

16. DIAGRAMA ENTIDAD RELACIÓN (LÓGICO)

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

17. MODELO RELACIONAL

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

18.

DICCIONARIO DE DATOS

PERMISOS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
Identificador auto-
incremental de
LLAVE
id INTEGER permisos (llave
PRIMARIA
primaria de
permisos).
Este es el nombre
del permiso que se
VARCHA
nombre 50 NO ES NULO asigna cuando se
R
crea un nuevo
permiso.

ROLES

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN

S DATO D
Identificador auto-
LLAVE incremental de
id INTEGER
PRIMARIA roles (llave primaria
de roles).
Este es el nombre
VARCHA del rol que se
nombre 50 NO ES NULO
R asigna cuando se
crea un nuevo rol.

PERMISOSROLES
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
LLAVE
INTEGE Identificador del
permisos_id FORANEA, NO
R permiso para un rol.
ES NULO
LLAVE Identificador del rol
INTEGE
roles_id FORANEA, NO para ponerle un
R
ES NULO permiso.

PERSONAS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
Identificador de la
id INTEGER PRIMARIA
persona.
Dirección de
VARCHA
direccion 50 NO_NULO residencia de la
R
persona.
VARCHA Nombre de la
nombre 50 NO_NULO
R persona.
VARCHA Primer apellido de
apellido1 50 NO_NULO
R la persona.
VARCHA Segundo apellido
apellido2 50
R de la persona
VARCHA Teléfono de la
telefono 50 NO_NULO
R persona.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

USUARIOS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
Esta es la llave
LLAVE
id INTEGER primaria de la tabla
PRIMARIA
usuarios.
Cada usuario tiene
un nombre de
VARCHA
username 50 UNICO usuario único que
R
lo identifica en el
sistema.
VARCHA Contraseña de la
password 50
R cuenta del usuario.
Identificador de la
persona, porque un
LLAVE
personas_id INTEGER usuario se crea a
FORANEA
partir de un
persona.
LLAVE Un usuario tiene un
roles_id INTEGER
FORANEA rol asignado.
Un usuario tiene es
de un hotel (el
LLAVE mismo usuario no
hoteles_id INTEGER
FORANEA puede estar dos
veces en el mismo
hotel).

CIUDADES
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
LLAVE Identificador único
id INTEGER
PRIMARIA para una ciudad.
VARCHA Nombre de la
nombre 50 NO ES NULO
R ciudad.

HOTELES
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
Identificador único
id INTEGER PRIMARIA
para un hotel.
VARCHA Nombre de un
nombre 100 NO_NULO
R hotel.
direccion VARCHA 50 NO_NULO Dirección física del

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

R edificio del hotel.

Teléfono para
VARCHA
telefono 20 NO_NULO comunicarse con el
R
hotel.
Identificador de la
Ciudades_id INTEGER ciudad en la que se
encuentra el hotel.

DESCUENTOS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
INTEGE Identificador único
id PRIMARIA
R para un descuento.
INTEGE Nombre del
nombre
R descuento.
DECIMA Porcentaje de
porcentaje
L descuento.
Fecha de inicio del
fechaInicio DATE periodo de
descuento.
Fecha en que cierra
fechaFin DATE el periodo de
descuento.

TIPOSHABITACIONES
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
Identificador del
id INTEGER PRIMARIA
tipo de habitación.
VARCHA Nombre del tipo de
nombre 50
R habitación.

DESCUENTOSTIPOSHABITACIONES
ATRIBUTOS TIPO DE LONGITU RESTRICCIÓ DESCRIPCIÓ
DATO D N N
Identificador
del descuento
INTEGE
descuentos_id FORANEA que se aplicará
R
a un tipo de
habitación.
tiposhabitaciones_i INTEGE FORANEA Identificador

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

del tipo de
d R
habitación.

RESERVAS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
INTEGE Identificador de la
id PRIMARIA
R reserva.
Fecha en que se
fecha DATE
hizo la reserva.
Identificador de la
INTEGE
Personas_id FORANEA persona que
R
reservó.
INTEGE El usuario que
Usuarios_id FORANEA
R registró la reserva.

PAGOS
ATRIBUTO TIPO DE LONGITU RESTRICCIÓN DESCRIPCIÓN
S DATO D
INTEGE Identificador único
id PRIMARIA
R del pago.
INTEGE Fecha en el que se
fecha FORANEA
R hizo el pago.
DECIMA Valor del pago de la
Valor
L reserva.
INTEGE Reserva a la que se
Reservas_id FORANEA
R le hizo el pago.

19. DIAGRAMA DE CLASES DEL NEGOCIO

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

20. DIAGRAMA DE CASOS DEL SISTEMA

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

21. DESCRIPCIÓN DE LOS CASOS DE USO.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

DESCRIPCION CASOS DE USOS

Caso de uso: Iniciar sesión.
Actores: Cliente, recepcionista y administrador.
Tipo propósito: Asociación.
Resumen: Cada usuario debe proporcionarle al sistema sus datos
personales para registrarse y hacer uso de la
funcionalidad completa de este.
Precondición: El usuario ya debe contar con su usuario y contraseña
para entrar al sistema.
Postcondiciones: El cliente puede ingresar al sistema.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Las credenciales no son válidas porque no
cumplen con un formato respetado por el sistema,
por ejemplo, puede contener caracteres extraños
o contienen sentencias SELECT, INSERT,
UPDATE o DELETE, esto con la finalidad de
prevenir un ataque de Inyección SQL (E3).
 El sistema informa que no se puede completar el
registro debido a que los datos no cumplen con
un formato válido (E3).
EXCEPCIÓN (E2): Credenciales no válidas
 El usuario y contraseña no coinciden con uno que
esté en la base de datos, por tanto, la persona no
podrá acceder al sistema (E3).
 El sistema informa a la persona que intenta
registrarse que las credenciales (nombre de
usuario y contraseña) no existen en el sistema y
que no puede iniciar sesión con esas credenciales
(E3).
EXCEPCIÓN (E3): Ha ocurrido un error interno en la
aplicación
 El sistema informa al cliente que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

DESCRIPCION CASOS DE USOS

Caso de uso: Registrar cliente.
Actores: Cliente.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Tipo propósito: Asociación.

Resumen: El cliente (que será un usuario) debe entregar al sistema
sus datos (nombres, cedula, teléfono, dirección) para
registrarse en el sistema.
Precondición: El usuario ya debió iniciar sesión en la plataforma.
Postcondiciones: se le ha aceptado el registro al cliente.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
el formato del sistema, por ejemplo, puede
contener caracteres extraños o contienen
sentencias SELECT, INSERT, UPDATE o
DELETE, esto con la finalidad de prevenir un
ataque de Inyección SQL (E3).
 El sistema informa que no se puede completar el
registro debido a que los datos no cumplen con
un formato válido (E3).

EXCEPCIÓN (E2): Usuario no válido porque ya existe

 El sistema al verificar los datos, encuentra un
usuario en la base de datos con el mismo nombre
de usuario que intenta registrarse, por lo tanto, no
se puede completar el registro del cliente (E3).
 El sistema informa que el nombre de usuario que
se intenta usar ya existe en la base de datos y
que debe seleccionar un nuevo nombre de
usuario (E3).

EXCEPCIÓN (E3): Ha ocurrido un error interno en la

aplicación
 El sistema informa al cliente que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

DESCRIPCION CASOS DE USOS

Caso de uso: Registrar habitación.

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Actores: Administrador.
Tipo propósito: Asociación.
Resumen: Permite que el administrador registre una nueva
habitación en su hotel, para esto le indica al sistema
cuales son los datos de la habitación para que el sistema
los guarde.
Precondición: El administrador deberá ingresar al sistema para tener
acceso a las funcionalidades de la plataforma.
Postcondiciones: Se deberá verificar que la habitación esté disponible.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
un formato respetado por el sistema, por ejemplo,
los datos enviados no pueden contener
caracteres extraños o contener sentencias
SELECT, INSERT, UPDATE o DELETE, esto con
la finalidad de prevenir un ataque de Inyección
SQL (E3).
 El sistema informa que no se puede realizar la
operación debido a que los datos no cumplen con
un formato válido (E3).

EXCEPCIÓN (E2): Código de habitación no válido

 El sistema detecta que ya existe una habitación
con ese código, este código es único por eso no
se puede hacer la operación (E3).
 El sistema informa que no se puede registrar la
habitación porque ya existe una habitación con
ese código de habitación registrado en la base de
datos (E3).

EXCEPCIÓN (E3): Ha ocurrido un error interno en la

aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

DESCRIPCION CASOS DE USOS

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Caso de uso: Registrar tipo de habitación.

Actores: Administrador.
Tipo propósito: Include.
Resumen: Permite que el administrador pueda registrar un tipo de
habitación en la base de datos. Este es uno de los
parámetros de consulta para encontrar el tipo de
habitación que quiere un cliente. Los tipos de
habitaciones pueden ser: sencillas, matrimoniales,
dobles, tipo estudio, tipo suite, triples, entre otros.
Precondición: El administrador deberá haber verificado que la
habitación esté disponible.
Postcondiciones: Al administrador se le acepta el registro del tipo de
habitación.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
un formato respetado por el sistema, por ejemplo,
los datos enviados no pueden contener
caracteres extraños o contener sentencias
SELECT, INSERT, UPDATE o DELETE, esto con
la finalidad de prevenir un ataque de Inyección
SQL (E2).
 El sistema informa que no se puede realizar la
operación debido a que los datos no cumplen con
un formato válido (E2).

EXCEPCIÓN (E2): Ha ocurrido un error interno en la

aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

EXCEPCIÓN (E3): Código del tipo de habitación ya

existe
El sistema informa que ya existe un tipo de habitación
con código que se le quiere asignar al nuevo tipo de
habitación (E2).

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

DESCRIPCION CASOS DE USOS

Caso de uso: Reservar habitación.
Actores: Cliente y recepcionista.
Tipo propósito: Asociación.
Resumen: Permite que el cliente una vez que ha encontrado la
habitación que desea a partir de la disponibilidad y el
tipo de habitación, este puede realizar una reserva en un
hotel específico.
Precondición: Para hacer la reserva deberá estar la habitación
registrada como disponible.
Postcondiciones: Al administrador se le ha aceptado el registro del tipo de
habitación.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
un formato respetado por el sistema, por ejemplo,
los datos enviados no pueden contener
caracteres extraños o contener sentencias
SELECT, INSERT, UPDATE o DELETE, esto con
la finalidad de prevenir un ataque de Inyección
SQL (E2).
 El sistema informa que no se puede realizar la
operación debido a que los datos no cumplen con
un formato válido (E2).

EXCEPCIÓN (E2): Ha ocurrido un error interno en la

aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

EXCEPCIÓN (E3): Código del tipo de habitación ya

existe
El sistema informa que ya existe un tipo de habitación
con código que se le quiere asignar al nuevo tipo de
habitación (E2).

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

DESCRIPCION CASOS DE USOS

Caso de uso: Confirmar habitación.
Actores: Recepcionista.
Tipo propósito: Asociación.
Resumen: Permite que el recepcionista confirme una habitación,
cuando haya acordado la forma de pago o si se hace un
descuento.
Precondición: El cliente debió pedir una reserva en una habitación.
Postcondiciones: Al recepcionista se le ha aceptado la confirmación de la
habitación.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
un formato respetado por el sistema, por ejemplo,
los datos enviados no pueden contener
caracteres extraños o contener sentencias
SELECT, INSERT, UPDATE o DELETE, esto con
la finalidad de prevenir un ataque de Inyección
SQL (E2).
 El sistema informa que no se puede realizar la
operación debido a que los datos no cumplen con
un formato válido (E2).

EXCEPCIÓN (E2): Ha ocurrido un error interno en la

aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

DESCRIPCION CASOS DE USOS

Caso de uso: Cancelar reservas.
Actores: Recepcionista.
Tipo propósito: Asociación.
Resumen: Permite que el recepcionista proceda a cancelar una
reserva si no se llegó a un acuerdo con el cliente o no se
pudo contactar.
Precondición: Que el cliente haya pedido una reserva.
Postcondiciones: Se le acepta al recepcionista cancelar la reserva.
Excepciones: EXCEPCIÓN (E1): Ha ocurrido un error interno en la
aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

DESCRIPCION CASOS DE USOS

Caso de uso: Registrar pagos.
Actores: Recepcionista.
Tipo propósito: Asociación.
Resumen: Permite que el recepcionista pueda registras los pagos
de las reserves que se han hecho en el hotel.
Precondición: Que el cliente haya pedido pagado una reserva.
Postcondiciones: Se registra el pago que ha realizado un cliente.
Excepciones: EXCEPCIÓN (E1): Campos ingresados no válidos para
el sistema
 Los datos no son válidos porque no cumplen con
un formato respetado por el sistema, por ejemplo,
los datos enviados no pueden contener
caracteres extraños o contener sentencias
SELECT, INSERT, UPDATE o DELETE, esto con
la finalidad de prevenir un ataque de Inyección
SQL (E3).
 El sistema informa que no se puede realizar la
operación debido a que los datos no cumplen con
un formato válido (E3).
EXCEPCIÓN (E2): La reserva ya tiene un pago
registrado previamente
 El sistema detecta que la habitación de la reserva
a la que se quiere registrar un pago ya tiene su

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

pago previamente asignado (E3).

 El sistema informa que no se puede registrar la
reserva porque ya existe una reserva en ese
periodo registrada en la base de datos (E3).

EXCEPCIÓN (E3): Ha ocurrido un error interno en la

aplicación
El sistema informa al usuario que ha ocurrido un error
interno en la aplicación (la persona no es responsable de
esto).

DESCRIPCION CASOS DE USOS

Caso de uso: Informes.
Actores: Administrador.
Tipo propósito: Asociación.
Resumen: Permite que el administrador del hotel genere un serie
de informes de acuerdo a la información que desee por
ejemplo saber cuál es el mes que se hacen más
reservas, calidad del servicio, mejores clientes, etc.
Precondición: Se deberá haber prestado varios servicios en el hotel.
Postcondiciones: Se deberá verificar todos los servicios prestados por el
hotel estén en estado de pagado.
Excepciones: EXCEPCIÓN (E1): Ha ocurrido un error interno en la
aplicación
 El sistema informa al usuario que ha ocurrido un
error interno en la aplicación (la persona no es
responsable de esto).

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

22. DIAGRAMA DE ACTIVIDADES

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

23. DIAGRAMA DE SECUENCIA

Descargado por Luis Huancas Ojeda ([email protected])

 lOMoARcPSD|5717404

Descargado por Luis Huancas Ojeda ([email protected])