ESTUDIO Y DESARROLLO DE UN PROTOTIPO DE APLICACIÓN...
Transcript of ESTUDIO Y DESARROLLO DE UN PROTOTIPO DE APLICACIÓN...
Universidad de Jaén
Escuela Politécnica Superior de Jaén
Trabajo Fin de Grado
ESTUDIO Y DESARROLLO DE
UN PROTOTIPO DE
APLICACIÓN WEB PARA LA
GESTIÓN DE COMANDAS EN
UN ESTABLECIMIENTO DE
HOSTELERÍA
Alumno: José Jiménez De la Paz
Tutor: Prof. D. José Ramón Balsas Almagro Dpto: Informática
Junio, 2018
Escu
ela
Polit
écn
ica S
up
eri
or
de J
aé
n
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 2
Universidad de Jaén
ESCUELA POLITÉCNICA SUPERIOR DE JAÉN
DEPARTAMENTO DE INFORMÁTICA
Don JOSÉ RAMÓN BALSAS ALMAGRO, tutor del Trabajo Fin de Grado titulado: ESTUDIO Y DESARROLLO DE UN PROTOTIPO WEB PARA LA GESTIÓN DE COMANDAS EN UN ESTABLECIMIENTO DE HOSTELERÍA, que presenta JOSÉ JIMÉNEZ DE LA PAZ, autoriza su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.
Jaén, junio de 2018
El alumno: Los tutores:
José Jiménez De la Paz José Ramón Balsas Almagro
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 3
Escuela Politécnica Superior de Jaén ............................................................................ 1
Grado en Ingeniería Informática .......................................................................................... 1
1. INTRODUCCIÓN. ................................................................................................. 9
1.1. Introducción al proyecto. ................................................................................ 9
1.2. Motivación ................................................................................................... 10
1.3. Objetivo ....................................................................................................... 11
Objetivos específicos ............................................................................................ 11
1.4. Metodologías ................................................................................................ 11
Diferencias entre metodología tradicional y metodología ágil. ................................... 13
SCRUM .............................................................................................................. 14
1.5. Estructura del documento ............................................................................ 16
2. ANÁLISIS. .......................................................................................................... 18
2.1. Análisis preliminar .......................................................................................... 18
Estado del arte ...................................................................................................... 21
2.2. Propuesta de solución....................................................................................... 23
2.3. Historias de usuario ......................................................................................... 24
2.4. Criterios de satisfacción ................................................................................... 26
2.5. Planificación temporal ..................................................................................... 29
Estimación de las historias de usuario y definición de las tareas. ................................ 29
Priorización de las historias de usuario .................................................................... 32
Estimación de velocidad ........................................................................................ 34
Evolución de las estimaciones ................................................................................ 36
2.6. Estudio de viabilidad........................................................................................ 38
2.7. Modelo de dominio........................................................................................... 40
3. DISEÑO .............................................................................................................. 41
3.1. Diagrama de Entidad-Relación ..................................................................... 41
3.2. Diagrama de clases ....................................................................................... 43
Aplicación Cliente ................................................................................................ 43
Aplicación Servidor .............................................................................................. 47
3.3. Diagramas de secuencia ................................................................................ 48
3.4. Diseño de la interfaz ..................................................................................... 56
4. IMPLEMENTACIÓN ........................................................................................... 67
4.1. Arquitectura de la aplicación ........................................................................ 67
4.2. Detalles sobre la implementación .................................................................. 69
Aplicación Cliente ................................................................................................ 69
Aplicación Servidor .............................................................................................. 74
5. PRUEBAS .......................................................................................................... 81
6. CONCLUSIONES ................................................................................................ 82
6.1. Trabajos futuros .......................................................................................... 83
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 4
7. BIBLIOGRAFÍA .................................................................................................. 85
APÉNDICE I: MANUAL DE INSTALACIÓN DEL SISTEMA ...................................... 88
APÉNDICE II: MANUAL DE USUARIO .................................................................... 89
APÉNDICE III: MANUAL DE CONTENIDOS SUMINISTRADOS ............................ 101
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 5
Índice de ilustraciones
Ilustración 1 Proceso tradicional ............................................................................... 13
Ilustración 2 Proceso ágil.......................................................................................... 13
Ilustración 4 Enfoque ágil ......................................................................................... 13
Ilustración 3 Enfoque tradicional ............................................................................... 13
Ilustración 5 Costo del cambio .................................................................................. 14
Ilustración 6 Ciclo de trabajo SCRUM ...................................................................... 15
Ilustración 7 Sistema actual de anotación de comandas .......................................... 18
Ilustración 8 Aplicación nativa, híbrida o web ........................................................... 19
Ilustración 9 Capturas de MyOrder https://goo.gl/qAJiQd ......................................... 21
Ilustración 10 Captura de Mr Noow https://goo.gl/j2HEQG....................................... 22
Ilustración 11 Historias de usuario ............................................................................ 26
Ilustración 12 Criterios de satisfacción ..................................................................... 28
Ilustración 13 Tareas y estimación de las historias .................................................. 32
Ilustración 14 Prioridad Must .................................................................................... 33
Ilustración 15 Prioridad Should ................................................................................. 33
Ilustración 16 Prioridad Could ................................................................................... 34
Ilustración 17 Prioridad Would not ............................................................................ 34
Ilustración 18 Planificación 1 de los Sprints ............................................................. 35
Ilustración 19 Planificación 2 de los Sprints ............................................................. 37
Ilustración 20 Gráfico Burn Down ............................................................................. 37
Ilustración 21 Coste Herramientas Software ............................................................ 38
Ilustración 22 Coste Herramientas Hardware ........................................................... 38
Ilustración 23 Modelo del dominio ............................................................................ 40
Ilustración 24 Esquema comunicación con BD ......................................................... 41
Ilustración 25 Diagrama de BD ................................................................................. 42
Ilustración 26 Tablas creadas por JPA ..................................................................... 43
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 6
Ilustración 27 Esquema MVVM https://goo.gl/C2nRiC ............................................. 44
Ilustración 28 Diagrama de clases Cliente ............................................................... 45
Ilustración 29 Diagrama de clases lado del cliente, rol de camarero y cocinero....... 46
Ilustración 30 Diagrama de clases servidor .............................................................. 47
Ilustración 31 Diagrama de secuencia seguridad ..................................................... 48
Ilustración 32 Diagrama de secuencia login ............................................................. 49
Ilustración 33 Diagrama de secuencia login servidor ............................................... 50
Ilustración 34 Diagrama de secuencia registro cliente ............................................. 51
Ilustración 35 Diagrama de secuencia registro servidor ........................................... 52
Ilustración 36 Diagrama de secuencia realizar pedido ............................................. 53
Ilustración 37 Diagrama de secuencia realizar pedido en servidor ........................... 54
Ilustración 38 Diagrama de secuencia pagar cliente cliente ..................................... 55
Ilustración 39 Diagrama de secuencia pagar la cuenta servidor .............................. 55
Ilustración 40 Diagrama de estados del cliente ........................................................ 57
Ilustración 41 Interfaz de identificación ..................................................................... 58
Ilustración 42 Interfaz cuenta .................................................................................... 59
Ilustración 43 Interfaz categoría ............................................................................... 60
Ilustración 44 Interfaz producto ................................................................................ 61
Ilustración 45 Interfaz historial .................................................................................. 62
Ilustración 46 Interfaz buscar .................................................................................... 63
Ilustración 47 Interfaz carrito .................................................................................... 64
Ilustración 48 Interfaces enlazar y cobrar ................................................................. 65
Ilustración 49 Interfaz cocinero ................................................................................. 66
Ilustración 50 Diagrama cliente-servidor .................................................................. 67
Ilustración 51 Diagrama arquitectónico del sistema ................................................. 68
Ilustración 52 Ionic Workflow https://goo.gl/JoR6aE ................................................. 69
Ilustración 52 Estructura ionic ................................................................................... 70
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 7
Ilustración 54 Vista enlazar.html ............................................................................... 71
Ilustración 55 Controlador enlazar.ts ........................................................................ 71
Ilustración 56 Generar app en distintas plataformas ................................................ 72
Ilustración 57 Ejemplo petición get ........................................................................... 73
Ilustración 58 Local Storage ..................................................................................... 74
Ilustración 59 GIT servidor........................................................................................ 75
Ilustración 60 Etiquetas JPA ..................................................................................... 76
Ilustración 61 Pedido DAO ....................................................................................... 76
Ilustración 62 Tabla end-points ................................................................................. 78
Ilustración 63 Creación de token .............................................................................. 79
Ilustración 64 Comprobación token en cada petición ............................................... 80
Ilustración 65 Server Side Events ............................................................................. 80
Ilustración 63 Vista registro ...................................................................................... 89
Ilustración 67 Vista login ........................................................................................... 89
Ilustración 69 Vista categorías .................................................................................. 90
Ilustración 65 Vista productos ................................................................................... 90
Ilustración 67 Vista producto 2 ................................................................................. 91
Ilustración 71 Vista producto .................................................................................... 91
Ilustración 69 Vista carrito ........................................................................................ 92
Ilustración 73 Vista categorías con carrito ................................................................ 92
Ilustración 71 Pedido con éxito ................................................................................. 93
Ilustración 75 Confirmación pedido .......................................................................... 93
Ilustración 73 Confirmación pagar ............................................................................ 94
Ilustración 77 Vista de cuenta ................................................................................... 94
Ilustración 78 Vista buscador .................................................................................... 95
Ilustración 79 Vista historial de pedidos ................................................................... 96
Ilustración 77 Vista enlazar éxito .............................................................................. 97
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 8
Ilustración 81 Vista enlazar 1 .................................................................................... 97
Ilustración 79 Vista servir eliminar ............................................................................ 98
Ilustración 83 Vista servir 1....................................................................................... 98
Ilustración 84 Vista cobrar ........................................................................................ 99
Ilustración 85 Vista cocinero ................................................................................... 100
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 9
1.1. Introducción al proyecto.
Para finalizar la carrera de ingeniería informática he decidido basar mi trabajo fin de
grado en la realización de una aplicación móvil para pedir la comanda en un restaurante.
Este tipo de aplicación va a automatizar la forma de dar servicio a los clientes del
restaurante añadiendo una mejor comunicación con la cocina y los camareros. A través de
ella estarán "conectados" los clientes, camareros y cocineros para que la relación cliente-
restaurante sea automática y reduciendo tiempos de espera.
La idea es que el cliente desde su mesa y con su móvil, ya sea con un sistema operativo
Android o Apple iOS, se conectará con su cuenta a la aplicación y podrá acceder a los
distintos menús.
El cliente puede consultar la carta de productos, ordenada por categoría (ensaladas,
carnes, bebidas, etc.) ir añadiendo al carrito los productos que desee tomar y, finalmente,
hacer el pedido. También desde el móvil puede ver la cuenta total hasta el momento de
pagar, los pedidos que ha realizado en ese momento, un historial de pedidos y un
buscador de productos.
El camarero también tendría un dispositivo móvil donde puede ver el estado de los
pedidos de las mesas para avisarle si tiene que llevar algún pedido o cobrarles.
Por otra parte, el cocinero tendrá acceso a la aplicación desde la cocina para ver el estado
de los pedidos, ordenados por orden de entrada. El cocinero una vez que haya preparado
el pedido lo marcará como preparado para que el camarero lo entregue a los clientes.
Con esta aplicación los camareros del restaurante seguirían en sus puestos de trabajo,
aunque cambiando un poco sus tareas a desempeñar. Además, los clientes que sean más
reacios al uso de tecnología, el método tradicional de que el camarero apunte las
comandas en la libreta podrá convivir con la aplicación.
Esta digitalización de la comunicación cliente-restaurante facilita al restaurante la
promoción de sus productos, ofertas e incluso hacer un sistema de puntos para premiar a
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 10
sus mejores clientes, que en definitiva contribuirá a mejorar la experiencia de usuario del
cliente.
1.2. Motivación
Pedir la comanda en un restaurante desde el teléfono móvil, en la actualidad, no sería
algo extraño. Según una noticia, España es el 5º país del mundo que más tiempo pasa con
el teléfono. [1].
Además, supondría una serie de ventajas como automatizar los pedidos aportando un
toque moderno y agilizando los tiempos de comunicación cliente-camarero-cocina, o la
novedad para los clientes de usar su propio móvil para pedir su comanda.
En el año 2017 por primera vez los móviles superaron a los ordenadores como medio más
habitual de acceso a internet [1], esto conlleva un gran aumento en la industria del móvil,
además de que en los últimos 5 años ha aumenta el uso de "smartphones" en España,
siendo el porcentaje de españoles con móvil de 81% según una noticia de cadena ser [2].
Por otro lado, existe un gran mercado de teléfonos móviles con sus respectivos sistemas
operativos, entre lo que destacan: Android e iOS, entre otros. Esta diversidad de sistemas
operativos provoca desarrollos específicos dedicados para cada uno, y esto hay que
tenerlo en cuenta si se quiere hace una aplicación para ser compatible con el mayor
número de SO.
Una aplicación móvil híbrida multiplataforma, tiene como ventaja realizar un solo
desarrollo de la aplicación y generar la aplicación con compatibilidad con distintos
sistemas operativos. Por ello se decidió basar la aplicación en un framework que nos
permitiera esto.
A partir de estas ideas, se contactó con un Restaurante que pudiera servir como cliente y
permitiera obtener de primera mano los requisitos reales de la aplicación. En la reunión
con la dueña del restaurante se explicaron estas noticias y las ventajas de usar esta
aplicación en su restaurante. Finalmente, su confirmación, me permitió basar mi trabajo
fin de grado en el desarrollo de dicha aplicación. El nombre que se decidió para la
aplicación fue "TuComanda".
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 11
La realización de este proyecto me permite poner en práctica los conocimientos
aprendidos en las asignaturas de la carrera. De cómo asignaturas que aparentemente no
tenían relación como: Desarrollo ágil, Desarrollo de aplicaciones web, Desarrollo de
aplicaciones empresariales, Estructura de datos, Base de datos… etc componen entre
todas la aplicación. Cada una desde su ámbito, pero con la misma importancia que las
demás, formando así la aplicación y metodologías a seguir. Además de dar la oportunidad
de aplicar los conocimientos a un caso real y que verdaderamente ayuda a las personas o
al negocio.
1.3. Objetivo
El objetivo principal del proyecto es realizar una app móvil que sea compatible para los 2
sistemas operativos de móvil más usados en la actualidad, Android o Apple iOS, y sea
capaz de pedir la comanda en un restaurante. Se realizará con el Framework Ionic que
está basado en Angular JS y el servidor con Spring Boot. El uso de estos lenguajes
punteros me permitirá en el futuro tener experiencia y poder acceder con más
conocimientos en el mundo laboral.
El proyecto implicará un estudio previo de soluciones existentes, además de análisis,
diseño e implementación del proyecto.
Objetivos específicos
De forma detallada, para la realización del presente TFG se establecieron los siguientes
objetivos, cuyo alcance y consecución se presenta a lo largo de esta memoria:
Realizar un estudio de necesidades y soluciones existentes en el contexto
seleccionado.
Diseñar un sistema informático especialmente orientado a la utilización de
arquitecturas, principios de diseño y metodologías de desarrollo web.
Seleccionar un entorno de desarrollo web e implementar un prototipo de
aplicación web que satisfaga las necesidades que se hayan determinado.
1.4. Metodologías
Para el desarrollo del trabajo, se decidió seguir una metodología ágil para dar un papel
importante al cliente durante las estepas del proceso, ir entregando el producto en
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 12
intervalos para que el producto final sea una suma de entregables que nos proporcione un
mejor seguimiento, y conocer realmente cuales son las tareas innecesarias para poder
centralizar los esfuerzos en las verdaderamente importantes. Se comentan a continuación
algunas ideas sobre este tipo de metodologías.
Kent Beck y otros expertos en la industria del software se reunieron Utah, EEUU en 2001
[3]. Firmaron el 'Manifiesto por el desarrollo ágil del software' [4], en el que destacaron
los siguientes principios:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio, mejor que acogerse a un plan.
Dando importancia a los elementos de la derecha, aunque con más importancia aún a los
de la izquierda, surgió un nuevo paradigma.
Principios derivados del manifiesto [5]:
Satisfacción del cliente como prioridad, mediante entregas frecuentes y en etapas
tempranas.
Los cambios son bienvenidos, aun en una etapa avanzada del desarrollo.
Entrega frecuente de software que funcione, de 2 semanas a un par de meses lo
más pronto que se pueda.
El personal de la empresa y los desarrolladores deben trabajar juntos y mejorar la
comunicación.
Motivación del equipo, con los trabajadores motivados se aumentará la
productividad.
Comunicación cara a cara como método de comunicación con los integrantes del
equipo principal.
El software que funciona es la mejor medida de progreso.
Ritmo de desarrollo sostenible, máximo 40 horas semanales.
Atención continua a la calidad técnica y al buen diseño.
Maximizar el trabajo no hecho, no desarrollar más de lo acordado.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 13
Equipos auto-organizados, mantener los equipos de un proyecto a otro.
Autoevaluación, el equipo se reúne regularmente para hacer autocrítica y plantear
posibles mejoras.
Diferencias entre metodología tradicional y metodología ágil.
El proceso ágil sigue haciendo las mismas actividades del proceso de desarrollo de
software, aunque difiere en la forma de hacerlo. [6]
Como se observa en las ilustraciones 1 y 2 se puede observar que las fases de desarrollo
en el proceso ágil son las mismas, pero varía en la forma de hacerlo.
Ilustración 2 Proceso ágil
Pero, aunque tengan las mismas actividades tiene una consecuencia importante a la hora
de realizar el proyecto. En el enfoque tradicional se fijan los requisitos y a partir de ellos
se estiman el tiempo y coste para poder cumplir los requisitos. Sin embargo, con el
enfoque ágil se fijan el tiempo y el coste y a partir de estos dos valores se estima los
requisitos [5]. Como se observa en las ilustraciones 3 y 4.
Tiempo
Coste
Requisitos
Estimado
Fijo
Estimado
Tiempo
Coste
Requisitos
Fijo
Ilustración 4 Enfoque tradicional
Ilustración 1 Proceso tradicional
Ilustración 3 Enfoque ágil
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 14
El enfoque ágil "suaviza" el costo de cambio (véase la Ilustración 6) consiguiendo la
satisfacción de los clientes. El proceso ágil contempla la entrega incremental además de
pruebas unitarias continuas, disminuyendo el coste de cambios.
Ilustración 5 Costo del cambio
Finalmente debido a que el proyecto tiene una alta probabilidad de que tenga requisitos
cambiantes, predispuestos al cambio y modificaciones, y con un desarrollo que se adapte
a las necesidades del cliente he decidido usar una metodología ágil. Además de que el
cliente obtenga regularmente pequeñas versiones del proyecto es uno de los motivos que
me ha hecho decidirme a este tipo de metodología. Concretamente la metodología elegida
es SCRUM.
SCRUM
SCRUM es un proceso ágil adaptable, iterativo, rápido, flexible y eficaz que está
diseñado para entregar valor al cliente durante el desarrollo del proyecto. [7]
SCRUM usa patrones de desarrollo que son eficaces para proyecto con plazos de entrega
cortos y requisitos cambiantes. Con intervalos de 2 o 4 semanas se puede ver el software
funcionando y decidir si seguir mejorándolo o entregarlo.
El objetivo principal es satisfacer las necesidades del cliente, favoreciendo la
comunicación con el cliente y el equipo de desarrolladores.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 15
Ciclo de trabajo en SCRUM:
Ilustración 6 Ciclo de trabajo SCRUM
1. Toma de requisitos al cliente, para cada requisito principal se crea una historia
de usuario.
2. El cliente ordena la lista priorizada del producto (backlog), que contiene la lista
de los requisitos en orden de prioridad para el negocio en forma de historias de
usuario.
3. El equipo de trabajo toma un grupo de historias del backlog y las incluyen en la
planificación del Sprint divididas en sub tareas más sencillas. El equipo trabaja
en la realización de los entregables durante 2-6 semanas. En el Sprint no se
admiten cambios para que el equipo trabaje de forma estable y a corto plazo.
4. Durante el Sprint se realizan reuniones diarias y se debe responder a 3 preguntas
clave:
a. ¿Qué hiciste ayer?
b. ¿Qué harás hoy?
c. ¿Hay obstáculos en tu camino?
Al final de cada Spring se realiza una reunión de retrospectiva del Spring donde se
analizan los aspectos que mejorar y los problemas ocurridos durante el mismo.
Una vez finalizado el Spring se entrega al cliente el resultado del trabajo y se vuelve al
punto 2 hasta acabar con las historias.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 16
Adaptación de SCRUM al proyecto:
En mi caso, para adaptar esta metodología ágil he tenido que adaptar algunos roles y uso
de reuniones:
Product Owner: sí se mantiene, es el responsable del producto. Define las
funcionalidades principales del producto, estima fechas, prioriza las
funcionalidades, además de evaluar los entregables. Este rol lo adoptaría la
dueña del restaurante.
Scrum Master y Team: El responsable del funcionamiento de SCRUM y
equipo de desarrollo (analista y programador) lo haría individualmente.
Reuniones de equipo: Puesto que yo adoptaré el perfil de equipo, no tiene
sentido hacer las reuniones, aunque sí es útil hacer un seguimiento del
trabajo realizado, anotando los problemas, lo que se hará en el futuro y lo
que hice el día anterior.
1.5. Estructura del documento
El documento se ha organizado de la siguiente forma: en el apartado 2 llamado "Análisis"
se describirá el sistema del que se parte y se verán sus desventajas además de ver otras
aplicaciones similares y la propuesta de solución, incluyendo historias de usuario,
planificación y viabilidad.
En el apartado 3 de diseño se mostrarán los detalles que se han tenido en cuenta a la hora
de organizar la información que gestionará la aplicación, así como la estructura y
funcionamiento del software a desarrollar, para los que se incluyen: el diagrama entidad
relación de la base de datos, el diagrama de clases de la aplicación, diagramas de
secuencia de los aspectos más relevantes y diseño de la interfaz mediante un programa
informático.
En apartado 4 de implementación se detallará la arquitectura de la aplicación y la relación
entre los elementos, además de los detalles sobre la implementación donde se menciona
técnicas y tecnologías empleadas.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 17
Después en el apartado 5 llamado “Pruebas”, se mostrará cómo se ha comprobado el
correcto funcionamiento de la aplicación y si se ha obtenido los resultados esperados.
En el apartado 6 se explica las conclusiones del proyecto y trabajos futuros para ampliar
o mejorar el proyecto.
Finalmente se añaden tres anexos: manual de instalación del sistema, manual de usuario y
manual de contenidos suministrados.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 18
La etapa de análisis debe estar completa antes de pasar al diseño. El análisis proporciona
al diseño toda la información necesaria para crear los modelos del diseño [1].
2.1. Análisis preliminar
Se parte de un sistema para atender las comandas tradicional, que en gran medida cumple
su propósito: trasladar a la cocina los pedidos del cliente, pero se observan grandes
deficiencias.
El proceso tradicional consiste en que los camareros
están atentos a las mesas para ver si alguien nuevo se
sienta.
El cliente se sienta a la mesa y mira la carta, que está
impresa y plastificada en la mesa para ver las cosas
que ofertan. En esta aparece los productos agrupados
en categorías y con el precio de cada producto.
A continuación, el cliente llama al camarero y le
dicta las cosas que desea tomar. Éste apunta en su
libreta, que tiene la estructura tal y como se observa
en la Ilustración 7, anotando: nombre del camarero, la
mesa donde está sentado el cliente, la fecha, la
cantidad del producto, el producto y el precio de cada producto.
Después, el camarero lleva la nota a la cocina y la pega en una pared por orden de
llegada. Se fija en las bebidas y acude a la barra a prepararlas y servirlas.
El cocinero recoge la nota de la pared y comienza a realizar las comandas. Conforme va
finalizando una comanda la deja en una mesa grande a la espera de que el camarero acuda
a la cocina y recoja la comanda. La nota no puede perderse porque ahí está apuntada la
mesa del pedido. De hecho, el camarero cada vez que acude a la cocina y quiere llevarse
una comanda debe mirarla.
Ilustración 7 Sistema actual de anotación de comandas
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 19
Finalmente, cuando el cliente quiere finalizar y pagar su cuenta, debe llamar la atención
al camarero y pedirle la cuenta para que le cobre.
Inconvenientes del proceso tradicional:
Si se quisiera editar la información de un producto se deberían reimprimir todas
las cartas.
Las cartas se deterioran con el paso del tiempo y se deben volver a imprimir.
El camarero debe anotar su nombre, la fecha y la mesa cada vez que atiende a un
cliente, siendo un proceso lento.
A veces no se entiende la caligrafía del camarero.
Es posible que se pierda la nota y no se sepa los productos que había apuntados o
la mesa.
El camarero continuamente debe entrar a la cocina y mirar si hay algún plato
cocinado.
El cliente debe llamar la atención al camarero cada vez que quiera pedir algo.
Como hemos visto anteriormente son numerosos los inconvenientes, sin embargo, con el
nuevo sistema que se propone se solventarían todos ellos.
Hay varias alternativas [8] para hacer una aplicación web para el móvil: aplicación
nativa, aplicación híbrida o una web.
Ilustración 8 Aplicación nativa, híbrida o web
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 20
La principal desventaja de hacer una aplicación nativa es que no sería multiplataforma y
solo nos serviría para el sistema operativo en que se base. Una aplicación nativa sería un
inconveniente para el proyecto.
Basar la aplicación en una web, tendría inconvenientes, como que no nos proporcionaría
una interfaz fluida e intuitiva, no se podría subir a las tiendas de aplicaciones móviles y
tendría poco rendimiento.
Una aplicación híbrida es una combinación de HTML, CSS y JavaScript, que se ejecuta
dentro de un contenedor nativo. Permite usar funcionalidades del dispositivo como el
GPS o la cámara entre otras.
Además, una aplicación híbrida proporciona una interfaz fluida e intuitiva,
multiplataforma, posibilidad de subir la aplicación a las tiendas de aplicaciones móviles
entre otras ventajas.
Una vez realizada la comparación con las tres opciones, nos hemos decantado por realizar
una aplicación híbrida. Puesto que sus características son ideales para el proyecto.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 21
Estado del arte
A continuación, se comentarán algunas aplicaciones similares a la que vamos a
desarrollar para pedir la comanda desde el móvil. Esto servirá para coger ideas para
nuestra aplicación y evitar los posibles fallos.
My Order1
Ilustración 9 Capturas de MyOrder https://goo.gl/qAJiQd
Esta es una aplicación para pedir la comanda desde el móvil, puedes navegar en la carta y
pedir los productos que desees, además puedes añadir notas en los productos.
Ventajas:
Se puede añadir notas a los productos.
Disponible en Android y Apple iOS.
Tiene el sistema de carrito para pedir los productos.
Dispone de buscador.
Inconvenientes:
Interfaz poco llamativa.
Actualmente en desuso.
1 https://goo.gl/kPwQoQ
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 22
No tiene sistema de bonificar a los usuarios.
MR. Noow2
Es una aplicación similar a la anterior, pero con más funcionalidades y optimizada. Está
desarrollada por españoles y en Madrid actualmente existen comercios que la utilizan.
Ilustración 10 Captura de Mr Noow https://goo.gl/j2HEQG
Ventajas:
Interfaz muy intuitiva y llamativa.
Dispone de pago virtual.
Encontrar por geolocalización restaurantes cercanos.
Disponible en Android y Apple iOS.
Son pocos los inconvenientes que he podido encontrar, pero por ejemplo añadir notas al
producto a pedir es uno de ellos, creo que es algo muy importante para adaptarte a las
necesidades del cliente.
2 https://www.mrnoow.com/
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 23
2.2. Propuesta de solución
Con este análisis previo, se ha quedado más claro el sistema que se quiere realizar. El
objetivo es hacer un prototipo de una aplicación web móvil híbrida instalable y
multiplataforma.
El sistema estará dividido en dos aplicaciones, la del cliente y la del servidor.
Cliente
El framework elegido para hacer la aplicación web híbrida es Ionic3 que es un SDK
(software development kit) que provee servicios y herramientas para desarrollar
aplicaciones híbridas. Está basado en AngularJS 4 y Apache Cordova5, el objetivo es
simplificar el front-end. Ionic es gratuito, con foro para dudas y un gran manual online
donde explica con ejemplos todo su potencial.
Servidor
El servidor deberá proporcionar una API RESTFUL para la comunicación el cliente
mediante peticiones POST y GET, además de proporcionar un sistema de identificación
por token y acceso cómodo a la base de datos. La mejor opción es utilizar el estándar
JAX-RS de java utilizando Spring Boot6 .
Spring boot es un framework basado en Java, nos permite hacer Servidores de
aplicaciones embebidos (Tomcat, Jetty, Undertow), POMs con dependencias y plug-ins
para Maven, uso extensivo de anotaciones que realizan funciones de configuración,
inyección, etc.
Utilizaremos JPA para mapear las clases de persistencia (que queramos guardar en la
base de datos) haciendo uso de DAOs para acceder a la base de datos. Como base de
datos se utilizará MySQL.
3 https://ionicframework.com/ 4 https://angularjs.org/ 5 https://cordova.apache.org/ 6 https://es.wikipedia.org/wiki/Spring_Framework
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 24
La combinación de Ionic y Spring Boot nos dará una interfaz atractiva para el cliente y
fluida y un servidor estable que proporciona todo lo necesario para el cliente.
2.3. Historias de usuario
Puesto que se ha decidido usar una metodología ágil, concretamente
SCRUM, detallaremos más adelante las historias de usuario, estas se centran en el valor
del cliente con una fuerte intención de fomentar la comunicación. Y obtendremos así los
requisitos.
Las historias de usuario son una forma de obtener los requisitos a partir de la información
obtenida del cliente, mezclando la forma oral y escrita. [9]
Cada historia de usuario es enumerada con un número entero que sirve de identificador,
además tiene criterios de satisfacción. Los criterios de satisfacción describen las acciones
que hay que realizar una vez acabada la historia de usuario para que se válida. Más
adelante se mostrará una tabla con esta información.
Con la ayuda del Product Owner, en este caso es el cliente, he realizado las siguientes
historias de usuario que recoge las funcionalidades principales de la aplicación.
Haré una aclaración de los roles que se usan en las historias de usuario:
Propietario: dueño del restaurante.
Usuarios: clientes del restaurante.
Camarero: camareros contratados del restaurante.
Cocinero: cocinero del restaurante.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 25
ID Título Descripción
1 Registro en el sistema Como propietario del restaurante quiero que los usuarios puedan registrarse en el sistema de forma gratuita introduciendo todos los datos requeridos por el sistema para poder acceder a las funcionalidades del sistema.
2 Identificación en el sistema Como cliente quiero que los usuarios puedan acceder al sistema una vez hayan sido registrados en este.
3 Carta del restaurante Como cliente quiero que los usuarios puedan acceder a la carta del restaurante organizada en categorías, y al seleccionar un producto, podrá ver la información detallada del producto.
4 Añadir producto al carrito Como cliente quiero que los usuarios puedan añadir en el carrito el producto que desee seleccionando la cantidad y dando la opción de añadir notas al producto.
5 Ver carrito Como cliente quiero que los usuarios puedan acceder al carrito y ver los productos seleccionados y finalmente realizar el pedido.
6 Eliminar productos del carrito Como cliente quiero que los usuarios puedan eliminar productos del carrito.
7 Buscador de productos. Como cliente quiero que los usuarios puedan acceder a un buscador de productos y seleccionar la vista del producto detallada.
8 Histórico de pedidos. Como cliente quiero que los usuarios puedan visualizar el histórico de pedidos realizados en el restaurante.
9 Estado de la cuenta Como cliente quiero que los usuarios puedan ver el estado de sus pedidos realizados que están pendientes de pago y una opción para poder llamar al camarero para que le cobre dichos pedidos.
10 Lista del cocinero Como cliente quiero que el cocinero pueda ver la lista de los pedidos en estado de 'pedido', cada producto se detallará la cantidad que introdujo el cliente y el apartado de notas.
11 Producto cocinado Como cliente quiero que el cocinero cuando haya cocinado el producto pueda eliminarlo de su vista para notificar al camarero de que está listo para servir.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 26
12 Enlazar cliente Como cliente quiero que el camarero pueda enlazar al cliente a la mesa en la que está sentado.
13 Servir producto Como cliente quiero que el camarero pueda ver la lista de pedidos listos para servir, que los emite el cocinero y eliminar el pedido una vez servido.
14 Cobrar cliente Como cliente quiero que el camarero pueda seleccionar una mesa y ver los pedidos en estado 'pendiente de pago' para cobrar al cliente y cambiar el estado del pedido a 'pagado'
15 Bonificar con puntos Como cliente quiero que el usuario obtenga puntos para premiarle por sus pedidos. Con estos puntos podrá obtener descuento del precio a pagar.
16 Sistema de gestión Como cliente quiero que el administrador pueda gestionar la carta, cuentas de usuarios, camareros y cocineros.
17 Capturar productos con código Bidi
Como cliente quiero que los usuarios puedan capturar desde su móvil el código Bidi de cada producto desde la carta impresa del restaurante.
Ilustración 11 Historias de usuario
2.4. Criterios de satisfacción
En la siguiente tabla podemos ver los criterios de satisfacción que tiene cada historia de
usuario. Éstos nos indican las acciones a realizar para dar como válida una historia de
usuario. [10]
ID Nombre Criterios de satisfacción
1 Registro en el sistema Introducir datos de registro
incompletos de un nuevo usuario y
comprobar que se indica error.
Introducir todos los datos correctos y
comprobar que ha habido un registro
de un nuevo usuario.
2 Identificación en el sistema Introducir datos de usuario erróneos y comprobar que se da error
Introducir datos de usuario correctos y comprobar que este accede correctamente al sistema.
3 Carta del restaurante Comprobar la correcta navegación entre
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 27
categorías.
4 Añadir producto al carrito Comprobar que el producto con su
cantidad y notas es efectivamente lo
que seleccionamos.
5 Ver carrito Comprobar que se puede acceder al
carrito.
Comprobar que los productos que
tiene el carrito son los añadidos
previamente.
Comprobar que se ha realizado el
pedido del carrito correctamente.
6 Eliminar productos del carrito Comprobar que se pueda eliminar productos del carrito correctamente.
7 Buscador de productos. Comprobar que el buscador muestra productos que contengan en su nombre parte del texto introducido en el buscador.
8 Histórico de pedidos. Comprobar que los pedidos
mostrados en el histórico fueron
realizados por dichos usuarios.
Comprobar que los pedidos
mostrados en el histórico muestren
los productos que se pidieron.
9 Estado de la cuenta Comprobar que los pedidos
mostrados tengan el estado pendiente
de pago.
Comprobar que se envié la
notificación al camarero
correctamente.
10 Lista del cocinero Comprobar que los pedidos mostrados equivalgan con los pedidos por el cliente.
11 Producto cocinado Comprobar que se elimina el producto
de su lista.
Comprobar que se notifica al
camarero que atendió el pedido
correctamente.
12 Enlazar cliente Comprobar que se muestra la lista de
mesas del restaurante.
Comprobar que se pueda buscar al
cliente por su nick.
Comprobar que se produce el enlace
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 28
correctamente mesa-nick.
13 Servir producto Comprobar que se añade en la lista
de productos a servir justo cuando el
cocinero lo marca como listo para
servir.
Comprobar que se pueda eliminar de
la lista.
14 Cobrar cliente Comprobar se muestra la lista de
mesas del restaurante para
seleccionar una.
Comprobar que muestre
correctamente los pedidos de la mesa
seleccionada.
Comprobar que se produce los
cambios de estado del pedido
correctamente.
15 Bonificar con puntos Comprobar que cuando el cliente
paga el pedido, se le da los puntos.
Comprobar que el cliente puede
canjear los puntos por reducir el
precio del pedido.
16 Sistema de gestión Comprobar que el administrador pueda hacer alta/baja/modificación de la carta y las cuentas de usuarios.
17 Capturar productos con código Bidi
Comprobar que al capturar el código Bidi le muestre la ventana del detalle del producto capturado correctamente.
Ilustración 12 Criterios de satisfacción
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 29
2.5. Planificación temporal
En este apartado se hará la planificación temporal para realizar las historias de usuario,
esto conlleva a la estimación, priorización y cálculo de la velocidad.
Estimación de las historias de usuario y definición de las tareas.
A continuación, se estiman las historias de usuario para hacer una idea de la dificultad
que llevaría hacer cada una, he utilizado la serie de Fibonacci: 1,2,3,5,8 cuanto mayor sea
la nota mayor dificultad conlleva realizarla.
En primer lugar, he buscado una historia para que sirva como referencia en la estimación
de las demás, esta historia no es ni la más fácil ni la más difícil: “Estado de la cuenta” con
5 puntos asignados.
En base a esta historia hemos estimado las demás, siendo la más difícil “Producto
cocinado” con 8 puntos, porque se debe reducir en 1 la cantidad del pedido
correspondiente al que pertenece y notificar al camarero que atendió el pedido
inmediatamente.
Cabe destacar que en la tabla siguiente se descompone cada historia de usuario en tareas.
Esta descomposición se debería realizar al sacar la historia de usuario del Backlog.
Además de reflejar las horas de trabajo realizadas con cada perfil.
ID Historia de usuario-Tareas Asignado a
1 Registro en el sistema 3 puntos de historia
1.1 Análisis y diseño de los requisitos Analista- 5 horas
1.2 Implementación en el controlador REST Programador- 5 horas
1.3 Diseño de la vista Programador - 2 hora
1.4 Implementación de la vista Programador- 2 horas
1.4 Pruebas Programador- 3 horas
2 Identificación en el sistema 5 puntos de historia
2.1 Análisis y diseño de los requisitos Analista - 3 horas
2.2 Estudio de Spring Security y token JWT Analista - 5 horas
2.3 Implementación en el controlador REST Programador - 6 horas
2.4 Diseño de la vista Programador - 3 horas
2.5 Implementación de la vista Programador - 2 horas
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 30
2.6 Pruebas Programador - 1 horas
3 Carta del restaurante 3 puntos de historia
3.1 Análisis y diseño de los requisitos Analista - 5 horas
3.2 Implementación en el controlador REST Programador - 3 horas
3.3 Diseño de la vista Programador - 3 hora
3.4 Implementación de la vista Programador - 3 horas
3.5 Pruebas Programador - 8 horas
4 Añadir producto al carrito 5 puntos de historia
4.1 Análisis y diseño de los requisitos Analista – 4 horas
4.2 Estudio de almacenamiento en Storage Analista – 3 horas
4.3 Diseño e implementación de la vista Programador – 10 horas
4.4 Pruebas Programador – 8 horas
5 Ver carrito 3 puntos de historia
5.1 Análisis y diseño de los requisitos Analista – 5 horas
5.2 Diseño e implementación de la vista Programador – 5 horas
5.3 Pruebas Programador – 6 horas
6 Eliminar productos del carrito 1 punto de historia
6.1 Análisis y diseño de los requisitos Analista - 4 horas
6.2 Diseño e implementación de la vista Programador – 8 horas
6.3 Pruebas Programador - 5 horas
7 Buscador de productos 5 puntos de historia
7.1 Análisis y diseño de los requisitos Analista – 7 horas
7.2 Implementación en el controlador REST Programador – 9 horas
7.3 Diseño de la vista Programador – 3 horas
7.4 Implementación de la vista Programador – 3 horas
7.5 Pruebas Programador – 11 horas
8 Histórico de pedidos 2 puntos de historia
8.1 Análisis y diseño de los requisitos Analista – 5 horas
8.2 Implementación en el controlador REST Programador – 2 horas
8.2 Diseño de la vista Programador – 3 horas
8.3 Implementación de la vista Programador – 2 horas
8.4 Pruebas Programador – 5 horas
9 Estado de la cuenta 5 puntos de historia
9.1 Análisis y diseño de los requisitos Analista – 5 horas
9.2 Implementación en el controlador REST Programador – 5 horas
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 31
9.3 Diseño de la vista Programador – 4 horas
9.4 Implementación de la vista Programador – 5 horas
9.5 Pruebas Programador - 15 horas
10 Lista del cocinero 5 puntos de historia
10.1 Análisis y diseño de los requisitos Analista -5 horas
10.2 Estudio de Server Side Events Analista -5 horas
10.3 Implementación en el controlador REST Programador -10 horas
10.4 Diseño de la vista Programador -6 horas
10.5 Implementación de la vista Programador -4 horas
10.6 Pruebas Programador -11 horas
11 Producto cocinado 8 puntos de historia
11.1 Análisis y diseño de los requisitos Analista – 12 horas
11.2 Implementación en el controlador REST Programador – 10 horas
11.3 Diseño de la vista Programador – 5 horas
11.4 Implementación de la vista Programador – 8 horas
11.5 Pruebas Programador - 15 horas
12 Enlazar cliente 2 puntos de historia
12.1 Análisis y diseño de los requisitos Analista - 1 horas
12.2 Implementación en el controlador REST Programador - 4 horas
12.3 Diseño de la vista Programador - 3 horas
12.4 Implementación de la vista Programador – 3 horas
12.5 Pruebas Programador - 2 horas
13 Servir producto 5 puntos de historia
13.1 Análisis y diseño de los requisitos Analista – 5 horas
13.2 Implementación en el controlador REST Programador – 11 horas
13.3 Diseño de la vista Programador – 3 horas
13.4 Implementación de la vista Programador – 3 horas
13.4 Pruebas Programador – 8 horas
14 Cobrar cliente 3 puntos de historia
14.1 Análisis y diseño de los requisitos Analista – 4 horas
14.2 Implementación en el controlador REST Programador – 6 horas
14.3 Diseño de la vista Programador – 2 horas
14.4 Implementación de la vista Programador – 2 horas
14.4 Pruebas Programador – 3 horas
15 Bonificar con puntos 5 puntos de historia
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 32
15.1 Análisis y diseño de los requisitos Analista
15.2 Implementación en el controlador REST Programador
15.3 Diseño de la vista Programador
15.4 Implementación de la vista Programador
15.5 Pruebas Programador
16 Sistema de gestión 5 puntos de historia
16.1 Análisis y diseño de los requisitos Analista
16.2 Implementación en el controlador REST Programador
16.3 Diseño de la vista Programador
16.4 Implementación de la vista Programador
16.5 Pruebas Programador
17 Capturar productos Bidi 5 puntos de historia
16.1 Análisis y diseño de los requisitos Analista
16.2 Implementación en el controlador REST Programador
16.3 Diseño de la vista Programador
16.4 Implementación de la vista Programador
16.5 Pruebas Programador
Ilustración 13 Tareas y estimación de las historias
Priorización de las historias de usuario
La priorización proporciona una ordenación de las historias de usuario según su
importancia en la aplicación. Esto nos ayudará para determinar qué funcionalidades
podrán desarrollarse con los recursos y tiempo con los que se dispongan.
Para priorizar las historias de usuario hemos utilizado el sistema de priorización MoSCow
[11]. Se basa en agrupar las historias de usuarios en grupos llamados: Must, Should,
Should y Would Not. A continuación, se detallará cada grupo y las historias de usuario
que los forman.
En la siguiente tabla se agrupan las historias de usuario del grupo Must, que son los
requisitos que deben tener la solución, son los requisitos mínimos.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 33
Must
ID Nombre Puntos de
historia
1 Registro en el sistema 3
2 Identificación en el
sistema
5
3 Carta del restaurante 3
4 Añadir producto al
carrito
5
9 Estado de la cuenta 5
10 Lista del cocinero 5
11 Producto cocinado 8
12 Enlazar cliente 2
13 Servir producto 5
14 Cobrar cliente 3
Ilustración 14 Prioridad Must
A continuación, se agrupan las historias de usuario del grupo Should, que son los
requisitos que se deberían implementar, pero no son obligatorios necesarios.
Should
I
D
Nombre Puntos de historia
5 Ver carrito 3
6 Eliminar productos del
carrito
1
8 Histórico de pedidos 2
Ilustración 15 Prioridad Should
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 34
Los del grupo Could son requisitos que podrían incluir la solución.
Could
ID Nombre Puntos de historia
7 Buscador de
productos
5
Ilustración 16 Prioridad Could
Finalmente, los del grupo Would not son requisitos son requisitos que en un futuro
podrían hacerse.
Would not
ID Nombre Puntos de
historia
15 Bonificar con puntos 5
16 Capturar productos con
código Bidi
5
17 Sistema de gestión 5
Ilustración 17 Prioridad Would not
Estimación de velocidad
Para calcular la duración de la planificación desde los puntos de historia, se utiliza el
concepto de velocidad, la velocidad es una medida para estimar el avance del equipo de
desarrollo.
Inicialmente se tiene en cuenta las historias de usuario del grupo Would Not a pesar de
que técnicamente los requisitos de este grupo no se tendrían en cuenta.
Por lo tanto, la suma de todos los puntos de historia es: 70 puntos de historia.
La fecha de comienzo del proyecto será el 29 de enero de 2018 y como fecha de
finalización el 3 de junio. En semanas de trabajo son 17 semanas.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 35
La 1º semana del 29 de enero al 4 de febrero será dedicada para la instalación,
configuración y búsqueda de información de Spring Boot, MySql y ionic.
La 2º semana del 5 de febrero al 11 será dedicada para el análisis y diseño de la interfaz
de usuario, arquitectura de la aplicación y diseño de la base de datos.
Por último, las 2 últimas semanas del 21 de mayo al 3 de junio se usará para terminar la
memoria del TFG relacionada con guía de usuario y conclusiones.
Por lo cual de las 17 semanas iniciales estimadas ahora nos quedarían 14 semanas para
desarrollar las historias de usuario.
He estimado que la duración de cada Sprint es de 2 semanas. Por lo cual realizando la
división 14 semanas / 2 semanas por sprint tenemos 7 Sprints.
Velocidad: 70 / 7 = 10 puntos de historia por sprint.
Con los datos anteriores hice la siguiente planificación, ajustando la semana previa a
realizar las historias de usuario, Sprint 0. Además de reflejar las 2 últimas semanas para
dedicarlas a la memoria del TFG, Sprint 8.
Nº de
Sprint
Fecha Inicio Fecha Fin Puntos de
historia
Velocidad Historias de
usuario
0 29 de enero 4 de febrero Instalación SW
1 12 de febrero 25 de febrero 10 100% 1,2,12
2 26 de febrero 11 de marzo 10 100% 4,9
3 12 de marzo 25 de marzo 8 80% 3,10
4 26 de marzo 8 de abril 11 110% 11,14
5 9 de abril 22 de abril 9 90% 13,5,6
6 23 de abril 6 de mayo 12 120% 8,7,15
7 7 de mayo 20 de mayo 10 100% 16,17
8 21 de mayo 3 de junio Memoria TFG Ilustración 18 Planificación 1 de los Sprints
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 36
Como se aprecia en la tabla anterior, la primera historia de usuario se empieza a hacer el
12 de febrero y la última el 3 de junio. También se asocia una velocidad a cada Sprint,
concretamente hay varias superiores al 100%, el Sprint 4 y 6. Esto quiere decir que en
esas semanas hay que trabajar más horas que las planificadas para poder alcanzar el
objetivo planificado de terminar esas historias de usuario.
Evolución de las estimaciones
El Sprint 3 y 5, como sus velocidades son por debajo del 100% reflejan que habrá más
tiempo para terminar las historias de usuario asignadas.
Sin embargo, al finalizar el Sprint 2 el 11 de marzo, en la reunión con el cliente y
enseñarles los avances no se terminó completamente la historia de usuario con el id 9
“estado de la cuenta” y esto hizo que se replantearan las tareas a realizar en el proyecto.
Para ajustar el trabajo restante, se acordó con el cliente adaptar el alcance del proyecto, lo
que permitió reducir la velocidad de trabajo a un nivel razonable, por ello se analizó la
velocidad del 1er Sprint que fue de 10 y la velocidad del 2º Sprint que fue 7, con estas dos
velocidades la media es 8. Por tanto, la nueva velocidad es 8.
Adoptando esta velocidad de 8, las historias de usuario de la prioridad Would not no se
realizarían, es decir, no se incluirían en la siguiente planificación.
Historias de usuario de la categoría Would Not descartadas:
ID 15: Bonificar con puntos con 5 puntos de historia.
ID 16: Capturar productos con código Bidi con 5 puntos de historia.
ID 17: Sistema de gestión con 5 puntos de historia.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 37
Quedando finalmente la siguiente tabla de planificación:
Nº de
Sprint
Fecha Inicio Fecha Fin Puntos de
historia
Velocidad Historias de
usuario
0 29 de enero 4 de febrero Instalación SW
1 12 de febrero 25 de febrero 10 100% 1,2,12
2 26 de febrero 11 de marzo 10 100% 4,9
3 12 de marzo 25 de marzo 8 100% 9,10
4 26 de marzo 8 de abril 8 100% 11
5 9 de abril 22 de abril 8 100% 3,13
6 23 de abril 6 de mayo 7 75% 14,5,6,
7 7 de mayo 20 de mayo 7 88% 7,8
8 21 de mayo 3 de junio Memoria TFG Ilustración 19 Planificación 2 de los Sprints
Adoptando estos cambios en la planificación inicial antes descrita, en el Sprint 3 se
realiza 3 puntos de historia que faltaban de la historia con el id 9 además de la historia
con el id 10.
Con velocidades menores de 100% se proporciona un tiempo de trabajo más adecuado,
permitiendo así continuar con esta planificación.
Ilustración 20 Gráfico Burn Down
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8
Planificación 2 Planificación 1
Punto
s de h
istoria
Iteraciones
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 38
Como vemos en el gráfico anterior con la planificación 1 la inclinación es más abrupta
que en la planificación 2 que es más suave, menos inclinada. Esto es debido a la
diferencia del porcentaje de la velocidad, siendo en la planificación 1 más estable y no
pasando nunca del 100%.
2.6. Estudio de viabilidad
En este apartado se calculará el coste económico de llevar a cabo el proyecto. Este
cálculo se obtendrá en base del coste relacionado con el software necesario, el hardware y
el coste económico del personal. El coste total será incrementado un 15% para tener un
margen de beneficio.
A continuación, se muestra el coste de software requerido para el proyecto, la mayoría es
gratuito y con un tiempo de uso de 5 meses.
Programas Precio Tiempo de uso Precio de uso
Netbeans 8.2 0€ 5 meses 0€
Microsoft Office 365
Personal
7€/mes 5 meses 35€
Visual Studio Code 1.23 0€ 5 meses 0€
Postman 5.5.2 0€ 5 meses 0€
Visual Paradigm
Community Edition
0€ 5 meses 0€
MAMP 0€ 5 meses 0€
TOTAL: 35€ Ilustración 21 Coste Herramientas Software
Seguidamente se muestra el coste del hardware, el cálculo se ha realizado estimando la
vida útil del componente y estimando el tiempo de uso. A partir de estas estimaciones se
ha concluido un precio de uso.
Ilustración 22 Coste Herramientas Hardware
Hardware Precio Vida estimada Precio de uso
MacBook Pro
Retina 13"
1400€ 10 años 80€
Huawei p8 lite 200€ 4 años 70€
TOTAL: 150€
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 39
El tercer coste referente al cálculo del salario, se ha llevado a cabo tomando como
referencia el salario junior como programador y analista según tablas salariales del grupo
Ilunion [12].
El total de horas de trabajo ha sido calculado de la siguiente forma, los días de trabajo
realizados con el rol correspondiente en este caso Analista y programador multiplicado
por las horas al día de trabajo en este caso 5 horas.
Y finalmente las horas de trabajo multiplicadas por el salario por hora de cada rol nos da
como resultado el coste total por cada uno.
Tabla 1 Cálculo del salario
Ya calculados los tres costes anteriores, se procede a la suma de ellos que nos da como
resultado 4130,00€. Este resultado se incrementa un 15% de beneficio obteniendo el
precio total de llevar a cabo la aplicación.
Costes Precio
Coste hardware 150,00€
Coste software 35,00€
Coste personal 2773,14€
Coste total 2958,14€
Beneficio- 15% del total 443,7€
Total: 3401,8€
Tabla 2 Coste del proyecto
Cargo Salario
Mensual
Salario
por hora
Horas
al día
Total
de
horas
Precio
Programador 1200,08€ 7,60€ 5 269 2044,4€
Analista 1406,90€ 8,78€ 5 83 728,74€
Total 2773,14€
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 40
2.7. Modelo de dominio
A continuación, a partir de los conceptos anteriores de análisis se intenta hacer una
aproximación a la solución, donde podemos intuir las clases conceptuales que se crearán
en el proyecto.
La clase Usuario hace referencia tanto a clientes, camarero y cocineros. La clase usuario
tendrá un atributo que identifique qué rol de los tres tiene en el sistema.
La relación de Pedido_detalle a Producto es de 1 a 1, porque cada Pedido tiene una
referencia a un Pedido_detalle que en éste tendría como atributo la cantidad y notas del
producto, además de tener como atributo una lista de Producto.
A partir de este modelo se centrará el estudio del diseño donde posiblemente habrá
cambio con respecto a esta estructura.
Ilustración 23 Modelo del dominio
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 41
Como dice Taylor el diseño es "... proceso de aplicar distintas técnicas y principios para
definir un dispositivo, proceso o sistema con suficientes detalles como para permitir su
realización física" [13] además el diseño construye el sistema desde el punto de vista del
dominio de la solución, es por ello que previamente se ha realizado el modelo del
dominio.
3.1. Diagrama de Entidad-Relación
La base de datos relacional para la aplicación es MySql7, usando Hibernate 8 y JPA 9para
el mapeado objeto-relacional. En la siguiente imagen se muestra más detalladamente.
Son muchas las ventajas de usar mapeado objeto-relacional una de ellas es no encontrar
código SQL empotrado o el mapeado automático de estructuras de datos complejas,
podemos encontrar más información en [14].
Cuando la aplicación de Spring compile y se ejecute, las clases con las anotaciones
respectivas que requieran persistencia, se crearán automáticamente en la base de datos.
7 https://www.mysql.com/ 8 http://hibernate.org/ 9 https://es.wikipedia.org/wiki/Java_Persistence_API
BD relacional
Aplicación Java
ORM
JPA
Hibernate
JDBC
MySql
Ilustración 24 Esquema comunicación con BD
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 42
Además, cuando se realice inserciones, modificaciones y borrados se realizará sin usar
código SQL.
Ilustración 25 Diagrama de BD
En la siguiente imagen se puede observar también las tablas desde la web de mysql, que
ha creado automáticamente JPA.
Como podemos observar las tablas están en 3ª forma normal, porque están en 2FN (los
atributos no clave depende de toda la clave principal) y no existe ninguna dependencia
transitiva entre los atributos que no son clave.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 43
Ilustración 26 Tablas creadas por JPA
3.2. Diagrama de clases
A continuación, se estudiará el diagrama de clases de la aplicación, donde se podrá ver la
estructura del sistema compuesta en paquetes y clases, con sus atributos, operaciones o
métodos y las relaciones.
Cabe destacar que se estudiará el diagrama de clases del cliente y el diagrama de clases
del servidor por separado. Debido a que son aplicaciones que se ejecutan en equipos
distintos y con lenguajes diferentes.
Aplicación Cliente
En el lado del cliente dado que hemos usado el Framework Ionic que está basado en
AngularJS es importante explicar el flujo que va a realizar la aplicación.
AngularJS usa el patrón de diseño MVVM (Modelo-Vista-Vista-Modelo) que es un
refinamiento del patrón MVC. La vista está totalmente aislada del modelo, sin embargo,
mediante eventos se comunica con el ViewModel que este si se comunica con el modelo.
Por tanto, si se modifica un dato en la vista, éste se modifica en el ViewModel y
viceversa. [15]
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 44
Ilustración 27 Esquema MVVM https://goo.gl/C2nRiC
Cabe destacar que se ha separado en 2 los diagramas de clases de la aplicación
atendiendo a la funcionalidad de los diferentes roles implicados: por un lado, está el
cliente y por otro está el diagrama del personal que incluye al camarero y al cocinero.
Esta separación se ha hecho para facilitar la claridad de los diagramas.
En los diagramas se ha usado nomenclatura de colores, relacionando la vista y el
controlador del mismo color, indicando también qué servicio usa cada controlador.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 45
Ilustración 28 Diagrama de clases Cliente
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 46
A continuación, se muestra el diagrama de clases referente al rol de cocinero y camarero.
Tienen un servicio denominado Servicio, que proporciona métodos para llevar a cabo la
comunicación con cocina-camarero-cliente.
El servicio Auth está relacionado con la mayoría de los controladores porque utiliza
funciones como Logout() que permite al cliente cerrar la sesión.
Además, Servicio, se comunica con el servidor y los resultados los guarda en listas, para
proporcionar esa información a los controladores. Los controladores suministran la
información a las vistas para mostrar los datos.
Ilustración 29 Diagrama de clases lado del cliente, rol de camarero y cocinero
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 47
Aplicación Servidor
La estructura del servidor sigue el esquema que nos proporciona Spring Boot, se han
utilizado paquetes para agrupar las diferentes clases.
El paquete servidor contiene la clase que inicializa la aplicación, y ejecuta el paquete de
recurso.
El paquete de recursos contiene las clases que llevan a cabo la aplicación RESTFUL que
a su vez hacen uso de los DAOs 10 para el acceso a la base de datos.
El paquete de DAOs hace uso del paquete de excepciones para controlar si hay algún
error.
Cuando es necesario devolver al cliente información encapsulada en DTOs 11 se hace uso
del paquete de dicho nombre.
Finalmente, el paquete Security proporciona seguridad a la API, restringiendo urls a
usuarios con autorización.
Ilustración 30 Diagrama de clases servidor
10 https://es.wikipedia.org/wiki/Data_Access_Objects 11 https://es.wikipedia.org/wiki/Objeto_de_transferencia_de_datos
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 48
3.3. Diagramas de secuencia
A continuación, se muestra los diagramas de secuencia [16] más representativos del
sistema, mediante ellos se puede observar la interacción de objetos a través del tiempo.
Debido a que realmente tenemos dos aplicaciones, la del cliente y el servidor que
proporciona la API, tenemos que hacer dos diagramas por cada historia de usuario.
Seguridad
Cada petición a la API REST va acompañada del token del usuario. Este token es enviado
en el encabezado http Authorization cada vez que la aplicación hace una solicitud HTTP.
Inicialmente JWTFilter intercepta la petición y capta el token, solicitando a
TokenProvider si es válido el token. Este extrae la información de nick del token y
mediante UsuarioDAO se accede a la BD y se comprueba si el usuario existe en el
sistema.
Finalmente, si es válido se permite acceder a la petición del controlador de recurso o si es
inválido se devuelve un código de error.
Ilustración 31 Diagrama de secuencia seguridad
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 49
Identificación del usuario (Login)
Inicialmente es imprescindible hacer un login válido para poder acceder a las
funcionalidades del sistema.
El usuario solicita al controlador de login la vista y este se la proporciona. Una vez que el
usuario rellene los datos, los envía al controlador de login y este se los manda al servicio
que se encarga de la autentificación.
El servicio envía los datos a la API a la espera de una respuesta. Si la respuesta es válida,
se devuelve el token [17] al usuario y se redirige a la ventana de home.
El token es una secuencia de cadena de caracteres, que en nuestra aplicación tiene un
significado coherente. Está basado en el estándar JWT, compuesto en tres partes:
encabezado, carga útil y firma.
El token se enviará al servidor para cada petición que requiera validación, para
comprobar si el cliente está identificado en el sistema y tiene los permisos requeridos.
Ilustración 32 Diagrama de secuencia login
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 50
En el servidor, se recibe los datos de login en el controlador de la API, y este hace uso del
DAO de usuarios para que este acceda a la base de datos para comprobar que el usuario
es válido.
Finalmente, si el usuario es válido se devuelve el token como hemos visto anteriormente,
y si no se devuelve un error.
Ilustración 33 Diagrama de secuencia login servidor
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 51
Registro de usuario
Inicialmente, el usuario solicita al controlador de login que le muestre la vista de login y
este la recibe. Seguidamente, cuando pulse en el botón de registro, el controlador de login
recibe la solicitud y le muestra al usuario el formulario de registro. Una vez que el
usuario rellene los datos lo envía al controlador de (Signup) y este los envía al servicio
llamado auth.ts que se comunica con la API.
El servidor devuelve una respuesta de éxito o fracaso y se muestra al cliente la respectiva
vista.
Ilustración 34 Diagrama de secuencia registro cliente
El registro por parte del servidor comienza recibiendo del cliente los datos mediante la
API, seguidamente utiliza el DAO de usuarios para comprobar que no existe ningún
usuario con dicho nick, y devuelve el token si es válido y vacío si no lo es.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 52
Ilustración 35 Diagrama de secuencia registro servidor
Realizar Pedido
El usuario solicita ver los productos de una categoría al controlador de por_categoria y
este le devuelve la lista de productos. Cuando el usuario selecciona un producto, se le
proporciona la vista detallada del producto.
Una vez que el usuario selecciona agregar al carrito se envía el producto al controlador de
producto para añadirlo a la lista. Este proceso de ir añadiendo productos al carrito se
repite hasta que finalice la compra.
Cuando el usuario pulsa en ver carrito se envía la solicitud al controlador de
productosCarrito para mostrarle la vista, a continuación, cuando pulse en realizar pedido,
el controlador envía al servicio los productos a pedir.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 53
El servicio es el encargado de comunicarse con la API y enviarle el pedido a la espera de
una respuesta.
Ilustración 36 Diagrama de secuencia realizar pedido
El servidor recibe del cliente el pedido, después utiliza el DAO de pedidos para insertarlo
en la base de datos y envía una respuesta al cliente según si hubo o no éxito.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 54
Ilustración 37 Diagrama de secuencia realizar pedido en servidor
Pagar la cuenta
El camarero solicita al controlador de cobrar la vista y este se la devuelve. Después envía
la mesa y el cliente al servicio para que se comunique con la API y le envía los datos.
Según la respuesta de la API se muestra un mensaje de éxito o error.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 55
Ilustración 38 Diagrama de secuencia pagar cliente cliente
En el servidor se recibe los datos y usa el DAO de pedido para insertar en la base de datos el
nuevo pedido y se devuelve un mensaje según si hubo éxito o no.
Ilustración 39 Diagrama de secuencia pagar la cuenta servidor
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 56
3.4. Diseño de la interfaz
En este apartado mostraremos en primer lugar un diagrama de estados de la aplicación
cliente, para observar los distintos estados y transiciones de la aplicación cliente [18].
Después se mostrará los bocetos de las interfaces cliente, cocinero y camarero.
Diagrama de estados de la aplicación cliente
El siguiente diagrama muestra el flujo de ejecución del cliente para facilitar su
comprensión. Cada estado tiene un identificador, para ser usado en el siguiente apartado
y ver que vista corresponde con cada estado.
Inicialmente el usuario se le muestra la ventana de login, si el login es incorrecto se le
vuelve a mostrar. También si no tiene cuenta, accede a la ventana de registro para
registrarse y después hacer el login.
Cuando el login es válido se redirige al menú de navegación, donde tiene acceso a varias
opciones.
Cuando accede a carta se le muestra las categorías de los productos, al seleccionar un
producto accede al detalle del producto seleccionado y lo puede agregar al carrito y
vuelve a la carta para poder seguir añadiendo más productos.
Además, puede hacer uso del buscador para acceder a la ficha del producto directamente.
Cuando acceda al carrito puede realizar el pedido. Finalmente, cuando acceda a cuenta
puede solicitar que le cobre la comanda para terminar la estancia en el restaurante.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 57
Ilustración 40 Diagrama de estados del cliente
Interfaces de identificación
A continuación, se muestra la interfaz de identificación y crear cuenta en el sistema, que
corresponden con el diagrama de estados anterior: ID1, ID2, ID3.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 58
Ilustración 41 Interfaz de identificación
Este primer boceto, representa las ventanas de identificación y registro de la cuenta de
usuario. Lo primero que encontraría el usuario sería la venta de identificación, con dos
campos de texto para introducir su nick y su contraseña. Si los datos introducidos son
válidos, se accede al sistema con el rol correspondiente a la cuenta (cliente, camarero o
cocinero) y se mostrará el menú de navegación, correspondiente al ID 3 del diagrama de
estados.
La interfaz de registro contiene varios campos a rellenar por el usuario, estos son:
nombre, correo, nick y contraseña. Si el usuario pulsa sobre el botón de registro y estos
campos no son válidos el texto erróneo se marca en rojo y aparece un símbolo de error
como se indica en el boceto.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 59
Interfaces del cliente
El cliente es el rol de usuario con más tipo de interfaces, hace uso de navegar entre los
productos, ver los pedidos que ha realizado o hacer uso del buscador. A continuación, se
detalla cada una de las interfaces.
Cuenta del cliente, ID 4
Ilustración 42 Interfaz cuenta
En esta primera interfaz del cliente, se muestra la estructura a seguir en las demás
interfaces de cliente.
Todas ellas estarán compuestas de dos botones con sus respectivos iconos en la parte
superior derecha para desconectar de la aplicación y acceder al carrito de productos.
En la parte inferior se ha pensado en hacer una barra de navegación entre las
funcionalidades principales que puede hacer el cliente que son Cuenta, Carta, Historial y
Buscar.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 60
La idea de esta interfaz es mostrar los pedidos que está realizando el cliente que están
pendientes de pago. Cada pedido mostrará la hora en la que se pidió y los productos que
compone el pedido. Además de mostrar el total a pagar que lleva hasta ese momento con
esos pedidos.
Finalmente, un botón Pedir Cuenta que llamará al camarero para que se acerque a la mesa
y le cobre esos pedidos.
Carta de productos, ID 10, ID 12
Ilustración 43 Interfaz categoría
Dado que los productos están agrupados en categorías, la interfaz de Carta mostrará una
lista de todas las categorías permitiendo la navegabilidad entre ellas.
Una vez accedido a una categoría, la interfaz de productos por categoría mostrará todos
los productos de esa categoría en forma de lista. Cada elemento de esta lista contiene una
imagen del producto, el título y su precio.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 61
Una vez que acceda al producto se mostrará la interfaz de producto que detalla toda su
información. Contiene el título del producto, una imagen, descripción, precio,
ingredientes, seleccionar la cantidad y añadir notas introduciendo un texto. Finalmente,
un botón para añadirlo al carrito.
Ilustración 44 Interfaz producto
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 62
Historial de pedidos, ID 8
Ilustración 45 Interfaz historial
Esta interfaz es muy sencilla, mostrará una lista de los pedidos realizados por el cliente
que estén en estado de pagado.
Cada elemento de la lista contendrá la fecha en que se realizó y una descripción,
conteniendo los productos que se pidieron. Es meramente informativa.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 63
Buscar producto, ID 6
Ilustración 46 Interfaz buscar
Esta es la interfaz del buscador, en la parte superior se deberá introducir el texto a buscar,
y en la lista de abajo se mostrará los productos que coincidan en su nombre con el texto
introducido. Pudiendo pulsar en uno de ellos para redirigirle a la interfaz de detalle del
producto.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 64
Detalle del pedido, ID 7
Ilustración 47 Interfaz carrito
Esta interfaz se mostraría cuando el usuario pulse sobre el icono de arriba a la derecha
llamado carrito. Este icono estaría en todas las interfaces de cliente como se ha
comentado anteriormente.
El objetivo sería mostrar los productos en forma de lista, mostrando su nombre, notas y
precio. Cada producto tendría un botón para eliminarlo del carrito. En la parte de abajo
un botón para realizar el pedido.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 65
Aplicación cliente: vista de camarero
El camarero cuando hace login con éxito en la aplicación, accede al sistema.
El camarero no tiene el botón de carrito como le cliente porque carece de sentido, si tiene
el botón de cerrar sesión en la parte superior derecha.
Ilustración 48 Interfaces enlazar y cobrar
En la interfaz de enlazar, aparecería un buscador para buscar al cliente por su
identificador ("nick"), también aparecería las mesas del restaurante y seleccionas la mesa
en la que está sentado el cliente.
Finalmente, un botón para realizar el enlace del cliente con la mesa.
En la interfaz de cobrar, el camarero seleccionaría la mesa del cliente al que quiere
cobrar, y se muestra en forma de lista el detalle de todos los pedidos que están en
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 66
pendiente de pago por parte del cliente. Una vez realizado el pago en metálico por parte
del cliente al camarero, éste pulsaría el botón “Cobrar”, y los pedidos se ponen en estado
de cobrado.
Aplicación cliente: vista de cocinero
El cocinero tiene una interfaz muy sencilla, no tiene menús de navegación, solo la tabla
con los pedidos entrantes y el botón de cerrar sesión.
Ilustración 49 Interfaz cocinero
La tabla muestra los productos que componen el pedido, el orden es con prioridad al más
antiguo.
Cada producto es un botón que muestra el nombre del producto, la cantidad y las notas.
Por cada click que haga el cocinero en el producto la cantidad se decrementará en uno
hasta llegar a cero y desaparecerá el producto.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 67
En este punto se explicará la arquitectura de la aplicación y los componentes más
relevantes que se han usado para llevar a cabo la aplicación ayudándonos de fragmentos
de código.
4.1. Arquitectura de la aplicación
Nuestra aplicación usa una arquitectura cliente-servidor, el servidor proporciona recursos
y estos son solicitados por el cliente. Es decir, el cliente realiza peticiones y estas son
respondidas por el servidor.
Ilustración 50 Diagrama cliente-servidor
Nuestro servidor para atender las peticiones del cliente, proporciona una API [19].
Una API REST se puede definir como una interfaz entre sistemas que utilizan el
protocolo HTTP [20] para obtener datos o generar operaciones sobre esos datos en
distintos formatos como JSON [21] o XML [22].
Por lo tanto, siguiendo esta arquitectura, la siguiente imagen muestra cómo estaría
organizada la aplicación en base a los frameworks y tecnologías usados.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 68
Ilustración 51 Diagrama arquitectónico del sistema
En el lado del cliente, se muestra como angular proporciona a Ionic está basado en
Angular y como Ionic hace uso de HTML, CSS y JS. Después Ionic hace uso de Apache
Cordova para generar las aplicaciones móviles. Éstas pueden ser Android, iOS o
Windows Phone.
Con la aplicación móvil generada previamente con Apache Cordova12, mediante
peticiones POST/GET se comunica con la REST API proporcionada por el servidor.
Las peticiones recibidas en el servidor, hacen uso de clases de Java, que son del modelo
de negocio, y éstas a su vez si necesitan acceder a la base de datos lo hacen mediante
JPA.
12 https://cordova.apache.org/
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 69
4.2. Detalles sobre la implementación
A continuación, se describirá una lista de las tecnologías empleadas durante la
implementación:
Ionic v3.2
AngularJS v1.6.8
HTML 5
CSS 3
Apache Cordova
GIT 2.6.2
Spring Boot 2.0
Postman 5.5.2
Aplicación Cliente
Git Workflow
Usando Ionic se ha empleado el sistema control de versiones que proporciona, para ir
guardando los avances del proyecto. Está basado en Git, sobre todo se ha usado commits,
push y pull. [23]
En la siguiente imagen se muestra un histórico de commits.
Ilustración 52 Ionic Workflow https://goo.gl/JoR6aE
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 70
Estructura Ionic
Al crear un proyecto con Ionic se crea una carpeta con el nombre del proyecto y dentro
de ella una estructura de archivos y carpetas. Ahora veremos los aspectos más relevantes
que tiene el proyecto en base a su estructura.
En la carpeta src están todos los archivos con el contenido de
nuestra aplicación. Src contiene la carpeta de app que es el
módulo principal, assets, pages donde se encontrarán nuestras
páginas y su respectivo controlador, pipes para procesar
información, provider que contiene nuestros servicios y theme
que suministra estilos. [24]
En las siguientes imágenes se muestra un ejemplo de una página concretamente la de
Enlazar, está formada por el controlador Enlazar.ts y la vista Enlazar.html. Se puede
observar la declaración y uso de funciones y cómo por ejemplo cuando una variable es
modificada en la vista, simultáneamente se modifica en el controlador.
Ilustración 53 Estructura ionic
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 71
Ilustración 54 Vista enlazar.html
Ilustración 55 Controlador enlazar.ts
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 72
Generar aplicación para varias plataformas
En este apartado veremos cómo se genera la aplicación [25] para Android o IOS.
Mediante el CLI 13de IONIC, escribimos los siguientes comandos para agregar la
plataforma Android o IOS al proyecto:
ionic cordova platform add android
ionic cordova platform add ios
Ahora para generar el archivo apk se escribe los siguientes comandos:
ionic build android --release
ionic build ios --release
El archivo apk14 se encuentra en Plataformas \ Android \ Build \ Outputs \ apk
Ilustración 56 Generar app en distintas plataformas
13 https://ionicframework.com/docs/cli/ 14 https://es.wikipedia.org/wiki/APK_(formato)
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 73
Finalmente, para instalar el archivo .apk hay que seguir una serie de pasos [26]:
Dar permiso al dispositivo móvil para poder instalar aplicaciones que no
provengan de App Store. Se debe acceder Ajustes-Seguridad y habilitar la opción
de “Orígenes desconocidos”.
Conectar el dispositivo móvil mediante USB al ordenador y elegir en el
dispositivo móvil la opción de “Transferir archivos”.
Copiar el archivo desde el ordenador al dispositivo móvil.
Finalmente extraer de forma segura el móvil y acceder desde el móvil a la carpeta
donde ha sido copiada la aplicación y ejecutarla para instalarla.
Ejemplo de un servicio
Los servicios de la aplicación cliente se encargan de comunicarse con el servidor
mediante peticiones asíncronas. Además, estos guardan estructuras de datos para guardar
información necesaria. Como estructura de datos se ha usado listas debido al uso que se
le han dado.
En la siguiente función se puede observar una petición GET y el resultado se guarda en
una lista llamada pedidos_cocina. Todo ello dentro de una promesa, para indicar que el
objeto promesa contendrá un valor en el futuro que nos interesa y no podemos dejar que
bloqueen la función.
Ilustración 57 Ejemplo petición get
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 74
Local Storage
Local Storage [27] nos permite almacenar información en el navegador, aunque se cierre
el navegador, la información permanece. Unas de las características destacadas es que
permite almacenar entre 5MB y 10MB, la información está almacenada en el dispositivo
del cliente y no es enviada en cada petición al servidor.
Se ha empleado Local Storage para guardar en la memoria del dispositivo el carrito del
cliente, guardando en formato JSON el detalle de todos los productos, cantidad, notas etc.
Ilustración 58 Local Storage
En la imagen anterior se puede observar que, con la aplicación del cliente en ejecución en
localhost y abierta sobre el navegador Chrome, se usa la memoria para guardar en
formato (llave,valor) la información. En este caso la llave es 'items' y el valor es la
información en formato JSON que contiene la información del carrito.
Aplicación Servidor
Sistema gestor de versiones GIT
También se ha utilizado el sistema gestor de versiones GIT para ir guardando el proyecto
y sea más fácil recuperar versiones anteriores.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 75
Ilustración 59 GIT servidor
Mapeo ORM de clases con anotaciones JPA
Dado que el mapeado de una clase a una tabla no es automático, tenemos que
proporcionar a JPA una mínima información, mediante anotaciones en código Java. [28]
En la siguiente imagen se puede observar un ejemplo del uso de anotaciones en la clase
Categoría.
Con la anotación @Entity indicamos que la clase Categoría es una clase persistente, que
en JPA se denomina entidad.
Con la anotación @Id marcamos el atributo que hace de clave primaria de la tabla, en
este caso es autogenerado, marcado con la etiqueta @GeneratedValue.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 76
Ilustración 60 Etiquetas JPA
Acceso a la base de datos con DAOs
Cuando la capa de lógica de negocio quiera interactuar con la base de datos, lo hará a
través del DAO de su clase respectiva.
Ilustración 61 Pedido DAO
En cada DAO está inyectado el EntityManager. El EntityManager está asociado con el
contexto de persistencia, el cual será utilizado para administrarlas entidades y las
transacciones. [29]
Con EntityManager podemos hacer operaciones como:
Búsquedas: find()
Insertar: persist()
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 77
Actualizar: merge()
Borrar: remove()
Recursos API
El servidor proporciona una API REST con distintos servicios para atender las peticiones
del cliente.
Por ejemplo, en la siguiente imagen se puede ver el servicio de tipo GET para realizar las
búsquedas de productos.
En caso de no encontrar resultado se devuelve el objeto vacío.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 78
Tabla de end-points REST
A continuación, se observa la información relevante de los end-points REST 15de la
aplicación:
Tipo Detalle URL RequestBody Devuelve Devuelve
en caso de
error
GET Suscribir
camarero al
emitter
/tucomanda/avisoscomanda/{nickc} null Emitter null
POST Realizar
pedido
/tucomanda/pedidos/ List<ProductoInfo> Cod: 200 Cod:404
GET Comprueba
enlace
tucomanda/enlace/{nick} null 200 404
GET Pedidos a
cobrar
/tucomanda/pedidos/cobro/{mesa} null Pedido null
POST Cobrar
pedidos
/tucomanda/pedidos/cobro Pedidos 200 404
GET Pedidos a
cocinar
/tucomanda/pedidos Null 200 404
POST Producto
cocinado
/tucomanda/producto Producto 200 404
GET Pedidos a
pagar cliente
/tucomanda/pedidos/actuales Null 200 404
GET Historial /tucomanda/pedidos/historial Null 200 404
GET Solicita
cobro
/tucomanda/pedidos/aviso Null 200 404
GET Buscar
producto
/tucomanda/productos/buscar/{patron} null 200 404
POST Buscar
usuario
/tucomanda/usuarios/buscar/{patron} null Usuario null
GET Cargar mesas /tucomanda/mesas Null Mesas null
POST Crear enlace /tucomanda/enlace Enlace 200 404
POST Identificarse /login Usuario Token null
POST Crear cuenta /signup Usuario Token Null
GET Productos
por tipo
/productos/por_tipo/{categoria} Null Productos null
GET Cargar
categorías
/categorias Null Categorías null
Ilustración 62 Tabla end-points
15 https://smartbear.com/learn/performance-monitoring/api-endpoints/
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 79
Seguridad token JWT
Con la utilización del token en forma jwt, podemos extraer del token el Nick del cliente.
Esto nos proporciona en cada petición la posibilidad de comprobar si tiene permiso de
acceso, proporcionando seguridad a la aplicación.
JWT (Json Web Token) es un estándar para crear tokens de acceso. [30]. El JWT está
formado por 3 partes, encabezado, carga útil y una firma. Para crear el token, los datos
necesarios para crear el token son: la palabra secreta proporcionada desde el archivo
applycation.yml, el tiempo que va a ser válido el token y para la firma el algoritmo
(HMAC con SHA-512)16.
Ilustración 63 Creación de token
Además, se filtran las solicitudes entrantes usando el token creado y Spring security. En
la siguiente imagen se puede observar cómo se comprueba la validación del token y si el
usuario existe en la base de datos, además se devuelve una serie de excepciones cuando
falla la validación.
16 https://es.wikipedia.org/wiki/HMAC
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 80
Ilustración 64 Comprobación token en cada petición
Server Side Events (SSEs)
Consiste en que el cliente se suscribe a una 'transmisión' desde el servidor y el servidor
enviará mensajes 'eventos' al cliente, hasta que se cierre la conexión.
SSEs se envían a través de HTTP tradicional. Significa que no requieren un protocolo
especial o implementación de servidor para funcionar [31].
El uso de enviar eventos del servidor al cliente se ha usado para las notificaciones al
camarero de servir un producto o para notificarle de cobrar una mesa.
Ilustración 65 Server Side Events
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 81
Se ha comprobado el correcto funcionamiento de las historias de usuario, después de cada
sprint. Las historias de usuario fueron validadas con el usuario utilizando los criterios de
aceptación expuestos en la tabla del apartado 2.4.
Surgió un problema a la finalización del Sprint 2, la historia de usuario con el id 9
“estado de la cuenta” no fue realizada completamente. Este hecho se solventó con la
reducción de la velocidad de scrum, de manera que en el siguiente sprint se finalizó.
Además, para comprobar el funcionamiento de la interfaz REST se ha utilizado un
software llamado “Postman”17. Enviando peticiones GET o POST al servidor con los
datos requeridos analizando los resultados y comprobando si la respuesta del servidor era
correcta.
Finalmente, surgieron ideas nuevas en las que se añadirían en futuras ampliaciones como
que el cliente pueda pagar desde la aplicación con la tarjeta de crédito directamente. Estas
ideas son expuestas en el apartado 6.1 llamado “Trabajos futuros”.
17 https://www.getpostman.com/
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 82
En la actualidad podemos observar que uno de los motivos del desarrollo tecnológico es
el de dar servicios a la sociedad. Automatizar procesos o realizar cálculos proporciona a
la persona ahorro de tiempo, eficiencia y fiabilidad.
Además, año tras año, el uso de la tecnología para realizar tareas habituales es más
común y esto abre la posibilidad de un avance tecnológico y nuevas aplicaciones
orientadas a dar servicio a las personas.
Es por ello que esta aplicación proporciona una automatización del servicio que da un
restaurante a sus clientes aumentando mucho la eficiencia en el servicio.
Esta aplicación hace un tiempo hubiera sido inviable, debido a que las personas carecían
de un dispositivo móvil con conexión a internet, pero hoy en día la mayoría de las
personas dispone de móvil, y es extraño que no tenga tarifa de datos en el mismo por lo
que la idea de ir a un restaurante y pedir la carta desde tu propio dispositivo no resultaría
tan extraño.
En lo referente al desarrollo del proyecto, podemos concluir que se han alcanzado con
éxito los objetivos inicialmente propuestos:
Se ha desarrollado un estudio en el contexto donde se quiere instalar la aplicación,
analizando su funcionamiento y extrayendo sus ventajas e inconvenientes.
Además de una reunión con el cliente para estudiar sus necesidades y proponerle
las soluciones más adaptadas a las mismas.
Se ha diseñado un sistema informático, definiendo la funcionalidad del sistema
mediante historias de usuario y se ha estudiado la viabilidad temporal y
económica del desarrollo. Siguiendo una metodología ágil, SCRUM.
Se han realizado implementaciones utilizando tecnologías actuales como Angular
JS, CSS, HTML5 (Ionic) en la aplicación del cliente; y Spring para la aplicación
del servidor.
Y, por último, se han probado los resultados obtenidos siguiendo los criterios de
satisfacción junto con el cliente, adaptándose la planificación a los imprevistos
surgidos.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 83
Desde un punto de vista personal, al realizar este proyecto he podido ser consciente de la
importancia del trabajo al que me dedicaré, debido a que muchos negocios o empresas se
basan en software y sus beneficios económicos pueden variar mucho dependiendo de la
calidad de dicho software.
Al inicio del desarrollo del proyecto me enfrenté a una tecnología nueva para mí como es
Ionic, no obstante, a las dificultades que encontré fui resolviéndolas a través de foros
especializados en esta tecnología. Después, con el conocimiento adquirido pude avanzar
con mayor eficacia en el proyecto.
Desde un punto de vista técnico, el uso de JPA para crear las tablas en la base de datos de
forma automática me ha servido para conocer mejor su funcionamiento y las utilidades en
lo que lo puedo emplear. Otro de los aspectos que he aprendido es el de los beneficios
que tiene las aplicaciones híbridas porque proporciona una aplicación multiplataforma,
que puede usar funcionalidades nativas del móvil y con una interfaz muy conseguida.
También he valorado mucho el uso de sistema control de versiones GIT porque hubo
veces que tuve que regresar a una versión del proyecto anterior para solventar errores y el
empleo de esta tecnología me facilitó mucho la tarea.
Creo que este trabajo me servirá en el futuro porque sigue una arquitectura muy común
en muchos proyectos y he usado tecnologías muy punteras en el mercado, aparte de que
me ayudará en mi currículum profesional.
6.1. Trabajos futuros
En este apartado voy a comentar brevemente las historias de usuario que se descartaron
en la planificación inicial y serian unas buenas candidatas para incluirlas en una futura
planificación. Así como otras nuevas o mejoras de las existentes que han ido surgiendo a
lo largo de la realización del proyecto.
Principalmente si se quisiera ampliar el proyecto, las historias de usuario esenciales son:
Bonificar con puntos.
Capturar productos con código Bidi.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 84
Sistema de gestión.
Por otro lado, las mejoras y nuevas funcionalidades podrían ser:
Un sistema de estadísticas e informes de ventas, para ver qué productos compran
más los clientes, en qué franja horaria, etc.
El uso de estadísticas daría al empresario una buena visión de pasado y de futuro
de su negocio, como por ejemplo para contratar más personal u ofertar más
productos relacionados con los gustos de sus clientes.
Incluir ofertas temporales para llamar la atención a los clientes.
Valoración de los productos por parte de los clientes.
En un futuro si se implementara la aplicación en varios restaurantes, se podría añadir un
sistema de geolocalización de restaurantes más cercanos que usen el sistema. Esto
serviría también como promoción del restaurante. La idea sería crear una red de
restaurantes que usen esta tecnología.
Otra propuesta sería en la ficha específica del producto, aparte de mostrarse el nombre,
precio e ingredientes, incluir un vídeo mostrando la elaboración del producto.
Con todas estas ideas podría desarrollarse una aplicación muy completa y con mucha
probabilidad de éxito en el mercado.
Con el diseño, arquitectura y tecnologías utilizadas en el proyecto, no sería difícil integrar
estas mejoras, porque en los elementos de la aplicación se ha intentado que tengan alta
cohesión y bajo acoplamiento; además de estar basada en una arquitectura modelo-vista-
controlador.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 85
[1] «Expansion,»[Enlínea].Available:
http://www.expansion.com/economiadigital/innovacion/2017/03/10/58c19825e5fdea6f
688b456b.html.
[2] «Cadenaser,»[Enlínea].Available:
http://cadenaser.com/ser/2017/02/28/ciencia/1488281552_888684.html.
[3] «Wikipedia,»[Enlínea]. Available:
https://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil.
[4] A. Á. G. R. d. l. H. d. D. Carmen Lasa Gómez, Métodos Ágiles. Scrum, Kanban, Lean,
Anaya, 2017.
[5] P. González, Apuntes de la asignatura Desarrollo Ágil, 2017.
[6] «Equipo Altran,» [En línea]. Available: http://equipo.altran.es/metodologias-agiles-vs-
metodologias-tradicionales/.
[7] J. Sutherland, Scrum: El nuevo y revolucionario modelo organizativo que cambiará tu
vida, 2015.
[8] «Auth0,» [En línea]. Available: https://auth0.com/blog/alternatives-to-native-mobile-
app-development/.
[9] M. Cohn, User stories applied: For Agile Software Development, Addison Wesley,
2004.
[10] R. d. l. H. C. L. Alonso Álvarez, Métodos ágiles y Scrum, Anaya, 2012.
[11] «EllaboratoriodelasTI,»[Enlínea].Available:
http://www.laboratorioti.com/2016/09/26/tecnica-priorizacion-moscow/.
[12] «Tablas salariales grupo Ilunion,» 2017. [En línea]. Available: https://www.ccoo-
servicios.es/archivos/ilunioncontactcenter/TablasSalariales2017.pdf.
[13] S. M. y. R. F. S. Bennett, Análisis y diseno orientado a objetos de sistemas, 3a edición,
McGraw-Hill, 2006.
[14] V. Mihalcea, High-Performance Java Persistence, 2016.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 86
[15] «Adictos al trabajo,» [En línea]. Available:
https://www.adictosaltrabajo.com/tutoriales/zk-mvc-mvvm/.
[16] «Wikipedia,» [En línea]. Available:
https://es.wikipedia.org/wiki/Diagrama_de_secuencia.
[17] «Esacademic,» [En línea]. Available:
http://www.esacademic.com/dic.nsf/eswiki/1155905.
[18] «WikiUml,» [En línea]. Available:
https://wikiuml.wikispaces.com/Diagrama+de+Estados.
[19] E. Amodeo, Principios de Diseño de APIs REST.
[20] «Wikipedia,» [En línea]. Available:
https://es.wikipedia.org/wiki/Protocolo_de_transferencia_de_hipertexto.
[21] «W3schools,» [En línea]. Available: https://www.w3schools.com/js/js_json_intro.asp.
[22] «W3schools,» [En línea]. Available: https://www.w3schools.com/xml/.
[23] «Ionicframework,» [En línea]. Available:
https://dashboard.ionicframework.com/app/c2229688/code/builds.
[24] E. Revilla, Desarrollo de aplicaciones móviles multiplataforma con Ionic desde cero,
2017.
[25] «Ionic Framework,» [En línea]. Available:
https://ionicframework.com/docs/cli/commands.html.
[26] «El android libre,» [En línea]. Available:
https://elandroidelibre.elespanol.com/2016/04/como-instalar-aplicaciones-apk-
android.html.
[27] «ASDSDSADSDSDdictos al trabajo,» [En línea]. Available:
https://www.adictosaltrabajo.com/tutoriales/html-5-almacenamiento-local/#04.
[28] A. Rueda, Apuntes de la asignatura Desarrollo de aplicaciones empresariales, 2017.
[29] «Arquitectura Java,» [En línea]. Available: https://www.arquitecturajava.com/ejemplo-
de-jpa/.
[30] «IETF-related tools, standalone or hosted on tools.ietf.org,» [En línea]. Available:
https://tools.ietf.org/html/rfc7519.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 87
[31] «Stream data,» [En línea]. Available: https://streamdata.io/blog/server-sent-events/.
[32] S. M. y. R. F. S. Bennett, Análisis y diseno orientado a objetos de sistemas, 3a edición,
McGraw-Hill, 2006.
[33] «El confidencial,» [En línea]. Available:
https://www.elconfidencial.com/tecnologia/2017-05-26/movil-uso-exceso-espana-
salud-enganchados-smartphone_1389117/.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 88
Aplicación del servidor
Inicialmente se requiere tener instalado MAMP e iniciar la aplicación, para que se inicie
de MYSQL Server. Los parámetros de la BD son:
spring.datasource.url: jdbc:mysql://localhost:8889/tucomanda_db
spring.datasource.username: tienda_user
spring.datasource.password: 123456
Es necesario tener instalado Netbeans. El siguiente paso es pulsar sobre “Archivo”-
“Importar proyecto” y abrir la carpeta llamada “tucomandaspring” que contiene la
aplicación del servidor que está en el USB entregado.
Después pulsar sobre “Ejecutar proyecto”.
Aplicación móvil
Primero acceder con consola de comandos a la carpeta suministrada en el USB llamada
“tucomanda”, después ejecutar: Ionic serve. Este comando abrirá el navegador con la
aplicación.
Además, se incluye en la carpeta Platforms el proyecto compilado para Android o IOS.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 89
En este apartado vamos a presentar una guía de uso de la aplicación, con una cuenta con
el perfil de cliente. Donde se podrá observar el flujo de ejecución y las distintas opciones
de cada vista.
Aplicación cliente: vista de clientes
Al ejecutar la aplicación se muestra una vista para la identificación del usuario, se debe
insertar el nick y la contraseña. También se puede registrar en la plataforma en caso de no
tener cuenta, rellenando los datos que solicita el formulario de alta. Estos formularios
validan los datos y muestran mensajes de errores.
Ilustración 67 Vista login
Una vez se realice el “login” correctamente, se tiene acceso a la aplicación, en la parte
inferior de la pantalla se muestra las distintas funcionalidades donde se puede acceder
como: Cuenta, Carta, Pedidos o Buscar.
En la sección de Carta se muestra una lista de todas las categorías de productos, si se
accede a una categoría se muestra los productos de dicha categoría.
Ilustración 66 Vista registro
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 90
Ilustración 69 Vista categorías
Por ejemplo, si se accede a la categoría de ensaladas, se muestra una lista de ensaladas y
cada producto con su imagen, nombre, precio y un botón a la derecha llamado 'VER
MÁS' para acceder a la ficha del producto.
Cuando se accede a la ficha del producto, se muestra una pantalla con toda su
información. El nombre, una foto del producto, el precio, un seleccionador de cantidad y
un apartado para introducir notas, donde se puede poner por ejemplo tus preferencias para
la carne si muy hecho o poco hecho o algún ingrediente que no quieras que tenga la
ensalada.
Ilustración 68 Vista productos
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 91
Ilustración 71 Vista producto
Una vez configuradas tus preferencias, solo faltaría pulsar el botón que pone 'AGREGAR
AL CARRITO' y se actualizará el icono de carrito de arriba a la derecha con el número
de productos que tengas en tu carrito.
Si haces “click” en el botón de carrito se muestra una lista de los productos que tienes
listos para hacer el pedido, por cada producto se muestra una foto, el nombre, precio y
cantidad.
Ilustración 70 Vista producto 2
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 92
Ilustración 73 Vista categorías con carrito
Finalmente, si hace “click” en el botón de 'REALIZAR PEDIDO' se mostrará un mensaje
de confirmación para asegurar la decisión.
Ilustración 72 Vista carrito
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 93
Ilustración 75 Confirmación pedido
Ahora si se accede al menú de 'Cuenta' se muestra el estado actual de nuestra cuenta, y
una lista de los pedidos realizados hasta ese momento. Si se quiere dar por finalizada la
estancia y pagar, solo habría que hacer “click” en el botón de 'PEDIR CUENTA' y
confirmar el mensaje de confirmación. Ahora solo habría que esperar a que el camarero
acuda a cobrarnos.
Ilustración 74 Pedido con éxito
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 94
Ilustración 77 Vista de cuenta
También se dispone de buscador, si accedemos a la opción 'Buscar' del menú y
escribimos la palabra 'ensalada', aparecerán todas las ensaladas que se ofertan. Ahora
pulsando sobre una de ellas accedes a la ficha de la ensalada seleccionada.
Ilustración 76 Confirmación pagar
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 95
Ilustración 78 Vista buscador
Finalmente, si accedemos a 'Pedidos' podremos ver el historial de pedidos que hemos
hecho en el restaurante, es meramente informativo.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 96
Ilustración 79 Vista historial de pedidos
CAMARERO
Inicialmente con una cuenta con el rol de camarero se debe iniciar sesión en la aplicación
para acceder al sistema. Una vez dentro hay 2 opciones en el menú de navegación
'Enlazar' ,'Servir' y 'Cobrar'. A continuación, se detallarán estas opciones.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 97
Ilustración 81 Vista enlazar 1
En la opción 'Enlazar' se enlaza el cliente con la mesa en la que está sentado para saber el
destino de sus pedidos.
En la parte superior aparece un buscador, donde hay que introducir el nick del cliente y
pulsar sobre el botón con el símbolo de más. A continuación, aparece un seleccionador
donde se elige la mesa del cliente. Por último, se pulsa sobre el botón enlazar para
realizar la acción.
En la opción de 'Servir' aparecerán los productos del pedido listos para servir, en forma
de lista donde aparece la cantidad, nombre, mesa destinataria y notas del producto.
Cuando se sirve el plato se tiene que eliminar de la lista desplazando el ítem hacia la
izquierda y pulsando el botón de 'Servido'.
Ilustración 80 Vista enlazar éxito
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 98
Ilustración 83 Vista servir 1
Por último, la opción de 'Cobrar', muestra una lista de todos los pedidos que ha realizado
la mesa seleccionada en el seleccionador de mesas. Una vez cobrado se debe pulsar en el
botón 'COBRAR' para que se marquen esos pedidos como cobrados.
Ilustración 82 Vista servir eliminar
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 99
Ilustración 84 Vista cobrar
Cocinero
Lo primero que hay que hacer es acceder al panel de login y identificarse
satisfactoriamente con una cuenta de cocinero. Una vez dentro del sistema se muestra la
lista de pedidos pendientes por servir, estos pedidos están ordenados por orden de
llegada.
Una vez preparado el producto se tiene que hacer click sobre el botón del producto para
notificar al camarero que lo recoja y lo sirva a la mesa determinada.
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 100
Ilustración 85 Vista cocinero
José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería
Escuela Politécnica Superior de Jaén 101
Se suministra un USB que contiene los siguientes archivos comprimidos:
Aplicación del servidor llamada tucomandasrping.zip
Aplicación del cliente llamada tucomanda.zip