"Hotel Los Delfines"

Introduccin

El Hotel Los Delfines inici operaciones hace 2 aos en el puerto de Veracruz, Mxico. Ahora desea
expandirse a nivel regional hacia los dems estados que conforman el Golfo de Mxico (Tamaulipas,
Tabasco, Campeche y Yucatn). Hasta ahora no cuenta con ningn sistema automatizado de
informacin o software que apoye su principal proceso de negocio. Como parte de las estrategias que
deber implementar para lograr expandirse con xito se ha detectado la necesidad de automatizacin
del sistema de reservaciones.

Como parte de una inversin inicial, el consejo de administracin del hotel ha creado un rea de
tecnologas de informacin con un lder de proyecto, que forma parte de la plantilla del personal del
hotel para crear la infraestructura de soporte de TI. Se cuenta hasta el momento con 1 servidor HTTP
Apache v2.2 y 2 servidores de aplicaciones JBoss AS v5.1.0. Los 3 servidores corren bajo sistema
operativo Red Hat Enterprise Linux v5.9 (Tikanga). Adicionalmente se cuenta con licencia para
Oracle Database 10g Enterprise Edition Release 10.2.5.0 64 bits.

El consejo de administracin del hotel ha firmado un contrato de Outsourcing para que tu firma
desarrolle el sistema informtico que necesita el hotel. Se requiere desarrollar un sistema que soporte
el principal proceso de negocio: realizar reservaciones.

Anlisis de requerimientos

El hotel posee tres tipos de habitaciones: sencilla, doble y triple (todas con camas matrimoniales), y
dos tipos de clientes: habituales (inscritos en un programa que tiene el hotel llamado Clientes
Programa VIP en el cual se inscribe al cliente que se haya hospedado al menos una vez al mes
durante 3 meses consecutivos) y espordicos.

Una reservacin registra datos del cliente como nombre, email, telfono de contacto, fecha de llegada
y fecha de salida, nmero de adultos, nmero de nios menores de 10 aos, tipo de habitacin,
cantidad de habitaciones a reservar, y si desea servicio de estacionamiento.

Se han identificado los siguientes roles de usuario para el nuevo sistema: recepcionista y
administrador.

El recepcionista del hotel debe poder:

Obtener un reporte de las habitaciones disponibles de acuerdo a su tipo

Consultar el precio de una habitacin de acuerdo a su tipo
Cotizar el precio total a pagar para un cliente dado, especificando el tipo de habitacin y
nmero de noches
Realizar reservaciones
Cancelar reservaciones

El administrador puede usar el sistema para:

Cambiar el precio de cualquier habitacin

Cambiar el valor del descuento ofrecido a los clientes habituales

1
 Calcular las ganancias (una estimacin) que tendrn en un mes especfico (se considera que
todos los meses tienen treinta das).
Crear otros usuarios con el rol de recepcionista.

Informacin adicional

En una segunda ronda de entrevistas para detallar los requerimientos, se encontraron algunas otras
actividades o funciones del recepcionista al interactuar con el sistema propuesto. A continuacin se
muestran estos requerimientos adicionales a tomar en cuenta:

Consultar el descuento ofrecido a los clientes habituales (aquellos inscritos en el programa

Clientes programa VIP).
Consultar una determinada habitacin de acuerdo a su tipo (esta consulta muestra en pantalla
fotografas de la habitacin consultada).

El hotel posee informacin sobre qu clientes son habituales. Esto lo hace mediante una clave que
identifica al cliente como parte del programa referido anteriormente.

Las cotizaciones que haga el recepcionista deben considerar si un cliente es VIP o espordico.

Es importante considerar en el modelo, que el administrador, debido a su rol, puede realizar, en un

momento dado, todas las funciones en el sistema que realiza el recepcionista. A su vez, todas aquellas
interacciones con el sistema que impliquen una afectacin a la base de datos del sistema, por ejemplo
registrar una reservacin o modificar el precio de alguna habitacin (entre otras) debern dejar
constancia en la base de datos de la fecha, hora, usuario y operacin realizada, a manera de una
bitcora o log, por cuestiones de seguridad y rastreabilidad.

Como ya se ha determinado por el anlisis de requerimientos previo, el sistema debe contemplar 2

tipos de usuario y realizar su autenticacin de manera segura, nunca almacenando las contraseas en
texto plano, sino cifradas. Almacenar las contraseas en la base de datos como texto legible es un
riesgo enorme para la seguridad y puede ir contra la Ley de proteccin de datos. Las contraseas
deben almacenarse cifradas, por ejemplo guardando en vez de la contrasea el resultado de cifrarla
usando el algoritmo sha256 (Secure Hash Algorithm). De esta manera para validar las contraseas al
entrar en la aplicacin, se validar si el resultado de aplicar sha256 a la contrasea introducida por el
usuario es el mismo valor almacenado en la base de datos.

Por ltimo, el sistema notificar apropiadamente a los usuarios de los inicios y cierres de sesin, as
como de los eventos que requieran notificacin para cumplir los estndares de usabilidad de acuerdo
a la norma ISO-25000 (SQuaRE)1

1
Entre estos estndares se encuentra la legibilidad visual (color, tipo, tamao de fuente y adecuacin del
texto, disposicin evitando el scroll horizontal), facilidad de lectura (informacin distribuida en grupos
temticos, evitar sobrecarga de texto), orientacin al usuario (mensajes claros que indiquen la accin a
realizar, los controles de la interfaz muestran al usuario su posicin actual dentro de la aplicacin, se provee
mapa del sitio), navegabilidad, ahorro de esfuerzo, entre muchos otros. Esta norma ha introducido un nuevo
concepto llamado Learnability, que hace referencia a todos aquellos atributos presentes en una aplicacin
web que hacen posible que el usuario aprenda su uso. Para ms informacin consultar
http://iso25000.com/index.php/en/

2
La aplicacin deber desarrollarse para que pueda ser visualizada con una resolucin mnima de 800
x 600. De esta manera la aplicacin puede ser usada desde tablets o telfonos mviles de ltima
generacin.

Tareas a Desarrollar

1) Identificar los requerimientos funcionales del sistema a desarrollar.

2) Una vez identificados los requerimientos funcionales, se debern identificar los casos de uso
del sistema que cubrirn los requerimientos funcionales (Nota: Algunos casos de uso ya han
sido identificados en la semana 3. Lo que se debe hacer ahora es identificar requerimientos
funcionales y casos de uso adicionales a fin de complementar el anlisis de requerimientos).
3) Realizar el diagrama de casos de uso correspondiente (utilizando la herramienta StarUML).
Puede ocuparse de igual manera el diagrama de la semana 3 y solo actualizarlo a los nuevos
requerimientos. Para este entregable NO sern necesarias las narrativas o flujos de los
casos de uso. Realizar un anlisis detallado de tal manera que se muestren relaciones
include y extend.
4) Construir un modelo lgico del sistema mediante la creacin de Diagramas de Flujo de
Datos (DFD). Se debern incluir varios niveles de este tipo de diagrama (tomar como
referencia el DFD de la semana 3 y aumentarlo) de manera que se llegue a un nivel
suficiente de detalle (recordar que estos diagramas facilitan la comunicacin y
entendimiento entre los stakeholders). Para mayor referencia y apoyo consultar ejemplos
en http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI441/Ejemplo_DFD.pdf
5) Identificar los requerimientos no funcionales: rendimiento, seguridad, confiabilidad,
disponibilidad, mantenibilidad y portabilidad. La gran mayora de estos requerimientos se
mencionan en el planteamiento del problema. Tienen la libertad de definir los que crean
adecuados, en caso de ser necesario, a fin de tener requerimientos no funcionales para los 6
criterios solicitados.
6) Crear el Diagrama Entidad-Relacin (diseo de la base de datos) del sistema a desarrollar.
Este diagrama ser creado con la herramienta StarUML.
7) Describir los datos empleados en el sistema mediante el Diccionario de datos.
8) Toda la informacin anterior deber emplearse para elaborar el Documento de
Especificacin de Requerimientos de Software (SRS, por sus siglas en ingls). La elaboracin
de este documento (que ser el entregable) deber apegarse y respetar la plantilla
propuesta (deben respetarse secciones, encabezados, pies de pgina, tipografias, tamao
de letra, numeracin propuesta, deben eliminarse y sustituir resaltados en amarillo,
eliminar itlicas en azul, de acuerdo a las instrucciones detalladas dentro de la plantilla
misma). El alumno propondr un nombre para el proyecto.

3
Rbrica de Evaluacin del Entregable

Elementos a Principiante Competente

calificar
Plantilla de No emple la plantilla, o bien se Emple y respet la plantilla
entregable modific o alter algn elemento. propuesta y se incluyen todos los
Esto incluye no haber eliminado en elementos (de acuerdo a las
su totalidad las itlicas en azul y/o observaciones del problema y a las
no haber sustituido el texto por instrucciones dentro de la plantilla
datos reales del proyecto. misma)
(2.5 ptos) ( 5 ptos)
Casos de uso El SRS no contiene Casos de uso El SRS contiene Casos de uso
(Diagrama en StarUML y (Diagrama en StarUML y solo
descripciones) descripciones, no narrativas)
( 2.5 ptos) ( 5 ptos)
DFD El SRS no contiene diagramas de El SRS contiene los diagramas de
flujo de datos o bien solo se flujo de datos con al menos 2 o 3
muestra un nivel sin el suficiente niveles de detalle.
detalle. ( 5 ptos)
(2.5 ptos)
Diagrama ER El SRS no contiene el diagrama ER El SRS contiene el diagrama ER que
de la BD del sistema, o bien al representa la BD del sistema
diagrama le faltan entidades y/o (diagrama hecho en StarUML).
relaciones, o bien no est realizado ( 5 ptos)
en StarUML.
(2.5 ptos)
Diccionario de El SRS no contiene el diccionario El SRS contiene el diccionario de
Datos de datos datos
(2.5 ptos) ( 5 ptos)
Requerimientos El SRS no identifica requerimientos El SRS identifica tanto
funcionales y no funcionales y no funcionales, requerimientos funcionales como no
funcionales alguna o ambas categoras funcionales del sistema
(2.5 ptos) ( 5 ptos)