Aplicacion para La Reserva de Citas Online Centrada en Alberola Torres Jose

Grado en Ingeniería Informática
Trabajo Fin de Grado

Autor:
Jose Alberola Torres
Tutor/es:
David Tomás Diaz
Jose Luis Vicedo González Página | 1
Julio 2022
Página | 2
Agradecimientos
Quería dedicar este pequeño espacio a todas aquellas personas que de alguna manera me
han ayudado a desarrollar este TFG. Gracias a mis tutores David Tomás Diaz y Jose Luis
Vicedo González por marcarme siempre las pautas adecuadas y no dejarme solo en
ningún momento de estos seis meses.
Con este Trabajo de Fin de Grado se acerca el final de mi camino como estudiante del
Grado de Ingeniería Informática, por ello quiero dar las gracias a todos los profesores con
los que me he cruzado, me habéis enseñado todo lo que hoy se, en especial a Domingo
Gallardo López, por compartir su pasión por lo que hace y dejar huella en muchos de
nosotros. Gracias a todo mi grupo de amigos con los que desde el inicio comparto esta
aventura, habéis sido mi mayor apoyo. Para terminar, reconocer a mi familia su confianza
en mí, especialmente a mi madre, la persona que más ha luchado no sólo porque se cumpla
este objetivo sino también por no permitirme otro.
Gracias de corazón a todos.
Página | 3
Página | 4
Índice de contenidos
Agradecimientos _____________________________________________________________ 3
Índice de figuras ______________________________________________________________ 7
1. Introducción y justificación del proyecto _________________________________________ 9
2. Objetivos ________________________________________________________________ 14
2.1. Objetivos principales ____________________________________________________ 14
2.2. Objetivos secundarios ___________________________________________________ 15
3. Metodología ______________________________________________________________ 17
3.1. Planificación __________________________________________________________ 17
3.2. Estudio _______________________________________________________________ 19
3.3. Realidad ______________________________________________________________ 21
4. Análisis de requisitos _______________________________________________________ 25
4.1. Requisitos funcionales___________________________________________________ 26
4.2. Requisitos no funcionales ________________________________________________ 28
4.3. Casos de uso __________________________________________________________ 30
5. Estado de la cuestión _______________________________________________________ 33
5.1. Booksy _______________________________________________________________ 34
5.2. Timp _________________________________________________________________ 35
5.3. Uala _________________________________________________________________ 36
6. Herramientas y tecnologías __________________________________________________ 39
6.1. Backend ______________________________________________________________ 39
6.2. Frontend _____________________________________________________________ 41
6.3. Otras tecnologías_______________________________________________________ 42
6.4. Mockups _____________________________________________________________ 43
7. Arquitectura del sistema ____________________________________________________ 47
7.1. Esquema UML _________________________________________________________ 48
7.2. Funcionamiento del sistema ______________________________________________ 55
7.2.1. Modelo ___________________________________________________________ 56
7.2.2. Vista _____________________________________________________________ 58
7.2.3. Controlador _______________________________________________________ 59
7.3. Funcionalidades del sistema ______________________________________________ 61
8. Conclusiones______________________________________________________________ 70
8.1. Leitmotiv. Ventajas y desventajas __________________________________________ 70
Página | 5
8.2. Próximas versiones _____________________________________________________ 71
8.3. Un paso más allá _______________________________________________________ 72
Referencias _________________________________________________________________ 74
Página | 6
Índice de figuras
Figura 1: Dibujo situación cliente ________________________________________________ 10
Figura 2: Dibujo situación empresa ______________________________________________ 11
Figura 3: Tablero Trello _______________________________________________________ 18
Figura 4: Tarjeta Trello ________________________________________________________ 19
Figura 5: Diagrama de Gantt. Tareas _____________________________________________ 23
Figura 6: Diagrama de Gantt ___________________________________________________ 24
Figura 7: Esquema clasificación de requisitos ______________________________________ 29
Figura 8: Caso de uso proceso de reserva _________________________________________ 31
Figura 9: Caso de uso consulta de estadísticas _____________________________________ 32
Figura 10: Web Booksy ________________________________________________________ 34
Figura 11: Web Timp _________________________________________________________ 35
Figura 12: Web Uala __________________________________________________________ 36
Figura 13: Ranking lenguajes de programación más populares de 2021__________________ 39
Figura 14: Frameworks para backend más populares de 2022 _________________________ 40
Figura 15: Mockup página registro ______________________________________________ 43
Figura 16: Mockup página inicio de sesión ________________________________________ 44
Figura 17: Mockup home clientes _______________________________________________ 44
Figura 18: Mockup estadísticas empresas _________________________________________ 45
Figura 19: Arquitectura del sistema ______________________________________________ 47
Figura 20: Esquema UML fase I _________________________________________________ 49
Figura 21: Esquema UML fase II _________________________________________________ 51
Figura 22: Esquema UML fase III ________________________________________________ 52
Figura 23: Explicación modificación servicio I ______________________________________ 54
Figura 24: Explicación modificación servicio II ______________________________________ 54
Figura 25: Patrón MVC ________________________________________________________ 56
Figura 26: Clase Company.java _________________________________________________ 57
Figura 27: Clase CompanyRepository.java _________________________________________ 57
Figura 28: Método para crear una reserva. Clase AppointmentService.java ______________ 58
Figura 29: Fragmento página detallesEmpresa.html _________________________________ 59
Figura 30: Ejemplo método CompanyController.java ________________________________ 60
Figura 31: Interfaz página servicios de empresa ____________________________________ 61
Figura 32: Panel de control. Indicadores mensuales _________________________________ 62
Figura 33: Panel de control. Pie Charts ___________________________________________ 62
Figura 34: Comparativa clientes por rangos de edad ________________________________ 63
Figura 35: Panel de control. Histórico de reservas __________________________________ 63
Figura 36: Panel de control. Histórico de nuevos clientes _____________________________ 64
Figura 37: Panel de control. Rankings ____________________________________________ 65
Figura 38: Agenda empresa ____________________________________________________ 65
Figura 39: Agenda empresa. Modificación reserva __________________________________ 66
Figura 40: Reserva modificada __________________________________________________ 66
Figura 41: Home clientes ______________________________________________________ 67
Figura 42: Home cliente. Búsqueda ______________________________________________ 67
Figura 43: Detalles empresa ____________________________________________________ 68
Página | 7
Figura 44: Crear review _______________________________________________________ 69
Página | 8
1. Introducción y justificación del proyecto
Voy a hacer una simple pregunta, ¿cuántas veces hemos tenido que hacer una reserva para
acudir a un lugar? Sin tener superpoderes, puedo afirmar que cualquier persona lo ha
hecho al menos una vez en su vida. En mi caso particular se trata de al menos una vez al
mes.
Producto de esta necesidad nace nuestra idea: crear una aplicación web para la reserva de
citas que ofrezca las siguientes características.
Lado del cliente:
• Consultar la agenda de los negocios: los clientes podrán consultar la información

de los negocios y su agenda para ver qué huecos hay disponibles.
• Reservar cita en negocios: sobre la agenda del negocio, se podrá hacer una reserva
en los huecos disponibles introduciendo el servicio que se quiere consumir.
• Historial de reservas: contarán con un listado con todas las reservas que han hecho
a través del sistema.
• Reviews: funcionalidad para dejar una opinión acerca de un negocio.
Lado del negocio:
• Añadir citas de manera manual: en caso de que tenga que añadir él la reserva,
podrá clicar sobre un día de la agenda, introducir el cliente y el servicio.
• Autogestionar la agenda: la agenda se autogestiona para no permitir
solapamientos y mostrar las reservas de los clientes.
• Ofrecer una serie de servicios: se debe establecer qué servicios ofrece el negocio.
Estos servicios serán los que los clientes consuman.
• Obtener estadísticas: apartado para analizar la situación de la empresa. Se verán
los clientes clasificados por tipo, gráficas de ingresos, captación de nuevos
clientes, históricos de reservas…
Página | 9
El lado del negocio será la parte fundamental de este proyecto, especialmente la
manipulación de sus datos, con lo que buscamos aportar ese valor oculto a los
propietarios. Todas estas ideas han sido desarrolladas y se encuentran disponibles en un
repositorio público de GitHub (https://github.com/JoseAlberola/TFG-Voyendo) para su
consulta.
Vivimos en una época en la que todo tiene que suceder ya, y si puede ser, antes incluso.
De hecho, quizá en este periodo de tiempo haya llegado el paquete de Amazon que
compraste ayer como usuario “prime” para que llegue antes. Vivimos acelerados y
estamos inmersos en un proceso de digitalización enorme. Sin embargo, escondidos en
una esquina se encuentran los procesos de reservas.
Ahora que conocemos un poco la idea general, veamos con unos dibujos qué
comportamiento o situación queremos solucionar. Primero nos pondremos en la piel de
un cliente y posteriormente en la de un negocio.
Figura 1: Dibujo situación cliente
En la figura 1 hemos querido reflejar las diferentes fases por las que pasaría un cliente de
una peluquería. En primer lugar, necesita cortarse el pelo. Ante esa situación, decide
navegar en el sistema buscando lo que necesita hasta que un negocio le llama la atención.
En ese momento decide informarse acerca de su trabajo leyendo algunas de las opiniones
Página | 10
de otros clientes y le acaba gustando. Por último, consulta su agenda, ve todos los huecos
disponibles y hace su reserva.
Este sería un flujo totalmente normal para nuestra plataforma, que pretende exactamente
eso, concentrar todos los negocios que necesiten de reserva en un mismo lugar, y, por
ende, a todos los clientes. De esta manera se consiguen ventajas para los clientes, como
es la rapidez y la flexibilidad, y para los negocios la captación de nuevos clientes de
manera indirecta.
Si nos fijamos en la figura 1 vemos una flecha verde con una interrogación. Esto indica
justo lo que acabamos de comentar, ese proceso de captación de nuevos clientes que
buscamos lograr para los negocios. Tras la búsqueda de un servicio que en un determinado
momento me ha hecho falta, he encontrado un negocio que cumple mis expectativas y
puedo repetir.
De la misma manera, veamos el flujo de una empresa reflejado en la figura 2.
Figura 2: Dibujo situación empresa
La situación inicial siempre es la misma, se quiere lograr un objetivo. La figura 2 muestra

cómo el propietario de un negocio está cansado de atender llamadas para hacer reservas
Página | 11
y se ha dado cuenta de que pierde mucho tiempo en ese proceso. Decide buscar una
solución y se encuentra con nuestra plataforma, se registra y ve todas las ventajas
disponibles. Entre esos beneficios se encuentra la gestión automática de la agenda; ahora
sólo se encargará de hacer su trabajo. Y lo más importante, cuenta con una sección de
estadísticas avanzadas acerca de su negocio para tener un mayor control y estudiar formas
de mejorar.
La idea de desarrollar una aplicación que resolviera esta problemática ronda por mi
cabeza desde hace aproximadamente un año o dos. En numerosas ocasiones he
preguntado en mi peluquería de confianza si estarían dispuestos a migrar su antigua libreta
a un sistema que les gestionara todo. Su respuesta siempre ha sido positiva. De hecho,
empecé este proyecto el verano pasado, pero lo abandoné antes de obtener ningún
resultado.
Desde entonces, he vivido muchas situaciones que me recordaban el proyecto que tenía
estancado. Hasta ahora, ya que la aplicación web de Voyendo es una realidad.
De nuevo, mi peluquero es ejemplo de estas situaciones. Hace muchos años que acudo a
la misma peluquería. Al principio se usaba el teléfono móvil. Cristian, mi peluquero,
paraba de hacer su trabajo, dejaba la herramienta que estaba usando en la mesa, iba hasta
el teléfono y lo atendía. Desde hace poco más de un año se actualizó comprando un
pinganillo que le permitiera atender llamadas a la vez que trabajaba. Sin embargo, esta
solución no era perfecta ya que aun así debía apuntar a mano la cita y, a veces, la calidad
de la llamada no era buena teniendo que colgar sin haber entendido nada.
Como vemos, este negocio buscaba maneras de optimizar su trabajo y de mejorar. El

problema no sólo se reduce a aspectos del propio comercio, si no que en ocasiones
también se compara con otros. Al final son interacciones de personas y no se puede evitar
hacer comparaciones, ya sea precios, calidad del servicio, etc. Sin ir más lejos, ahora
Cristian cuenta con una cafetera para los clientes.
Con esto quiero decir que muchas personas son ambiciosas y trabajan por mejorar
continuamente sus negocios. Por esta razón, como desde el principio hemos tenido un
Página | 12
enfoque en las empresas, nuestra aplicación estará orientada principalmente en ellas,
definiendo y explorando nuevas posibilidades y ventajas.
El resto de este documento se estructura como sigue: la Sección 2 presenta los objetivos
perseguidos en este TFG; la Sección 3 muestra la metodología que hemos seguido para
su desarrollo; la Sección 4 plantea los requisitos del sistema; la Sección 5 estudia las
alternativas del mercado; la Sección 6 explica las herramientas utilizadas; las Sección 7
descubre la arquitectura y funcionamiento del sistema; la Sección 8 sintetiza toda la
información.
Como dijo Henry Ford:
“La mayoría de las personas gastan más tiempo y energías en hablar de los problemas
que en afrontarlos.”
Comencemos.
Página | 13
2. Objetivos
“Si no sabes dónde vas, acabarás en otra parte.”
Quizá esa frase sea la mejor aproximación de lo que vamos a tratar a continuación.
Siempre, en todo lo que hagamos, debemos ser capaces de responder a las preguntas ¿qué
queremos lograr? y ¿para qué lo estamos haciendo? Estas preguntas sirven para
marcarnos unos objetivos y no alejarnos de ellos.
Habrá momentos en los que nos desviaremos del camino y necesitaremos recordar la idea
principal. Ahí es dónde necesitamos consultar la brújula y ver hacia dónde dirigirnos.
Extrapolando todas estas ideas, vamos a determinar el camino de nuestro proyecto, es
decir, los objetivos que queremos conseguir.
2.1. Objetivos principales

El objetivo principal de este trabajo es desarrollar una plataforma para la gestión de citas
con especial énfasis en las empresas.
Queremos desarrollar una aplicación web que sea útil a la hora de reservar cita en un
negocio, tanto para los clientes, ya que pueden reservar cuando quieran desde la web,
como para los negocios, que no necesitarán gestionar su agenda.
Cuando decimos con especial énfasis en las empresas nos referimos a que serán éstas el
centro de nuestra aplicación, ofreciéndoles funcionalidades nuevas que no tengan en otras
plataformas y que les aporten un verdadero valor. En la siguiente lista podemos ver los
objetivos que hemos tenido más presentes:
• Aplicación web funcional: lo que marcará la diferencia será que la web haga lo
que tiene que hacer, debe funcionar correctamente y cumplir con todas las
expectativas.
• Diseño atractivo y simple: siempre he sido partidario de diseños simples y
elegantes. Hacen que la aplicación en cuestión sea más usable y de fácil
adaptación, aspecto muy importante para captar todo tipo de clientes.
Página | 14
• Aportar mucho valor a las empresas en la parte de estadísticas: hay que
diferenciarse, y aportar un verdadero valor a las empresas hace que éstas quieran
migrar al sistema, lo que repercutirá en la promoción hacia sus clientes.
• Plataforma útil para clientes y empresas: por supuesto, si no se ofrece utilidad a
ambos usuarios la plataforma no será sostenible en el tiempo.
2.2. Objetivos secundarios

Como objetivos secundarios nos hemos planteado aquellas cosas que no eran el pilar
fundamental pero que ayudaban en gran medida a cumplir los objetivos principales.
Estos objetivos son:
• Analizar el mercado y detectar innovaciones: si queremos diferenciarnos debemos

estudiar el mercado y las ofertas que éste ofrece. De esta manera podremos
estudiar opciones que todavía no existan o hacer un producto más completo.
• Aprender a utilizar la librería de Plotly1 para generación de gráficas: conseguir
seguir un buen proceso de aprendizaje no sólo ayudará a la construcción de
gráficas sino también a la mantenibilidad y robustez de ese componente de la
aplicación.
• Aprender a utilizar las funcionalidades ofrecidas por la API de Google Maps2:
herramienta totalmente nueva para nosotros que puede aportar mucho valor a la
hora de trabajar con los datos, estableciendo perímetros de zona de trabajo de
negocios e incluso cálculos de clientes potenciales por áreas.
• Ser más polivalente y desarrollar el lado frontend, profundizando en JavaScript:
es innegable que JavaScript nos permite hacer muchísimas cosas muy interesantes
en el lado del cliente, y desde luego, en este proyecto se ha convertido en una parte
fundamental a la que dedicar horas de aprendizaje.
Errar en estos objetivos conlleva también errar en los principales, y por ende, en el
producto final. Por ejemplo, no aprender a utilizar correctamente la librería de Plotly se
puede traducir en unas gráficas escasas y mediocres, lo cual repercutiría en nuestro
1
https://plotly.com/javascript/
2
https://developers.google.com/maps/documentation/places/web-service?hl=es-419
Página | 15
objetivo de aportar valor a las empresas. De la misma manera con el resto. La API de
Google Maps nos permitirá ofrecer funcionalidades que harán el conjunto más potente y
útil.
Página | 16
3. Metodología
En esta sección vamos a hablar de los pasos que hemos seguido para sacar adelante el
proyecto, del proceso de aprendizaje que hemos experimentado y, en general, de qué
hemos hecho y cómo lo hemos hecho para desarrollar la aplicación web de Voyendo y
cumplir con nuestros objetivos.
Un proyecto con este nivel de importancia y dificultad hace que durante el desarrollo
vivamos situaciones más complejas de lo normal, situaciones de estrés por periodos de
entrega y por querer construir algo que de verdad sea valioso y útil. Cada persona
establece sus marcas de lo que quiere lograr, pero en definitiva, todos queremos sentirnos
orgullosos del trabajo realizado.
Como digo, este es el apartado destinado al aprendizaje, a comentar aquellas cosas que
en algún momento hacíamos mal pero que hemos cambiado, incluso las sensaciones que
nos han llevado a tomar todas las decisiones.
Comenzaré contando cómo fue el inicio de este proyecto en el ámbito de la planificación.
3.1. Planificación
A pesar de ser consciente de cómo ayuda y facilita el trabajo la planificación previa de
éste, los inicios no fueron tan organizados como me hubiera gustado. Intentaba abordar
las tareas sin ningún tipo de orden, según lo que a mi parecer era lo mejor y correcto,
hasta que llegó un punto en el que el tiempo apremiaba.
En ese punto de estrés y necesidad, involuntariamente anotaba en una libreta las pequeñas
tareas que tenía que hacer y no se me podían olvidar. Sin darme cuenta, estuve trabajando
dos semanas con lo que eran unas historias de usuario muy básicas. Eran verdaderamente
simples, pero me ayudaron en gran medida a avanzar rápidamente.
Después de estar trabajando de esa manera, me di cuenta de lo importante que era

planificar todo bien para así ser capaz de organizar mejor los tiempos. En ese momento
Página | 17
decidí pasar toda la planificación a Trello3, herramienta que había utilizado previamente
en numerosos proyectos pero que me resistía a utilizar por pensar que era una pérdida de
tiempo si sólo trabajaba una persona.
Finalmente, a día de hoy, la instantánea de mi tablero se puede ver en la figura 3.
Figura 3: Tablero Trello
Se trata simplemente de un tablero con cuatro columnas. La primera es el “Backlog”,

cuya función es agrupar las tareas que debemos realizar. Después vemos la columna
“Seleccionadas”, en este lugar tenemos las tareas que hemos seleccionado para desarrollar
del backlog pero que se encuentran en espera. Cuando empezamos a desarrollar una de
estas tareas, la movemos a la columna “En marcha”, que se encarga de mostrar qué tareas
estamos llevando a cabo en ese momento. Finalmente, en la figura vemos la columna
“Terminadas”, donde irán las tarjetas que ya se hayan completado.
Quiero destacar también las etiquetas de las tarjetas. Estos colores indican la
prioridad/importancia que tiene cada tarea, siendo el verde la prioridad más baja y el rojo
la más alta. En la figura 4 podemos observar el formato de las tarjetas.
3
https://trello.com/es
Página | 18
Figura 4: Tarjeta Trello
En ellas indicamos qué queremos hacer y una serie de detalles que se deben cumplir a la
hora de implementarlas.
3.2. Estudio
Como todos sabemos, el Grado en Ingeniería Informática es un grado que requiere tener
capacidades autodidactas. Podemos encontrar información acerca de todo lo que
queremos hacer, pero debemos saber buscarla, encontrarla e interpretarla. A veces
tendremos que buscar en otros idiomas y otras veces navegar en páginas nada populares.
De eso vamos a hablar ahora, del aprendizaje que hemos vivido en los diferentes aspectos
del proyecto. Sin ir más lejos, la parte de estadísticas para las empresas supuso un gran
reto. Hasta ahora había trabajado con datos, pero nunca antes había tenido que hacerlos
valiosos. No tenía ningún tipo de experiencia haciendo gráficas ni conocía las librerías
que me ayudarían a ello, por lo que tenía que instruirme desde cero.
Al poco tiempo de estar investigando y pedir consejo a mis tutores, descubrí D3.js4, una
librería de análisis de datos muy potente que me podía servir para hacer todo lo que
4
https://d3js.org/
Página | 19
necesitaba. Sin embargo, tras buscar documentación para empezar a trabajar con ella me
di cuenta de que era muy compleja, demasiado engorrosa para lo que yo quería conseguir
y contaba con muy pocos ejemplos de código libre de los que aprender.
Esta fase constó de una semana entera de trabajo muy frustrante ya que no conseguía
ningún avance sustancial. Por esas sensaciones decidí buscar una alternativa. Encontré
algunas como Chart.js5 que a primera vista ya me parecían más simples, pero quería estar
seguro de mi cambio, lo último que necesitaba era equivocarme de elección. Seguí
buscando hasta que encontré Plotly.js, una librería construida a partir de D3.js pero que
solucionaba todos los problemas que no me gustaban y era igual de potente.
La gran ventaja que tenía Plotly.js es que se podía implementar en muchos lenguajes de
programación, y por ende contaba con muchos ejemplos en Internet, videotutoriales para
aprender a usarla y tenía un amplio abanico sobre el que trabajar. No sólo eran los típicos
gráficos, podía llegar a construir gráficos dinámicos muy potentes. Así que decidí seguir
adelante con ella, y en tan sólo tres días tras el cambio, ya había logrado tener las mismas
gráficas anteriores y terminar toda la parte básica para las empresas.
Otro de los aspectos que me gustaría destacar en lo que a aprendizaje se refiere es la parte
del frontend. Y no sólo el diseño y el trabajo con HTML y CSS, que también, ya que he
mejorado mucho mis habilidades, sino la parte de JavaScript. Mis proyectos anteriores
nunca habían tenido tanto código en JavaScript. Sabía manejarme, pero no al nivel que
algunas de las páginas requerían.
Hemos desarrollado funciones para trabajar con formatos de fechas, funciones vinculadas
a eventos para hacer la página más dinámica, funciones encargadas de la manipulación
de todos los datos que recibíamos del lado del servidor para la construcción de las gráficas
anteriormente comentadas y, además, la parte que todavía no hemos nombrado: el
calendario para mostrar el horario de una empresa y hacer las respectivas reservas.
5
https://www.chartjs.org/
Página | 20
Para esta tarea hemos utilizado el plugin de FullCalendar.js6, una librería muy popular
que cuenta con gran variedad de personalización y métodos para trabajar con ella. El
aprendizaje con esta herramienta todavía sigue avanzando, pero hasta ahora estoy muy
contento porque me ha ahorrado mucho tiempo al tener algunas de las ideas que rondaban
por mi mente ya implementadas. Por ejemplo, arrastrar eventos, clicar en ellos o incluso
crear el calendario en función del horario de la empresa. De manera muy similar que con
Plotly.js, este proceso ha sido pura investigación y búsqueda en la documentación
ofrecida por ellos mismos.
3.3. Realidad
En ocasiones no todo sale como uno espera, existen factores que nos obligan a tomar
determinadas decisiones. Ejemplo de esto es el tiempo, la carga de trabajo o la
complejidad que algo puede tener.
Personalmente, he experimentado problemas de falta de tiempo y cargas de trabajo que

no me permitían dedicar tanto tiempo al proyecto como debería. Fruto de esto he ido
tomando decisiones para evitar complejidades innecesarias que sólo retrasarían mi
trabajo. Es cierto que estas complejidades o retos son los que nos hacen crecer y aprender
cosas nuevas, pero hay situaciones en las que hay que priorizar, y que el producto final
fuera usable y estuviera terminado era nuestro máximo interés.
Nuestros primeros pasos fueron analizar el mercado para ver qué podíamos aprovechar
para marcar la diferencia, formamos una idea mental sólida sobre qué queríamos hacer y
nos pusimos manos a la obra.
Empezamos a desarrollar los requisitos para tener una imagen más clara del resultado
final. Desde el principio sabíamos las tecnologías que íbamos a utilizar, por lo que una
vez terminamos con los requisitos, construimos el que fue el primer esquema UML de
clases, que como veremos en apartados posteriores, ha ido evolucionando junto con
nuestras ideas y el proyecto. En este punto todavía no teníamos sensaciones de ir
atrasados, fue al mes de estar desarrollando cuando el proyecto sufrió un estancamiento.
6
https://fullcalendar.io/
Página | 21
Después de estar varias semanas en las que los avances eran mínimos, aparecieron las
primeras sensaciones de agobio y se hizo todo lo posible por agilizar el trabajo.
En cuanto al desarrollo, decidimos comenzar por la parte de las empresas, construyendo

toda su lógica e interfaces. Al fin y al cabo, esta era la parte principal del proyecto y la
que más tiempo requería. Posteriormente, empezamos a desarrollar lo que es la parte de
los clientes, esta parte compartía algunas funcionalidades que ya habíamos hecho para los
negocios, como eran las reservas, por lo que sería más sencilla y nos ocuparía menos
tiempo.
En definitiva, creo que esta estrategia fue la correcta. No hubo ningún obstáculo que nos
impidiera el desarrollo, todo era como escribir un párrafo, donde la palabra siguiente no
tenía sentido sin la anterior.
Para entender un poco las fechas de las que estoy hablando y la duración de todas las
tareas que se han ido haciendo durante el desarrollo, he creado un diagrama de Gantt [4].
Un diagrama de Gantt es una herramienta de gestión de proyectos en la que se recoge la

planificación de un proyecto. Normalmente tiene dos secciones: en la parte izquierda se
incluye una lista de tareas y, en la derecha, un cronograma con barras que representan el
trabajo.
Página | 22
Figura 5: Diagrama de Gantt. Tareas
La lista de tareas puede verse en la figura 5. En esta parte se enumeran las tareas, con las
fechas de inicio y su duración. Vemos que el proyecto está previsto que se termine de
desarrollar por completo el día 6 de julio, fruto de esta fecha son las sensaciones que
hemos explicado anteriormente.
Para finalizar, la figura 6 muestra el diagrama de Gantt al completo.
Página | 23
Figura 6: Diagrama de Gantt
Página | 24
4. Análisis de requisitos
Llegados a este punto, dentro del proceso en el que nos estamos imaginando cómo
queremos desarrollar el producto final, debemos realizar un análisis de requerimientos,
es decir, definir con la mejor calidad posible las características del sistema software que
satisfagan las necesidades de negocio de clientes y usuarios.
La definición de dicho sistema se realiza mediante lo que se conoce como una

especificación de requisitos. Esta es una pieza clave para proporcionar un sistema de
información con calidad, entendiendo como calidad la satisfacción del usuario, cubriendo
sus expectativas, deseos y necesidades.
En nuestro caso no vamos a obtener feedback de usuarios, pero sí que debemos recoger
los requisitos del sistema poniéndonos en las dos perspectivas más importantes para el
desarrollo: el negocio y los usuarios finales.
El resultado de esta tarea o actividad no es estático, ya que a lo largo del proyecto pueden
aparecer nuevos requisitos, ampliaciones, incluso eliminaciones o modificaciones de los
existentes. Vamos a llevar a cabo un desarrollo ágil, de manera que nos mantendremos
siempre en el lado de la adopción de los nuevos cambios que hagan del producto uno
mejor.
Para asegurar la calidad de los requisitos, éstos deben cumplir ciertas características:
• Independencia del diseño: no deben indicar cómo debe implementarse el sistema.

• Redundancia: dos o más requisitos no deben hacer referencia al mismo aspecto
del software.
• Concisión: deben expresarse de la forma más simple posible.
• Realizabilidad: se puede implementar con la tecnología disponible.
• Internamente consistente: no existen contradicciones entre requisitos.
• Externamente consistente: no existen contradicciones entre requisitos y
documentos externos como políticas u objetivos de empresa.
• Ambigüedad: no debe haber requisitos que puedan tener distintas interpretaciones.
Página | 25
• Verificabilidad: deben existir pruebas para determinar su existencia en el producto
final.
A la hora de anotar todos los requisitos se les suele asignar:
• Identificación: identificador único para evitar confusiones y distinguir

perfectamente los requisitos.
• Prioridad: indica cuánto de necesario cree el cliente que es un requisito.
Dicho todo esto, procedamos a comentar los requisitos del sistema, clasificados según
funcionales o no funcionales.
4.1. Requisitos funcionales

Los requisitos funcionales son declaraciones de los servicios que debe proporcionar el
sistema, la forma en que debe reaccionar a las entradas y cómo se debe comportar en
situaciones particulares. Especifica una función que un sistema o componente de un
sistema debe ser capaz de llevar a cabo. Además, pueden declarar explícitamente lo que
el sistema no debe hacer.
Requisitos funcionales. Sistema
ID Descripción Prioridad
El sistema debe permitir dos tipos diferentes de usuarios

RF.S.1 Alta
(negocios y usuarios).
El sistema debe ser compatible con los principales
RF.S.2 Alta
navegadores.
RF.S.3 El sistema debe almacenar las contraseñas encriptadas. Alta
El sistema debe tener un buscador de servicios avanzado por

RF.S.4 Media
nombre, ubicación, tipo de servicio…
Las ubicaciones serán tratadas con alguna API que nos
RF.S.5 Media
proporcione funciones útiles.
RF.S.6 La aplicación web debe ser responsive. Media
Página | 26
Requisitos funcionales. Negocios
Los negocios deben de poder decidir si desean compartir su

RF.N.1 información. De ser así, recibirán estadísticas globales con Alta
los datos que comparten también otros comercios.
Los negocios deben tener un apartado para ver todas sus
RF.N.2 Alta
estadísticas.
RF.N.3 Los negocios deben poder ver su horario y ver las reservas. Alta
RF.N.4 Los negocios deben poder establecer su horario de trabajo. Alta
Los negocios deben poder consultar y modificar sus datos

RF.N.5 Alta
personales.
Los negocios podrán crear nuevas citas desde el calendario.
RF.N.6 Alta
Además de modificar y cancelar las existentes.
Los negocios deben poder introducir al sistema los servicios
RF.N.7 Alta
que ofrecen.
Los negocios deben poder establecer días libres y cancelar
RF.N.8 Media
periodos de tiempo para reservar.
Los negocios deben poder ver la información de los clientes
RF.N.9 Media
con reservas.
RF.N.10 Los negocios deben poder subir imágenes a su perfil. Baja
Requisitos funcionales. Usuarios
Los usuarios deben poder ver el horario de un negocio y hacer

RF.U.1 Alta
una reserva en un hueco disponible.
RF.U.2 Los usuarios podrán cancelar reservas. Alta
Los usuarios deben poder consultar y actualizar sus datos

RF.U.3 Alta
personales.
RF.U.4 Los usuarios podrán ver un listado de sus reservas. Media
Página | 27
Los usuarios deben poder establecer la visibilidad de sus
RF.U.5 Media
datos.
RF.U.6 Los usuarios podrán escribir reseñas y valorar los negocios. Baja
4.2. Requisitos no funcionales

Son aquellos requisitos no relacionados directamente con la funcionalidad del sistema,
pueden estar relacionados con propiedades emergentes del sistema, considerando
ejemplos de propiedades emergentes las siguientes:
• Fiabilidad: característica fundamental de los sistemas informáticos por la que se

mide el tiempo de funcionamiento sin fallos.
• Tiempo de respuesta: medida para evaluar los tiempos de respuesta de un producto
de software cuando se le realiza una petición.
• Capacidad de almacenamiento: capacidad para recopilar y conservar toda la
información necesaria de un sistema.
• Escalabilidad: capacidad para manejar una carga creciente de datos y trabajo y
seguir satisfaciendo las necesidades.
Los requisitos no funcionales surgen de las necesidades del usuario, debido a restricciones
en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad
con otros sistemas, etc. Los clientes o usuarios establecen requisitos no funcionales como
metas generales, tales como: facilidad de uso, capacidad para recuperarse de los fallos o
la respuesta rápida al usuario. Es por eso que estos requisitos suelen ser difíciles de
verificar y más críticos que los requisitos funcionales.
En nuestro caso, vamos a seguir la misma clasificación que se hace en el libro Ingeniería
del Software [1]. En esta clasificación se establecen 3 categorías principales, de las que
después surgen otras más específicas.
Página | 28
Figura 7: Esquema clasificación de requisitos
1. Requerimientos del producto. Estos requerimientos especifican o restringen el

comportamiento del software. Algunos ejemplos son la eficiencia o cuánta
memoria requiere.
2. Requerimientos de la organización. Son requerimientos derivados de políticas y

procedimientos en la organización del cliente y del desarrollador. Por ejemplo,
requerimientos del proceso de desarrollo que especifican el lenguaje de
programación.
3. Requerimientos externos. Esta categoría cubre todos los requerimientos fruto de

factores externos al sistema y su proceso de desarrollo, requerimientos legislativos
que deben cumplirse, etc.
Requisitos no funcionales. Producto
El sistema debe ser fácil de usar y de acceder para cualquier

RNF.P.1 Alta
perfil de usuario.
Debe permitir el acceso y tener la misma apariencia en los
RNF.P.2 Alta
navegadores más importantes del mercado.
Página | 29
El sistema debe de estar disponible siempre, alcanzando una
fiabilidad mínima de un 90% del tiempo de funcionamiento
RNF.P.3 Alta
sin fallos, estando disponible las 24 horas del día todos los
días.
Los tiempos de respuesta deben estar siempre dentro de una
RNF.P.4 Alta
franja razonable de espera.
El sistema debe de ser escalable en función al número de
RNF.P.5 Media
accesos simultáneos.
Requisitos no funcionales. Organizacionales
El producto debe ser una aplicación web desarrollada en

RNF.O.1 Alta
Java.
RNF.O.2 El sistema debe de ser fácil de mantener. Alta
La base de datos con toda la información debe de estar

RNF.O.3 Media
alojada en un servidor seguro.
Requisitos no funcionales. Externos
Cada tipo de usuario debe poder acceder sólo a su zona de

RNF.E.1 trabajo. Un usuario no podrá acceder a ninguna función de Alta
los negocios.
Se debe pedir el consentimiento a los negocios para poder
RNF.E.2 Alta
utilizar sus datos.
Se debe poder interoperar con otras APIs. Por ejemplo, para
RNF.E.3 Media
ubicaciones.
4.3. Casos de uso

El modelado de un sistema desde el punto de vista del usuario se realiza mediante los
casos de uso. Su objetivo es describir la manera en que se usará el sistema, es decir,
describir sus funcionalidades esenciales.
Los diagramas de casos de uso fueron concebidos por I. Jacobson y describen una
interacción entre un agente externo (al que se llama actor) y el sistema. Estos diagramas
Página | 30
permiten definir los límites del sistema, sus relaciones con el entorno y, además, nos dejan
ver qué hace el sistema, pero no cómo lo hace.
Nosotros nos hemos centrado en dos situaciones que serán muy comunes una vez que el
sistema esté en funcionamiento: la reserva de citas por parte de los usuarios y la consulta
de estadísticas por parte de los negocios. Estos diagramas han quedado así:
1. Proceso de reserva
Figura 8: Caso de uso proceso de reserva
Lo que se quiere reflejar en la figura 8 es el proceso que un usuario normal debería seguir
a la hora de hacer una reserva.
En primer lugar, tendrá que buscar qué quiere reservar. Después, de toda la lista de
negocios que ofrecen ese servicio, deberá elegir el que más se ajuste a sus necesidades.
Hecho esto, verá información de ese negocio más detallada y en caso de todavía querer
reservar, tendrá que elegir un hueco disponible en el horario y finalmente, completar su
reserva.
2. Consulta de estadísticas
Página | 31
Figura 9: Caso de uso consulta de estadísticas
Del lado de los negocios, hemos plasmado de manera simplificada qué posibilidades
tendrían a la hora de consultar sus estadísticas.
Como vemos en la figura 9, estos tendrían algunas opciones que estarían siempre
habilitadas, que serían aquellas estadísticas que se generan a partir de sus propios datos.
Sin embargo, de manera opcional y habilitando su cesión de datos al sistema, podrían
optar a análisis más completos y que además están vinculados con todos los datos de otros
negocios para poder observar comparaciones y avances en su sector.
Para evitar hacer un esquema excesivamente complejo, hemos simplificado opciones

como vista diaria, semanal y mensual de todas las estadísticas y hemos hecho
agrupaciones. Por ejemplo, ‘Análisis de clientes’ lleva consigo numerosas estadísticas
como el número de reservas de cada cliente, su frecuencia, número de nuevos clientes,
gasto medio, etc.
Página | 32
5. Estado de la cuestión
En los últimos años hemos vivido un impresionante auge en la tecnología, pero no sólo
en cuanto a avances, sino también en la adopción de esta. Además, la situación provocada
por el Coronavirus ha hecho que este crecimiento sea exponencial.
Esto nos lleva a la necesidad de implantar tecnología en campos o experiencias de usuario

que antes ni tan siquiera se planteaban. En nuestro caso, vamos a hablar de algo que todos
hemos hecho alguna vez. Se trata de la reserva de citas para acudir a un comercio.
La mayoría de nosotros, para reservar cita con nuestro peluquero, por ejemplo, tenemos
que llamar al negocio y seguir una conversación que básicamente se resume en algo
similar a lo siguiente:
- Peluquero: ¿Qué día te va bien?

- Cliente: Pues este mismo martes, o el miércoles sólo por la mañana
- Peluquero: Vale… ¿Qué te parece el martes a las 10 de la mañana?
- Cliente: Buff, ¿podría ser a las 12?
- …
Esta conversación será en la mayoría de los casos de tan sólo 1 minuto o 2, pero ¿por qué
no automatizar este proceso? De lograr eso, evitaríamos que el peluquero dejara de
trabajar para atender el teléfono y perdiera tiempo con la llamada. De la misma manera,
el cliente podría ver qué huecos tiene disponible el negocio al que desea ir y reservar en
el momento más adecuado para él, y todo esto sin hablar de las cancelaciones. Es en la
resolución de este problema dónde aparece la idea de negocio para hacer reservas online.
Algunas empresas ya han desarrollado aplicaciones que cubren estas necesidades, pero
como es normal, cada una de ellas tiene algún aspecto diferenciador.
Página | 33
5.1. Booksy7
Figura 10: Web Booksy
FUNCIONALIDADES DESCRIPCIÓN
Distintos idiomas
Centrada en el nicho de belleza y bienestar

GENERALES
Sistema de pagos
Aplicación móvil
Buscador por servicio y ubicación
Sección de blog con tips, e información
Al buscar aparece un listado con los negocios que ofrecen

ese servicio, sus precios y una opción para reservar
CLIENTES
Pueden ver detalles sobre un negocio (reseñas, imágenes,
ubicación, contacto y servicios que ofrecen)
Notificaciones y recordatorios de sus reservas
NEGOCIOS Calendario y citas
7
https://booksy.com/en-es/
Página | 34
Herramientas para mandar mensajes, promociones e
incluso Boosts (mejor posicionamiento en la app)
Seguimiento de rendimiento (estadísticas de tu propio
negocio)
Servicio Pro con funciones más avanzadas como la gestión
de empleados e inventario
5.2. Timp8
Figura 11: Web Timp
Sectores de fitness, bienestar, belleza y educación

GENERALES
Sistema de pagos
Aplicación móvil
CLIENTES Hacer reservas
Notificaciones y recordatorios de sus reservas
NEGOCIOS Calendario digital
8
https://www.timp.pro/
Página | 35
Métricas con datos internos del propio negocio (captación de
usuarios, pagos, gasto medio por cliente…)
Exportar datos
Información sobre sus clientes
Control de empleados
Automatización de la contabilidad (pagos pendientes, dinero

total ganado…)
Bonos y mensualidades
Canales de comunicación con los clientes
Servicios online con su propia plataforma de streaming
Diferentes tarifas según las funciones
5.3. Uala9
Figura 12: Web Uala
9
https://www.uala.es/
Página | 36
Sectores de belleza y bienestar
GENERALES Recordatorios de citas
Sistema de pagos
Buscador por negocio, servicio o ubicación
CLIENTES Regalar tarjetas de experiencias
Bonos y tarjetas VIP
Agenda digital muy funcional
Gestión de empleados (turnos y horarios)
Gestión de inventario
NEGOCIOS
Venta de productos
Estadísticas (número de reservas de cada cliente, nuevos

clientes adquiridos, frecuencia de clientes, productos
vendidos, empleados con mejores métricas, distribución de
los servicios)
Después de analizar las principales empresas orientadas a la idea que perseguimos

construir, nos hemos dado cuenta de que podemos implementar algo que nos diferencie
de ellas y aporte a nuestro sistema un valor añadido para los negocios.
Poniendo el foco sobre los negocios, hemos visto que ninguna de las opciones anteriores
ofrece a los negocios la posibilidad de consultar estadísticas generales, es decir, sus
propios datos frente a los datos de los negocios de su mismo sector. Con esto, podríamos
ofrecer a los comercios estadísticas muy interesantes. Por ejemplo:
• Porcentaje de clientes que abarcan del total

• Días en los que hay más reservas
Página | 37
• Su coste frente al del resto de empresas del sector
• Servicios populares en la zona
• Negocios líderes de la zona
• Cantidad de clientes por tipología (edad, sexo…)
Por lo tanto, nuestro sistema va a estar centrado sobre todo en la parte de los negocios, y
más aún en la muestra de estadísticas útiles y de calidad para ellos.
Página | 38
6. Herramientas y tecnologías
Una parte fundamental a la hora de desarrollar un proyecto software es la elección de las
tecnologías que se van a usar. Estas elecciones son muy importantes y marcarán en gran
medida no sólo el resultado final, sino también el proceso de desarrollo y el
mantenimiento posterior. En esta sección veremos qué herramientas hemos elegido usar
frente a otras y los motivos que nos han llevado a ello.
6.1. Backend
Para la parte del backend de nuestra aplicación web hemos decidido que el lenguaje de
programación que vamos a utilizar sea Java. Se trata de una aplicación web, y en ese
sentido, Java es muy potente y nos aporta muchas facilidades. Sin embargo, no debemos
limitarnos al lenguaje que usaremos. Desde mi punto de vista, actualmente existen
infinidad de herramientas complementarias y que aportan mucho valor añadido al
lenguaje.
Es por ello que, más que elegir un lenguaje de programación, tenemos que elegir un
entorno. Y para mí, la mejor opción es la combinación de Java junto a Spring Boot como
framework. Java es un lenguaje muy robusto, multiplataforma, y muy demandado, algo
que he valorado mucho en mi elección. La figura 13 muestra estadísticas de los lenguajes
de programación más populares de 2021. Se trata de unas estadísticas muy completas que
comparan diversas fuentes, dónde vemos dos índices y dos de las plataformas más usadas
entre los desarrolladores, Stack Overflow y Github. Java está en las primeras posiciones
en todos los rankings.
Figura 13: Ranking lenguajes de programación más populares de 2021

(https://self-starters.com/most-popular-programming-languages/)
Página | 39
¿Y por qué utilizar Spring Boot? Spring Boot es rápido, evitando tener que configurar
contenedores y servidores web Apache Tomcat, permitiendo tener la estructura de tu
aplicación y tener todas tus dependencias en un formato legible en un archivo POM para
su gestión Maven, además de la conexión a tu base de datos.
Con Spring Boot es rápido desarrollar y es rápido ejecutar. Las aplicaciones hechas con
esta tecnología están optimizadas para altas cargas de trabajo con un mínimo consumo de
memoria, creando sistemas óptimos para entornos web con miles de peticiones por
segundo. Además, este framework tiene un gran ecosistema y también se encuentra entre
los más usados, concretamente en el top 6 de los frameworks para backend más populares
de 2022, como podemos ver en la figura 14.
Figura 14: Frameworks para backend más populares de 2022

(https://statisticsanddata.org/data/most-popular-backend-frameworks-2012-2022/)
Una vez que sabemos que queremos desarrollar el proyecto con Java y Spring Boot,
surgen otras dudas que debemos resolver, como por ejemplo la base de datos y su acceso.
Como hemos dicho anteriormente, Spring Boot ofrece un amplio abanico de opciones en
todo su ecosistema y nosotros hemos optado por Spring Data JPA. Spring Data JPA
facilita la construcción de aplicaciones impulsadas por Spring Boot que utilizan
tecnologías de acceso a datos.
Página | 40
Utilizaremos una base de datos SQL. Durante el desarrollo trabajaremos con la base de
datos de memoria H210 y cuando estemos en producción usaremos MySQL. Este cambio
lo llevaremos a cabo gracias a los perfiles de configuración.
6.2. Frontend
Quizá sea, sin darnos cuenta, uno de los aspectos más determinantes a la hora de que
nuestro producto final triunfe o no. Y no hablamos de que esta cuestión pueda hacer que
el proyecto fracase por cuellos de botella en el trabajo o por una mala decisión de
arquitectura, sino por los usuarios finales.
Muchos estudios realizados al respecto [2] demuestran que la apariencia de una web
determina el comportamiento de los usuarios en ella:
• Los usuarios forman una opinión de un sitio web en 0,05 segundos.

• El 94% de las primeras impresiones en los sitios web se basan completamente en
su apariencia.
• El 38% de los visitantes del sitio web no interactúan si el diseño les parece poco
atractivo.
• Casi la mitad de los visitantes de la web creen que el diseño es el factor principal
que respalda la credibilidad de un sitio web.
Y existen muchas más afirmaciones. Por esta razón debemos esforzarnos en crear un sitio
web que sea atractivo, fácil de usar y amigable para todo tipo de usuarios.
En nuestro caso, para realizar esta labor hemos decidido combinar el motor de plantillas
Thymeleaf11 junto a la librería de Bootstrap12. Hemos trabajado con ambas herramientas
previamente y pensamos que la curva de aprendizaje de otras opciones presentes como
Angular13 o React14 sería demasiado para el proyecto. Estas herramientas nos permiten
10
https://www.h2database.com/html/quickstart.html
11
https://www.thymeleaf.org/
12
https://getbootstrap.com/
13
https://angular.io/
14
https://es.reactjs.org/
Página | 41
hacer todo lo que tenemos en mente y en el caso de Bootstrap, es una librería muy
reconocida y extendida mundialmente.
6.3. Otras tecnologías

En esta sección nombraremos tecnologías que no son el foco principal pero que a su vez
nos resultan muy útiles e imprescindibles a la hora de desarrollar software.
• Git15: software de control de versiones.

• Trello: software de administración de proyectos con interfaz web y con cliente
para iOS y Android.
• Adobe XD16: software para crear y compartir interfaces, tanto para páginas webs
como para aplicaciones.
• Microsoft Project17: software de administración de proyectos.
• Google Cloud Platform18: plataforma que reúne todas las aplicaciones de
desarrollo web que ofrece Google. Lo utilizamos para acceder a la API de Google
Maps.
• Maven19: herramienta de software para la gestión y construcción de proyectos
Java.
• JUnit20: conjunto de bibliotecas utilizadas para hacer pruebas unitarias.
• IntelliJ21: entorno de desarrollo integrado para el desarrollo de programas
informáticos.
• FullCalendar: plugin JavaScript para la construcción y manipulación de
calendarios.
• D3.js: biblioteca de JavaScript para manipular documentos basados en datos.
• Plotly: biblioteca de JavaScript para la realización de gráficos de código abierto.
15
https://git-scm.com/doc
16
https://www.adobe.com/es/products/xd.html
17
https://www.microsoft.com/es-es/microsoft-365/project/project-management-software
18
https://cloud.google.com/gcp/
19
https://maven.apache.org/
20
https://junit.org/junit5/
21
https://www.jetbrains.com/es-es/idea/
Página | 42
6.4. Mockups
A lo largo de mi vida como estudiante he desarrollado muchos proyectos, tanto en equipo
como individualmente, y una de las cosas que he aprendido es que aquellos trabajos en
los que previamente hacíamos mockups siempre nos permitían avanzar más rápido y
evitaban ambigüedades. Además de que, en este caso, los mockups también han servido
como mecanismo para consensuar el diseño y la funcionalidad con los tutores del trabajo
antes de pasar a la implementación.
Y es que siempre sucedía lo mismo, cuando programábamos sin tener una guía
aproximada del resultado que queríamos conseguir (en cuanto a apariencia se refiere)
perdíamos mucho tiempo intentando crear un buen diseño. Por no hablar de que cuando
el proyecto era en equipo y cada miembro tenía una tarea diferente. Sin estos mockups
era casi imposible crear una web completamente cohesionada. El uso de mockups nos
permite solucionar todos estos problemas.
A continuación, vamos a ver una serie de diseños para nuestra web.
Figura 15: Mockup página registro
La figura 15 corresponde con la página de registro. En ella ya podemos ver que los
clientes y los negocios se registran de manera diferente, introduciendo los datos
correspondientes. También nos damos cuenta de que el diseño de la web girará en torno
a colores azules, colores vivos y se mostrará simple y elegante.
Página | 43
Figura 16: Mockup página inicio de sesión
Cuando ya tenemos nuestra cuenta creada, independientemente de que seamos un cliente

o una empresa, siempre accederemos desde el mismo sitio e introduciendo nuestras
credenciales, que serán el nombre de usuario y la contraseña. Vemos diseños muy
similares en las figuras 15 y 16.
Figura 17: Mockup home clientes
Página | 44
Esta interfaz corresponde al home, a la página principal de los usuarios que se registren
como clientes. Como vemos, tenemos un menú en la parte superior con las principales
acciones:
• Home: es la vista que vemos en la imagen

• Mis reservas: en esta página aparecerán todas las reservas que ha hecho.
• Nombre del cliente: este desplegable tiene 2 opciones, una para consultar tus datos
personales y hacer modificaciones y otra para cerrar sesión.
En la parte inferior al menú tenemos un buscador en el que podremos buscar por categoría
de negocio que necesitamos, por nombre del servicio que buscamos e incluso por
ubicación, siendo todos estos filtros combinables.
Finalmente, vemos un listado con los resultados que cumplen los requisitos del buscador.
Las cartas que muestra este listado siempre serán de negocios, no del propio servicio.
Para finalizar con los diseños, veamos uno de la parte de los negocios.
Figura 18: Mockup estadísticas empresas
Página | 45
Este es el panel de control de las empresas. Como vemos, consiste en una serie de gráficas
acerca de los datos que tiene el sistema. En la parte superior tenemos unos números que
pueden resultar muy útiles para analizar el progreso del negocio y en la parte inferior
gráficas que trabajan ya con esos datos.
Esta vista no está completa ya que como sabemos de puntos anteriores, existe la opción
de compartir tus datos al sistema y recibir así análisis comparativos con los datos que
otras empresas también han cedido. En resumen, la parte que vemos sería lo que todas las
empresas podrían ver, pero si hacemos scroll hacia abajo, habilitando previamente la
opción para compartir los datos, veríamos otra serie de gráficas.
Con estos cuatro diseños tenemos suficiente como para marcar las directrices principales
en cuanto a diseño y poder hacer una web que sea coherente en cada una de sus páginas.
Página | 46
7. Arquitectura del sistema
En esta sección hablaremos del funcionamiento del sistema. Vamos a analizar su
arquitectura, detallaremos cada una de sus partes y nos adentraremos posteriormente en
lo que para mí ofrece mayor claridad a la hora de intentar comprender un sistema
software: el diagrama UML de clases.
Para la arquitectura de nuestro sistema hemos decidido seguir el patrón MVC, sobre el
que profundizaremos más adelante, pero, de momento, veamos el diagrama del sistema
al completo para ser más conscientes de este.
Figura 19: Arquitectura del sistema
En la figura 19 podemos observar el esqueleto de nuestro sistema. Vemos todos sus

componentes, cómo se comunican entre ellos y las tecnologías utilizadas. Todo comienza
con una petición proveniente de un usuario, procedemos a realizar el mapeo de la URL y
en este paso, hacemos validaciones de seguridad, por ejemplo, que el usuario esté
logueado si es necesario o que acceda a una ruta permitida por su rol (cliente/empresa).
Después, este mapeo invoca a un método de nuestro controlador, el cual se comunica con
nuestra capa de Modelo para obtener toda la información necesaria. Esta capa es la
encargada de acceder a la base de datos, y una vez ha terminado su función, el controlador
Página | 47
puede utilizar esos datos para enviarlos al motor de plantillas a través de la Interfaz Model
de Spring. Nosotros hemos utilizado Thymeleaf como motor de plantillas, este recoge las
variables de la interfaz y las interpreta en la vista HTML. Por último, retornamos al
usuario la página de la URL que había consultado.
7.1. Esquema UML

Desde el principio hemos insistido en que seguiríamos un desarrollo ágil, abrazando todos
los cambios que puedan surgir en este proceso y construyendo el producto poco a poco.
Ejemplo de esto es nuestro esquema UML, ya que no hay nada en este trabajo que haya
experimentado tantos cambios.
En este apartado vamos a ver su evolución, el porqué de algunas modificaciones y el

resultado final. Como sabemos, el modelo UML describe lo que supuestamente hará un
sistema, pero no dice cómo implementar dicho sistema. Nos centraremos en el diagrama
de clases, popular entre los ingenieros de software para documentar arquitectura de
software. Los diagramas de clases son un tipo de diagrama de estructura porque describen
lo que debe estar presente en el sistema que se está modelando.
La figura 20 muestra el primer modelo de nuestro esquema. A simple vista puede parecer
correcto. De hecho, en los pasos iniciales lo era, hasta que nos dimos cuenta de que
necesitábamos más atributos en determinadas clases o, simplemente, nuevas clases para
extender y completar el sistema.
Página | 48
Figura 20: Esquema UML fase I
Para ser sinceros, este diagrama nos permitió avanzar bastante. Las ideas principales
habían quedado claras y gran parte del código se podía implementar con esa base.
Uno de los conceptos más importantes que tuvimos que aclarar en esta etapa inicial fue
la estructura que queríamos que tuviera uno de los pilares del proyecto: las reservas. Esta
idea consiste en lo siguiente: imaginemos que somos una peluquería. Como peluquería
podemos ofrecer varios servicios (corte de pelo, recorte de barba, tinte…) donde cada uno
tiene unas propiedades diferentes (duración, precio…) Esto queda reflejado en la clase
“Labour”, siendo una composición de “Company”. Toda “Company” tendrá una o más
“Labours” y cada “Labour” pertenecerá a una “Company”.
Por otro lado, la clase “Appointments” trata de albergar aquellas citas que se han
materializado. Es decir, cuando se asigna un servicio de una “Company” a un determinado
“Customer”. Esta reserva por supuesto contará con atributos propios como son la fecha y
el periodo de tiempo.
Página | 49
Gracias a esta arquitectura podemos hacer lo siguiente:
• Los clientes pueden buscar por servicios (“Labours”).

• Las empresas pueden ofrecer tantos servicios como quieran.
• Tenemos las reservas más estructuradas ya que pertenecen a un tipo de servicio.
• Una reserva contiene todos los datos fundamentales (“Company”, “Customer” y
“Labour”).
• Un cliente no puede hacer una reserva fuera de lo estipulado por la empresa.
Posteriormente, cuando nos adentramos en la construcción de las estadísticas de las

empresas, nos dimos cuenta de que necesitábamos más datos acerca de los clientes. Por
tanto, ampliamos esa clase añadiendo un atributo para el sexo y otro para la edad.
Después de unas semanas trabajando con el esquema UML de la figura 20, llegamos a la
situación en la que una empresa creaba una reserva. En ese momento vimos que nuestro
esquema no contemplaba la opción para que la empresa pudiera crear una reserva para un
cliente que no estuviera registrado en el sistema.
Meditamos múltiples alternativas hasta que finalmente nos decantamos por el diagrama
mostrado en la figura 21.
Página | 50
Figura 21: Esquema UML fase II
Diseñamos una herencia en la clase “Appointment”, teniendo “GuestAppointment” para

las reservas en las que el cliente no está registrado en el sistema y “NormalAppointment”
para las que el cliente sí está registrado, de manera que internamente la base de datos
trabajaría únicamente con una tabla “Appointment”.
La otra opción que pensamos fue establecer la herencia en la clase “Customer”, pero
detectamos un problema en esa solución. Tendríamos que almacenar clientes que no están
en el sistema y no se van a volver a utilizar ya que con cada reserva de invitado la empresa
pondría un nombre diferente. Con la solución planteada logramos avanzar y mantener la
misma idea general que teníamos acerca de las reservas.
Página | 51
Además, en la figura 21 se ha añadido un campo en la clase “Company”. Este campo es
el de “premium” e indica aquellas empresas que han habilitado la opción de cesión de sus
datos.
Para terminar, veamos el diagrama final de nuestro esquema UML representado en la

figura 22.
Figura 22: Esquema UML fase III
En este esquema hay dos cambios principales: el nuevo campo “activated” en la clase
“Labour” y la nueva clase “Review”.
Página | 52
A primera vista el campo “activated” que hemos añadido puede parecer insignificante,
pero determina factores muy importantes de nuestra arquitectura. Hasta este momento,
los negocios podían tener el número que quisieran de servicios, pero quisimos limitar este
número y darles únicamente cinco. De esta manera, un negocio sólo podrá tener cinco
servicios con el valor “activated” a “true” y estos cinco servicios serán los únicos que se
pueden reservar. Pero la función de este campo no es sólo esa, sino solucionar los
problemas de borrado y modificación de servicios.
¿Qué sucede si un negocio decide modificar un servicio? En la arquitectura anterior de la

figura 21 encontrábamos muchos problemas ya que todas las reservas seguían vinculadas
a ese servicio y, en caso de modificar la duración, podríamos tener problemas de
solapamientos. Sin embargo, la arquitectura actual nos permite pasar el servicio que
vamos a modificar a no activado y crear uno nuevo con las modificaciones que sí esté
activado, logrando así mantener todas las reservas del antiguo servicio tal cual se hicieron
en su momento.
Lo mismo sucedería en caso de cambiar el precio de un servicio. Perderíamos el precio

que pagaron todas las antiguas reservas y, por ende, nuestras estadísticas no serían reales.
Lo que hacemos ahora es crear un nuevo servicio, de manera que las reservas antiguas
seguirán vinculadas al antiguo y las nuevas reservas se harán con el nuevo servicio
modificado.
Para aclarar esta idea, en los siguientes dibujos explicamos la misma situación.
Página | 53
Figura 23: Explicación modificación servicio I
Como vemos en la figura 23, contamos únicamente con cinco servicios activados, donde
el servicio 1 tiene vinculadas tres reservas. El servicio 1’ (rojo) representa la modificación
que el negocio ha hecho al servicio 1 (azul).
No podemos simplemente sobrescribir el servicio 1 y modificar su información ya que

las reservas vinculadas a él se han hecho en base a sus antiguos datos (duración, precio,
nombre del servicio…) por lo que tenemos que pasarlo a inactivo. En la figura 24
observamos el resultado.
Figura 24: Explicación modificación servicio II
Página | 54
Así quedaría el sistema tras la operación de modificación. Hemos creado un nuevo
servicio (servicio 1’) que reemplaza la posición del antiguo (servicio 1) sin modificar en
absoluto las reservas hechas. De ahora en adelante no se podrán hacer reservas con el
servicio 1, únicamente con aquellos que estén activados.
La situación ante el borrado de un servicio es prácticamente la misma. Queremos

mantener sus reservas, así que no eliminamos el servicio, sino que lo pasamos a estar
inactivo, dejando así un hueco para crear un nuevo servicio.
Para finalizar con los cambios que ha traído este nuevo diagrama hablaremos de la nueva
clase “Review”, encargada de albergar todas las opiniones que los clientes tengan sobre
los negocios. Esta clase cuenta con el texto del comentario que el cliente haga y su
valoración. Destacar que un cliente sólo puede tener una opinión para un negocio, que
podrá editar y eliminar.
7.2. Funcionamiento del sistema

Ya en el apartado anterior nos hemos adentrado un poco en lo que sería el funcionamiento
del sistema. Sin embargo, aquí vamos a comentar aquellos detalles que no hemos
nombrado y explicaremos todo el conjunto.
Como hemos dicho antes, el sistema se ha construido siguiendo el estilo de arquitectura

Modelo Vista Controlador (MVC) [3]. Es una arquitectura que separa los datos de una
aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos. Se
trata de un modelo muy popular, simple y que produce un sistema muy fácil de mantener
debido a esta característica de “separación de obligaciones”. La figura 25 muestra su
funcionamiento.
Página | 55
Figura 25: Patrón MVC
7.2.1. Modelo
Contiene una representación de los datos que maneja el sistema, su lógica de negocio, y
sus mecanismos de persistencia.
• Accede a la capa de almacenamiento de datos.

• Define las reglas de negocio.
Nuestra implementación de esta capa está dividida en dos paquetes: model y service. El
paquete model contiene las entidades JPA, que utilizan tecnologías de acceso a datos para
poder determinar el esquema de la base de datos y hacer consultas a ésta. De esta manera
los objetos Java de este paquete estarán vinculados a la base de datos y podrán operar
sobre ella. Por ejemplo, para guardar una nueva empresa:
companyRepository.save(company)
Página | 56
Figura 26: Clase Company.java
La figura 26 muestra una parte de nuestra clase Company, la cual utiliza anotaciones de
Spring Data JPA para declarar que es una entidad, sus respectivas columnas y las
relaciones que tiene con otras entidades, como por ejemplo con Appointment a través de
ese Set.
Figura 27: Clase CompanyRepository.java
Página | 57
En la figura 27 podemos observar la clase “repositorio” de la entidad Company. Esta clase
es la encargada de establecer el vínculo con la base de datos y es la que hace todas las
llamadas. Desde ella invocamos a las funciones para hacer consultas, actualizar, eliminar
o crear.
El paquete service contiene toda la lógica de negocio vinculada a cada clase. Un ejemplo
de esto sería comprobar que no haya solapamientos al crear una nueva reserva.
Figura 28: Método para crear una reserva. Clase AppointmentService.java
En la figura 28 observamos el código que se encarga de hacer todas las comprobaciones

antes de crear una nueva reserva. Recibe una empresa y un objeto
CrearAppointmentData, este objeto es el que nos trae los datos para crear la reserva desde
la interfaz. En primer lugar, convertimos la fecha de tipo String a Date, después
comprobamos que el servicio solicitado exista. En caso afirmativo creamos una reserva,
le asignamos todos los valores y llamamos al método comprobarHorasCitas que es quien
hace todas las comprobaciones de tiempos, fechas, etc. Para terminar, si todo va bien,
guardaremos la reserva en la base de datos y habrá sido creada con éxito.
7.2.2. Vista
Compone la información que se envía al cliente y los mecanismos de interacción con éste.
Página | 58
• Recibe datos del modelo y los muestra al usuario.
Esta parte consta de nuestras plantillas HTML que trabajan con el motor de Thymeleaf.
El controlador recibe los datos del modelo y se encarga de enviarlos a las plantillas para
que éstas se lo muestren al cliente.
Esta comunicación la hemos hecho principalmente con la interfaz Model del framework
de Spring. A través de ella mandamos las variables a las plantillas y después trabajamos
con ellas con Thymeleaf, que nos permite escribir código HTML dinámico en función a
estas variables.
Figura 29: Fragmento página detallesEmpresa.html
La figura 29 es un ejemplo perfecto para entender cómo funcionan las plantillas

Thymeleaf. Podemos ver cómo la plantilla trabaja con la variable company, obtiene sus
servicios y los recorre uno por uno para crear este componente con los datos específicos
de cada servicio.
7.2.3. Controlador
Actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información
entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.
• Recibe los eventos de entrada.
Página | 59
• Contiene reglas de gestión de eventos. Estas acciones pueden suponer peticiones
al modelo, a las vistas o a ambos.
Recibe todo tipo de interacciones que haga el usuario: la carga del contenido de las
páginas, la solicitud de datos a través por ejemplo de un buscador o el envío de
información mediante un formulario. Todas estas acciones desencadenan una petición
que gestiona el controlador y se encarga de realizar las respectivas llamadas tanto al
modelo como a la vista.
En la figura 30 vemos un ejemplo de nuestro controlador de empresas que se encarga de

mostrar la página de los servicios.
Figura 30: Ejemplo método CompanyController.java
Simplemente comprobamos que el negocio esté logueado y que exista, hecho esto
procedemos a enviar las variables a la plantilla para que ésta pueda trabajar con ellas.
Esta página, en el lado del cliente se traduce de la siguiente manera.
Página | 60
Figura 31: Interfaz página servicios de empresa
En la figura 31 vemos los valores de cada uno de los servicios, la empresa que está
logueada y, si pulsamos en editar, se abre un modal con los datos del servicio en cuestión
cargados.
Así es cómo funciona nuestra aplicación en profundidad y cómo se comunican los

diferentes componentes que la forman.
7.3. Funcionalidades del sistema

Ahora que conocemos los componentes del sistema en su totalidad, veamos el resultado
obtenido. Quiero destacar que las siguientes figuras han sido tomadas utilizando datos
sintéticos generados precisamente para esto, pruebas de sistema y demostraciones. Estos
datos se resumen en:
• 13 empresas: de las cuales 5 son peluquerías

• 50 clientes
• 266 reservas: divididas entre 3 empresas
• 25 reviews: divididas entre 3 empresas
Dicho esto, comenzaremos del lado de las empresas, sobre todo con su panel de control,
el cual cuenta con las siguientes características:
Página | 61
1. Indicadores mes actual comparado con el anterior
Figura 32: Panel de control. Indicadores mensuales
En la figura 32 vemos la parte superior del panel de control, donde tenemos cuatro
indicadores que reflejan una comparación del mes actual con respecto al anterior. Estos
indicadores sirven para conocer de un vistazo muy rápido la situación del negocio.
Contamos con cuatro tipos: reservas totales; ingresos totales; clientes totales; nuevos
clientes.
2. Gráficos circulares
Figura 33: Panel de control. Pie Charts
En la parte inferior de la figura 33 vemos tres gráficos circulares, en los que comparamos
con respecto al total de la empresa todas las variables que vemos: los clientes por género;
los clientes por rangos de edad; el número de citas por cada servicio. Además, estas
gráficas nos permiten hacer las comparaciones que necesitemos, de manera que, si
Página | 62
queremos comparar únicamente dos rangos de edad, podremos hacerlo. La figura 34
muestra el resultado.
Figura 34: Comparativa clientes por rangos de edad
3. Histórico de reservas con los picos mensuales de reservas de cada servicio
Figura 35: Panel de control. Histórico de reservas
Página | 63
En la figura 35 vemos el histórico de reservas de la empresa. Cada línea representa uno
de sus servicios, y en cada mes vemos un pico que indica la cantidad de reservas en ese
mes. Este gráfico permite movernos en el tiempo y establecer los periodos de tiempo que
queramos para obtener una perspectiva global. De la misma manera podemos seleccionar
sólo algunos de los servicios y compararlos entre ellos. Esta gráfica puede ser muy útil
para detectar los meses con menos reservas, entender el porqué, e intentar solucionarlo o
quizá, en base a eso, tomar los días libres en esas fechas.
4. Histórico de nuevos clientes
Figura 36: Panel de control. Histórico de nuevos clientes
El gráfico que vemos en la figura 36 es una línea acumulativa que indica los nuevos
clientes que hemos captado en cada mes. De manera que podemos saber si estamos
realizando una buena actividad de captación o nos encontramos estancados y necesitamos
algún tipo de promoción. Si buscamos hacer crecer nuestro negocio esta gráfica puede ser
muy conveniente, ya que refleja nuestro avance en cuanto a nuevos clientes.
5. Ranking datos globales
Página | 64
Figura 37: Panel de control. Rankings
La figura 37 indica los rankings de las mejores empresas o servicios de tu misma

categoría. En este caso, la empresa en cuestión es una peluquería, por lo que en el primer
ranking vemos los servicios de peluquerías que son los más reservados. En el segundo
ranking vemos las peluquerías que han obtenido más ingresos este mes y, por último, el
tercer ranking nos muestra las peluquerías que tienen mejores reviews, ordenadas por
media de opiniones y cantidad de éstas.
Adicionalmente a estas gráficas, el panel de control tiene:
• Histórico de ingresos por servicio

• Gráfico de barras con total ingresos por mes
• Porcentaje de clientes abarcado del total
• Coste medio frente al resto
Otro de los aspectos con gran importancia dentro de la aplicación es la agenda.
Figura 38: Agenda empresa
Página | 65
En la figura 38 se muestra la agenda de un negocio. Vemos todas las reservas del mes de
mayo y las funciones que ofrece el propio calendario para mostrar otras vistas (mensual,
semanal, diaria o modo agenda). Desde esta vista tenemos una perspectiva global de todas
las reservas y, además, es desde dónde podemos crear nuevas reservas, modificar y
cancelar. Veamos un ejemplo de modificación.
Figura 39: Agenda empresa. Modificación reserva
La figura 39 muestra la interfaz cuando hemos clicado sobre una de las reservas del
calendario. Podemos ver los valores de esta reserva y haríamos el cambio necesario.
Figura 40: Reserva modificada
Finalmente, como muestra la figura 40 aparecería un pop-up con el resultado de la

operación, en este caso exitosa.
Página | 66
Ahora vamos a pasar al lado de los clientes para ver algunas de sus funcionalidades:
1. Búsqueda de empresas
Figura 41: Home clientes
La figura 41 muestra el home de los clientes. Se trata de un buscador con cuatro campos
opcionales, podemos buscar según lo que queramos. Al entrar se mostrarán todas las
empresas disponibles con una paginación en la parte inferior. Podemos, por ejemplo,
buscar todas las peluquerías que estén cerca de Aspe y tengan hueco para el día
15/07/2022.
Figura 42: Home cliente. Búsqueda
Página | 67
Como vemos, la figura 42 muestra los resultados del ejemplo, en este caso sólo existen
tres empresas que cumplan los requisitos: ser una peluquería; estar a menos de 30
kilómetros de Aspe; tener un hueco el día 15/07/2022.
2. Consultar información de empresas
Figura 43: Detalles empresa
Al clicar sobre una de las empresas, veríamos su página. La figura 43 muestra la página
de la barbería Rapiño, donde vemos sus valoraciones (una vista general y en la parte
inferior todas ellas con paginación), su información con todos los servicios que ofrece y
desde aquí, podemos crear una review o hacer nuestra reserva.
3. Opinar
Página | 68
Figura 44: Crear review
En la figura 44 vemos el pop-up para crear una review. Como sabemos, sólo podemos
hacer una review a cada empresa, por lo que sólo podríamos editarla o eliminarla.
4. Reservar
El proceso para reservar es muy similar al que hacen las empresas, tal y como se muestra
en las figuras 38 y 39, seleccionan un día e introducen los datos.
Página | 69
8. Conclusiones
Tras mucho trabajo podemos decir que ya estamos llegando al final. En esta última
sección resumiremos todo el contenido del documento, resaltaremos las ideas principales
y al final, antes de acabar, me gustaría comentar mis últimos pensamientos. Hablaré sobre
qué mejoras podríamos hacer a la aplicación, diferentes usos que hasta ahora no hemos
nombrado y funcionalidades que por desgracia han quedado en el tintero.
8.1. Leitmotiv. Ventajas y desventajas

Como venimos diciendo desde el principio, el pilar fundamental sobre el que hemos
querido construir el sistema siempre han sido las empresas. Nuestra aplicación busca dar
valor a todas aquellas personas dueñas de empresas que buscan mejorar sus números y
hacer crecer su negocio. Queremos aportar algo diferente, y hemos apostado por
ofrecerles un panel de control dónde puedan ver una serie de gráficas y estadísticas que
trabajen con sus datos. Además, esta idea no termina ahí, también hemos construido una
plataforma donde permitimos que los negocios compartan sus datos para así manejar una
cantidad aún mayor y ponerlos en común. De esta manera podemos establecer relaciones
entre aquellos negocios del mismo sector, aquellos que cubren la misma zona geográfica,
e incluso cómo se dividen los clientes y su comportamiento a la hora de elegir su comercio
favorito.
Esta idea es la principal virtud del sistema y la que lo hace resaltar sobre las alternativas
existentes. La aplicación es muy sencilla de utilizar e intuitiva, guiada por el objetivo de
hacer reservas, los clientes en tan sólo 5 clicks pueden llegar a reservar y los negocios
cuentan con una interfaz basada en una agenda muy avanzada y un panel de control para
las estadísticas muy completo y útil.
Como desventajas del sistema tenemos el reducido número de funciones que tienen los
clientes. Sólo pueden ver sus reservas, buscar servicios, consultar empresas y reservar.
Siento que falta algo para fidelizar a los clientes y conseguir que esta aplicación se
convierta en una herramienta de su día a día. Quizá un sistema de puntos con los que
conseguir descuentos, funciones para programar reservas, notificaciones cuando se
acerque la fecha de la reserva o haya una cancelación…
Página | 70
En definitiva, se trata de potenciar esta parte, ya que ha podido quedar un tanto escasa.
8.2. Próximas versiones

¿Hemos dejado algo que consideremos importante fuera de la implementación? Por un
lado, pienso que sí, pero por otro, la realidad es que considero que son funcionalidades
que van un paso más allá de la idea inicial que creamos de la aplicación.
Una de estas funcionalidades es la pasarela de pago. Esta funcionalidad sí que la

contemplamos al inicio del proyecto, pero por falta de tiempo decidimos dejarla fuera. El
motivo por el que pienso que no afecta a los propósitos del sistema es porque podemos
lograr todos los objetivos que teníamos programados. Tenemos una aplicación que aporta
valor a los negocios y su principal función es hacer reservas. De todos modos, la pasarela
de pago iba a ser una imitación del proceso, sin consultar con ningún banco, así que queda
por desarrollar completamente el día que queramos expandir el sistema.
Por otro lado, está el perfil de administrador, idea que no surgió hasta momentos
avanzados del desarrollo, en los que ya no quedaba tiempo suficiente para desarrollar.
Este perfil hubiera sido realmente útil y, para ser sinceros, sí que puede llegar a afectar la
experiencia con la aplicación. Podría ser el encargado de bloquear usuarios, crear nuevas
categorías de negocios e incluso eliminar reviews. En definitiva, gestionar el sistema.
Considero que debería ser lo primero a expandir por el valor que trae consigo.
En esta sección estamos hablando de cosas que se podrían mejorar con respecto a lo que
hemos hecho o teníamos pensado hacer. La tercera y última cosa que quiero resaltar es la
apariencia de la web. No he quedado realmente feliz con el resultado en cuanto a
apariencia se refiere. Para nada es fea ni estoy descontento, tan sólo es el no haber sido
capaz de proyectar la asombrosa imagen mental que tenía. Me he dado cuenta de mis
limitaciones con HTML, CSS y Bootstrap. He perdido mucho tiempo tan sólo para alinear
elementos y he sido incapaz de hacer determinadas cosas.
Página | 71
8.3. Un paso más allá
Quizá ese sea el paso que determine el grado de éxito, y yo desde luego que estoy
dispuesto a darlo. Como siempre, valoramos las cosas y vemos el verdadero potencial de
algo cuando estamos inmersos en ello, cuando ya hemos recorrido una parte del camino.
A mí me ha sucedido exactamente eso. Como he comentado en secciones anteriores, ya

había intentado construir y llevar a cabo esta idea, pero no había terminado de fraguar. Es
ahora cuando he desarrollado una buena parte de ella cuando me he dado cuenta de todo
lo que se puede llegar a hacer y de su valor. Por eso en esta sección me gustaría hablar
sobre todos los posibles usos que todavía no hemos visto y hacer una pequeña reflexión.
Ciertamente, cada uno de nosotros vive su vida de una manera diferente, y por ello yo
sólo puedo explicar mi punto de vista. Desde mi perspectiva, puedo decir que a lo largo
de mi vida he hecho numerosas reservas, y me quedan todavía más. Hemos hecho mucho
hincapié en las peluquerías porque son el ejemplo más cotidiano, pero podemos ir más
allá. Este sistema podría ser perfectamente un estándar en el mundo de las reservas. Un
sistema donde se pudiera reservar pista de pádel en un polideportivo, mesa en un
restaurante, butaca en un cine, cita en un estudio de tatuaje, despachos de abogados,
consultas de psicólogos, comisarías, ayuntamientos…
Puede ser tan potente como queramos y, tomando una idea muy general, se puede llegar
a construir un sistema que satisfaga las expectativas en todas esas situaciones.
Comparemos el ejemplo del cine con el de las peluquerías, que ya somos expertos. Un
cine puede tener varias salas. Esto sería lo mismo que una peluquería en la que trabaja
más de un peluquero. Además, cada sala tiene un número determinado de butacas, opción
que se puede adaptar estableciendo un número de personas por servicio. En la peluquería
será uno, pero en el cine será el número de butacas. El cine ofrece películas, mientras que
la peluquería ofrece cortes de pelo. Un polideportivo tiene muchas pistas, sólo puede
reservar la pista una persona, sus servicios serán los deportes de cada pista. Una comisaría
tiene muchos departamentos, pueden reservar a la vez tantas personas como trabajadores
de ese departamento haya y sus servicios serán los diferentes procesos.
Página | 72
Todo se puede vincular, y, tras todos estos meses trabajando en este proyecto, he llegado
a la conclusión de que se puede construir una aplicación estándar que reúna lo principal
de cada nicho.
Esta es una pequeña síntesis de este paso tan importante del que hablamos:
• Permitir tener más de un recurso: varios peluqueros.

• Permitir modificar el número de clientes por servicio: 80 personas pueden reservar
butaca para la película de Batman.
• Permitir solapamientos: más de una reserva a la vez si tenemos más recursos.
• Permitir un inicio de sesión general: vista global del negocio.
• Permitir varios inicios de sesión secundarios: uno por cada recurso.
• División de agendas por recursos: departamento de DNIs, denuncias…
Con esto me gustaría llamar a la reflexión individual de cada uno, para que penséis en
aquellas reservas que este sistema podría haber facilitado y en la importancia de tener una
plataforma que agrupe en un mismo lugar una gran cantidad de negocios y servicios que
la sociedad consume.
Por supuesto, esto es un proyecto totalmente diferente al que hemos presentado y

desarrollado en este documento. Son palabras mayores y conlleva muchísimo esfuerzo,
pero no quería terminar sin dejar escritos todos mis pensamientos, ideas y futuros trabajos.
Para finalizar, he de decir que me siento muy orgulloso del trabajo realizado, agradecido
de los obstáculos que sobrepasé por enseñarme los trucos para hacerlo de nuevo y feliz
por ver todo lo que he aprendido a lo largo de este tiempo.
Espero haber explicado correctamente cada uno de los temas tratados, espero haber
logrado mostrar todos mis pensamientos durante el proceso, que os haya parecido
interesante el proyecto y, lo más valioso para mí, que os haya gustado.
Un placer.
Página | 73
Referencias
[1]. Sommerville, Ian, 2011. Ingeniería de software. Pearson educación, Novena edición.
Capítulo 4: Ingeniería de requerimientos.
https://sistemamid.com/panel/uploads/biblioteca/2018-06-11_03-37-12144643.pdf
[2]. Jonas Sunico. 30 Astonishing Website Design Industry Statistics for 2022.
https://websitebuilder.org/blog/website-design-industry-statistics/
[3]. Modelo Vista Controlador (MVC)

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-
mvc.html#:~:text=Modelo%20Vista%20Controlador%20(MVC)%20es,control%20en%2
0tres%20componentes%20distintos.
[4]. Eddie Meardon. ¿Qué es un diagrama de Gantt?

https://www.atlassian.com/es/agile/project-management/gantt-chart
Página | 74

Aplicacion para La Reserva de Citas Online Centrada en Alberola Torres Jose

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Aplicacion para La Reserva de Citas Online Centrada en Alberola Torres Jose

Cargado por

Copyright:

Formatos disponibles

Grado en Ingeniería Informática

Trabajo Fin de Grado

Gracias de corazón a todos.

Lado del cliente:

• Consultar la agenda de los negocios: los clientes podrán consultar la información

Lado del negocio:

Figura 1: Dibujo situación cliente

De la misma manera, veamos el flujo de una empresa reflejado en la figura 2.

Figura 2: Dibujo situación empresa

La situación inicial siempre es la misma, se quiere lograr un objetivo. La figura 2 muestra

Como vemos, este negocio buscaba maneras de optimizar su trabajo y de mejorar. El

Como dijo Henry Ford:

2.1. Objetivos principales

2.2. Objetivos secundarios

Estos objetivos son:

• Analizar el mercado y detectar innovaciones: si queremos diferenciarnos debemos

Comenzaré contando cómo fue el inicio de este proyecto en el ámbito de la planificación.

Después de estar trabajando de esa manera, me di cuenta de lo importante que era

Finalmente, a día de hoy, la instantánea de mi tablero se puede ver en la figura 3.

Figura 3: Tablero Trello

Se trata simplemente de un tablero con cuatro columnas. La primera es el “Backlog”,

Personalmente, he experimentado problemas de falta de tiempo y cargas de trabajo que

En cuanto al desarrollo, decidimos comenzar por la parte de las empresas, construyendo

Un diagrama de Gantt es una herramienta de gestión de proyectos en la que se recoge la

Para finalizar, la figura 6 muestra el diagrama de Gantt al completo.

La definición de dicho sistema se realiza mediante lo que se conoce como una

• Independencia del diseño: no deben indicar cómo debe implementarse el sistema.

A la hora de anotar todos los requisitos se les suele asignar:

• Identificación: identificador único para evitar confusiones y distinguir

4.1. Requisitos funcionales

Requisitos funcionales. Sistema

El sistema debe permitir dos tipos diferentes de usuarios

RF.S.3 El sistema debe almacenar las contraseñas encriptadas. Alta

El sistema debe tener un buscador de servicios avanzado por

RF.S.6 La aplicación web debe ser responsive. Media

Los negocios deben de poder decidir si desean compartir su

RF.N.4 Los negocios deben poder establecer su horario de trabajo. Alta

Los negocios deben poder consultar y modificar sus datos

RF.N.10 Los negocios deben poder subir imágenes a su perfil. Baja

Requisitos funcionales. Usuarios

Los usuarios deben poder ver el horario de un negocio y hacer

RF.U.2 Los usuarios podrán cancelar reservas. Alta

Los usuarios deben poder consultar y actualizar sus datos

RF.U.4 Los usuarios podrán ver un listado de sus reservas. Media

4.2. Requisitos no funcionales

• Fiabilidad: característica fundamental de los sistemas informáticos por la que se

1. Requerimientos del producto. Estos requerimientos especifican o restringen el

2. Requerimientos de la organización. Son requerimientos derivados de políticas y

3. Requerimientos externos. Esta categoría cubre todos los requerimientos fruto de

Requisitos no funcionales. Producto

El sistema debe ser fácil de usar y de acceder para cualquier

Requisitos no funcionales. Organizacionales

El producto debe ser una aplicación web desarrollada en

RNF.O.2 El sistema debe de ser fácil de mantener. Alta

La base de datos con toda la información debe de estar

Requisitos no funcionales. Externos

Cada tipo de usuario debe poder acceder sólo a su zona de

4.3. Casos de uso

Figura 8: Caso de uso proceso de reserva

Para evitar hacer un esquema excesivamente complejo, hemos simplificado opciones

Esto nos lleva a la necesidad de implantar tecnología en campos o experiencias de usuario

- Peluquero: ¿Qué día te va bien?

Figura 10: Web Booksy