Diferencias de cuadrados, Esquemas y mapas conceptuales de Derecho

¡Descarga Diferencias de cuadrados y más Esquemas y mapas conceptuales en PDF de Derecho solo en Docsity! SISTEMA WEB PARA LA GESTIÓN DE ÓRDENES DE PEDIDOS EN RESTAURANTES DE COMIDAS Diego Alejandro Peña Reyes Oscar Javier Cely Berdugo Universidad Distrital Francisco José de Caldas Tecnoloǵıa en Sistematización de Datos Facultad Tecnológica Bogotá D.C. Marzo de 2021 SISTEMA WEB PARA LA GESTIÓN DE ÓRDENES DE PEDIDOS EN RESTAURANTES DE COMIDAS Diego Alejandro Peña Reyes Oscar Javier Cely Berdugo Proyecto de grado para optar al t́ıtulo Tecnólogo en Sistematización de Datos Asesor: Hector Florez Fernandez Universidad Distrital Francisco José de Caldas Tecnoloǵıa en Sistematización de Datos Facultad Tecnológica Bogotá D.C. Marzo de 2021 Resumen En Bogotá hay muchos establecimientos de régimen simplificado que ofrecen productos alimen- ticios, estos establecimientos no cuentan con las herramientas tecnológicas para brindar su máxima eficiencia en sus tiempos de servicio y administrar la información del negocio de una forma rápida y sencilla, igualmente muchos de estos establecimientos disminuyeron sus ventas y su eficiencia conside- rablemente debido a la pandemia del covid-19 por esta razón surge la necesidad de reducir el contacto personal entre los clientes y los empleados de estos locales. En esta monograf́ıa se presenta una propuesta tecnológica para mejorar la eficiencia de locales de comida, de tal manera de lo que se presenta a continuación es la oportunidad de implementar una herramienta tecnológica que apoye los locales de comida en su administración y en la mayoŕıa de necesidades que pueden tener estos establecimientos. ii Abstract In Bogotá there are many simplified regime establishments that offer food products, these esta- blishments do not have the technological tools to provide maximum efficiency in their service times and manage business information quickly and easily, and many of these establishments also decreased. their sales and their efficiency considerably due to the covid-19 pandemic, for this reason there is a need to reduce personal contact between customers and employees of these premises. This monograph presents a technological proposal to improve the efficiency of food stores, in such a way that what is presented below is the opportunity to implement a technological tool that supports food stores in their administration and in most needs that these establishments may have. iii Tabla de Contenido Agradecimientos I Resumen II Abstract III Introducción 1 1. Planeación 2 1.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.2. Objetivos Espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7. Marco de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.1. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.1.1. Sistema de Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.1.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.1.3. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7.1.4. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7.1.5. Bases de Datos Relacionales . . . . . . . . . . . . . . . . . . . . . . . 8 1.7.1.6. ClearDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.1.7. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.1.8. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.2. Marco Metodológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.2.1. Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7.2.1.1. Recolección de requisitos y/o levantamiento de información . 11 1.7.2.1.2. Planificación y Estimación . . . . . . . . . . . . . . . . . . . 11 1.7.2.1.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.2.1.4. Revisión y Retrospectiva . . . . . . . . . . . . . . . . . . . . 12 1.7.2.1.5. Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.2.2. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 iv Tabla de Contenido 5.4.15. Ver estad́ısticas de ventas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.4.16. Consultar item inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.4.17. Registrar item inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.4.18. Consultar movimiento de bodega . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.4.19. Agregar existencias en bodega . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.4.20. Extraer existencias en bodega . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.4.21. Eliminar orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.5. Cocinero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.5.1. Órdenes en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.5.2. Cambiar estado de orden a en preparación . . . . . . . . . . . . . . . . . . . . . 120 5.5.3. Cambiar estado de orden a preparado . . . . . . . . . . . . . . . . . . . . . . . 121 5.6. Cajero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.6.1. Órdenes en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.6.2. Cambiar estado de orden a pagado . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.6.3. Mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.6.4. Seleccionar mesa por atender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.7. Mesero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.7.1. Órdenes en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.7.2. Mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.7.3. Tomar pedido de una mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.7.4. Órdenes en curso móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.7.5. Mesas disponibles movil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 5.7.6. Confirmar entrega de orden movil . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.7.7. Confirmar entrega de orden web . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.8. Encargado de bodega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.8.1. Consultar item inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.8.2. Registrar item inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.8.3. Consultar movimiento de bodega . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.8.4. Agregar existencias en bodega . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 5.8.5. Extraer existencias en bodega . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Recomendaciones 142 Conclusiones 143 Bibliograf́ıa 144 vii Lista de Figuras 1.1. Metodoloǵıa SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3. Cronograma final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1. Historia de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Diagrama de Clases aplicativo web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Diagrama de Clases aplicativo móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3. Diagrama de proceso login de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4. Diagrama de proceso solicitar pedido (1/3) . . . . . . . . . . . . . . . . . . . . . . . . 30 3.5. Diagrama de proceso solicitar pedido (2/3) . . . . . . . . . . . . . . . . . . . . . . . . 31 3.6. Diagrama de proceso solicitar pedido (3/3) . . . . . . . . . . . . . . . . . . . . . . . . 31 3.7. Diagrama de proceso ingreso de mercanćıa a la bodega (1/2) . . . . . . . . . . . . . . 32 3.8. Diagrama de proceso ingreso de mercanćıa a la bodega (2/2) . . . . . . . . . . . . . . 32 3.9. Registro de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.10. Diagrama de proceso estadistica de ventas . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1. Modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2. Modelo NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3. Tablero trello sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4. Pagina de inicio proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.5. Sistema de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.6. Dashboard del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.7. Modulo de creacion de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.8. Modulo de visualizacion de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.9. Modulo de edicion de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.10. Modulo de cambio de foto de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.11. Modulo de visualizacion informacion de usuario . . . . . . . . . . . . . . . . . . . . . . 69 4.12. Tablero trello sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.13. modulo de mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.14. Sistema de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.15. modulo de pagar pedido cajero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.16. Base de datos no relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.17. Módulo de estad́ısticas de ventas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.18. Módulo de cancelación de pedidos en curso . . . . . . . . . . . . . . . . . . . . . . . . 72 viii Lista de Figuras 4.19. Módulo de asignación de mesas por atender cajero . . . . . . . . . . . . . . . . . . . . 73 4.20. Tablero trello sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.21. Módulo de filtro de mercanćıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.22. Módulo de visualización de información de mercanćıa . . . . . . . . . . . . . . . . . . . 74 4.23. Módulo de registro de mercanćıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.24. Módulo de agregar existencias de bodegal . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.25. Módulo de extraer existencias de bodega . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.26. Módulo de filtrar movimientos de bodega . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.27. Módulo de visualizar detalles de movimiento de bodega . . . . . . . . . . . . . . . . . 77 4.28. Módulo de materia prima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.29. Tablero trello sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.30. Módulo móvil de mesas por atender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.31. Módulo web de mesas por atender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.32. Módulo móvil de órdenes en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.33. Módulo web de órdenes en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.34. Módulo web de creación de orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.35. Módulo móvil de creación de orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.36. Módulo móvil de estado de mesas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.37. Módulo web de estados de mesas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.1. Prueba 1 - imágen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2. Prueba 1 - imágen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3. Prueba 2 - imágen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.4. Prueba 3 - imágen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5. Prueba 3 - imágen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.6. Instalar aplicación: 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.7. Instalar aplicación: 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.8. Instalar aplicación: 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.9. Instalar aplicación: 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.10. Opciones modulo de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.11. modulo de mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.12. Opciones modulo de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.13. Módulo de consultar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.14. Opciones módulo de gestionar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.15. Módulo tipo de documento.png . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.16. Opciones módulo de gestionar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.17. Módulo de gestionar categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.18. Opciones módulo categoŕıas producto de venta . . . . . . . . . . . . . . . . . . . . . . 99 5.19. Módulo de consultar producto de venta . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.20. Opciones módulo categoŕıas producto de venta . . . . . . . . . . . . . . . . . . . . . . 100 5.21. Módulo agregar producto de venta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.22. Opciones módulo ordenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.23. Módulo mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.24. Módulo mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.25. Modulo mesas disponibles con mesa por atender . . . . . . . . . . . . . . . . . . . . . 103 5.26. Módulo mesas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 ix Lista de Tablas 1.1. Proyectos relacionados al presente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Comparativa de los proyectos anteriores con el presente . . . . . . . . . . . . . . . . . 5 1.3. Costo de Integrantes del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4. Costo de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3. identificacion de roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4. actividades segun rol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5. definicion de horas de trabajo por sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6. planeacion de historias en cada sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7. ejemplo de historia terminada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2. inventories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. bodega transaction inventories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4. bodega transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.5. users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.6. phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.7. id types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.8. rols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.9. sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.10. product sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.11. products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.12. categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.13. password resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.14. migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.15. failed jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.16. sessiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.17. historias de usuario sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.18. sprint backlog 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.19. product backlogs print 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.20. historias de usuario sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.21. sprint backlog sprin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.22. product backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 xii Lista de Tablas 4.23. historias de usuario sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.24. sprint backlog 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.25. product backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.26. historias de usuario sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.27. sprint backlog 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.28. product backlogs print 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1. Formulario de pruebas 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2. Formulario de pruebas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3. Formulario de pruebas 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 xiii Introducción La ciudad de Bogotá, la capital colombiana alberga más de 8 millones de habitantes y con ello un sin número de tradiciones culturales, experiencias, historia y demás factores de las que deriva uno de los temas que es parte del desarrollo tuŕıstico y económico no solo de la ciudad, sino también de todo el páıs. La gastronomı́a. La gastronomı́a juega un rol cada vez más fundamental no solo en la oferta tuŕıstica del páıs, sino también en el desarrollo económico de este. Y es que si hablamos de cifras, vemos que a corte de febrero del 2021 y según el medio period́ıstico Portafolio, en Colombia hay 51.670 restaurantes con expendio a la mesa[1]. Dado lo anterior, es importante reconocer la importancia que juega el papel de la gastronomı́a no solo en las zonas gastronómicas que existen, grandes restaurantes, plazas de mercado sino también en aquellos restaurantes de régimen simplificado o de barrio como los conocemos en los que también se incluyen pasteleŕıas y cafeteŕıas. Y es que en las cifras mencionadas anteriormente no se incluyen como tal los negocios dedicados también a la gastronomı́a como cafeteŕıas, pasteleŕıas, asaderos, y entre otros tipos de expendio. Cuyas cifras no deben ser pasadas por alto ya que estamos hablando de incluso más de 40.000 establecimientos adicionales. Sumado a esto, hablamos de más de 90.000 negocios al servicio de la gastronomı́a en el páıs. 1 Caṕıtulo 1. Planeación Tabla 1.1: Proyectos relacionados al presente Año Autores Carrera Universidad 2015 Burgos Cando, Carlos Xavier Ingeniero en sistemas informáticos y de computación ESCUELA POLITÉCNICA NACIONAL URL https://bibdigital.epn.edu.ec/bitstream/15000/10337/3/CD-6157.pdf Titulo DESARROLLO DE UN SISTEMA WEB PARA LA GESTIÓN DE PEDIDOS EN UN RESTAURANTE. APLICACIÓN A UN CASO DE ESTUDIO. Año Autores Carrera Universidad 2015 Espinosa Roberto, León Juan Carlos Ingenieŕıa de sistemas UNIVERSIDAD POLITÉCNICA SALESIANA SEDE GUAYAQUIL URL https://dspace.ups.edu.ec/bitstream/123456789/10329/1/UPS-GT001240.pdf Titulo IMPLEMENTACIÓN DE SISTEMA PARA RESTAURANTES PARA GESTIÓN DE PEDIDOS Y FACTURACION ELECTRONICA (AMBIENTE MÓVIL Y SISTEMA ADMINISTRABLE DESDE UNA PC) Año Autores Carrera Universidad 2015 Acevedo Diana, Martiño Juan Especialización en gerencia de proyectos UNIVERSIDAD LIBRE URL https://repository.unilibre.edu.co/bitstream/handle/10901/8709/Último %20corregido %201711.pdf?sequence=1&isAllowed=y Titulo DESARROLLO DE UN MODELO DE RESTAURANTE VIRTUAL QUE OFREZCA UN MENÚ DE PRODUCTOS ALIMENTICIOS POR PORCIONES PARA EL ALMUERZO EN LA LOCALIDAD DE FONTIBÓN, EN LA CIUDAD DE BOGOTÁ 4 Caṕıtulo 1. Planeación A continuación, se muestra una tabla comparativa entre los proyectos existentes y el propuesto, los ı́tems marcados con una X representan que aquel proyecto no cumple con esa caracteŕıstica y los ı́tems marcados con un Xrepresenta que aquel proyecto cumple con esa caracteŕıstica. Tabla 1.2: Comparativa de los proyectos anteriores con el presente Aplicaciones Web Android Gestor de Inventarios Gestor de cobros Modulo de Cocinero DESARROLLO DE UN SISTEMA WEB PARA LA GESTIÓN DE PEDIDOS EN UN RESTAURANTE. APLICACIÓN A UN CASO DE ESTUDIO. 4 4 6 4 6 IMPLEMENTACIÓN DE SISTEMA PARA RESTAURANTES PARA GESTIÓN DE PEDIDOS Y FACTURACIÓN ELECTRÓNICA. 4 4 6 4 6 DESARROLLO DE UN MODELO DE RESTAURANTE VIRTUAL QUE OFREZCA UN MENÚ DE PRODUCTOS ALIMENTICIOS POR PORCIONES PARA EL ALMUERZO EN LA LOCALIDAD DE FONTIBÓN, EN LA CIUDAD DE BOGOTÁ. 4 4 4 6 6 SISTEMA DE GESTIÓN DE ÓRDENES PARA RESTAURANTES SGRUD 4 4 4 4 4 5 Caṕıtulo 1. Planeación 1.3. Justificación De acuerdo con la problemática planteada y al estado de arte se puede concluir que surge la necesidad de desarrollar un sistema que brinde una mayor eficiencia en la toma de los pedidos, permita una comunicación rápida y eficiente, tenga un control de las ventas y mercanćıa en bodega. Como se puede apreciar en la tabla 1.2, nuestro proyecto propuesto es superior en funcionalidad y beneficio ya que tiene módulos que los demás proyectos no, ya que este contiene funcionalidad web y móvil, gestor de inventarios , gestor de cobros y un módulo para los cocineros. 1.4. Objetivos 1.4.1. Objetivo General Desarrollar un sistema de información web con aplicativo móvil para la gestión de pedidos en establecimientos de régimen simplificado que ofrecen almuerzos y otros alimentos. 1.4.2. Objetivos Espećıficos Diseñar y desarrollar el módulo por el cual el mesero registrara los pedidos de los clientes. Diseñar y desarrollar un módulo que ilustre las estad́ısticas de las ventas realizadas. Diseñar y desarrollar un módulo de cobros. Diseñar y desarrollar un módulo que permita la toma de los pedidos por parte de los meseros. 1.5. Alcances El sistema de gestión permite a los meseros saber el estado de las mesas y de las órdenes en tiempo real. El sistema de gestión permite la toma de pedidos de una manera rápida y sencilla. El sistema de gestión permite que los cocineros cambien el estado de la orden cuando la orden sé este preparando y cuando ya esté preparada. El sistema de gestión permite que los meseros cambien el estado de la orden cuando la orden sea entregada por el mesero. El sistema de gestión permite que los cajeros cambien el estado de la orden cuando el pedido sea pagado por el cliente. 6 Caṕıtulo 1. Planeación permitiendo un manejo de datos estructurado y garantizando la seguridad de sus datos, existen tres tipos de relación entre tablas, relación de uno a uno, de uno a muchos y de muchos a muchos. 1.7.1.6. ClearDB ClearDB es un servicio de base de datos que provee al gestor MySQL y que se ejecuta en múltiples computadores en la nube diseñado para eliminar la necesidad de almacenar y administrar una base de datos en un servidor local. Dentro de otras caracteŕısticas que tiene este servicio, podemos ejecutar nuestras bases de datos locales implementadas en MariaDB vs MySQL en la nube usando este servicio. 1.7.1.7. Framework Es una plataforma concreta o conceptual donde un código en común con funcionalidad genérica puede ser especializado selectivamente o sobre escrito por desarrolladores o usuarios. Estos toman la forma de libreŕıas, las cuales se pueden reusar en cualquier lado y memento de un software bajo desarrollo. 1.7.1.8. Bootstrap Es un framework open source creado por los desarrolladores de Twitter convirtiéndose en uno de los frameworks más populares para el desarrollo de páginas web y es uno de los proyectos open source más importantes del mundo. Bootstrap contiene una combinación de código HTML, CSS y Javascript diseñado para ayudar a construir interfaces web de usuario. Es una herramienta fácil de usar por su amplia documentación donde se explica cómo implementarla en un sitio web y a través de ejemplos existentes en la documentación se pueden acoplar a una página propia dándole un buen aspecto visual y comportamental en menos tiempo a diferencia de hacerlo manual. 1.7.2. Marco Metodológico La metodoloǵıa que usaremos en este proyecto es la metodoloǵıa SCRUM, que se basa en me- todoloǵıas de desarrollo ágil, que permite construir el proyecto de manera iterativa, enfocándose en módulos, funciones y caracteŕısticas que agregan más valor. En nuestra industria, en comparación con las metodoloǵıas de desarrollo tradicionales, Scrum permite a los equipos de desarrollo generar más y mejor software en menos tiempo, mientras que las metodoloǵıas de desarrollo tradicionales no fomen- tan la transparencia o la integración continua. Scrum no solo se usa en el campo del software, sino también en diferentes industrias que requieren flexibilidad y agilidad en el proceso de construcción del producto. Antes de hablar de los procesos, es necesario aclarar que según la terminoloǵıa Scrum define un Sprint como aquel evento temporal con una duración máxima de un mes en el que debe crearse una 9 Caṕıtulo 1. Planeación versión utilizable del producto. Cada Sprint cumple con los siguientes elementos: reunión de planeación, Daily Scrum, trabajo de desarrollo, revisión del Sprint y retrospectiva del Sprint. Figura 1.1: Metodoloǵıa SCRUM [7] El scrum se ejecuta siempre y cuando se indique un proyecto a realizarse con esta metodoloǵıa, una vez el proyecto se ejecuta en base en sprints, de duración fija y concreta, que se planifican al arrancar cada sprint, con las Daily cada 24 horas. En cada sprint se resuelve o construye el Sprint backlog, que se integra al final del sprint con el resultado de sprints anteriores, conformando un producto entregable. 1.7.2.1. Etapas La metodoloǵıa de desarrollo Scrum considera cinco fases para realizar un trabajo. Estas etapas están definidas por un ĺımite de tiempo para llevar a cabo una ejecución, además se crea un mecanismo para que las reuniones no sobrepasen un tiempo estimado para aśı no perder tiempo innecesariamente. De esta manera se garantiza que funcione como una metodoloǵıa ágil. 10 Caṕıtulo 1. Planeación 1.7.2.1.1. Recolección de requisitos y/o levantamiento de información El proceso parte de la realización de una lista de objetivos o requisitos fundamentales del sistema donde se detalle claramente hacia dónde se quiere llegar y las expectativas que se tienen, para qué de este modo estos documentos sirvan como base para un plan de proyecto. Esta información debe ser diligenciada y entregada por el cliente que solicita el sistema. En este primer proceso por llamarlo de alguna forma interviene el cliente por ser el mayor portador de conocimientos sobre el sistema qué se quiere llevar a cabo, claro está a nivel de expectativas y de una posible solución a un problema. Además, para ayudarlo a expresar sus ideas está a su servicio el Scrum master, que es la persona que ejerce el papel del director del proyecto y encargado de eliminar los obstáculos que impiden que el equipo de desarrollo alcance el objetivo del sprint. En conclusión, podemos decir que esta fase se compone de la explicación del proyecto, buscar intereses y/o expectativas, además de identificar roles claves del proyecto como el Scrum Master, Product Owner, interesados, equipo del proyecto. Los siguientes son los procesos exactos de esta fase: Crear la visión del proyecto: expectativas del cliente, dirección del proyecto. Identificar al Scrum Máster y a los interesados o socios del proyecto: una vez aclarada la parte de expectativas, posibles soluciones, meta acordada, se les explica a los integrantes del grupo de programadores para que ellos decidan sobre sus intereses si participaran y qué rol cumplirán dentro de la metodoloǵıa de desarrollo. Formación del equipo Scrum: se conforma el equipo y se realiza la asignación de tareas. Desarrollo de épica(s): se conforma el equipo y se realiza la asignación de tareas. Creación de la lista priorizada de pendientes del producto Realizar el plan de lanzamiento (Conduct Release Planning) 1.7.2.1.2. Planificación y Estimación Se plantea cómo se realizará el proyecto detallando cada acción a realizar para que sea de lo más claro posible para todos los interesados. Esto incluye: Elaborar historias de usuario Aprobar, estimar y asignar historias de usuarios Elaboración de tareas Estimar tareas Elaboración de la lista de pendientes del Sprint 11 Caṕıtulo 1. Planeación 1.8.2. Factibilidad Operativa El proyecto será elaborado por los estudiantes Diego Alejandro Peña Reyes y Oscar Javier Cely Berdugo los cuales cuentan con el conocimiento tecnológico para desarrollar el proyecto. Adicional- mente, el ingeniero Hector Florez será el encargado de brindar asesoŕıa a lo largo del proyecto. 1.8.3. Factibilidad Económica El costo del proyecto se presenta con base en: 1) el costo de los equipos requeridos para la elabo- ración del diseño y desarrollo de los prototipos que requiere el proyecto y 2) el costo de mano de obra de los integrantes. La Tabla 1.3 presenta el costo total de los integrantes del proyecto. La Tabla 1.4 presenta el costo total de los demás recursos requeridos para elaborar el proyecto. Tabla 1.3: Costo de Integrantes del Proyecto Integrante Valor hora Horas Valor total Diego Alejandro Peña Reyes $15.000 240 $3.600.000 Oscar Javier Cely Berdugo $15.000 240 $3.600.000 Hector Florez $100.000 20 $2.000.000 Total $9.200.000 Tabla 1.4: Costo de Recursos Recurso Cantidad Valor Unitario Valor total Equipos de Computo 2 $1.800.000 $3.600.000 Luz (Mensual) 2 $40.000 $240.000 Internet (Mensual) 2 $90.000 $540.000 Hosting (Anual) 1 $200.000 $200.000 Dominio.com.co (Anual) 1 $25.000 $25.000 Tablets 4 $800.000 $3.200.000 Total $7.805.000 1.8.4. Factibilidad Legal Teniendo en cuenta que el software utilizado es de libre acceso, no se cuentan con implicaciones legales que afecten al proyecto. 1.9. Cronograma La Figura 1.2 presenta el cronograma. 14 Caṕıtulo 1. Planeación F ig u ra 1. 2: C ro n og ra m a 15 Caṕıtulo 1. Planeación 1.10. Cronograma final La Figura 1.2 presenta el cronograma final. Figura 1.3: Cronograma final 16 Caṕıtulo 2. Análisis 16 Como mesero Quiero ver las mesas del establecimiento y ver si están ocupadas o no Para saber la disposición de cada mesa en el estableci- miento 17 Como mesero Quiero poder ver las órdenes en curso que un cliente me ha solicitado Para estar pendiente de cuando debo recogerlas y en que estado del proceso se encuentran. 18 Como mesero Quiero generar pedidos a través de una aplicación en una tablet y que estos se puedan editar antes de su preparación Para ser enviados al área de cocina, preparados y posteriormente entregados 19 Como mesero Quiero editar los pedidos que aún no estan en estado ”en preparación” Para dar al cliente la posibilidad de cambiar algo en el pedido 2.2. Definición de Actores Se establecen los actores que se presentan en la tabla 2.2. Tabla 2.2: Actores Nombre Administrador Descripción Actor encargado de gestionar todo lo relacionado con el sistema de ges- tion. Además, puede modificar cualquier dato del sistema Atributos Nombres, apellidos, correo, contraseña, foto de perfil, tipo de identifica- ción , rol Nombre Mesero Descripción Actor encargado de crear ordenes y antender mesas en el sistema. Atributos Nombres, apellidos, correo, contraseña, foto de perfil, tipo de identifica- ción , rol Nombre Cocinero Descripción Actor encargado de crear de cambiar estado de ordenes cuando estas esten preparadas para llevar al sistema. Atributos Nombres, apellidos, correo, contraseña, foto de perfil, tipo de identifica- ción , rol Nombre Cajero Descripción Actor encargado de cambiar estado de orden cuando esta sea pagada. Atributos Nombres, apellidos, correo, contraseña, foto de perfil, tipo de identifica- ción , rol 19 Caṕıtulo 2. Análisis Nombre Bodeguero Descripción Actor encargado de administrar la mercancia en bodega . Atributos Nombres, apellidos, correo, contraseña, foto de perfil, tipo de identifica- ción , rol 2.3. Identificacion de roles Podemos ver el identificación de roles en la tabla 2.3 Tabla 2.3: identificacion de roles Rol Asignacion Scrum Master Diego Alejandro Peña Reyes y Oscar Javier Cely Berdugo Product Owner Hector Arturo Florez Fernandez Development Team Diego Alejandro Peña Reyes y Oscar Javier Cely Berdugo 2.4. Lista de actividades según el rol Podemos ver las actividades segun rol en la tabla 2.4 Tabla 2.4: actividades segun rol Rol Asignacion Scrum Master *Dictaminar conflictos que interrumpan el normal desarrollo del proyecto *Autentificar que la metodologia se desarrolle de manera adecuada *Resolver dudas del proyecto, brindado la guia necesaria *Revisar y validar los avances del proyecto al final de cada Sprint *Realizar las correcciones y/o observaciones de cada uno de los avances presentados del proyecto Product Owner *Evidenciar la asignacion de labores para cada Sprint *Seleccionar los requisitos que se desarrollan en cada Sprint *Gestionar el Product Backlog y redactar las historias de usuario Development Team *Solucionar cada una de las tareas incluidas en el Product Backlog *Desarrollar cada una de las tareas priorizadas en el Sprint Backlog *Realizar un seguimiento diario del avance del proyecto *Garantizar la calidad de cada tarea antes de realizar la entrega 20 Caṕıtulo 2. Análisis 2.5. Definicion de Sprint El núcleo de la metodoloǵıa Scrum es el sprint, que es un pequeño proyecto, ejecutado en un peŕıodo fijo no mayor a un mes, y su propósito es incrementar el valor de nuestro producto. Para este proyecto se harán 4 sprint con un periodo mayor a un mes donde en cada sprint trabajara diferentes historias de usuario. Podemos ver la definicion de horas de trabajo por sprint en la tabla 2.5 Tabla 2.5: definicion de horas de trabajo por sprint Rol Asignacion Tamaño del Sprint Minimo de 2 dias / Maximo de 30 (dias laborales) Product Owner 5 horas Development Team Minimo de 10 horas /Maximo de 150 horas 2.6. Planeacion de historias en cada Sprint Podemos ver la planeacion en cada sprint en la tabla 2.6 Tabla 2.6: planeacion de historias en cada sprint Número de historia de usuario Definición de historia de usuario Sprint 1 Como usuario Quiero ingresar con correo y clave Para acceder mis módulos e información 1 2 Como administrador Quiero crear usuarios en el sistema y asignarles sus datos y roles Para llevar control de los usuarios que pueden entrar al sistema. 1 3 Como administrador Quiero editar información personal de los usuarios existentes asi como sus roles Para tener control de acceso al sistema y tener al dia la información de todos los usuarios 1 21 Caṕıtulo 2. Análisis 2.7. Historias terminadas El estado terminado hace referencia a que se ha cumplido con el objetivo que propone la historia de usuario y todos sus criterios de aceptación estén cumplidos, todas las historias tienen un nivel de prioridad esto nos permitirá priorizar las historias más importantes de las demás. Podemos ver un ejemplo de historia terminada en la tabla 2.7 Tabla 2.7: ejemplo de historia terminada Número de historia de usuario Definición de historia de usuario Sprint Estado 1 Como usuario Quiero ingresar con correo y clave Para acceder mis módulos e información 1 Terminada 24 Caṕıtulo 3 Diseño 3.1. Diagrama de Clases A continuación se presentan los diagramas de clases y la respectiva descripción de las clases im- plementadas tanto en el aplicativo web como en el aplicativo móvil. 3.1.1. Aplicativo web En el aplicativo web, dado que se implementó el ORM de Eloquent que nos permite llevar la capa de persistencia de la base de datos por medio de objetos. No se declaran variables propias de las clases sino que los atributos de cada clase son implementadas una vez se obtienen de la abla de la base de datos. En el caso de los controladores. Estos solo cuentan con métodos relacionados al CRUD de las diferentes clases del aplicativo. Y en ciertos casos, métodos relacionados a la lógica de negocio del proyecto. Estas clases se muestran en la Figura 3.1 y se describen a continuación: Rol. Esta clase representa al mapeo de la tabla 4.8. RolController. Esta clase contiene el método de obtener los elementos de la tabla 4.8. IdType. Esta clase representa al mapeo de la tabla 4.7. IdTypeController. Esta clase contiene el CRUD la tabla 4.7. User. Esta clase representa al mapeo de la tabla 4.5. UserController. Esta clase contiene el CRUD la tabla 4.5. UserPhone. Esta clase representa al mapeo de la tabla 4.6. 25 Caṕıtulo 3. Diseño UserPhoneController. Esta clase representa el CRUD de la tabla 4.6. Category. Esta clase representa al mapeo de la tabla 4.12. CategoryController. Esta clase contiene el CRUD la tabla 4.12. Product. Esta clase representa al mapeo de la tabla 4.11. ProductController. Esta clase contiene el CRUD la tabla 4.11. Sale. Esta clase representa al mapeo de la tabla 4.9. OrderController. Esta clase contiene el CRUD la tabla 4.9 incluido la capa loǵıca correspon- diente a los pedidos. ProductSale. Esta clase representa al mapeo de la tabla 4.10. Measure. Esta clase representa al mapeo de la tabla 4.1. OrderController. Esta clase se encarga de gestionar la creación de movimientos de productos de la bodega. CartController. Esta clase se encarga de llevar la logica correspondiente a la creación de las diferentes ordenes. Inventory. Esta clase representa al mapeo de la tabla 4.2. StoreController. Esta clase contiene el CRUD la tabla 4.2. BodegaTransaction. Esta clase representa al mapeo de la tabla 4.4. BodegaTransactionController. Esta clase contiene el CRUD la tabla 4.4. BodegaTransactionInventory. Esta clase representa al mapeo de la tabla 4.3. En lo que concierne a la API, todas las peticiones, validaciones y sus correspondientes respuestas son manejadas desde la ruta routes/api.php 26 Caṕıtulo 3. Diseño Figura 3.2: Diagrama de Clases aplicativo móvil 3.2. Diagramas de Procesos A continuación se presentan los diagramas de proceso BPMN de algunos de los procesos ejecutados por la aplicación. 29 Caṕıtulo 3. Diseño 3.2.1. Login de Usuario Figura 3.3: Diagrama de proceso login de usuario 3.2.2. Solicitar Pedido Figura 3.4: Diagrama de proceso solicitar pedido (1/3) 30 Caṕıtulo 3. Diseño Figura 3.5: Diagrama de proceso solicitar pedido (2/3) Figura 3.6: Diagrama de proceso solicitar pedido (3/3) 31 Caṕıtulo 4 Implementación Para la implementación del presente proyecto se ha hecho uso tanto de una base de datos relacional para concentrar la mayor parte de la información del proyecto y tambien aquella que se persiste de manera fija, como también uso del gestor de base de datos no relacional Firebase. Este se encarga de llevar en tiempo real el listado de pedidos que se están generando, aśı como también el listado de mesas que tiene el negocio y su estado en tiempo real. Esto para saber si está disponible para recibir a un cliente o no. También se hace uso de Firebase para llevar listado de los usuarios conectados a un dispositivo móvil y aśı mismo, esta nos ayuda a prevenir que un mismo usuario esté conectado en dos dispositivos diferentes al mismo tiempo. 34 Caṕıtulo 4. Implementación 4.1. Modelo Relacional 4.1.1. Diagrama Relacional La Figura 4.1 presenta el modelo relacional. Figura 4.1: Modelo relacional 4.1.2. Diccionario de Datos Modelo Relacional A continuación se presenta el diccionario de datos para cada una de las tablas presentadas en el diagrama relacional. measures Tabla 4.1: measures Columna Tipo Nulo Extra Enlace a id BIGINT NO auto increment measure TEXT NO 35 Caṕıtulo 4. Implementación inventories Tabla 4.2: inventories Columna Tipo Nulo Extra Enlace a id BIGINT NO auto increment name TEXT NO description LONGTEXT NO photo path TEXT NO quantity DOUBLE NO measure id BIGINT NO id measures bodega transaction inventories Tabla 4.3: bodega transaction inventories Columna Tipo Nulo Extra Enlace a id BIGINT NO auto increment bodega transaction id BIGINT NO id bodegatransactions inventory id BIGINT NO id inventories quantity DOUBLE NO bodega transaction Tabla 4.4: bodega transaction Columna Tipo Nulo Extra Enlace a id BIGINT NO auto increment datetime DATETIME NO user id BIGINT NO id user e/s CHAR NO users Tabla 4.5: users Columna Tipo Nulo Extra Enlace a id BIGINT NO auto increment name TEXT NO lastname TEXT NO email VARCHAR NO password VARCHAR NO two factor secret TEXT NO two factor recovery codes VARCHAR NO remember token VARCHAR NO 36 Caṕıtulo 4. Implementación Tabla 4.14: migrations Columna Tipo Nulo Extra Enlace a id BIGINT NO migration VARCHAR NO batch INT NO failed jobs Tabla 4.15: failed jobs Columna Tipo Nulo Extra Enlace a id BIGINT NO uuid VARCHAR NO connection TEXT NO queue TEXT NO payload LONGTEXT NO exception LONGTEXT NO failed at TIMESTAMP NO sessiones Tabla 4.16: sessiones Columna Tipo Nulo Extra Enlace a id VARCHAR NO user id BIGINT NO ip address VARCHAR NO user agent TEXT NO payload TEXT NO last activity INT NO 4.2. Modelo NoSQL (Firebase) Como se ha mencionado, se hace uso de la plataforma de Firebase la cual presta el servicio de dos tipos de bases de datos no relacionales alojadas en la nube y la cuales como las de su tipo están estructuradas en formato JSON. A estas bases de datos se puede acceder ya sea desde un aplicativo web o móvil y su despliegue es sencillo de llevar a cabo. La primera de ellas es Cloud Firestore la cual es una base de datos para colecciones y documentos encargada de llevar el registro de los usuarios conectados desde un dispositivo móvil que corre la aplicación Android. Al momento de conectarse un usuario y hacer la validación de sus datos se añade un nuevo documento con sus datos tráıdos desde el aplicativo web. Esto se hace con el fin de validar 39 Caṕıtulo 4. Implementación si este usuario se llega a conectar desde otro dispositivo sin haberse desconectado del que estaba conectado previamente, entonces el aplicativo móvil no le va a permitir iniciar sesión. Una vez que el usuario se desconecta del aplicativo móvil, su registro es eliminado de Firebase y podrá iniciar sesión si aśı lo requiere desde el mismo u otro dispositivo. Se usa Cloud Firestore ya que demuestra un mejor desempeño en Android. Por otro lado, tenemos a Realtime Database la cual es una base de datos en forma de ”árbol 2se usa para llevar el registro de los pedidos generados por los meseros en tiempo real. Se hace uso de esta base de datos ya que, al ser en tiempo real, los cambios ocurridos en el estado de los pedidos, aśı como también su creación son mostrados de manera inmediata tanto en el aplicativo web como en el aplicativo móvil los cuales son conectados a esta para que lleve el registro de los pedidos. Dado a que los pedidos deben ser almacenados en la base de datos relacional que es la que lleva los registros fijos del aplicativo, estos son almacenados una vez que el pedido ha sido pagado por parte del cliente. Una vez esto sucede, la orden es removida de la base de datos de Firebase y se deja libre el espacio para poder registrar una orden que sea creada y que como se ha mencionado. Mientras que una orden este en Firebase, podrá ser visualizada desde el aplicativo web o móvil, hasta que el usuario paga su pedido y esta se elimina de Firebase, ya no se visualiza desde los aplicativos web o móvil y se registra en la tabla de sales de la base de datos relacional. Por último, tenemos el registro table donde se enumera cada una de las mesas del negocio según su disponibilidad para ser escogida por un cliente y maneja los siguientes estados: 0 - Equivale a una mesa disponible para un cliente 1 - Equivale a una mesa pendiente por atender de un mesero y que ha sido marcada por el cajero o por el administrador 2 - Equivale a una mesa que está ocupada por un cliente y que no puede ser seleccionada para crear una nueva orden. Los estados de las mesas son controlados desde el aplicativo web y móvil en caso de que una orden sea creada o que sea cancelada por el mesero y finalmente cuando un pedido es pagado y movido a la base de datos relacional, el estado de la mesa donde fue solicitado se ajusta a 0 para que una nueva orden pueda ser generada en esta mesa. 4.2.1. Diagrama del modelo NoSQL A continuación, se muestra una aproximación al modelo de estas bases de datos, ya que a diferencia de las bases de datos SQL estas no cuentan con una forma estandarizada para ser representada en un diagrama. 40 Caṕıtulo 4. Implementación Figura 4.2: Modelo NoSQL 4.3. Implementación de BD y Epica de login de usuarios 4.3.1. sprint planning En esta fase elegiremos las historias de usuario que desarrollaremos en este sprint, esto significa que tomaremos algunas historias de usuario que están en el product backlog y las desarrollamos en este sprint igualmente se plane cuánto tiempo tomará este sprint y se dará la prioridad a cada historia de usuario que se desarrollara. A continuación mostraremos las historias de usuario que trabajaremos en este sprint en la tabla 4.17 41 Caṕıtulo 4. Implementación Figura 4.3: Tablero trello sprint 1 4.3.5. Sprint retrospective La etapa final es evaluar el desempeño del equipo de trabajo y actualizar el product backlog en base a las opiniones de los miembros del equipo dando la posibilidad de agregar, modificar o eliminar historias de usuario, también actualizaremos el product backlog con las historias de usuario que ya fueron completadas en este sprint. A continuación mostraremos el product backlog despues de completar el primer sprint en la tabla 4.19 Tabla 4.19: product backlogs print 1 Número de historia de usuario Definición de historia de usuario Sprint Estado 1 Como usuario Quiero ingresar con correo y clave Para acceder mis módulos e información 1 Completado 44 Caṕıtulo 4. Implementación 2 Como administrador Quiero crear usuarios en el sistema y asignarles sus datos y roles Para llevar control de los usuarios que pueden entrar al sistema. 1 Completado 3 Como administrador Quiero editar información personal de los usuarios existentes asi como sus roles Para tener control de acceso al sistema y tener al dia la información e todos los usuarios 1 Completado 4 Como administrador Quiero eliminar aquellos usuarios que ya no están presentes en el negocio Para liberar información en el sistema que ya no se requiere 1 Completado 5 Como administrador Quiero ver estad́ısticas de las ventas realizadas diariamente , semanalmente y mensualmente. Para llevar un control de las ventas del negocio. 2 Sin iniciar 6 Como administrador Quiero eliminar los pedidos que por fuerza mayor no pudieron ser entregados. Para liberar los pedidos que no se pueden facturar y no afectar la contabilidad 2 Sin iniciar 7 Como cajero Quiero visualizar las mesas que hay disponibles 2 Sin iniciar 45 Caṕıtulo 4. Implementación 8 Como cajero Quiero visualizar las órdenes en curso Para obtener la información de pedidos en el negocio y acceder al módulo de pago con determinado producto 2 Sin iniciar 9 Como cajero Quiero poder liquidar la orden que fue pagada por el cliente Para poder confirmar que esta venta fue realizada 2 Sin iniciar 10 Como cajero Quiero asignar una mesa que esté disponible a un cliente que entre al negocio Para que se envie una alerta a los meseros y que uno de estos tome el pedido de esta meso 2 Sin iniciar 11 Como encargado de bodega Quiero visualizar la mercancia que tengo actualmente en bodega Para llevar control de la mercanćıa 3 Sin iniciar 12 Como encargado de bodega Quiero registrar toda la mercanćıa que entra a la bodega Para llevar un control de la mercanćıa existente 3 Sin iniciar 13 Como encargado de la bodega Quiero registrar la mercancia que sale de la bodega Para llevar control de la mercancia que se envia a la cocina. 3 Sin iniciar 14 Como administrador Quiero eliminar aquellas materias primas que ya no se usarán mas en el negocioPara no tener información innecesaria de materias primas que no se usan. 3 Sin iniciar 46 Caṕıtulo 4. Implementación 9 Como cajero Quiero poder liquidar la orden que fue paga da por el cliente Para poder confirmar que esta venta fue realizada 10 Como cajero Quiero asignar una mesa que esté disponible a un cliente que entre al negocio Para que se envie una alerta a los meseros y que uno de estos tome el pedido de esta meso 4.4.2. sprint backlog Una vez definido las historias de usuario de este sprint tomamos cada una y la dividimos en una serie de tareas para cumplir cada una de las historias de usuario también estimamos un tiempo para cada una de estas tareas y designamos un responsable por cada tarea. A continuación mostraremos el sprint backlog del sprint 2 en la tabla 4.21 Tabla 4.21: sprint backlog sprin ID Descripción H Responsable(s) Duración 1 Crear vista para módulo de estad́ısticas de ventas 5 Diego Alejandro Peña Reyes 4 horas 2 Crear rutas y lógica para el módulo de estad́ısticas de ventas 5 Diego Alejandro Peña Reyes 6 horas 3 Crear vista para módulo de cancelación de pedidos por fuerza mayor 6 Diego Alejandro Peña Reyes 5 horas 4 Crear rutas y lógica para el módulo de cancelación de pedidos por fuerza mayor 6 Diego Alejandro Peña Reyes 5 horas 5 Crear vista para módulo de mesas disponibles 7 Diego Alejandro Peña Reyes 4 horas 6 Crear rutas y lógica para el módulo de mesas disponibles 7 Diego Alejandro Peña Reyes 6 horas 7 Crear vista para módulo de pedidos en curso 8 Diego Alejandro Peña Reyes 4 horas 49 Caṕıtulo 4. Implementación 8 Crear rutas y lógica para el módulo de pedidos en curso 8 Diego Alejandro Peña Reyes 5 horas 9 Crear vista para módulo de liquidar orden 9 Diego Alejandro Peña Reyes 4 horas 10 Crear rutas y lógica para el módulo de liquidar orden 9 Diego Alejandro Peña Reyes 5 horas 11 Crear vista para módulo de asignar mesa por atender 10 Diego Alejandro Peña Reyes 4 horas 12 Crear rutas y lógica para el módulo de asignar mesa por atend 10 Diego Alejandro Peña Reyes 4 horas 13 Crear base de datos no relacional para notificar el sistema de cambios 7,8,9 y 10 Diego Alejandro Peña Reyes 6 horas 4.4.3. Control del sprint Para levar un control de los avances del proyecto y del estado de las tareas utilizamos la plataforma trello la cual nos permite tener un tablero donde podemos colocar las tareas por realizar , las que se están realizando y las que ya están hechas. La Figura 4.12 presenta el tablero de trello para el sprint. 4.4.4. Sprint review En esta fase del Sprint veremos el incremento del producto veremos las tareas que se completaron y el resultado del cumplimiento de estas. 50 Caṕıtulo 4. Implementación Figura 4.5: Sistema de login 4.4.5. Sprint retrospective La etapa final es evaluar el desempeño del equipo de trabajo y actualizar el product backlog en base a las opiniones de los miembros del equipo dando la posibilidad de agregar , modificar o eliminar historias de usuario , también actualizaremos el product backlog con las historias de usuario que ya fueron completadas en este sprint. A continuación mostraremos el product backlog despues de completar el segundo sprint en la tabla 4.22 Tabla 4.22: product backlog sprint 2 Número de historia de usuario Definición de historia de usuario Sprint Estado 1 Como usuario Quiero ingresar con correo y clave Para acceder mis módulos e información 1 Completado 2 Como administrador Quiero crear usuarios en el sistema y asignarles sus datos y roles Para llevar control de los usuarios que pueden entrar al sistema. 1 Completado 51 Caṕıtulo 4. Implementación 17 Como mesero Quiero poder ver las órdenes en curso que un cliente me ha solicitado Para estar pendiente de cuando debo recogerlas y en que estado del proceso se encuentran. 4,2 Sin iniciar 18 Como mesero Quiero generar pedidos a través de una aplicación en una tablet y que estos se puedan editar antes de su preparación Para ser enviados al área de cocina, preparados y posteriormente entregados 4,2 Sin iniciar 19 Como mesero Quiero editar los pedidos que aún no estan en estado .en preparación” Para dar al cliente la posibilidad de cambiar algo en el pedido 4,2 Sin iniciar 4.5. Módulo de encargado de bodega y sistema de inventarios 4.5.1. sprint planning En esta fase elegiremos las historias de usuario que desarrollaremos en este sprint, esto significa que tomaremos algunas historias de usuario que están en el product backlog y las desarrollamos en este sprint igualmente se plane cuánto tiempo tomará este sprint y se dará la prioridad a cada historia de usuario que se desarrollara. A continuación mostraremos las historias de usuario que trabajaremos en este sprint en la tabla 4.23 54 Caṕıtulo 4. Implementación Figura 4.6: Dashboard del proyecto Tabla 4.23: historias de usuario sprint 3 Número de historia de usuario Definición de historia de usuario 11 Como encargado de bodega Quiero visualizar la mercancia que tengo actualmente en bodega Para llevar control de la mercanćıa 12 Como encargado de bodega Quiero registrar toda la mercanćıa que entra a la bodega Para llevar un control de la mercanćıa existente 13 Como encargado de la bodega Quiero registrar la mercancia que sale de la bodega Para llevar control de la mercancia que se envia a la cocina. 14 Como administrador Quiero eliminar aquellas materias primas que ya no se usarán más en el negocio Para no tener información innecesaria de materias primas que no se usan. 4.5.2. sprint backlog Una vez definido las historias de usuario de este sprint tomamos cada una y la dividimos en una serie de tareas para cumplir cada una de las historias de usuario también estimamos un tiempo para cada una de estas tareas y designamos un responsable por cada tarea. A continuación mostraremos el sprint backlog en la tabla 4.24 Tabla 4.24: sprint backlog 3 ID Descripción H Responsable(s) Duración 1 Crear vista para módulo de visualizar mercanćıa 11 Diego Alejandro Peña Reyes 4 horas 2 Crear rutas y lógica para el módulo de visualizar mercanćıa 11 Diego Alejandro Peña Reyes 6 horas 3 Crear vista para módulo de entrada de mercanćıa 12 Diego Alejandro Peña Reyes 5 horas 4 Crear rutas y lógica para el módulo de entrada de mercanćıa 12 Diego Alejandro Peña Reyes 5 horas 55 Caṕıtulo 4. Implementación 5 Crear vista para módulo de salida de mercanćıa 13 Diego Alejandro Peña Reyes 4 horas 6 Crear rutas y lógica para el módulo de salida de mercanćıa 13 Diego Alejandro Peña Reyes 6 horas 7 Crear vista para módulo de eliminar materia prima 14 Diego Alejandro Peña Reyes 4 horas 8 Crear rutas y lógica para el módulo de eliminar materia prima 14 Diego Alejandro Peña Reyes 5 horas 4.5.3. Control del sprint Para levar un control de los avances del proyecto y del estado de las tareas utilizamos la plataforma trello la cual nos permite tener un tablero donde podemos colocar las tareas por realizar , las que se están realizando y las que ya están hechas. La Figura 4.3 presenta el tablero de trello para el sprint 3. 4.5.4. sprint review En esta fase del sprint veremos el incremento del producto veremos las tareas que se completaron y el resultado del cumplimiento de estas. 56 Caṕıtulo 4. Implementación 10 Como cajero Quiero asignar una mesa que esté disponible a un cliente que entre al negocio Para que se envie una alerta a los meseros y que uno de estos tome el pedido de esta meso 2 Completado 11 Como encargado de bodega Quiero visualizar la mercancia que tengo actualmente en bodega Para llevar control de la mercanćıa 3 Completado 12 Como encargado de bodega Quiero registrar toda la mercanćıa que entra a la bodega Para llevar un control de la mercanćıa existente 3 Completado 13 Como encargado de la bodega Quiero registrar la mercancia que sale de la bodega Para llevar control de la mercancia que se envia a la cocina. 3 Completado 14 Como administrador Quiero eliminar aquellas materias primas que ya no se usarán mas en el negocio Para no tener información innecesaria de materias primas que no se usan. 3 Completado 15 Como mesero Quiero visualizar aquellas mesas que ha asignado el cajero y que tienen clientes pendientes por atender Para acercarme una de estas mesas y tomar el pedido de este cliente 4,2 Sin iniciar 16 Como mesero Quiero ver las mesas del establecimiento y ver si están ocupadas o no Para saber la disposición de cada mesa en el establecimiento 4,2 Sin iniciar 59 Caṕıtulo 4. Implementación 17 Como mesero Quiero poder ver las órdenes en curso que un cliente me ha solicitado Para estar pendiente de cuando debo recogerlas y en que estado del proceso se encuentran. 4,2 Sin iniciar 18 Como mesero Quiero generar pedidos a través de una aplicación en una tablet y que estos se puedan editar antes de su preparación Para ser enviados al área de cocina, preparados y posteriormente entregados 4,2 Sin iniciar 19 Como mesero Quiero editar los pedidos que aún no estan en estado .en preparación” Para dar al cliente la posibilidad de cambiar algo en el pedido 4,2 Sin iniciar 4.6. Módulo web y móvil de mesero 4.6.1. sprint planning En esta fase elegiremos las historias de usuario que desarrollaremos en este sprint, esto significa que tomaremos algunas historias de usuario que están en el product backlog y las desarrollamos en este sprint igualmente se plane cuánto tiempo tomará este sprint y se dará la prioridad a cada historia de usuario que se desarrollara. A continuación mostraremos las historias de usuario que trabajaremos en este sprint en la tabla 4.26 60 Caṕıtulo 4. Implementación Figura 4.8: Modulo de visualizacion de usuarios Tabla 4.26: historias de usuario sprint 4 Número de historia de usuario Definición de historia de usuario 15 Como mesero Quiero visualizar aquellas mesas que ha asignado el cajero y que tienen clientes pendientes por atender Para acercarme una de estas mesas y tomar el pedido de este cliente 16 Como mesero Quiero ver las mesas del establecimiento y ver si están ocupadas o no Para saber la disposición de cada mesa en el establecimiento 61 Caṕıtulo 4. Implementación Figura 4.9: Modulo de edicion de usuarios 4.6.3. Control del sprint Para levar un control de los avances del proyecto y del estado de las tareas utilizamos la plataforma trello la cual nos permite tener un tablero donde podemos colocar las tareas por realizar, las que se están realizando y las que ya están hechas. La Figura 4.29 presenta el tablero de trello para el sprint 4. 4.6.4. Sprint review En esta fase del Sprint veremos el incremento del producto veremos las tareas que se completaron y el resultado del cumplimiento de estas. 64 Caṕıtulo 4. Implementación Figura 4.10: Modulo de cambio de foto de usuario 4.6.5. Sprint retrospective La etapa final es evaluar el desempeño del equipo de trabajo y actualizar el product backlog en base a las opiniones de los miembros del equipo dando la posibilidad de agregar , modificar o eliminar historias de usuario , también actualizaremos el product backlog con las historias de usuario que ya fueron completadas en este sprint. A continuación mostraremos el product backlog despues de completar el primer sprint en la tabla 4.28 Tabla 4.28: product backlogs print 4 Número de historia de usuario Definición de historia de usuario Sprint Estado 1 Como usuario Quiero ingresar con correo y clave Para acceder mis módulos e información 1 Completado 2 Como administrador Quiero crear usuarios en el sistema y asignarles sus datos y roles Para llevar control de los usuarios que pueden entrar al sistema. 1 Completado 65 Caṕıtulo 4. Implementación 3 Como administrador Quiero editar información personal de los usuarios existentes asi como sus roles Para tener control de acceso al sistema y tener al dia la información de todos los usuarios 1 Completado 4 Como administrador Quiero eliminar aquellos usuarios que ya no están presentes en el negocio Para liberar información en el sistema que ya no se requiere 1 Completado 5 Como administrador Quiero ver estad́ısticas de las ventas realizadas diariamente , semanalmente y mensualmente. Para llevar un control de las ventas del negocio. 2 Completado 6 Como administrador Quiero eliminar los pedidos que por fuerza mayor no pudieron ser entregados. Para liberar los pedidos que no se pueden facturar y no afectar la contabilidad 2 Completado 7 Como cajero Quiero visualizar las mesas que hay disponibles 2 Completado 8 Como cajero Quiero visualizar las órdenes en curso Para obtener la información de pedidos en el negocio y acceder al módulo de pago con determinado producto 2 Completado 9 Como cajero Quiero poder liquidar la orden que fue pagada por el cliente Para poder confirmar que esta venta fue realizada 2 Completado 66 Caṕıtulo 4. Implementación Figura 4.11: Modulo de visualizacion informacion de usuario Figura 4.12: Tablero trello sprint 2 69 Caṕıtulo 4. Implementación Figura 4.13: modulo de mesas disponibles Figura 4.14: Sistema de login 70 Caṕıtulo 4. Implementación Figura 4.15: modulo de pagar pedido cajero Figura 4.16: Base de datos no relacional 71 Caṕıtulo 4. Implementación Figura 4.21: Módulo de filtro de mercanćıa Figura 4.22: Módulo de visualización de información de mercanćıa 74 Caṕıtulo 4. Implementación Figura 4.23: Módulo de registro de mercanćıa Figura 4.24: Módulo de agregar existencias de bodegal 75 Caṕıtulo 4. Implementación Figura 4.25: Módulo de extraer existencias de bodega Figura 4.26: Módulo de filtrar movimientos de bodega 76 Caṕıtulo 4. Implementación Figura 4.31: Módulo web de mesas por atender Figura 4.32: Módulo móvil de órdenes en curso 79 Caṕıtulo 4. Implementación Figura 4.33: Módulo web de órdenes en curso Figura 4.34: Módulo web de creación de orden 80 Caṕıtulo 4. Implementación Figura 4.35: Módulo móvil de creación de orden Figura 4.36: Módulo móvil de estado de mesas 81