Proyecto #2 - GymTEC

Instituto Tecnológico de Costa Rica

Área Académica Ingeniería en Computadores
Bases de Datos (CE3101)
I Semestre 2023
Valor 20%

Objetivo general
➔ Desarrollar una aplicación que permita manejar la descripción del caso expuesto.

Objetivos específicos
➔ Aplicar los conceptos del modelo conceptual y relacional.
➔ Crear una Base de Datos relacional en Microsoft SQL Server para que permita el almacenamiento de
los datos.
➔ Crear un servicio API para que centralice la funcionalidad.
➔ Crear una aplicación móvil utilizando SQL Lite como Base de datos empotrada.
➔ Crear una página Web para que exponga la funcionalidad al usuario.
➔ Usar herramientas como Angular, Bootstrap, HTML5, CSS, Entity Framework, y Reporting Services,
Cristal Reports o similar para reportes.
➔ Crear un documento de instalación que permita el despliegue correcto de la aplicación en la nube.
➔ Evaluar de forma objetiva, válida y precisa la solución planteada al problema complejo de
ingeniería.
➔ Colaborar de forma activa en el equipo de trabajo para la realización del proyecto.

Descripción del problema

La cadena de Gimnasios del Tec ha decidido expandirse fuera de los campus académicos, por lo que ha
decidido implementar un sistema para su administración.
Los Gimnasios ya cuentan con 3 sucursales en los principales campus donde inicialmente se instalará el
sistema. Los principales servicios que proveen los gimnasios son: Uso de todo las maquinas del gimnasio,
clases grupales, clases personalizadas con un entrenador certificado, Spa’s y venta de artículos deportivos
de consumo como proteínas, creatinas, energéticos, etc así como productos de uso deportivo como pesas,
ligas, mancuernas, pads etc.

Se ha determinado que son requeridas las siguientes vistas:

• Vista Administrador: Es la vista que usaran los administradores del sistema para aspectos de
configuración de los gimnasios y los servicios brindados en cada gimnasio.
• Vista Cliente: esta es la plataforma que permitirá a los clientes darse de alta, buscar servicios e
inscribirse en los servicios si así lo desea.
Requerimientos del Software
Vista Administrador.
◆ Log In: Se debe contar con un log in unificado que permita autenticarse e identificar que rol
tiene la persona que se está logueando (instructor, dependiente de Tienda, Spa).
◆ Gestión de sucursales: Permite al administrador gestionar toda la información de las
sucursales: nombre, dirección (Provincia, Cantón, Distrito), fecha de apertura, horario de
atención, empleado administrador, capacidad máxima y números de teléfono.
● Activación de Spa: Por default todas las sucursales tienen un Spa sin embargo este
no se encuentra activo.
● Activación de Tienda: Por default todas las sucursales tienen una tienda de
conveniencia sin embargo esta no se encuentra activa.
◆ Gestión de tratamientos de Spa: permite al administrador gestionar los tratamientos que
brindan los spas, de los tratamientos se conoce solo el nombre y un identificador único. Los
servicios que se ofrecen por default son: Masaje relajante, masaje descarga muscular,
sauna, baños a vapor, estos tratamientos no se pueden modificar (Debe implementarse por
medio de un Trigger).
Si un tratamiento está asociado a un Spa no se podrá eliminar.
◆ Gestión de puestos: Permite al administrador gestionar todo lo relacionado con los puestos
necesarios para que el Gimnasio pueda operar de ellos se conoce un identificador único y
una descripción única. Los puestos por default que tiene el gimnasio son: Administrador,
Instructor, Dependiente Spa, Dependiente tienda.
◆ Gestión de tipos de planilla: Desde acá se pueden gestionar todos los tipos de planilla, de
las que se conoce una descripción, un identificador. Las planillas que se conocen son Pago
mensual, pago por horas y pago por clase.
◆ Gestión de empleados: Esta funcionalidad permite al administrador gestionar todo lo
necesario para los empleados. De ellos se conoce número de cedula, nombre completo,
dirección (Provincia, Cantón, Distrito), puesto que desempeña, sucursal en la que trabaja (si
ha sido asignado a un gimnasio), tipo de planilla, salario, correo electrónico y password
(encriptado usando MD5).
◆ Gestión de Servicios: desde acá se le permitirá al administrador agregar los servicios que
provee el gimnasio. Se conoce un identificador único y una descripción. Los servicios
básicos que se ofrecen son: Indoor Cycling, Pilates, Yoga, Zumba y Natación.
◆ Gestión de Tipos Equipo: En esta sección se le permite al administrador gestionar los tipos
de equipo que posee el gimnasio. De ellas se conoce: Identificador único y descripción del
tipo. Los Tipos de equipo básico son: Cintas de correr, bicicletas estacionarias,
multigimnasios, remos, pesas.
◆ Gestión de inventario: Esta sección permite al administrador gestionar todo el inventario de
máquinas que posee el gimnasio, de cada una de las máquinas se conoce, el tipo de equipo,
marca, número de serie, costo sucursal donde se encuentra si ya ha sido asignado a un
gimnasio, de lo contrario será vacío.
◆ Gestión de productos: Esta opción permite al administrador gestionar todos los productos
que son vendidos en las tiendas de conveniencia del gimnasio. De los productos se conoce
un nombre, código de barras, descripción y un costo.
 ◆ Configuración de gimnasio. Este es un dashboard de configuración permite al
administrador configurar el gimnasio.
● Asociación de tratamientos al Spa del gimnasio: Permite al administrador asociar
los tratamientos a un Spa en específico. Debe dar visibilidad de los servicios ya
asociados y los no asociados.
● Asociación de productos a la tienda del gimnasio: Permite al administrador asociar
los productos que se ofrecerán en la tienda del gimnasio. Debe dar visibilidad de los
productos ya asociados y los no asociados.
● Asociación de inventario: esta funcionalidad debe permitir asignar los equipos a un
gimnasio. Debe dar visibilidad de los productos ya asociados al gimnasio y los no
asociados a ningún otro gimnasio.
● Crear clases: En esta sección el administrador creará las clases (Indoor Cycling,
Pilates, Yoga, Zumba y Natación) que se impartirán en las semanas siguientes. Por
cada clase se sabe el tipo, el instructor, si es grupal o individual, capacidad, fecha,
hora de inicio y hora de finalización.
◆ Generación de planilla: Esta funcionalidad es prioritaria, permitirá al administrador saber el
pago que debe realizar a todos los empleados del gimnasio debe estar agrupado por
sucursal, posteriormente debe mostrar el número de cedula, nombre completo del empleado,
número de clases impartidas/horas laboradas (según corresponda) y monto a pagar.
● ¿Como se calcular el pago de los tipos de planilla?
● Mensuales: En este caso solo se deberá consultar el monto indicado en el salario
del empleado.
● Pago por horas: En este caso debe realizarse el cálculo de las horas laboradas
por el empleado y multiplicarse por el monto indicado en el salario del empleado.
● Pago por clase: En este caso debe realizarse el cálculo de las clases impartidas
por el empleado y multiplicarse por el monto indicado en el salario del empleado.
◆ Copiar calendario de actividades: Dado que el proceso de crear actividades es un poco
tedioso y por lo general el calendario de actividades no cambia mucho, esta funcionalidad
permite copiar las actividades de una semana en especifico a una semana en el futuro.
◆ Copiar Gimnasio: esta funcionalidad realizará la copia de un gimnasio existente en uno
nuevo, copiaría tratamientos del Spa, los productos de la tienda, las clases que se imparten
sin asignar el instructor.

Vista Cliente.
◆ Registro: Esta vista permitirá a los clientes darse de alta. El cliente debe registrar su número
de cédula, nombre y apellidos, edad, fecha de nacimiento, peso, IMC, dirección, correo
electrónico y password (encriptado usando MD5).

◆ Log In: Se debe contar con una cuenta que permita la autenticación del usuario. Una vez
logueado se mostrará las actividades próximas a realizar por el usuario.
◆ Búsqueda y registro en una clase:
● Búsqueda: El cliente podrá buscar clases por: sucursal tipo de clase (Indoor Cycling,
Pilates, Yoga, Zumba, Natación), periodo de inicio de búsqueda y periodo de
 finalización de búsqueda. El sistema deberá mostrar todas las clases que cumplen
con los criterios de búsqueda y debe mostrar cuando se realizará la clase, fecha de
inicio, fecha de finalización, instructor, cupos disponibles. En todas aquellas clases
donde hay cupo se habilitará la opción de registrarse.
● Registro en una clase: Una vez seleccionada la clase en la que se desea participar
se procede a registrar en la misma.

Aplicación móvil.
La aplicación móvil debe poder utilizarse sin conexión, por tanto, se debe manejar un base de datos
local en SQL Lite, que se sincronizará con la base de datos principal. Para el proceso de
sincronización es indispensable conexión con la base de datos principal. Toda la demás
funcionalidad se puede realizar sin conexión y en cuanto se reestablece la conexión se sincronizan
los datos.
La funcionalidad que debe desarrollarse en la App móvil es la misma expuesta en la vista cliente.

El término gestionar corresponde a las opciones de insertar, editar, eliminar y consultar.

Requerimientos no funcionales del sistema
➔ El Sistema debe ser una aplicación web (utilizando Angular, Bootstrap, HTML5, CSS) y debe ser
desplegada localmente en el IIS.
➔ La App Móvil debe ser desarrollada utilizando SQL Lite como base de datos.
➔ La Base de Datos debe estar en SQL Server.
➔ No se permite el uso de Procedimientos Almacenados, Vistas o Triggers. Los scripts de Base de
Datos deben implementarse en la capa de datos (una librería en proyecto de C#).
➔ La capa de servicios (API/WebServices/Microservicios) debe estar desarrollada en C# y debe ser
desplegada localmente en el IIS.
➔ El equipo de trabajo debe seleccionar a uno de sus miembros como único punto de contacto. Todas
las comunicaciones y solicitudes deben ser a través de dicho punto de contacto.

Entregables
➔ Manual de Usuario.
➔ Documento de evidencia de la solución elaborada y planificación del trabajo.
➔ Se deberá documentar el código fuente.
➔ Evidencia de uso de un manejador de código (se recomienda Gitgub).
➔ Documento de instalación.
➔ Plan de Proyecto.
➔ Script de Base de Datos.
➔ Script de populación de Base de Datos.
➔ Aplicación WEB.
➔ Web APIs.
➔ Minutas.

NOTA: Cada documento solicitado debe tener la estructura de un documento técnico (portada, índice de
contenidos, introducción, entre otros).
Documentación evidencia de solución elaborada y planificación del trabajo
➔ Se deberá entregar un documento que contenga:
◆ Modelo conceptual utilizando la notación de Chen.
◆ Modelo relacional.
◆ Descripción de las estructuras de datos desarrolladas (Tablas).
◆ Descripción detallada de la arquitectura desarrollada.
◆ Problemas conocidos: En esta sección se detalla cualquier problema que no se ha podido
solucionar en el trabajo.
◆ Problemas encontrados: descripción detallada, intentos de solución sin éxito, soluciones
encontradas con su descripción detallada, recomendaciones, conclusiones y bibliografía
consultada para este problema específico.
➔ Conclusiones del proyecto.
➔ Recomendaciones del proyecto.
➔ Bibliografía consultada en todo el proyecto.

Aspectos operativos y evaluación:

1. Fecha de entrega: Se establece el siguiente plan de entregas parciales:
a. Plan de Trabajo: 15/Abril/2023
b. Resumen Ejecutivo Avance 1: 22/Abril/2023
c. Resumen Ejecutivo Avance 2: 29/Abril/2023
d. Funcionalidad completa: 6/Mayo/2023
2. El proyecto tiene un valor de 20% de la nota del curso.
3. El trabajo es en grupos de 5 personas.
4. La implementación tendrá un valor de un 70% de la nota final, debe estar funcional. La defensa vale
un 10% y la documentación externa un 20%.
5. Cumplir con los requerimientos especificados en la documentación no significa que se tienen todos
los puntos, se evaluará que la documentación sea coherente, acorde al tamaño del proyecto y el
trabajo realizado, no escatimen en documentación.
6. Cada grupo recibirá una nota en cada uno de los siguientes apartados Código, Defensa y
Documentación.
7. El profesor no sólo evaluará la funcionalidad del proyecto, esto quiere decir que aunque el proyecto
este 100% funcional esto no implica una nota de un 100, ya que se evaluarán aspectos de calidad de
código, aplicación del paradigma OOP, uso de herramientas solicitadas, calidad de documentación
interna y externa, trabajo en equipo.
8. No se revisarán funcionalidades parciales, ni funcionalidades no integradas.
9. Es responsabilidad de cada miembro del grupo conocer su código, el profesor puede preguntar a
cualquier miembro del grupo que le explique alguna funcionalidad/porción de código.
10. Las citas de revisión oficiales serán determinadas por el profesor durante las lecciones o mediante
algún medio electrónico.
11. Aún cuando el código y la documentación tienen sus notas por separado, se aplican las siguientes
restricciones:
a. Si no se entrega documentación, automáticamente se obtiene una nota de cero en el
proyecto.
 b. Si no se utiliza un manejador de código se obtiene una nota de cero en el proyecto.
c. Si el código y la documentación no se entregan en la fecha indicada se obtiene una nota de
cero en el proyecto.
d. Si el código no compila se obtendrá una nota de cero en el proyecto, por lo cual se
recomienda realizar la defensa con un código funcional.
e. Si el grupo no cuenta con los equipos necesarios para realizar la revisión y no avisó al
profesor de esta situación obtendrá una nota de cero en el proyecto.
f. El código debe ser desarrollado en C#, en caso contrario se obtendrá una nota de cero en el
proyecto.
g. Si el grupo no se presenta a la revisión/defensa se obtiene nota de cero en el proyecto. Si
un estudiante no se presenta a la defensa y no cuenta con una justificación válida se le
asignará al estudiante una nota de cero en el proyecto.
12. Cada grupo tendrá como máximo 50 minutos para exponer su trabajo al profesor y realizar la defensa
de éste, es responsabilidad de los estudiantes mostrar todo el trabajo realizado, por lo cual se
recomienda tener todo listo antes de ingresar a la defensa y el profesor dispondrá de 10 minutos
para dar la retroalimentación y la nota del proyecto.
13. Cada excepción o error que salga durante la ejecución del proyecto y que se considere debió haber
sido contemplada durante el desarrollo del proyecto, se castigará con 2 puntos de la nota final del
proyecto.
14. Cada grupo es responsable de llevar los equipos requeridos para la revisión.
15. Durante la revisión únicamente podrán participar los miembros del grupo, asistentes, otros
profesores y el coordinador del área.
16. Las revisiones se realizan con los estudiantes matriculados en el curso, cualquier persona fuera de
estos y los mencionados en el punto 15, no pueden participar en la revisión.
Referencias

AngularJS (2018-10-04). Recuperado de: https://angularjs.io

Bootstrap Themes & Templates (2018-10-04). Recuperado de: https://wrapbootstrap.com/

How to Write Doc Comments for the Javadoc Tool. (2018-10-04). Recuperado de:
http://www.oracle.com/technetwork/articles/java/index-137868.html

C# Coding Conventions (C# Programming Guide). (2018-10-04). Recuperado de:

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-
program/coding-conventions