2 Proyecto.

51
2.1 Iteración 1. 53
2.1.1 Reunión con el cliente. 53
2.1.2 Planificación y Análisis de riesgos. 55
2.1.3 Análisis. 61
2.1.3.1 Requerimientos. 61
2.1.3.2 Casos de uso. 62
2.1.3.3 Diagramas de secuencia. 67
2.1.3.4 Análisis de Clases. 69
2.1.4 Diseño. 74
2.1.4.1 Desarrollo de casos de uso y diagramas de secuencia. 74
2.1.4.2 Reunión RTF. 103
2.1.4.3 Análisis y Diseño posterior a la Reunión RTF. 103
2.1.5 Implementación. 123
2.1.5.1 Diccionario de Clases. 123
2.1.5.2 Mapeo de clases y tablas. 151
2.1.5.3 Patrones de diseño: 153
2.1.6 Plan de Testeo. 154
2.1.6.1 Testing unitario. 154
2.1.6.2 Testing de integración. 156
2.1.6.3 Diseños de casos de prueba. 157
2.1.7 Diagrama de Gantt real de la Iteración 1. 183
2.1.8 Conclusión de la Iteración 1. 184
2.2 Iteración 2. 189
2.2.1 Reunión con el cliente. 189
2.2.2 Planificación y Análisis de riesgos. 190
2.2.3 Análisis. 196
2.2.3.1 Requerimientos. 196
2.2.3.2 Casos de uso. 197
2.2.3.3 Análisis de Clases. 201
2.2.4 Diseño. 203
2.2.4.1 Desarrollo de casos de uso y diagramas de secuencia. 203
2.2.4.2 Reunión RTF. 230
2.2.5 Implementación de iteración 2. 231
2.2.5.1 Diccionario de Clases. 231
2.2.5.2 Mapeo de clases y tablas. 241
2.2.5.3 Patrones de diseño: 243
2.2.6 Plan de Testeo. 244
2.2.6.1 Testing unitario. 244
2.2.6.2 Testing de integración. 246
2.2.6.3 Diseños de casos de prueba. 247
2.2.7 Diagrama de Gantt real de la iteración 2. 265
2.2.8 Conclusión de la Iteración 2. 266
3 Manual de Usuario. 270
4 Deployment 285
5 Política de Seguridad y Respaldos. 296
6 Plan de Contingencia. 297
7 Grado de Satisfacción del Cliente. 298
8 Conclusión Final 299
9 Glosario. 303
10 Bibliografía. 305
CTA DE RELEVAMIENTO 2. 308
2.0 Proyecto

2.1 Iteración 1
2.1.1 Reunión con el cliente

Durante el proceso de desarrollo del Anteproyecto se adquirieron los requerimientos principales del
cliente, teniéndolos en cuenta se pudo plantear dos iteraciones en donde estos serían divididos para
llevarlos a cabo en fases separadas.
Ya dentro de la primera iteración, se realizó una reunión con el cliente donde fue informado de los
requerimientos que serían contemplados en la misma y se profundizó en ellos, obteniendo en detalle
todo lo necesario para continuar con el proceso de desarrollo.

Funcionalidades:

Registro de clientes: el registro de clientes es una parte esencial para el uso del sistema, ya que ellos
componen el núcleo sobre el que funcionará el mismo. De ellos se necesitará registrar los datos
necesarios para poder identificarlos fácilmente.

Registro de habitaciones: el registro de las habitaciones es otro de los puntos importantes a ser tenidos
en cuenta, ya que servirá para llevar la información de las mismas para después contar con la posibilidad
de poder asignarla a un cliente.

Registro de estadías: este punto comprende la actividad primordial del hotel, ya que es el servicio
principal que ofrece. Luego de seleccionar un cliente y una habitación, será posible asignar la estadía
correspondiente.

Gestión de tarifas: Es necesario llevar un registro modificable de las tarifas que serán manejadas por el
hotel, ya que al momento de realizar el check-out de la habitación se podrán generar los cálculos en
base a esta y asi tener un precio exacto de lo que se le cobrará al cliente.

Listados de habitaciones disponibles, reservadas y ocupadas: para saber qué habitaciones el hotel
debería poder ofrecer, es necesario generar listados de las mismas, que se actualicen cada vez que
existe un cambio en el estado de las habitaciones.
Calcular gastos de productos consumidos durante la estadía del cliente: Además de tener la tarifa fija que
se cobra en base a los días que el cliente se hospeda en el hotel, también puede tener otros gastos, por
ejemplo por consumir productos como bebidas o golosinas que suelen haber en las habitaciones, o uso
de la lavandería.

Calcular el monto a cobrar en el momento del check out: contando ya con los datos de la estadía y de los
productos consumidos por el cliente, es posible generar una precio exacto de los gastos que el huésped
realizó teniendo en cuenta los días que estuvo en el hotel, los productos consumidos, el tipo de
habitación y la cantidad de personas que estuvieron alojadas.

2.2.3 Análisis
2.2.3.1 Requerimientos

Una vez comenzada esta iteración y como ya fue mencionado anteriormente, se realizó una nueva
reunión con el cliente donde se pudieron profundizar las necesidades correspondientes a esta etapa. De
esta manera el trabajo será realizado de forma óptima, también reduciendo el riesgo de insatisfacción del
cliente. Es por esto que durante el transcurso del proyecto y en cada etapa, los requerimientos globales
planteados se afinarán para asegurase del buen curso del mismo; siempre respetando el modelo
prototipo que fue seleccionado por el equipo de desarrollo, presentando en cada entrevista la versión
prototipo más actualizada. Si bien ésta es la primera etapa del proyecto; es justo mencionar que en el
futuro, en cada nueva etapa, se deberán rever los requerimientos ya implementados para poder adecuar
los mismos a la nueva iteración, cuando corresponda. Un hecho resaltable, es que los requerimientos
que componen esta primera iteración, han sido seleccionados basándose netamente en sus
características, permitiendo la entrega de prototipos funcionales a medida que sea concretada cada
iteración; en el caso específico de ésta iteración, se basó en la prioridad de migrar cuanto antes los datos
de los clientes del hotel a la base de datos, ya que es una tarea que requiere mucho tiempo y también
brindar la posibilidad de realizar las tareas básicas del hotel: check in, check out e implementar las
reservas. Esta decisión si bien fue tomada por los miembros del equipo, fue planteada al cliente y se
obtuvo su aprobación que fue tomada como punto de partida para el comienzo del proyecto. Los
restantes requerimientos son dejados para futuras iteraciones y se deja abierta la posibilidad del
surgimiento de nuevas necesidades como se planteó anteriormente.

Nota: Será responsabilidad del equipo de desarrollo, realizar un análisis de los requerimientos de mayor
complejidad para cada iteración, ya que el equipo reconoce que estos implicarán un mayor esfuerzo y
desglose. Esto no implica de ninguna manera que los requerimientos seleccionados para cada iteración
no se realicen como se plantearon en las reuniones con el cliente.

Requerimientos a implementar en la iteración 1:

 ● El sistema debe ser capaz de buscar las habitaciones disponibles y mostrarlas en pantalla
● Debe almacenar, modificar y eliminar (logico) datos básicos de los clientes (nombre, dirección,
ci, etc).
● El software debe almacenar qué habitaciones están fuera de servicio, cuales están sucias y
cuales están limpias.
● El sistema debe generar los costos de la estadía dependiendo de la duración de ésta, la
cantidad de personas y el tipo de habitación.
● El sistema debe permitir al usuario alterar el estado de las habitaciones dependiendo a como se
encuentren actualmente, ya sea libre, ocupada, reservada o mantenimiento.
● El software permitirá agregar, modificar y eliminar habitaciones y agregar o quitar las
comodidades que estas ofrecen.
● El sistema debe permitir al usuario gestionar las tarifas de las habitaciones.
● El sistema debe mantener un registro de estadías.
● El sistema debe ser capaz de emitir notificaciones de aviso al usuario si: se vence una reserva
o una estadía.

2.2.3.2 Casos de uso

En el marco del desarrollo orientado a objetos, es necesario identificar las clases cuyos objetos serán
necesarios para realizar un caso de uso y detallar su comportamiento mediante la interacción de estos
objetos (diagramas de interacción).

Esta tarea será llevada a cabo para cada caso de uso que exista en el desarrollo definido, en base a los
requerimientos.

Cabe destacar que estas actividades no serán realizadas de manera secuencial, sino en paralelo,
retroalimentándose continuamente entre ellas y con las ya realizadas anteriormente.

Diagrama de casos de uso general para esta iteración basado en los requerimientos a implementar.
 Identificación Descripción

CUG-01 Gestionar Cilente

CUG-02 Gestionar Habitación

CUG-03 Gestionar Tarifas

CUG-04 Gestionar Comodidades

CUG-05 Gestionar Estadías

CUG-06 Gestionar Reservas

CUG-01 Gestionar paciente: Permitiría al usuario ingresar, modificar, dar de baja y restaurar clientes
dados de baja en el sistema. Realizar búsquedas y listados de Clientes.
CUG-02 Gestionar Habitación: Permitiría al usuario ingresar y modificar habitaciones, realizar
búsquedas y listados de Habitaciones.
CUG-03 Gestionar Tarifas: Permitiría al usuario poder ingresar o modificar las tarifas que se le asignan
a los distintos tipos de habitaciones.
CUG-04 Gestionar Comodidades: Permitiría al usuario ingresar una información más detallada de las
comodidades de cada habitación.
CUG-05 Gestionar Estadías: Permitiría al usuario ingresar, modificar y cancelar las estadías de los
clientes.
CUG-06 Gestionar Reservas: Permitiría al usuario ingresar las posibles estadías de los clientes,
permitiendo saber qué habitaciones podrían estar ocupadas una fecha determinada.
Identificación de Clases Asociadas a un Caso de Uso

En este punto se identifican los objetos necesarios para el desarrollo de un caso de uso, basándose en
las especificaciones del mismo, y estudiándolos, se puede extraer una lista de objetos candidatos a ser
clases.
En principio puede ocurrir que no se tenga a disposición la información necesaria para identificar todos
estos objetos, por lo que se obtendrá inicialmente una aproximación que se afinará durante esta
actividad y también en el diseño.
Se debe tener en cuenta además, que algunos objetos representan mejor la información del sistema si
se los identifica como atributos en lugar de clases. Para poder realizar esta diferenciación se estudia el
comportamiento de los mismos en el diagrama de interacción y además se toman en cuenta una serie de
reglas como el suprimir palabras con significado vago o sinónimos.
Una vez que se obtienen cada una de las clases, se incorporan al modelo de clases de la actividad
“Diseño”, donde se definen sus atributos, responsabilidades y relaciones.
Los tipos de clases que se identifican en esta tarea podrán tratarse de entidades, interfaces de usuario y
control.
Las clases “entidad” representan la información manipulada en el caso de uso. En el caso de las
interfaces se utilizan para describir la interacción del sistema con los actores; éstas suelen representar
abstracciones de ventanas, interfaces de comunicación, formularios, etc.
Por otro lado, las entidades de control se encargan de la coordinación, secuencia de transacciones y
control de los objetos relacionados con un caso de uso.
Especificación de casos de uso generales.
Identificación Descripción Caso de uso general asociado

CU-01 Agregar Cliente CUG-01

CU-02 Modificar datos de un Cliente CUG-01

CU-03 Dar de baja un Cliente CUG-01

CU-04 Restaurar Cliente CUG-01

CU-05 Búsqueda de Cliente CUG-01

CU-06 Nueva Habitación CUG-02

CU-07 Modificar Habitación CUG-02

CU-08 Agregar Tarifa CUG-03

CU-09 Modificar Tarifa CUG-03

CU-10 Crear Comodidad CUG-04

CU-11 Agregar comodidad a habitación CUG-04

CU-12 Eliminar comodidad CUG-04

CU-13 Check In (agregar estadía) CUG-05

CU-14 Modificar Estadía CUG-05

CU-15 Check Out (eliminar estadía) CUG-05

CU-16 Generar costos de estadía CUG-05

CU-17 Agregar Reserva CUG-06

CU-18 Transformar Reserva en estadía CUG-06

CU-19 Cancelar reserva CUG-06

CU-20 Buscar Habitciones CUG-02

ocupadas/libres/reservadas

CU-21 Buscar Estadía CUG-05

Agregar Cliente: Permite al usuario agregar los datos de los clientes.

Modificar datos de un Cliente: Permite al usuario poder actualizar los datos de los clientes.

Dar de baja un Cliente: Permite al usuario dar de baja lógica a un cliente.

Restaurar Cliente: Permite al usuario recuperar a un cliente dado de baja.

Búsqueda de Cliente: Permite al usuario buscar clientes rápidamente.

Nueva Habitación: En el caso de que el hotel quiera expandirse, el usuario será capaz de agregar una
nueva habitación.

Modificar Habitación: En el caso de que el hotel modifique una habitación, el usuario será capaz de
agregar las modificaciones que se hagan.

Agregar Tarifa: Permite al usuario agregar las tarifas para cada tipo de habitación.

Modificar Tarifa: Permite al usuario modificar las tarifas existentes.

Crear Comodidad: Permite al usuario crear comodidades.

Agregar comodidad a habitación: Permite al usuario agregar las comodidades a las habitaciones.

Eliminar comodidad: Elimina las comodidades existentes.

Check In (agregar estadía): Permite al usuario, en base a un cliente, una habitación y una fecha, crear
una estadía.

Modificar Estadía: Permite al usuario modificar algunos datos de la estadía.

Check Out (eliminar estadía): Permite al usuario eliminar las estadías luego de que concluyan.

Generar costos de estadía: Permite al usuario, generar un monto exacto en base a los datos de las
estadías.

Agregar Reserva: Permite al usuario crear reservas, para luego convertirlas en estadías.

Transformar Reserva en estadía: Permite al usuario que cuando sea la fecha de la reserva, poder
transformarla en una estadía.

Cancelar reserva: Permite al usuario cancelar las reservas en caso de que el cliente no pueda asistir en
la fecha de esta o en caso de que la reserva haya vencido.

Buscar Habitaciones ocupadas/libres/reservadas: Permite al usuario buscar con filtros los estados de
las habitaciones para saber si estas están disponibles o no.

Buscar estadía: Permite al usuario buscar una estadía determinada entre las existentes para
posteriormente modificarla o eliminarla.

2.2.3.3 Diagramas de secuencia.

En esta tarea se estudia y describe la cooperación entre los objetos utilizados para la realización de los
casos de uso detallados en el punto anterior.
Dicha cooperación se representa a través de diagramas de interacción, que se componen por instancias
de los actores involucrados, objetos y la secuencia de mensajes que intercambian entre ellos. Es
recomendable establecer criterios que determinen qué tipo de objetos y mensajes incluirán estos
diagramas, objetos y llamadas a bases de datos, objetos de interfaz de usuario, de control, etc.
Los mencionados diagramas podrán ser tanto de secuencia como de colaboración (en caso de que
corresponda), y su uso dependerá de si se centra en la secuencia cronológica o en cómo se realiza la
comunicación entre los objetos.
En los casos en donde se especifique más de un escenario posible para un caso de uso, podría
manejarse la posibilidad de representar cada uno de ellos en un diagrama de interacción; siendo también
recomendable en el caso anterior, completar algunos de los diagramas con una descripción textual.
Los diagramas de secuencia se generalizan por tipo. Esto quiere decir que no se hace un diagrama
particular para cada caso, sino que se realiza uno por cada categoría:
● Crear elemento.
● Modificar elemento.
● Eliminar elemento.
● Buscar Elemento.
● Listar Elementos.
Diagramas de secuencia generalizados

Para la realización de los siguientes diagramas se tuvo en cuenta algunos casos de uso previamente
planteados.
Diagrama de secuencia: Crear elemento.
Modificar elemento

Eliminar elemento
Buscar elemento

Listar elemento
Análisis de Clases

Basándose en las clases identificadas en el análisis de casos de uso, se elaborará un modelo de clases.
A medida que se avance en el análisis, el modelo se irá completando con las clases que aparezcan,
tanto para estudiar los casos de uso y diagramas de secuencia, como también la interface de usuario
necesaria para el sistema.
Esta tarea tendrá como objetivo el detallar cada una de las clases surgidas, identificando las
responsabilidades asociadas a las mismas, sus atributos y las relaciones existentes entre ellas.

El proceso de análisis cuenta con los siguientes pasos:

Paso Descripción

Nombre de Se identifican las clases participantes y se define un nombre que identifica a cada
Clase una.

Atributos Se identifican los atributos que componen a cada clase en particular. No se

lógicos presentan aquellos atributos que serán necesarios para implementar una
 asociación.

Asociaciones Se identifican las asociaciones estáticas, es decir, aquellas que representan

estáticas de composición.
instancias

Herencia Se identifica la posibilidad de herencia entre clases basándose en su nivel de

cohesión en cuanto al negocio y a los atributos de las clases identificadas.

Asociaciones Se identifican asociaciones de objetos basadas en cómo estos se relacionan y

dinámicas de actúan para llevar a cabo responsabilidades.
instancias

Métodos Se identifican las operaciones de los objetos.

Este proceso se somete a un refinamiento iterativo hasta alcanzar un cierto nivel de conformidad. En los
siguientes apartados se presenta el producto final obtenido de dicho refinamiento.

Identificación Actividad en UML

Responsabilidades y Atributos Nombre de Clase, atributos lógicos,

operaciones

Asociaciones y Agregaciones Asociaciones estáticas de instancia,

asociaciones dinámicas de instancia.

Generalización Herencia

Responsabilidades y Atributos
En este punto se identifican las responsabilidades y atributos principales de una clase.

Responsabilidades: Definen la funcionalidad de una clase, y se basan en el estudio de los papeles

desempeñados por sus objetos en los distintos casos de uso. Partiendo de estas responsabilidades es
posible comenzar a detectar las operaciones que pertenecerán a esa clase en particular.
Estas operaciones deberán ser relevantes, simples y además participar en la descripción de la
responsabilidad.

Atributos: Se encargan de especificar las propiedades que tiene una clase, y son identificados por estar
implicados en sus responsabilidades. Estos atributos deberían ser conceptuales y conocidos por el
dominio.

Basándose en lo explicado anteriormente, se realiza una especificación para cada clase. Ésta debe
incluir la lista de sus operaciones y las clases que colaboran para cubrir estas operaciones. Además
debe contar con una especificación de las responsabilidades, los atributos y las operaciones que
componen esa clase.
En el caso de las clases, las que su comportamiento dependerá del estado en que se encuentren, se
puede realizar también un diagrama de transición de estados.
Diagrama conceptual para la Iteración 1
Para obtener este diagrama se ha basado en los casos de uso realizados en la etapa de análisis y en
sus respectivos diagramas de secuencia.
De los casos de uso se obtuvo una aproximación a las interfaces de usuario, y en base a los diagramas
de secuencia, se ha podido identificar algunas de las clases de dominio que se representan en la figura
anterior.
De esta manera el equipo de desarrollo logró entender el funcionamiento de la operativa de trabajo, en la
presente iteración.
Una vez analizado el problema en profundidad, se optó por modificar el diagrama conceptual inicial
planteado en el anteproyecto, agregando varias clases a dicha solución inicial para de esa manera
modelar de forma más consistente el problema.

Clases:

NOMBRE DE ENTIDAD POSIBLES ATRIBUTOS O CANDIDATOS

Cliente ci, nombre, apellido, ciudad, pais, telefono, email.

eliminado.

Comodidad nrohabitacion, comodidad.

Estadía nrohabitacion, ocupante, fechaentrada,

fechasalida, idestadia, cantper, tipohab,
preciohab, nombre.

Factura nrohabitacion, cicliente, preciohab, preciototal,

idestadia.

Habitación nrohabitacion, nombrehabitacion, estado,

tipoestado, tipohabitacion.

Reserva documento, nrohab, fechaent, fechasal, cantper

Tarifa tipohabitacion, precio

Las entidades previamente descriptas, son un punto de partida inicial por lo que en el correr de la
iteración I podrían variar, o quizás se agreguen otras.

Cliente: este objeto contiene todos los atributos con información del cliente tales como nombre, ci (que
no necesariamente es un documento nacional, ya que el hotel cuenta con clientes del exterior o tambien
puede ser el rut de una empresa) y de contacto con éste, como por ejemplo teléfono o email.
Comodidad: en este objeto, se encuentran los atributos necesarios para hacer referencia a las
comodidades que ofrecen las distintas habitaciones.
Estadía: este objeto contiene los datos necesarios para llevar el mejor control posible de las estadías,
conociendo en qué habitación (nrohabitacion) se encuentra el cliente (ocupante), la cantidad de personas
que se alojarán en éstas (cantper) y la fechas en las que el cliente estará alojado (fechaentrada)
(fechasalida), entre otros datos
Factura: en este objeto contiene la información con la cual se podrá llevar una contabilidad de las
ganancias teniendo en cuenta las estadías y los consumos para cada una de ellas. Si en una iteración
futura el cliente decide imprimir una factura se podrá acceder a la información de este objeto para ello.
Habitacion: este objeto contiene los atributos con la información de las habitaciónes como
nrohabitacion, o el estado en el que se encuentran (estado) para saber si una habitación determinada
está disponible o no.
Reserva: en este objeto se encuentran los datos necesarios para que se pueda crear una reserva como
el documento del ocupante, la habitación en la que se va a hospedar, las fechas en las que planea
alojarse y la cantidad de personas, para luego usar esos datos para transformar la reserva en una
estadía.
Tarifa: en este objeto, se encuentra la información del precio de las habitaciones teniendo en cuenta el
tipo de habitación que sea.
 Diseño

Desarrollo de casos de uso y diagramas de secuencia

En la siguiente tabla se muestran los casos de uso a desarrollar, y a continuación el correspondiente

desarrollo de cada uno y formulario del sistema asociado.

Identificación Descripción

CU-01 Agregar Cliente

CU-02 Modificar datos de un Cliente

CU-03 Dar de baja un Cliente

CU-04 Restaurar Cliente

CU-05 Búsqueda de Cliente

CU-06 Nueva Habitación

CU-07 Modificar Habitación

CU-08 Agregar Tarifa

CU-09 Modificar Tarifa

CU-10 Crear Comodidad

CU-11 Agregar comodidad a habitación

CU-12 Eliminar comodidad

CU-13 Check In (agregar estadía)

CU-14 Modificar Estadía

CU-15 Check Out (eliminar estadía)

CU-16 Generar costos de estadía

CU-17 Agregar Reserva

CU-18 Transformar Reserva en estadía

CU-19 Cancelar reserva

CU-20 Buscar Habitciones ocupadas/libres/reservadas

CU-21 Buscar Estadía

CU-22 Finalizar Estadía

Casos de uso: Gestión de clientes (CUG-01).

CU-01: Nuevo cliente.

CU-02: Modificar datos de un cliente.

CU-03: Dar de baja un cliente.

CU-04: Restaurar cliente.

Formulario del sistema asociado a los casos de uso: “Gestión de Clientes”