Cafetering: sistema para la gestión de pedidos en cafeterías universitarias. Subsistema para la gestión de los pedidos en las cafeterías

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA CAFETERING: SISTEMA PARA LA GESTIN DE PEDIDOS EN CAFETERAS UNIVERSITARIAS SUBSISTEMA PARA LA GESTIÓN DE LOS PEDIDOS EN LAS CAFETERÍAS CAFETERING: ORDER MANAGEMENT SYSTEM FOR UNIVERSITY CAFETERIAS ORDER MANAGEMENT SUBSYSTEM FOR CAFETERIAS Realizado por Mario Quintana Anaya Tutorizado por Antonio Maña Gómez Departamento Lenguajes y ciencias de la computación UNIVERSIDAD DE MÁLAGA MÁLAGA, Octubre 2018 Fecha defensa: El Secretario del Tribunal - 1 - Resumen: En esta memoria se describen todas las tareas llevadas a cabo para diseñar e implementar el subsistema para la gestión de los pedidos, que es parte de un sistema innovador de gestión de pedidos en cafeterías universitarias, incluyendo la preparación del correspondiente plan de negocio. El subsistema descrito aquí será usado por los empleados y encargados de las cafeterías universitarias para gestionar los pedidos, ofertas, menús y categorías. Además, se ofrecen herramientas graficas que soportan la toma de decisiones y permiten optimizar tanto los flujos de trabajo como las existencias de perecederos. Se ha desarrollado un algoritmo de planificación de pedidos que permitirá distribuir los pedidos en el tiempo de forma óptima. Por lo tanto, se proporcionará una mejor distribución de la carga de trabajo a los empleados. Por otro lado, un compañero se encarga en su TFG del desarrollo del subsistema cliente, que consiste en una aplicación web que permite a los alumnos y al personal universitario realizar los pedidos a la cafetería, pudiendo indicar a qué hora va a recogerlo o planificándolo semanalmente. Dicho sistema usa un API proporcionado por nuestro subsistema para comunicarnos las acciones de los clientes sobre los pedidos (creación, modificación, consulta de estado, etc.). Estos pedidos creados serán gestionables por el personal de la cafetería usando el subsistema que describimos en esta memoria. Palabras claves: Cafetería, pedidos, menú, oferta, cafetering, django, python, PostgreSQL. - 2 - Abstract: In this manuscript, we describe all the tasks carried out to design and implement the subsystem for order management, which is part of an innovative order management system for university cafeterias, including the preparation of the corresponding business plan. The subsystem described here will be used by employees and managers of university cafeterias to manage orders, quotations, menus and categories. In addition, graphics tools are offered to support decision making and optimize both workflows, and perishable stocks. An order planning algorithm has been developed that will allow orders to be distributed over time in an optimal manner. Therefore, a better distribution of employees’ workload will be provided. On the other hand, a colleague is responsible for the development of the client subsystem in his TFG. This subsystem consists of a web application that allows students and university staff to place orders for the cafeteria, being able to indicate at what time they want to pick up their orders and to plan orders on a weekly basis. This web application uses an API provided by our subsystem to communicate customer actions on orders (creation, modification, status query, etc.). The orders created by the client subsystem will be managed by the staff of the cafeteria using the subsystem described in this memory. Keywords: Cafeteria, orders, menu, offer, cafetering, django, python, PostgreSQL. - 3 - TABLA DE CONTENIDO 1. Introducción ..................................................................................................................................... 5 1.1. Motivación ..................................................................................................................................... 5 1.2. Objetivos del TFG ........................................................................................................................... 6 1.2.1. Objetivos generales del TFG ................................................................................................... 6 1.2.2. Objetivos específicos del TFG ................................................................................................. 6 1.3. Metodología .................................................................................................................................. 7 1.3.1. Fases de Trabajo ..................................................................................................................... 7 1.4. Estudio del estado del arte ............................................................................................................ 8 2. Solución .......................................................................................................................................... 10 2.1. Descripción de la solución ........................................................................................................... 10 2.2. Descripción del sistema actual .................................................................................................... 10 2.3. Estructura de la memoria ............................................................................................................ 11 3. Análisis y diseño.............................................................................................................................. 12 3.1. Definiciones, actores ................................................................................................................... 12 3.2. Requisitos funcionales ................................................................................................................. 13 3.3. Requisitos no funcionales ............................................................................................................ 15 3.4. Diagrama de casos de uso ........................................................................................................... 15 3.5. Diagrama de secuencia ................................................................................................................ 16 3.6. Diseño .......................................................................................................................................... 20 3.6.1. Diagrama de clases ............................................................................................................... 20 3.6.2. Prototipado: Mockups .......................................................................................................... 21 3.6.3. Diseño de vistas .................................................................................................................... 24 3.6.3.1. Productos ...................................................................................................................... 24 3.6.3.2. Menús ............................................................................................................................ 26 3.6.3.3. Ofertas ........................................................................................................................... 27 3.6.3.4. Pedidos .......................................................................................................................... 28 3.6.3.5. Categorías ...................................................................................................................... 31 3.6.3.6. Informes ........................................................................................................................ 33 3.6.3.7. Algoritmo de planificación ............................................................................................. 37 4. Pruebas ........................................................................................................................................... 39 4.1. Entorno de desarrollo .................................................................................................................. 39 4.2. Pruebas ........................................................................................................................................ 39 4.2.1. Pruebas de caja blanca ......................................................................................................... 39 4.2.2. Pruebas de caja negra .......................................................................................................... 40 5. Despliegue en produccin e Implantacin ..................................................................................... 41 5.1. Despliegue en el servidor ............................................................................................................ 41 5.2. Implantación en las cafeterías ..................................................................................................... 42 - 4 - 6. Conclusiones ................................................................................................................................... 43 6.1. Objetivos cumplidos .................................................................................................................... 43 6.2. Dificultades encontradas ............................................................................................................. 43 6.3. Mejoras posibles .......................................................................................................................... 44 7. Bibliografía y referencias ................................................................................................................ 45 8. Anexos ............................................................................................................................................ 46 8.1. Plan de pruebas e informe de resultados .................................................................................... 46 8.2. Plan de Negocio ........................................................................................................................... 49 8.2.1. Nuestra propuesta ................................................................................................................ 49 8.2.2. Descripción comercial........................................................................................................... 50 8.2.3. Descripcin tcnica ............................................................................................................... 50 8.2.4. Estrategias de arranque ........................................................................................................ 51 8.3. Guía de uso .................................................................................................................................. 51 8.3.1. Introducción ......................................................................................................................... 51 8.3.2. Listado de pedido y acciones rápidas ................................................................................... 52 8.3.3. Edición de pedido ................................................................................................................ 53 8.3.4. Gestión de productos .......................................................................................................... 54 8.3.5. Gestión de ofertas ................................................................................................................ 56 Tabla de ilustraciones ............................................................................................................................. 58 - 5 - 1. INTRODUCCIÓN 1.1. MOTIVACIÓN Las cafeterías de los campus universitarios de toda España (y probablemente de Europa y el mundo) presentan similares problemas de gestin. Los retrasos en los pedidos, las largas colas y el desperdicio de alimentos estn a la orden del día. Estos problemas, sin embargo, pueden solventarse aprovechando las posibilidades que nos brindan las tecnologas de la información. Son muchas las empresas de diversos mbitos (incluidas muchas del sector de la repostera) que ya han apostado por estas tecnologas, mientras que en las universidades los problemas se acumulan sin que parezca buscarse remedio alguno. El fin de este proyecto es, por tanto, el desarrollo de un sistema integrado que permita el seguimiento, planificación y optimización de los pedidos por parte del personal de la cafetería. As mismo, los datos que se producen durante el uso del sistema, sern almacenados y procesados para la posterior generacin de estadsticas que permitan apoyar la toma de decisiones (business intelligence). El sistema de gestión se divide en dos subsistemas principales. En primer lugar, el subsistema “servidor” que se encargar del almacenamiento de los pedidos y que ofrecerá un interfaz de gestión de los mismos para los empleados de las cafeterías, que ha sido desarrollado en el marco de este TFG. Por otra parte, existirá un subsistema “cliente” que implementar un interfaz de gestin de los pedidos para los clientes de las cafeterías. Este subsistema “cliente” ser realizado por un compañero de TFG, que implementa tanto el interfaz como la lógica necesaria para la creación, modificación y seguimiento de pedidos para los usuarios de las cafeterías. Los trabajadores de las cafeteras harn uso de la planificacin ofrecida por la nuestro susbistema para organizar los pedidos y administrar su tiempo de la manera ms eficiente. Finalmente, también usando nuestro subsistema, los gestores de las cafeteras tendrn acceso a estadsticas que les permitirn tanto reducir el desperdicio de alimentos como descubrir tendencias de consumo, optimizar las compras, etc. - 12 - 3. ANÁLISIS Y DISEÑO En este apartado se detallan las fases realizadas para diseñar el sistema. Los pasos seguidos son los típicos en el desarrollo de software, empezando con la definición de los actores y los requisitos que luego son usados para modelar los diagramas de casos de uso y de secuencia. Estos diagramas permiten tener una visión detallada del sistema a desarrollar. 3.1. DEFINICIONES, ACTORES Definiciones y palabras claves: • SGPPC: Subsistema para la gestión de los pedidos y productos para las cafeterías. Se trata del subsistema a desarrollar en este proyecto, que será usado en las cafeterías universitarias por los empleados de las mismas. • SGPA: Subsistema para la gestión de los pedidos para los alumnos. Corresponde al subsistema a desarrollar por mi compañero de proyecto Alejando Santiago Montiel que será usado por los alumnos para realizar los pedidos. Estos pedidos serán posteriormente gestionados por el SGPPC. • Menú: Conjunto de productos que ofrece el restaurante por un precio fijo. En este conjunto puede haber productos opcionales y alternativos. • Oferta: Producto o conjunto de productos que se ofrecen para su venta por debajo del precio habitual durante un periodo de tiempo determinado. El objetivo principal es la captación de clientes. • Pedido o comanda: Conjunto de productos (incluyendo ofertas y/o menús) que son solicitados por uno o varios alumnos en una fecha y hora concretas. • Review: Opinión sobre un producto por parte de un usuario del sistema en un momento determinado. Estas opiniones serán mostradas a otros usuarios en la página del producto en el SGPA. - 13 - Actores: • Empleado: Trabajador de la cafetería que atiende los pedidos. El sistema permite que se gestionen los permisos que posee, y que son necesarios para poder gestionar los pedidos. • Gerente: Trabajador responsable de la cafetería. Cuenta con los permisos de empleado y además, los de administración de cuentas, vista de gráficos de venta y CRUD de productos, categorías, menús y ofertas. • Alumnos: Usuarios de la cafetería que hacen uso del sistema para enviar sus pedidos. Se les requiere registrarse con el correo universitario para poder ser identificados como alumnos de una determinada universidad. 3.2. REQUISITOS FUNCIONALES Los requisitos funcionales especifican el funcionamiento del sistema. A continuación se detallan los requisitos de nivel usuario que deben reflejarse en el funcionamiento final del sistema: Requisito general: RF-1 Gestión de pedidos Descripción Operación RUD de pedidos ya creados por el SGPA Requisitos específicos RF-1.1 Visualización de pedidos RF-1.2 Estimaciones de tiempo automática para la recogida del pedido RF-1.3 Modificación de pedidos incluyendo la actualización del estado junto con fecha de recogida estimada del pedido RF-1.4 Eliminación del pedido - 14 - Requisito general: RF-2 Gestión de productos Descripción Operación CRUD de productos Requisitos específicos RF-2.1 Creación de productos RF-2.2 Visualización de productos RF-2.3 Modificación de productos RF-2.4 Eliminación productos RF-2.5 Asignación de alérgenos y etiquetas alimenticias. Requisito general: RF-3 Gestión de ofertas Descripción Operación CRUD de ofertas Requisitos específicos RF-3.1 Creación de ofertas RF-3.2 Visualización de ofertas RF-3.3 Modificación de ofertas RF-3.4 Eliminación de oferta Requisito general: RF-4 Gestión de menús Descripción Operación CRUD de menús Requisitos específicos RF-4.1 Creación de menús RF-4.2 Visualización de menús RF-4.3 Modificación de menús RF-4.4 Eliminación menús - 15 - Requisito general: RF-5 Visualización de estadísticas Descripción Visualizar las estadísticas de ventas. Requisitos específicos RF-5.1 Visualización de gráficos circulares que ilustren los niveles de ventas. RF-5.2 Visualización de gráficos de barras que ilustren los pedidos en un rango de fechas concreto. 3.3. REQUISITOS NO FUNCIONALES Los requisitos no funcionales para el sistema a desarrollar son los siguientes: • RNF-1: Predictibilidad. La fecha de recogida estimada debe ser generada automáticamente y ser compatible con el nivel productivo de la cafetería. • RNF-2: Usabilidad. El sistema debe ser intuitivo y fácil de usar, permitiendo un fácil aprendizaje para personas con poco experiencia usando entornos web. • RNF-3: Equidad. Se debe notificar al alumno con los cambios de estado de los pedidos (cuando el estado siguiente es: en proceso, preparado o cancelado) y con las variaciones de las estimaciones de tiempo para la preparación del pedido. • RNF-4: Accesibilidad. El sistema debe estar adaptado a dispositivos móviles y tabletas. 3.4. DIAGRAMA DE CASOS DE USO Los diagrama de casos de uso permiten representar que acciones realiza cada tipo de usuario en el sistema por lo que nos permite abstraernos hacia la funcionalidad. En la Ilustración 1 se analiza el sistema a desarrollar a través de este diagrama. - 16 - Ilustración 1.- Diagrama de casos de uso 3.5. DIAGRAMA DE SECUENCIA El diagrama de secuencia determina los diferentes escenarios de uso del sistema a desarrollar. Los casos de uso mas determinantes del apartado anterior son ilustrados a través de este diagrama. En la ilustración 2 podemos observar el diagrama correspondiente al proceso de gestión de los pedidos por parte de los empleados de la cafetería. Podemos diferenciar los siguientes procesos: • Filtrar los pedidos por fecha en la que fueron creados o estado en el que se encuentran actualmente. Estos filtros son pasados como argumentos a las vistas (mensaje 1 a 5). • Mostrar pedidos filtrados de acuerdo a los filtros anteriormente validados (mensaje 4 y 5). - 17 - • Editar un pedido determinado (mensaje 6 a 14) siendo “N” el ID del pedido y “data” la informacin del mismo. Este pedido es validado (mensaje 9) para comprobar que no se encuentra en los estados “cancelado” o “entregado” en los que la modificación no esta permitida. • Actualización del pedido con la nueva información introducida por el usuario “NewData” (mensaje 11 a 14). Ilustración 2.- Diagrama de secuencia de Gestionar pedido En la Ilustración 3 podemos observar la gestión de menú por parte de los encargados de la cafetería. Los procesos de gestión de las ofertas y de las categorías son muy similares al de gestión de menús, por lo que procedemos a analizar este último: • Creación de menú (mensaje 1 a 8). Se le muestra una serie de campos a rellenar al usuario que son validados y creados en la base de datos. Posteriormente, se hace uso de la vista “VerMen” para visualizar el men anteriormente creado. - 18 - • Visualización de menú (Mensaje 7 a 8 y 16 a 17). A partir de los datos extraídos de la base de datos, se modela la vista del menú con sus campos correspondientes rellenos. • Editar un menú determinado (mensaje 9 a 17) siendo “N” el ID del menú y “data” la informacin del mismo. Los nuevos datos correspondientes a la edicin sern enviados como “newData” y sern actualizados en la base de datos (mensaje 14). Ilustración 3.-Diagrama de secuencia de Gestionar menú En la Ilustración 4 podemos observar la generación y exportación de estadísticas por parte de los encargados de las cafeterías. • Filtrar los pedidos a partir de los que se genera los estadísticos (mensaje 1 a 4). Estos filtros son validados por la vista “viewEstadisticas”. Los pedidos que cumplan las condiciones serán traídos de la base de datos. - 19 - • Generación de los estadísticos a partir de los pedidos filtrados anteriormente (mensaje 5). Posteriormente, los gráficos generados son mostrados al encargado (mensaje 6). • Exportación de los gráficas visualizadas en un archivo PDF (mensaje 7 a 9). Ilustración 4.- Diagrama de secuencia de estadísticas - 20 - 3.6. DISEÑO 3.6.1. DIAGRAMA DE CLASES Los diagramas de clases son uno de los diagramas más útiles en UML, ya que trazan claramente la estructura de un sistema concreto al modelar sus clases, atributos, operaciones y relaciones entre objetos. Tras estudiar los requisitos funcionales a fondo, hemos concluido con dieciocho entidades con sus respectivas relaciones entre ellas. En la Ilustración 5 se muestra el diagrama. Ilustración 5.- Diagrama de clases - 21 - A continuación procedemos a explicar las entidades que no han sido definidas anteriormente: • Alérgeno: información alimentaria obligatoria del producto que se indicará en un lugar destacado, de manera que sea fácilmente visible. • Etiqueta: información alimentaria complementaria del producto hace referencia a los términos alimentarios como halal, vegano, vegetariano, etc… • OfertaPedido, ProductoPedido y MenuPedido: Tablas intermedias que almacena la cantidad y el precio del producto, menú o oferta en ese pedido concreto. • MenuProducto y OfertaProducto: Entidades intermedia implementadas para relacionar los productos con las ofertas y los menús. Estas entidades se almacena la cantidad de producto que se ha relacionado con cada entidad. 3.6.2. PROTOTIPADO: MOCKUPS Una vez definido el diagrama de entidad relación, procedemos a hacer uso de la herramienta de creación de mockups llamada balsamiq [1]. Esta aplicación web nos permite crear fácilmente mockups que son utilizados para refinar los requisitos. A continuación se detallan los principales mockups realizados: • La Ilustración 6 muestra la vista para la creación y modificación de los menús, que se asemeja a la de creación y modificación de las ofertas (por ello se omiten). • La Ilustración 7 muestra cómo se listan los productos, que es equivalente al listado de ofertas, pedidos, menús y categorías. • La Ilustración 8 muestra la edición de pedidos, que puede incluir acciones como añadir o eliminar ofertas o productos. • La Ilustración 9 muestra la vista de creación/modificación de productos donde se puede observar cómo se le asignan los alérgenos y las etiquetas alimenticias a los productos, además de las grasas saturadas y las calorías. - 28 - Ilustración 14.- Creación de oferta 3.6.3.4. Pedidos La Ilustración 15 muestra la vista a desarrollar para la edición de pedidos. Ilustración 15.- Edición de pedido - 29 - En esta vista son observables los siguientes detalles: • Los menús, ofertas y productos son añadidos o eliminados del pedido a través de esta vista. La función autocompletar facilita la búsqueda de los mismos. Para su eliminación basta con poner a cero la cantidad o, en el caso de los productos, pulsar el botón eliminar en la última columna de la fila del producto. • El alumno acudirá a recoger el pedido con una imagen correspondiente a un código QR. El empleado lo escaneará y comparará el código resultante con el código de confirmación del pedido situado debajo del código QR en la vista del pedido. • La fecha de recogida estimada del pedido se aproxima por el algoritmo de planificación desarrollado con la finalidad que distribuir la carga de trabajo en base a la capacidad productiva de la cafetería y el tiempo medio de preparación de cada producto elegido. • Como se observa en la ilustración 16, los cambios de estado del pedido son registrados junto al usuario del empleado que los realizó. El cliente es notificado vía email cuando el pedido transita a los estados preparado, entregado o cancelado. • Un pedido puede ser creado por un alumno o un grupo de alumnos. Ilustración 16.-Registros de cambios de estado de un pedido - 30 - En la Ilustración 17 podemos observar los dos filtros disponibles para el listado de los pedidos: el rango de fechas de la creación del pedido y el estado en el que se encuentran. Ilustración 17.- Listado de pedidos con acciones rápidas En esta vista cabe destacar las acciones rápidas disponible para los pedidos listados detalladas a continuación: • Edición del pedido. Este botón es un acceso directo a la vista de editar pedido ya que el proceso anterior requería ir a través de la visualización del pedido. • Ver pedido. Redirige a la vista del pedido, donde se pueden observar los detalles del mismo. • Cancelación del pedido. Muestra un cuadro de dialogo (Ilustración 18) en el que aparece un cuadro de texto junto a dos botones para marcar el pedido como no recogido o eliminado (cancelado). En este último caso, se deberá escribir un comentario en el cuadro de texto que explique el motivo de la cancelación. • Marcar estado rápido. Muestra un cuadro de dialogo en el que se muestra el código QR del pedido junto al código de confirmación del mismo y - 31 - dos botones para marcar el pedido como preparado o recogido (Ilustración 19). Ilustración 18.- Pedido recogido o preparado Ilustración 19.- Pedido cancelado o no recogido 3.6.3.5. Categorías En la Ilustración 20 podemos observar la vista de creación de categorías en la que se puede añadir una imagen de captación, un nombre y una descripción. Para añadir los productos, se ha implementando la misma función autocompletar anteriormente descrita. También, se ha añadido un campo llamado tiempo de preparación medio (TPM) que nos permitirá establecer el tiempo medio que dedica la cocina a la - 32 - preparación de un tipo de producto. Este campo será usado por el algoritmo de planificación de los pedidos. Ilustración 20.- Vista de creación de categoría Estas categorías son listadas junto con el número de productos pertenecientes a cada categoría. (Ilustración 21). Ilustración 21.- Vista del listado de categorías - 33 - 3.6.3.6. Informes Las vistas a desarrollar son las encargadas de satisfacer el requisito funcional número 5 consistente en la generación de gráficos circulares y de barras que ilustren los niveles de ventas y los pedidos realizados en rangos de fecha concretos. Para ello, se han dispuesto una serie de filtros que determinan los pedidos a tener en cuenta en la generación de los gráficos (Ilustración 22). Estos filtros son los siguientes: • Recurso: determina el tipo de diagrama a generar a elegir entre diagrama de pastel y diagrama de barras. Cada tipo de diagrama muestra diferente información que será detallada más adelante. • Rango de fechas: determina el rango de fechas en la que los pedidos a tener en cuenta fueron creados. • Estado: determina si solo se tendrán en cuenta los menús, las categorías, las ofertas y los productos que estén aun activos o ambos. • Estado del pedido: Determina el estado de los pedidos que serán tenidos en cuenta para la generación de los gráficos. Ilustración 22.- Filtros de pedidos en la vista de informes - 34 - En primer lugar, analizaremos los gráficos generados a partir de los diagramas de pastel (Ilustraciones 23 a 26). • Ventas por categorías (Ilustración 23): Se analizan los productos vendidos por cada categoría. Para ello, los productos vendidos a través de los pedidos son categorizados y cuantificados. • Menús vendidos (Ilustración 24): Se analizan los menús vendidos en cada pedido, agrupándolos y cuantificándolos. • Ofertas vendidas(Ilustración 25): Se analizan las ofertas servidas en cada pedido, agrupándolos y cuantificándolos. • Productos vendidos(Ilustración 26): Se analizan los productos servidos en cada pedido, agrupándolos y cuantificándolos. Ilustración 23.- Diagrama de pastel de las ventas por categoría - 35 - Ilustración 24.- Diagrama de pastel de los menús vendidos Ilustración 25.- Diagrama de pastel de las ofertas vendidas - 36 - Ilustración 26.- Diagrama de pastel de los productos vendidos En segundo lugar, analizaremos los gráficos generados a partir de los diagramas de barras (Ilustraciones 27 y 28). • Pedidos por estado (Ilustración 27): Se analizan el número de pedidos que están en cada estado en la base de datos. • Productos vendidos (Ilustración 28): Se analizan el número de pedidos que se crearon en una fecha determinada agrupándolos por dichas fechas. Ilustración 27.- Ofertas vendidas - 37 - Ilustración 28.-Productos vendidos 3.6.3.7. Algoritmo de planificación Para proporcionar una óptima planificación de los pedidos se ha requerido disponer de un algoritmo que estime el tiempo de preparación de pedidos de la forma más precisa posible. Este algoritmo deberá estimar el tiempo en el que los pedidos deberían estar preparados, en base al tiempo de preparación de sus productos, al nivel productivo de la cafetería y a la cantidad de pedidos encolados en ese momento. Para disponer de esta información, se han dispuesto una serie de atributos de clases que procedemos a explicar: • Capacidad productiva. Atributo de la entidad Cafetería que cuantifica el número de empleados medio encargados de preparar los productos pedidos. • Tiempo de preparación medio (TPM). Atributo de la entidad Categoría que expresa en minutos el tiempo de preparación medio de los productos pertenecientes a ella. En tiempo que toma un pedido en ser preparado será calculado sumando el tiempo de preparación de cada producto vinculado a el, incluyendo los productos vinculados a través de las ofertas y de los menús. - 44 - 6.3. MEJORAS POSIBLES La mejora principal sería la total integración de nuestro sistema con cada uno de los terminales de punto de venta actuales de las cafeterías universitarias. Esta sincronización nos permitiría integrar satisfactoriamente el sistema actual de pedidos de las cafeterías universitarias con el desarrollado en esta memoria, por lo que los pedidos creados en uno de los sistemas, fueran generados en el otro sistema. Esto permitiría que se siguiera usando el sistema actual para la gestión de pedidos y el sistema desarrollado para la gestión de productos, ofertas, menús y categorías, además de los automatizaciones desarrolladas. En cuanto al algoritmo de planificación de pedidos, una mejora esencial consistiría en implementar un motor de aprendizaje que permita al sistema aprender de los tiempos que han tomado los pedidos. Este aprendizaje permitiría mejorar las estimaciones de tiempo dadas a los clientes. - 45 - 7. BIBLIOGRAFÍA Y REFERENCIAS [1] Balsamiq. Herramienta de creación de MockUps. https://balsamiq.com/ [2] Justin Ellingwood. Instalación de Postgresql en Ubuntu 16.04. DigitalOcean. https://www.digitalocean.com/community/tutorials/como-instalar-y-utilizarpostgresql-en-ubuntu-16-04-es [3] Stef Maruch y Aahz Maruch. Python For Dummies. Wiley publishing. [4] Russell Miles y Kim Hamilton. Learning UML 2.0: A pragmatic introduction to UML. O’Reilly Media. [5] Página web oficial de Just Eat. https://www.just-eat.es/about [6] Pgina web oficial de Foster’s Holliwood. https://adomicilio.fostershollywood.es/ [7] Documentación oficial de Pycharm. https://www.jetbrains.com/pycharm/documentation/ - 46 - 8. ANEXOS Como resultado del desarrollo, hemos desarrollado los siguientes documentos: • Guía de uso del software desarrollado. Se trata de una guía rápida y practica de los procesos más comunes realizados por los empleados de las cafeterías. • Plan de pruebas e informe de resultados. Descripción de los test realizados a la aplicación con los resultados obtenidos después de su ejecución. • Plan de negocio. Análisis de la oportunidad de negocio de Cafetering. 8.1. PLAN DE PRUEBAS E INFORME DE RESULTADOS En esta sección mostraremos los casos de prueba que hemos diseñado y probado para evaluar el correcto funcionamiento del sistema desarrollado. Título Test gestionar producto Caso de uso Gestionar producto Precondición Usuario autenticado y con perfil Encargado ID Estado Entrada / acción del usuario Salida esperada Resultado 1 Vista de creación de producto 1. El usuario selecciona el estado. 2. El usuario introduce el nombre del producto. 3. El usuario introduce la descripción. 4. El usuario introduce las grasas. 5. El usuario introduce las calorías. 6. El usuario introduce el precio. 7. El usuario El sistema guardará el producto creado y redirigirá al usuario a la página donde se listan los productos. OK - 47 - selecciona imagen 8. El usuario pulsa botón guardar. 2 Vista de creación de producto 1. El usuario selecciona el estado. 2. El usuario introduce la descripción. 3. El usuario introduce las grasas. 4. El usuario introduce las calorías. 5. El usuario introduce el precio. 6. El usuario hace pulsa en el botón añadir en alérgenos. 7. El usuario introduce el nombre del alérgeno. 8. El usuario pulsa el botón guardar. El sistema se mantendrá en la misma página indicando que hay que introducir el nombre del producto. OK 3 Vista de edición de producto 1. El usuario pulsa en el botón editar pedido 2. El usuario introduce un nuevo nombre para el producto. 3. El usuario pulsa el botón guardar. El sistema redirigirá a la vista de ese pedido. El titulo ha cambiado. OK - 48 - Título Test gestionar pedido Caso de uso Gestionar pedido Precondición Usuario autenticado y con perfil empleado o encargado ID Estado Entrada / acción del usuario Salida esperada Resultado 1 Vista de edición de pedido 1. El usuario selecciona el nuevo estado. 2. El usuario pulsa el botón añadir oferta. 3. El usuario introduce la oferta. 4. El usuario introducirá una nueva fecha de recogida estimada 5. El usuario pulsa el botón guardar. El sistema redirigirá a la vista de ese pedido. El pedido tendrá el estado nuevo y tendrá la oferta seleccionada junto con la nueva fecha de recogida. OK 2 Vista de listado de pedidos 1. El usuario selecciona el botón de la papelera para un pedido 2. El usuario introduce un comentario 3. El usuario pulsa el botón eliminar El sistema te redirigirá otra vez a la página donde se listan los pedidos. El pedido no saldrá listado y el comentario será guardado en el pedido marcado como cancelado OK Título Test gestionar ofertas Caso de uso Gestionar ofertas Precondición Usuario autenticado y con perfil encargado ID Estado Entrada / acción del usuario Salida esperada Resultado 1 Vista de creación de la oferta 1. El usuario selecciona el estado. 2. El usuario introduce el titulo. 3. El usuario El sistema te redirigirá a la vista de la oferta creada. Se comprueba los campos con los OK - 49 - introduce la descripción. 4. El usuario introduce la fecha de validez. 5. El usuario introduce el descuento numérico. 6. El usuario selecciona el tipo de descuento “€”. 7. El usuario selecciona una imagen de captación. 8. El usuario pulsa el botón guardar. seleccionados anteriormente. 2 Vista de edición de oferta 1. Usuario selecciona un nuevo estado. 2. Usuario introduce nuevo título. 3. Usuario introduce nueva descripción. El sistema te redirigirá a la vista de la oferta con los campos modificados actualizados. OK 8.2. PLAN DE NEGOCIO 8.2.1. NUESTRA PROPUESTA Nuestra propuesta es una aplicacin que permita la realizacin de pedidos en las diferentes cafeterías de la Universidad de Mlaga. El objetivo es reducir las largas colas de espera que se forman a determinadas horas, ralentizando enormemente el servicio y provocando un gran estrés tanto entre alumnos como en el personal de la cafetera. En lugar de realizarse los pedidos nicamente en la barra de la cafetera, se ofrecera la posibilidad de realizarlos online a través de una página web adaptada a dispositivos móviles. Adems, la aplicacin permitiría realizar pedidos con varios - 50 - das de antelacin permitiendo realizar una mejor previsión de los suministros necesarios en la cafetera. 8.2.2. DESCRIPCIÓN COMERCIAL Nuestro sistema permitir a los clientes de las cafeteras de las universidades hacer sus pedidos de forma remota, lo que permitir reducir los tiempos de espera asociados a los pedidos fsicos. Esta idea surge debido al poco tiempo que los universitarios tienen para comer (a penas una hora) entre la ltima clase de la maana y la primera de la tarde. Este tiempo se ve reducido por el tiempo que dedica el alumnado a esperar para recoger su pedido. Nuestra aplicación aportar los siguientes beneficios: • Aumentar la eficiencia de los empleados de la cafetera, ya que stos sabrn a priori una estimación de la demanda de productos y podrn planificarse para prepararlos. • Aumentar la satisfaccin de los clientes y de los empleados. Los clientes no tendrn que esperar largas colas y los empleado no tendrn que soportar el estrés que ello supone. • Permitir ahorrar en stockaje de productos perecederos debido a la capacidad de planificación a corto y medio plazo que la aplicacin aporta. • Liberar carga de trabajo a los empleados, por lo que será necesario menos personal para atender los pedidos en la barra. 8.2.3. DESCRIPCIN TCNICA Nuestro sistema consta de dos subsistemas interconectados a través de una API. El primer subsistema es el que usan los clientes de la caferías para la creación de pedidos y el segundo en el que usan los empleados para la gestión de los pedidos. Este sistema se caracteriza por el bajo coste de implantacin del proyecto debido a que usaremos servidores VPS (como el AWS de Amazon o Aruba Cloud) y pagaremos nicamente por el uso y la carga de datos, por lo que no ser necesaria la adquisicin de servidores fsicos. - 51 - 8.2.4. ESTRATEGIAS DE ARRANQUE Para el arranque, ofertaremos a las cafeteras de las diferentes facultades de la Universidad de Mlaga un perodo de prueba gratuita, de manera que puedan durante ese tiempo comprobar los beneficios de su uso. Para la implementación del sistema, es necesaria una jornada de formación para los empleados que harán uso del sistema. El coste de desplegar el sistema es muy bajo. nicamente se requerirn los servidores donde se alojar el sistema (al ser remotos no ser necesaria una inversin inicial), y un monitor para la cocina de la cafetería. Adems, el sistema cuenta con una alta escalabilidad, debido al bajo coste de despliegue y a la facilidad de adaptar el sistema a diferentes escenarios una vez haya sido desarrollado el primer prototipo. Por tanto, una vez desarrollado y desplegado el sistema para una cafetera en particular, es posible llevar el sistema a las cafetería de otras facultades con mayor facilidad. 8.3. GUÍA DE USO 8.3.1. INTRODUCCIÓN Esta guía de uso se ha diseñado para asistir en el aprendizaje del software para la gestión de cafeterías universitarias. Esta guía se entregará después de un curso presencial donde se repasan los procesos que se deben seguir para realizar las tareas más comunes de la cafetería a través de este sistema. Se trata pues de una guía con un alto contenido gráfico, que permitirá facilitar el aprendizaje de los procesos que aquí se muestran. Se han omitido procesos como la generación de informes, gestión de menús y categorías al tratarse de procesos intuitivos o similares a los que se tratan en esta guía. - 52 - 8.3.2. LISTADO DE PEDIDO Y ACCIONES RÁPIDAS En la Ilustración 30 podemos observar como se listan los pedidos y las acciones rápidas disponibles. • Edición del pedido. Este botón es un acceso directo a la página donde se edita el pedido. El pedido solo será editable cuando no se encuentre en los estado “entregado” o “cancelado”. • Ver pedido. Redirige a la vista del pedido, donde se pueden observar los detalles del mismo. • Cancelación del pedido (1). Muestra un cuadro de dialogo en el que aparece un cuadro de texto junto a dos botones que permiten marcar el pedido como no recogido o eliminado (cancelado). En este último caso, se deberá escribir un comentario en el cuadro de texto que explique el motivo de la cancelación. • Marcar estado rápido (2). Muestra un cuadro de dialogo en el que se muestra el código QR del pedido junto al código de confirmación del mismo y dos botones que permiten marcar el pedido como preparado o recogido. Ilustración 30.- Guía visual para el listado de pedidos - 53 - También podemos observar los siguientes filtros de pedidos: • Rango de fechas: filtra por la fecha de creación del pedido. • Estado del pedido: filtra por el estado actual del pedido. El botón exportar genera un documento PDF con los pedidos filtrados. 8.3.3. EDICIÓN DE PEDIDO En esta vista, mostrada en la Ilustración 31, vamos a poder modificar los siguientes campos: • El estado del pedido (1). Permite activar o desactivar el producto. • La fecha de recogida del pedido (2). Indica la fecha en la que el pedido debería estar listo. Este campo es generado por el sistema en base al número de pedidos y a la capacidad productiva de la cafetería. • Menús pedidos (3). Menús seleccionados para el pedido. • Ofertas pedidas (4). Ofertas seleccionados para el pedido. • Productos pedidos (5). Productos seleccionados para el pedido. • Añadir nuevo(6). Cada botón permite añadir un producto, oferta o menú nuevo al pedido. • Código de confirmación del pedido (7). Código autogenerado que se asocia al pedido. El alumno acudirá a la cafetería con el código QR, que tras su escaneado, debe coincidir de forma exacta con el código mostrado. • Guardar los datos (8). Botón de confirmación que guarda los cambios realizado en el pedido.