D.Maza Trabajo Suficiencia Profesional Titulo Profesional 2023

Facultad de Ingeniería
Ingeniería de Sistemas e Informática
Trabajo de Suficiencia Profesional
“Implementación de una aplicación web para mejorar la gestión de pedidos en un
restaurante”
Dennis Alexis Maza Cerna
para optar el Título Profesional de
Ingeniero de Sistemas e Informática
Asesor: Mg. Wilfredo Mamani Ticona
Lima – Perú
Marzo del 2023
II
DEDICATORIA
Dedicado a mis padres y hermanas por la paciencia, apoyo,

cariño y consejos que me brindaron en cada paso, guiándome y
ayudándome a convertirme en la persona que soy ahora.
III
AGRADECIMIENTOS
Ya que son la base de mi vida, me gustaría agradecer a mi

familia por apoyarme en todos mis esfuerzos y por ayudarme a
alcanzar mis metas.
Agradezco a Dios por guiarme y estar a mi lado durante
toda mi vida, permitiéndome alcanzar mis sueños.
Y finalmente, expresar agradecimiento al total de las
personas que me han brindado su apoyo durante la carrera y
durante esta investigación, Gracias por confiar en mí.
IV
INDICE GENERAL
RESUMEN.............................................................................................................................................. XVI
ABSTRACT .......................................................................................................................................... XVII
INTRODUCCIÓN ...................................................................................................................................... 1
CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA ........................................................................ 2
1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA ..................................................... 2
1.2. FORMULACIÓN DEL PROBLEMA ...................................................................................... 4
1.2.1. Problema general .................................................................................................................... 4
1.2.2. Problemas específicos ............................................................................................................. 4
1.3. DETERMINACIÓN DE OBJETIVOS ..................................................................................... 5
1.3.1. Objetivo general ...................................................................................................................... 5
1.3.2. Objetivos específicos ............................................................................................................... 5
1.4. HIPÓTESIS ................................................................................................................................. 5
1.4.1. Hipótesis general ..................................................................................................................... 5
1.4.2. Hipótesis específicas ................................................................................................................ 5
1.5. JUSTIFICACIÓN DE LA INVESTIGACIÓN ........................................................................ 6
1.5.1. Teórica ..................................................................................................................................... 6
1.5.2. Práctica .................................................................................................................................... 6
1.5.3. Metodológica ........................................................................................................................... 7
1.6. DELIMITACIÓN DEL ESTUDIO ........................................................................................... 8
1.6.1. Espacial .................................................................................................................................... 8
1.6.2. Temporal .................................................................................................................................. 8
1.6.3. Conceptual ............................................................................................................................... 8
CAPÍTULO II: MARCO TEÓRICO ........................................................................................................ 8
2.1. ESTADO DEL ARTE ................................................................................................................. 8
2.2. BASES TEÓRICAS .................................................................................................................. 14
2.2.1. Aplicación web....................................................................................................................... 15
2.2.1.1. Motor de base de datos ..................................................................................................... 17
2.2.1.2. Backend con Java .............................................................................................................. 19
2.2.1.3. Frontend con Angular ...................................................................................................... 20
2.2.1.4. Diseño Responsive ............................................................................................................. 21
2.2.1.5. Control de versiones.......................................................................................................... 22
2.2.2. Gestión de pedidos ................................................................................................................ 27
V
2.2.2.1. Ciclo de la gestión de pedidos........................................................................................... 29
2.2.2.2. Pedidos ............................................................................................................................... 33
2.2.2.3. Administración de restaurantes ....................................................................................... 33
2.2.2.4. Establecimiento comercial ................................................................................................ 36
2.2.2.5. Atención al cliente ............................................................................................................. 37
2.2.2.6. Personal de una empresa .................................................................................................. 38
2.2.3. Proceso Racional Unificado (RUP) ...................................................................................... 39
2.2.4. SCRUM .................................................................................................................................. 42
2.2.5. Waterfall ................................................................................................................................ 43
2.2.6. Marco Conceptual ................................................................................................................. 44
2.2.6.1. Gestión ............................................................................................................................... 44
2.2.6.3. Spring Boot ........................................................................................................................ 46
2.2.6.4. Maven ................................................................................................................................. 47
2.2.6.5. HTML ................................................................................................................................ 48
2.2.6.6. TypeScript ......................................................................................................................... 49
2.2.6.7. Git ....................................................................................................................................... 50
2.2.6.8. Programación Reactiva .................................................................................................... 51
CAPÍTULO III: METODOLOGÍA DE INVESTIGACIÓN ................................................................ 53
3.1. DESARROLLO DE LA METODOLOGÍA ........................................................................... 53
3.1.1. Selección de la metodología .................................................................................................. 53
3.1.2. Desarrollo de la metodología ................................................................................................ 57
3.1.2.1. Fase de Inicio ..................................................................................................................... 57
3.1.2.2. Fase de Planeamiento y Estimación................................................................................. 59
3.1.2.3. Fase de Desarrollo y Diseño ............................................................................................. 62
3.1.2.4. Fase de implementación.................................................................................................... 65
3.1.2.5. Fase de Revisión y Retroalimentación............................................................................. 69
3.3.2.6. Fase de Despliegue ............................................................................................................ 71
3.4. CRONOGRAMA DE ACTIVIDADES ................................................................................... 71
3.5. PRESUPUESTO ....................................................................................................................... 72
3.5.1. Costos ..................................................................................................................................... 72
3.5.1.1. Costos de colaboradores / personal ................................................................................. 72
3.5.1.2. Costos de hardware ........................................................................................................... 73
3.5.1.3. Costos de software ............................................................................................................. 74
VI
3.5.1.4. Costos variables ................................................................................................................. 74
3.5.1.5. Costos de puesta en marcha ............................................................................................. 75
3.5.2. Beneficios ............................................................................................................................... 76
3.5.2.1. Beneficios tangibles ........................................................................................................... 76
3.5.2.2. Beneficios intangibles ........................................................................................................ 78
3.5.3. Rentabilidad del proyecto .................................................................................................... 78
3.5.3.1. Flujo de caja ...................................................................................................................... 78
3.5.3.2. Analisis del VAN ............................................................................................................... 79
3.5.3.3. Analisis del TIR ................................................................................................................. 81
CAPÍTULO IV: DESARROLLO DE LA SOLUCIÓN ........................................................................ 82
4.1. PROPUESTA DE SOLUCIÓN................................................................................................ 82
4.1.1 Fase de Inicio ......................................................................................................................... 82
4.1.2 Fase de Planeamiento y Estimación..................................................................................... 90
4.1.3 Fase de Desarrollo y Diseño ............................................................................................... 102
4.1.4 Fase de Implementación ..................................................................................................... 117
4.1.5 Fase de Revisión y Retroalimentación............................................................................... 130
4.1.6 Fase de Despliegue .............................................................................................................. 135
4.2. PROTOTIPO DE LA APLICACIÓN ................................................................................... 137
4.2.1. Módulo de inicio de sesión de usuarios ............................................................................. 138
4.2.2. Módulo de dashboard ......................................................................................................... 138
4.2.3. Módulo de registro de pedidos ........................................................................................... 139
4.2.4. Modulo del detalle del pedido ............................................................................................ 140
4.3. RESULTADOS ....................................................................................................................... 140
CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES......................................................... 145
5.1. CONCLUSIONES................................................................................................................... 145
5.2. RECOMENDACIONES......................................................................................................... 146
REFERENCIAS ...................................................................................................................................... 147
ANEXOS .................................................................................................................................................. 152
VII
ÍNDICE DE FIGURAS
Figura 1: Problema principal, causas y efectos…………………………………………………..3
Figura 2: Línea del tiempo de la evolución de la web…………………………………………..16
Figura 3: Diseño de bases de datos relacionales…………………...……………………………18
Figura 4: Logo de Java……………………..………………………………………………...…20
Figura 5: Logo de Angular………………………………………………………..……………..21
Figura 6: Diferencia entre cantidad de contenido del sitio web Boston Globe…………………22
Figura 7: Sistema de gestión de versiones locales………………………………………………23
Figura 8: Sistema de gestión de versiones centralizado………………………………………...25
Figura 9: Sistema de gestión de control de versiones distribuidas……………………………...26
Figura 10: Ejemplo de gestión de pedidos………………………………………………………28
Figura 11: Fases del ciclo de vida del pedido y eventos (subprocesos) asociados……………...31
Figura 12: Etapa de planteamiento de un restaurante……………………………….…………..34
Figura 13: Aspectos de la administración de un restaurante…………………………………....35
Figura 14: Proceso de atención al cliente……………………………………………………….38
Figura 15: Ciclo de vida del RUP……………………………………………………………….41
Figura 16: Ejemplo de flujo de trabajo del RUP………………………………………………..41
Figura 17: Roles, artefactos y eventos principales de SCRUM………………………………...43
VIII
Figura 18: Esquema de metodología Waterfall…………………………………………………44
Figura 19: Comparación de PostGreSQL con otras bases de datos…………………………….45
Figura 20: Configuración de Spring Boot………………………………………………………47
Figura 21: Ciclo de Maven………………………………………………………….…………..48
Figura 22: Estructura de un documento HTML…………………………………….…………..49
Figura 23: Esquema de versiones en Git……………………………………………….……….50
Figura 24: Aplicación de la programación reactiva en proyectos………………………………52
Figura 25: Flujo de caja…………………………………………………………………………78
Figura 26: Calculo del VAN…………………………………………………………………….79
Figura 27: Calculo de la TIR……………………………………………………………………81
Figura 28: Acta de constitución del proyecto…………………………………………………..84
Figura 29: Diagrama de flujo actual de pedidos………………………………………………..88
Figura 30: Diagrama del flujo con la mejora en la gestión de pedidos…………………………89
Figura 31: Scrum Poker Online………………………………………………………………..101
Figura 32: Esquema de puntajes……………………………………………………………….101
Figura 33: Diseño vista Inicio de sesión……………………………………………………….103
Figura 34: Implementación de interfaz de inicio de sesión……………………………………104
Figura 35: Implementación API de login……………………………………………………...105
IX
Figura 36: Diseño vista del dashboard más componente de logout…………………………...107
Figura 37: Implementación de interfaz del dashboard………………………………………...108
Figura 38: Implementación componente de logout……………………………………………109
Figura 39: Diseño vista del pop-up de registro del pedido…………………………………….111
Figura 40: Implementación de interfaz del pop-up del registro del pedido……………………111
Figura 41: Implementación API de registro de pedido………………………………………...112
Figura 42: Implementación API de lista de meseros disponibles……………………………...113
Figura 43: Implementación de API de lista de platos disponibles…………………………….113
Figura 44: Diseño vista del pop-up del detalle del pedido…………………………………….115
Figura 45: Implementación de interfaz del pop-up de detalle del pedido……………………..116
Figura 46: Implementación API de detalle del pedido………………………………………...117
Figura 47: Implementación API de actualización del estado del pedido……………………...117
Figura 48: Diagrama de base de datos…………………………………………………………118
Figura 49: Modulo frontend del login…………………………………………………………122
Figura 50: Modulo backend del login…………………………………………………………123
Figura 51: Modulo frontend del dashboard……………………………………………………124
Figura 52: Modulo frontend del pop-up del pop-up del registro del pedido…………………..125
Figura 53: Modulo backend del registro del pedido…………………………………………...127
X
Figura 54: Modulo frontend del pop-up del detalle del pedido………………………………..128
Figura 55: Modulo backend del detalle del pedido……………………………………………129
Figura 56: Reunión de verificación de sprint………………………………………………….130
Figura 57: Reunión de retrospectiva…………………………………………………………..134
Figura 58: Repositorio de código fuente………………………………………………………135
Figura 59: Documentación de termino………………………………………………………...136
Figura 60: Proyectos frontend y backend en Intellj Idea………………………………………137
Figura 61: Vista del login de la aplicación web……………………………………………….138
Figura 62: Vista del dashboard………………………………………………………………...138
Figura 63: Vista del registro…………………………………………………………………...139
Figura 64: Vista del detalle del pedido………………………………………………………..140
Figura 65: Grafico mejora en tiempo – simplificación de la gestión de pedidos……………...141
Figura 66: Grafico mejora de la productividad de los cocineros por pedidos…………………143
Figura 67: Grafico mejora de la productividad de los meseros por clientes…………………..143
Figura 68: Grafico de la mejora en la precisión de los pedidos……………………………….145
XI
ÍNDICE DE TABLAS
Tabla 1: Cuadro relación causa – efecto……...…………………………...….………………..…4
Tabla 2: Diferencia entre Ágil y Cascada…...…………………………….…...…………….…...7
Tabla 3: Criterios de selección por metodología..........................................................................55
Tabla 4: Factores de análisis…………………………………………………………………….56
Tabla 5: Fase de Inicio…………………………………………………………………………..57
Tabla 6: Fase de Planeamiento y Estimación…………………………………………………...60
Tabla 7: Fase de Desarrollo y Diseño……………………………………………,……………..62
Tabla 8: Fase de Implementación……………………………………………………………….65
Tabla 9: Fase de Revisión y Retroalimentación………………………………………………...69
Tabla 10: Fase de Despliegue…………………………………………………………………...71
Tabla 11: Cronograma de actividades del proyecto……………………………………………..71
Tabla 12: Cuadro de costos de colaboradores…………………………………………………..72
Tabla 13: Cuadro de costos de hardware………………………………………………………..73
Tabla 14: Cuadro de costos de software………………………………………………………...74
Tabla 15: Cuadro de costos variables…………………………………………………………...74
Tabla 16: Cuadro de costos de puesta en marcha……………………………………………….75
Tabla 17: Cuadro del beneficio del tiempo invertido por un mesero…………………………...76
Tabla 18: Cuadro del beneficio del tiempo invertido por un cocinero………………………….77
XII
Tabla 19: Cuadro de beneficios totales por mes………………………………………………...77
Tabla 20: Cuadro del Valor Actual Neto a 12 meses…………………………………………...80
Tabla 21: Cuadro de la Tasa Interna de Retorno a 12 meses……………………………………82
Tabla 22: Cuadro de la visión del proyecto……………………………………………………..83
Tabla 23: Cuadro de requerimientos funcionales……………………………………………….85
Tabla 24: Cuadro de requerimientos no funcionales……………………………………………86
Tabla 25: Cuadro de requerimientos comunes de las interfaces………………………………...87
Tabla 26: Cuadro del equipo Scrum…………………………………………………………….87
Tabla 27: Cuadro de historia de usuario – Iniciar sesión usuario Administrador………………90
Tabla 28: Cuadro de historia de usuario – Iniciar sesión usuario Mesero………………………91
Tabla 29: Cuadro historia de usuario – Iniciar sesión usuario Cocinero………………………..91
Tabla 30: Cuadro historia de usuario – Inicio de sesión incorrecta……………………………..92
Tabla 31: Cuadro historia de usuario – Lista de mesas…………………………………………93
Tabla 32: Cuadro historia de usuario – Registro del pedido usuario Administrador / Mesero…93
Tabla 33: Cuadro historia de usuario – Registro del pedido usuario Cocinero…………………94
Tabla 34: Cuadro historia de usuario – Detalle del pedido usuario Administrador / Cocinero…95
Tabla 35: Cuadro historia de usuario – Detalle del pedido usuario Mesero…………………….96
Tabla 36: Cuadro historia de usuario – Cerrar sesión…………………………………………...96
XIII
Tabla 37: Cuadro product backlog………………………………………………………………97
Tabla 38: Cuadro del product backlog priorizado………………………………………………99
Tabla 39: Cuadro listado de sprints……………………………………………………………100
Tabla 40: Cuadro de especificación del sprint 1…………………………………………….…102
Tabla 41: Cuadro del sprint backlog 1…………………………………………………………103
Tabla 42: Cuadro de especificación del sprint 2……………………………………………….106
Tabla 48: Tabla login…………………………………………………………………………..119
Tabla 49: Tabla waiter…………………………………………………………………………119
Tabla 50: Tabla dish…………………………………………………………………………...120
Tabla 51: Tabla restaurant_order………………………………………………………………120
Tabla 52: Tabla order_detail…………………………………………………………………...121
Tabla 53: Aceptación de los entregables………………………………………………………131
Tabla 54: Cuadro resultante de la reunión de retrospectiva……………………………………134
XIV
Tabla 55: Detalle de mejora en tiempo de la simplificación de la gestión de pedidos………...141
Tabla 56: Cuadro de mejora en la productividad de los cocineros…………………………….142
Tabla 57: Cuadro de mejora en la productividad de los meseros……………………………...143
Tabla 58: Cuadro de la mejora en la precisión de la gestión de pedidos………………………144
XV
RESUMEN
El actual estudio se focaliza en la implementación de una aplicación web que permitirá a
los usuarios (chefs y meseros) visualizar los distintos pedidos y sus estados actuales realizados
por los comensales en un restaurante. El principal objetivo de este proyecto es implementar una
aplicación web para la mejora de la gestión de pedidos en un restaurante. Esto se debe a que,
durante los años que ha estado involucrado este restaurante en el sector comercial, todavía hay
muchos procesos manuales, uno de los cuales es la gestión de pedidos. Por esta razón, la adición
de una aplicación web para la gestión de pedidos ayudara al restaurante a optimizar sus
operaciones y obtener un mejor manejo de los pedidos realizados en el establecimiento. De esta
forma, se podrá mejorar el tiempo dedicado a la atención de los clientes.
El marco de trabajo utilizado para la implementación de la aplicación web es Scrum.
Asimismo, se hizo uso de los frameworks de desarrollo Angular y Spring Boot con un gestor de
base de datos PostgreSQL.
Los resultados fueron satisfactorios obtenidos mediante encuestas, en donde se puede
apreciar la aceptación y satisfacción hacia implementación hecha, logrando la facilidad en la
dirección de los pedidos y la verificación de pedidos, el cual suma para reducir los tiempos y los
errores en la entrega de los pedidos, así como el tiempo de espera por parte de los clientes.
En consecuencia, resaltar que se logró cumplir con la implementación de la aplicación
web para mejorar la gestión de pedidos en un restaurante y evidenciando que en efecto la
propuesta de solución brindada dio una gran contribución al objetivo principal de este proyecto.
Palabras Clave: gestión de pedidos, aplicación web, Scrum, restaurante, atención al
cliente.
XVI
ABSTRACT
The current study focuses on the implementation of a web application that will allow
users (chefs and waiters) to view the different orders and their current statuses made by diners in
a restaurant. The main objective of this project is to implement a web application to improve
order management in a restaurant. This is because, during the years that this restaurant has been
involved in the commercial sector, there are still many manual processes, one of which is order
management. For this reason, the addition of a web application for order management will help
the restaurant to optimize its operations and obtain a better management of the orders placed in
the establishment. In this way, the time dedicated to customer service can be improved.
The framework used for the implementation of the web application is Scrum. Likewise,
the Angular and Spring Boot development frameworks were used with a PostgreSQL database
manager.
The results were satisfactory obtained through surveys, where the acceptance and
satisfaction towards the implementation made can be appreciated, achieving ease in the direction
of the orders and the verification of orders, which adds to reduce the times and errors in the
delivery of orders, as well as the waiting time by customers.
Consequently, it is worth highlighting that the implementation of the web application was
achieved to improve order management in a restaurant and evidencing that in effect the proposed
solution provided made a great contribution to the main objective of this project.
Keywords: web application, order management, Scrum, restaurant, customer service.
XVII
INTRODUCCIÓN
A lo largo de los años, la evolución tecnológica ha brindado grandiosos beneficios a las
empresas, tales como, lograr reducir la barrera comercial, poder incrementar los ingresos e
inclusive mejorar los procesos internos aumentando la productividad, eficacia y eficiencia.
Es así, que en la actualidad es necesario que los restaurantes opten por usar soluciones
digitales que permitan automatizar procesos repetitivos, permitiendo optimizar las tareas
administrativas y la atención al cliente, reflejando un ahorro de tiempo y dinero. Por otro lado, la
sociedad actual está preparada para adaptarse a un cambio que pueda realizarse en los
restaurantes.
El actual estudio maneja como objetivo principal, implementar una aplicación web para
mejorar la de gestión de pedidos en un restaurante. El cual está formado por estos capitulos:
Capítulo I: Describe el problema de investigación, donde se aborda la situación
problemática, así como la formulación de los problemas, objetivos de la investigación y se
aborda la justificación de la presente investigación.
Capítulo II: Describe el marco teórico y conceptual, donde se muestran los antecedentes
de la investigación, se desarrolla las bases teóricas y la identificación de la variable de estudio.
Capítulo III: Describe la metodología utilizada para el desarrollo de la presente
investigación.
Capítulo IV: Describe los resultados obtenidos de la investigación, utilizando las etapas
definidas en la metodología Scrum.
Capítulo V: Describe las conclusiones y recomendaciones.
1
CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA
1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA
En el mercado internacional y nacional la mayoría de los restaurantes poseen un
sistema automatizado que ayuda en el manejo y/o gestión de pedidos de una manera
muy optima y eficiente, con herramientas que facilitan a los clientes y al personal
(meseros y chefs) a realizar el flujo de un pedido, es decir, desde la petición del
pedido, preparación y finalmente entregar el pedido al usuario final o cliente.
Los restaurantes pueden estar entre los entornos de trabajo más ocupados y agitados,
no solo existen los requisitos de los clientes que solicitan bebidas, alimentos, menús
y facturas, también la demanda del personal y el mantenimiento del local, hacen que
muchos de los restaurantes empiecen a plantearse en hacer uso de herramientas
tecnológicas que permitan optimizar las tareas administrativas y la atención al
cliente, reflejando en un ahorro de tiempo y dinero (Melgarejo, 2019).
Actualmente uno de los procedimientos críticos del restaurante, es el flujo de gestión
de los pedidos ya que esta se realiza de manera tradicional, es decir, de forma
manual.
Cuando los clientes entran al local y realizan sus pedidos de platos que desean, los
meseros apuntan las solicitudes en comandas, posteriormente con estas comandas los
meseros avisan a los chefs para la preparación. Los chefs y meseros no tienen una
manera rápida y ordenada de visualizar que platos ya se encuentran en preparación,
que platos estan pendientes y las mesas correspondientes.
2
Esto ocasiona que con frecuencia los clientes se vayan inconformes del restaurante,
por estas principales razones: errores al apuntar los pedidos, pedidos duplicados,
errores en la entrega de los pedidos y retraso en entregar los pedidos, es a causa de
ello, que se genera una mala percepción en los clientes y, por ende, no quieren volver
más al restaurante para no repetir la experiencia.
Por tal razón, se ha determinado mejorar la gestión de los pedidos mediante la
implementación de una aplicación web, que agilice el registro de ordenes de pedidos.
Figura 1
Problema principal, causas y efectos
Pérdida de
Efectos
Sobreesfuerzo de Rechazo de los

Pérdida de tiempo Pérdida de clientes
los chefs y clientes hacia la confianza hacia el
para los clientes
meseros atención restaurante
Problema
Ineficiencia gestión de pedidos en un restaurante
general
Causas
Errores al apuntar Pedidos retraso en la Errores en la Mala atención a

los pedidos duplicados entrega de los entrega de los los clientes
pedidos pedidos
Nota. El diagrama representa el problema general y la relación de las causas y sus
efectos. Elaboración propia.
3
Tabla 1
Tabla relación de causa y efecto
Problema principal: Ineficiente gestión de pedidos en un restaurante
CAUSAS EFECTOS
Errores al apuntar los pedidos Pérdida de tiempo para los clientes
Pedidos duplicados Sobre esfuerzo de los chefs y meseros
Retraso en la entrega de los pedidos Rechazo de los clientes hacia la atención
Errores en la entrega de los pedidos Pérdida de confianza hacia el restaurante
Mala atención a los clientes Pérdida de clientes
Nota. Esta tabla representa la relación directa entre las causas y sus respectivos
efectos. Elaboración propia.
1.2. FORMULACIÓN DEL PROBLEMA
1.2.1. Problema general
¿Cómo la implementación de una aplicación web influye en la gestión de
pedidos en un restaurante?
1.2.2. Problemas específicos
PE1: ¿Cómo la implementación de una aplicación web influye en la
simplificación de la gestión de pedidos en un restaurante?
4
productividad de la gestión de pedidos en un restaurante?
precisión de la gestión de pedidos en un restaurante?
1.3. DETERMINACIÓN DE OBJETIVOS
1.3.1. Objetivo general
Implementar una aplicación web para la mejora de la gestión de pedidos en
un restaurante.
1.3.2. Objetivos específicos
OE1: Determinar como la implementación de una aplicación web mejora
la simplificación de la gestión de pedidos en un restaurante.
la productividad de la gestión de pedidos en un restaurante
la precisión de la gestión de pedidos en un restaurante.
1.4. HIPÓTESIS
1.4.1. Hipótesis general
La implementación de una aplicación web influye notablemente en la
gestión de pedidos en un restaurante.
1.4.2. Hipótesis específicas
HE1: La implementación de la aplicación web influye notablemente la
simplificación de la gestión de pedidos en un restaurante.
5
productividad de la gestión de pedidos en un restaurante.
precisión de la gestión de pedidos en un restaurante.
1.5. JUSTIFICACIÓN DE LA INVESTIGACIÓN
1.5.1. Teórica
Este presente proyecto para la implementación de la aplicación web se
desarrolló con el objetivo principal de mejorar el flujo de gestión de pedidos
de un restaurante, considerando las buenas prácticas utilizadas en
investigaciones previas y aplicando el conocimiento obtenido en el ámbito
laboral y profesional. La gestión de pedidos es unos de los procedimientos
más importantes y esenciales del mercado actual, es por ello por lo que se
busca reducir tiempos de entrega y disminuir errores humanos en el flujo.
1.5.2. Práctica
Finalizando con la implementación de la aplicación web el restaurante
tendrá una eficiente gestión de pedidos en donde los usuarios (meseros y
chefs) podrán consultar el listado de pedidos y sus estados por cliente, el
cual, reducirá errores al apuntar los pedidos, eliminación de pedidos
duplicados y reducirá los tiempos de entrega, por ende, también se mejorará
el servicio al cliente.
6
1.5.3. Metodológica
El marco de trabajo utilizado en implementar la aplicación web es el marce
de trabajo ágil llamada Scrum, esta metodología se utilizará con la finalidad
de optimizar uno de los procesos más decisivos en un restaurante.
Se eligió utilizar el marco de trabajo ágil Scrum debido a la gran capacidad
que tiene de ayudar a gestionar proyectos y servicios de complejidad alta,
facilitando el desarrollo basado en entregables mínimos, viables y de gran
utilidad para el cliente.
Lista comparativa de las primordiales cualidades entre metodología Ágil y
Cascada:
Tabla 2
Diferencia entre Ágil y Cascada
7
Nota. Esta tabla muestra las principales diferencias entre las metodologías
Waterfall y Scrum. Tomado de Edrawsoft, por Edraw, 2022.
1.6. DELIMITACIÓN DEL ESTUDIO
1.6.1. Espacial
Esta investigación se efectuara en un restaurante localizado en el
jurisdicción de Cercado de lima, en la ciudad de Lima.
1.6.2. Temporal
Esta investigación e implementación harán uso de datos del año 2022.
1.6.3. Conceptual
El presente estudio analizara los flujos involucrados directamente en la
gestión de los pedidos. Esto se refiere a que se trabajara con los clientes,
meseros, chefs y gerente del restaurante. Es desde este punto que se
implementará la aplicación web haciendo uso del marco de trabajo ágil
Scrum, que admitirá la mejora continua del producto.
CAPÍTULO II: MARCO TEÓRICO
2.1. ESTADO DEL ARTE
Las soluciones tecnológicas proporcionan múltiples características que tienen como
finalidad aumentar la eficacia y eficiencia de los proceso o flujos internos en una
empresa. Una de las principales características que permite elevar la productividad y
8
que permite volver más competitiva a las empresas es la producción de información
fácil, precisa y confiable. De hecho, las aplicaciones orientadas al sector comercial,
es decir, aplicaciones que permiten la adquisición de recursos (bienes y servicios)
mediante internet, es el sector empresarial que mayor porcentaje de crecimiento está
teniendo. De las razones más importantes del crecimiento del sector empresarial es
que las aplicaciones de comercio electrónico han conllevado a que los consumidores
obtengan muchos beneficios en los últimos 10 años (Truden, 2022). Del mismo
modo, las aplicaciones web orientadas al sector comercial se han convertido en una
necesidad empresarial. Ya que desde que las aplicaciones web se convirtieron en una
novedad de vanguardia en el sector, los empresarios con menor capital en su mayoría
los utilizan para atraer nuevas ventas o para proporcionar a los usuarios una
investigación muy valiosa de los productos (Yasmeen, 2022). Asimismo, la
investigación del comercio electrónico es de las ramas con más aceptación tiene por
los usuarios y más beneficios trae para las empresas del sector comercial, por ende,
es una de las ramas más estudiadas por la administración de empresas que se
establecen electrónicamente mediante el uso de internet, la aprobación del comercio
electrónico está ganando más usuarios y empresas estan añadiendo sitios web y
aplicaciones de comercio electrónico debido a lo anteriormente comentado (Abdalla,
2021). En resumen, la adición de aplicaciónes web en las empresas, produce grandes
beneficios estas debido a que optimizan los procesos internos facilitando y
mejorando la productividad, eficiencia y eficacia de los colaboradores y, por ende,
todas estas mejoras se reflejan en la mayor aceptación de los usuarios e incremento
en los porcentajes de ventas.
9
De las bonificaciones más interesantes que las aplicaciones web brindan a las
empresas que las utilizan en sus procesos internos es la seguridad que estos poseen,
ya que las debilidades de la lógica de negocio empresarial son susceptibles a la
manipulación y a la mala utilización, lo que podría provocar diversos tipos de
ataques (Mitra, 2020). Sumado a lo anterior, hay diferentes pruebas que se le hacen a
las aplicaciones web para así poder asegurar la calidad, integridad y seguridad de la
lógica de negocio que hay de detrás de estas, estas pruebas estan basadas en
diferentes técnicas que tratan de romper propiedades ya que estas tienen la función
de generación de datos internos para así poder certificar que la aplicación cumple con
el comportamiento especificado (Bernharrd, 2019). Adicionalmente, el progreso de
las tecnologías con las que se desarrollan y se soportan las aplicaciones web
avanzado inmensamente y fomentan la cocreación de factores que generen valor en
los entornos comerciales. Los soportes a las herramientas y tecnologías que se
utilizan para la implementación y desarrollo de las plataformas web sirven para
compartir información y así poder crear ecosistemas de generación de valor a partir
de esa colaboración colectiva (Clara, 2018). Por consiguiente, las bondades que se
generan con la adición de aplicaciones web a nivel de seguridad en los procesos
internos de las empresas, está tomando un valor muy importante, ya que, se logra
afianzar la confianza a estas herramientas, tanto para las propias empresas como para
los usuarios que las utilizan.
El siguiente punto de vista, es el cambio y evolución constante que está teniendo el
internet lo que conlleva al incremento exponencial de servidores web, por ende, la
adición de aplicaciones web en el mundo es cada vez más necesaria, y con
10
obligatoriedad específicamente en el sector empresarial, ya que las empresas buscan
que los usuarios tengan una interacción más cercana con lo que estos ofrecen para así
que tener una mayor rentabilidad (Artail, 2017). Del mismo modo, desde la
perspectiva del entorno que adicionalmente como se sabe también está en continua
evolución y cambio en las empresas del sector comercial, la implementación de
herramientas que permitan procesos y flujos comerciales adaptables es algo
fundamental, en especial en áreas en donde se tienen procesos internos con mucha
demanda de información y que se hacen de una manera no optima ni eficiente (Xu,
2019). Sin embargo, con la generalización económica, la demanda y oferta en el
mercado estan evolucionando de forma rápida mejorando los procesos internos de
sus cadenas de suministros para que puedan garantizar las respuestas hacia las
exigencias del mercado y así poder sobrevivir y desarrollarse. En dicho entorno los
pasos para concretar un implementación de aplicación web son muy complicados en
el sentido de que la lógica de negocio está en constante mejora, es por ello, que los
pasos y herramientas que se requieren para la ejecución e implementación de las
aplicaciones web tienen que estar a la vanguardia de esos cambios, para que así se
logre la finalidad de dichas aplicaciones, como por ejemplo, optimizar procesos,
aumentar la productividad, disminuir errores humanos y/o aumentar en ventas (Jing,
2022). En este sentido, cabe resaltar que la adición de aplicaciones web en empresas
del sector comercial no son para nada sencillas, debido a la constante evolución de la
lógica de negocio y tecnológicas, necesarias para el desarrollo de estas, por lo cual es
requisito que las empresas se mantengan a la vanguardia en esos factores o al menos
11
que puedan cubrir esas necesidades o necesidades de los usuarios a los que estan
enfocados.
Actualmente internet es el medio de información y comunicación más usado en el
mundo. Análisis establecen el número de aplicaciones web en más de cien millones,
el porcentaje de aplicaciones web que se utilizan en empresas del sector comercial va
en aumento, a pesar de ello, algunas empresas rechazan la idea de implementar estas
herramientas como sistema de optimización de procesos. Algunas de las
características por la cual se rechaza la adición de esta tecnología es por la
dedicación en tiempos que se deben tener en cuenta para facilitar la adaptación de los
usuarios y colaboradores (Morales-Vargas, 2020). Sumado a lo anterior, se debe
tener mapeado los costos de soporte, mantenimiento y posteriores actualizaciones,
para así poder cubrir las necesidades del negocio, del mercado y de los clientes como
se sabe, estan en constante cambio y mejora (Aicherning, 2019). Incluso, las
empresas al tomar la decisión de añadir e implementar aplicaciones web para cubrir y
optimizar ciertos procesos internos y comerciales, estan tomando un potencial riesgo,
debido a que, está la posibilidad de que en el proceso de implementación se
presenten inconvenientes que hagan que la implementación falle, ya que como se
sabe, las áreas internas de una empresa estan orientadas al objetivo colectivo de la
misma pero cada área tiene adicionalmente un objetivo independiente (Bassano,
2018). Además, por varios años, indicadores, investigaciones y análisis, han
determinado que implementar aplicaciones web que ayuden a optimizar procesos
comerciales requieren de inversiones no necesariamente monetarias, sino,
inversiones de tiempo, ya que se debe analizar a detalle el contexto en el que se
12
encuentra la empresa y así poder asegurar que la aplicación será un aporte y no un
simplemente una perdida tanto de dinero como de tiempo (Filipeti, 2018). Por tanto,
implementar aplicaciones web en entornos comerciales requiere grandes inversiones
que las empresas deben considerar antes de realizar la implementación, dinero y
tiempo son de los factores más críticos, adicionalmente, está el riesgo que deben
asimilar las empresas, ya que, como se sabe hay antecedentes de proyectos que
fracasaron por no tener en cuenta los factores anteriormente mencionados, adiciona a
eso, por obvias razones se debe tener un gran equipo con suma experiencia para que
se pueda hacer la transición de realizar procedimientos manuales a realizarlos
mediante la aplicación web, tanto para los colaboradores que lo utilicen de manera
interna y de darse el caso, en entornos empresariales y comerciales para los usuarios
finales.
Generalmente, la mayoría de las empresas que prefieren implementar aplicaciones
web son aquellas empresas que ven todas las ventajas que te da el ingresar al
mercado del comercio electrónico ya que varios gobiernos tienden a realizar grandes
apoyos para que así, dicho mercado mejore y evolucione rápidamente, una de las
áreas con mayor relación y se ve afectada directamente al implementar una
aplicación web para uso comercial, es el área logística de dicha empresa, ya que,
comparando el flujo tradicional con el nuevo flujo dentro del entorno del comercio
electrónico aparecen cambios sin precedentes dentro de estos, está la simplificación
de procesos y la automatización de la gestión de los pedidos, el cual busca disminuir
el trabajo mental y físico de las personas que interactúan en dicho proceso (Shi,
2022). Asimismo, la mejora de las áreas que interactúan y se ven afectados por la
13
adición de una aplicación web dentro de la empresa, implican un gasto monetario que
debe asumir la empresa por mejorar los procesos internos de estas áreas para que
engranen de la mejor manera con la adición de la aplicación web y no exista un
desfase que conlleve al fracaso de la implementación (Huang, 2021). Por otro lado,
hay factores evidentes que suman para implementar y desarrollar la solución
tecnológica a nivel de desarrollo en una empresa falle, de las principales
características, es el asegurar que el código, arquitectura e infraestructura cumpla con
las buenas prácticas ya definidas y con ello garantizar la buena calidad del software,
otro de las características a considerar, es el buen proceso de adaptación que deben
tener las personas que van a interactuar con la herramienta, ya que, por este motivo
se puede dejar de lado y en desuso la aplicación web debido a que no hubo el proceso
de adaptación adecuado y se hizo de maneras en las que no se tuvo en cuenta el
feedback de las personas involucradas (Busalim, 2021). Debido a las dificultades
mencionadas, ciertas empresas alrededor del mundo optaron por continuar realizando
sus procesos de manera tradicional, es decir, de forma manual, ya que se encuentran
en su zona de confort (Ali, 2019). En síntesis, ciertamente hay riesgos que deben
asumir las empresas para realizar la implementación y ejecución de una aplicación
web, debido al contexto en el que se encuentra dicha empresa, realizar un análisis del
mercado, colaboradores y clientes para así lograr que la implementación sea un éxito.
2.2. BASES TEÓRICAS
14
2.2.1. Aplicación web
Es denominada aplicación web, a la herramienta que permite disponibilidad
y facilidad a los navegantes o usuarios para poder enlazarse a un servidor
mediante internet mediante los protocolos de comunicación HTTP o HTTPS
haciendo uso de un navegador predeterminado. Las aplicaciones web estan
desarrolladas a través de lenguajes especialmente preparados para que
puedan ser interpretados por los navegadores web, para que así la
responsabilidad de ejecución se delegue al navegador utilizado. Las
aplicaciones web son únicamente instrumentos de ofimática de la web 2.0 y
que utilizan solamente un enlace a internet, el mayor porcentaje de los casos
una de las opciones es usar la computadora como manera de acceder a las
múltiples aplicaciones remotas. (Villoria, 2010)
Los términos aplicación web y sitio web, pueden llegar a confundir debido a
que comparten el concepto funcional y propósito, ya que, ambas son
plataformas digitales. Sin embargo, estas tienen diferencias, tales como:
 La aplicación web puede llegar a estar incluida y/o pertenecer al
proyecto de un sitio web, pero nunca un sitio web llegara a pertenecer
al proyecto de una aplicación web.
 El sitio web tiene como objetivo principal informar a los usuarios,
mientras que, la aplicación web tiene como objetivo principal realizar
acciones.
 La aplicación web es compleja, debido a que realiza muchas tareas y
tiene múltiples funcionalidades.
15
Posterior a comprender estas diferencias, se nombrarán algunos de los
principales beneficios que se dan por utilizar una aplicación web:
 Seguridad: Las aplicaciones web utilizan medios y herramientas que
refuerzan la autenticidad del usuario, como por ejemplo usuario y
contraseña, aun mas en el medio actual en donde se disponen de
herramientas como OAuth 2.0, dicha herramienta facilita la
identificación de usuarios con cuentas ya existentes, haciendo uso de
plataformas tales como Gmail, Facebook, entre otras.
 Compatibilidad: Las aplicaciones web son indistintas a las
especificaciones del computador donde se esta utilizando, ya que, esta
se ejecuta en un navegador web que tenga las mínimas
especificaciones requeridas.
 Actualización: El cliente, grupo de interesados o el equipo que ha
desarrollado la aplicación, podrá aplicar modificaciones que afectaran
a todos los usuarios que la utilizan.
 Ahorro de tiempo: Las aplicaciones web al ejecutarse en navegadores,
los usuarios no necesitan de alguna configuración o instalación previa
para poder utilizarlas, el único requisito es tener conexión a internet.
Figura 2
16
Línea del tiempo de la evolución de la web
Nota. El grafico representa la evolución de la web a través del tiempo.
Tomado de Novaspivack, por Nova Spivack, 2007.
2.2.1.1. Motor de base de datos
Desde sus inicios, la tecnología de información se ha encargado de brindar
herramientas que hagan posible la administración de información. Los
cajones, alfombras y fichas en las que se almacenan los datos eran las únicas
herramientas utilizadas por las organizaciones para gestionar sus datos antes
de que aparezcan las aplicaciones de información. El tipo solicitado para
manipular tales datos en ese proceso manual fue muy alto (Nevado, 2010).
Con el paso de los años, las bases de datos fueron evolucionando, y hoy en
día se pueden clasificar de la siguiente manera:
17
 Según el modelo:
o Relacionales
o Distribuidas
o NoSQL
 Según el contenido:
o Bibliográficas
o Texto completo
 Según la variabilidad:
o Estáticas
o Dinámicas
Y muchas más clasificaciones y tipos, la presente investigación hará uso
de un gestor de base de datos relacional basada en onpremise, es decir, una
base colocada de manera privada.
Figura 3
Diseño de bases de datos relacionales
Nota. El grafico representa el diseño de las bases de datos relacionales.
Tomado de UF2175 – Diseño de base de datos relacionales (p. 15), por A.
B. García, 2015.
18
2.2.1.2. Backend con Java
Colaboradores sumergidos en el desarrollo de software oímos hablar
de Java sin saber que convivimos de manera cercana con este término,
para ilustrarlo aquí va un ejemplo simple, si tiene un teléfono
inteligente en las manos, las aplicaciones que utiliza pueden estar
escritas en Java. Sin embargo, ¿Por qué debería ser este el caso
cuando existen muchos otros lenguajes de programación como Visual
Basic?, Java se diferencia de otras aplicaciones debido a que es mucho
más portátil (Torres, 2013).
Las siguientes características de Java como lenguaje de programación
lo convierten en una de las opciones más populares para tareas de
backend:
 Escalable
 Fácil de entender
 Compatible con subprocesos múltiples
 Bibliotecas de código abierto
 Tiene opciones de seguridad mejoradas
Se usará Spring Boot como marco de trabajo y r2dbc basado en JPA
que se usará como ORM relacionado para la base de datos, se utilizará
java 8 como versión del lenguaje.
19
Figura 4
Logo de Java
Nota. El grafico muestra el logo representativo de Java. Tomado de
Oracle Java, https://www.oracle.com/pe/java.
2.2.1.3. Frontend con Angular
Angular se utiliza para crear paginas SPA (Single Page Application),
debido a que es uno de los framework de desarrollo open source
(código abierto) basado en JavaScript y mantenido por Google, el
termino SPA significa que las actualizaciones posteriores ocurren sin
necesidad de recargar completamente la página, es decir, la página
carga todas las funcionalidades solo al inicio.
Fue introducido en el año 2010 y recibió el nombre AngularJs,
después del lanzamiento de la versión 2 en 2016, se reescribió por
completo y cambio su nombre a solo Angular (Puciarelli, 2020).
Una de las razones por las que es uno de los marcos de desarrollo
(frameworks) más populares también se debe a su modularización que
permite el trabajo en equipo y ha acelerado su adopción por parte de
los equipos de trabajo en desarrollo de software. Además, el lenguaje
20
de programación utilizado es TypeScript, que es un superconjunto de
JavaScript que Microsoft creo en 2012 y que hace que JavaScript se
centre en la programación orientada a objetos.
Los equipos que siempre han desarrollado en lenguajes para backend
(creando software monolítico) ahora se sienten cómodos haciendo la
transición al frontend como resultado del factor anterior.
Figura 5
Logo de Angular
Nota. El grafico muestra el logo de Angular. Tomado de la
documentación oficial de Angular, https://angular.io/docs
2.2.1.4. Diseño Responsive
Varios años posteriormente a la introducción de HTML y 19 años
después de la introducción de CSS, Ethan Marcotte público su artículo
sobre “Diseño web adaptable” en la revista online A List Apart en
2010. En ese artículo, Ethan explico que el concepto de adaptabilidad
web está basada en la combinación de tres factores técnicos:
cuadriculas fluidas, imágenes flexibles y consultas de medios, sin
21
embargo, este nuevo enfoque también adopta una moderna forma de
pensar acerca de las plataformas web, en lugar de crear varias
versiones separadas de un sitio web, se debe centrar en crear varios
aspectos de un diseño único y unificado que se pueda personalizar
para el contexto de preferencia de cada usuario (De León, 2016).
Figura 6
Diferencia entre cantidad de contenido del sitio web Boston Globe
Nota. Adaptado de Responsive & Fast: Implementing High-
Performance Responsive Design (p. 8), por G. Podjarny, 2014
2.2.1.5. Control de versiones
El neófito tiende a pensar en control de versiones como un sistema
incremental de protección de información, gracias a un sistema de
administración de versiones, los developers pueden recuperar todas
sus versiones anteriores, Git, sin embargo, también abre una amplia
22
gama de otras posibilidades, además, te permite ejecutar muchas
versiones del mismo programa simultáneamente, por ejemplo,
mientras un desarrollador está trabajando en una nueva característica,
sin embargo, esta función no debe integrarse en programa terminado,
Git también es útil como documentación completa. Cada nuevo
cambio en el código vendrá con un mensaje. Después de varios años,
estos mensajes podrían contarse por miles y convertirse en registros
fascinantes de las circunstancias en las que se realizaron los cambios
(Dauzon, 2018).
Figura 7
23
Sistema de gestión de versiones locales
Nota. El grafico muestra el control de versiones local. Tomado de la
documentación oficial de Git, https://git-scm.com/book/es/v2/Inicio---
Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones
24
Figura 8
Sistema de gestión de versiones centralizado
Nota. El grafico muestra el control de versiones centralizado. Tomado
de la documentación oficial de Git, https://git-
scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-
del-Control-de-Versiones
25
Figura 9
Sistema de gestión de control de versiones distribuidas
Nota. El grafico muestra el control de versiones distribuidas. Tomado
de la documentación oficial de Git, https://git-
scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-
del-Control-de-Versiones
26
2.2.2. Gestión de pedidos
La administración de pedidos corresponde a un procedimiento inicial que
toma la empresa, en esta se recepcionan, aceptan, consultan o archivan los
pedidos. Asimismo, en caso de aceptación de un pedido, esta es derivada a
su respectiva área de interés, en donde se toma en cuenta, con la
información disponible, opciones para satisfacer el pedido registrado.
Además de ello, se considera un proceso muy importante debido las
exigencias que demanda el mercado en la actualidad, exigencias
relacionadas a la rapidez, atención personalizada, eficiencia con el fin de ser
competentes frente a las demás empresas del rubro (Sanchis & Poler, 2018).
Por otra parte, se menciona que, anteriormente, el flujo de gestión de
pedidos pertenecía a la gestión de clientes, en donde además de tratar el
pedido del cliente, se trataban quejas, reclamos y devoluciones. Además de
ello, se resalta que el inicio del proceso se da con el arribo del pedido y
finaliza cuando este es entregado, vaerificado y pagado por el cliente.
Finalmente, este proceso busca maximizar el valor de cadena de
abastecimiento y atención al cliente, para ello, el procedimiento de gestión
de pedidos está en una constante actualización, de acuerdo con los avances
de la tecnología, generando una amplia ventaja entre aquellos que emplean
los beneficios de esta y aquellos que no (Cruz, 2019).
27
Figura 10
Ejemplo de gestión de pedidos
Nota. El grafico representa el diseño de gestión de datos en una empresa
Tomado de “Order promising” y Gestión de Pedidos: una visión de
procesos (p. 6), por F. Alarcón, 2005.
28
2.2.2.1. Ciclo de la gestión de pedidos
Recepción
En esta etapa se recibe la propuesta y se hace la prevalidación
inicial, teniendo en cuenta que la propuesta que hace el cliente se
convierte en pedido, solo cuando esta es aceptada por la empresa.
En la prevalidación se evalúa si, efectivamente, la propuesta del
pedido está correctamente planteada, es decir, si presenta la
información necesaria para llevar a cabo el pedido como cantidad,
descripción del producto, fecha, entre otros. Luego de ello, se da el
visto bueno a la prevalidación de la propuesta del pedido, o caso
contrario, la empresa se comunica con el cliente para esclarecer
dudas acerca del pedido.
Validación
En esta fase posterior a la prevalidación, conocida como
validación final, se evalúan los criterios relacionados con la
política de la empresa, como no aceptar pedidos fuera del área de
reparto establecidas u observar si el cliente es moroso o
problemático, además de tener en cuenta decisiones específicas
de la empresa, como no admitir pedidos de un tipo con menos de
cierta cantidad.
29
Registro
El proceso siguiente a la validación es el guardado en la base de
datos del restaurante, este va a depender del software que maneje
la empresa en su sistema informático, pero en general, en este
proceso ocupa el rellenado de campos importantes para el
conocimiento de las áreas a cargo de llevar a cabo el pedido.
Order Promising
Es el conjunto de acciones o medidas que establece la empresa, a
través de sus áreas encargadas con el fin de llevar a cabo el pedido.
En esta etapa se evalúan las fechas de entrega, cantidades,
compromiso de calidad, siendo estas respuestas a la pregunta
¿Cuán posible es comprometerse con la propuesta de pedido? Al
analizar ello, el pedido pasa a estar pendiente de cumplimiento,
gracias a que el OP ha dado todos los lineamientos para la acción.
Consulta del estado del pedido
Esta etapa se caracteriza por evaluar el performance de la empresa
al cumplir los plazos y costes, conociendo en qué etapa se
encuentra el pedido, dentro del proceso de fabricación.
Almacenamiento y consulta de pedidos terminados
30
En esta etapa, el pedido comprometido pasa a ser pedido terminado
y se irá almacenando en el core de la empresa como parte del
historial de pedidos, en donde ya no figurará más como pedido
activo sino como pedido inactivo. Asimismo, está abierta la
posibilidad de reclamo por parte del cliente luego de haberse
entregado el producto, en caso eso se llegue a dar, el pedido inactivo
pasará a llamarse pedido reactivado para reingresar al proceso de
fabricación.
Asimismo, es importante mencionar que no todas las empresas
ocupan todos los subprocesos, ya sea por una mala administración o
porque tienen una capacidad productiva que permite aceptar todo
tipo de pedidos por más grandes que sean (Alarcón, 2005).
Figura 11
Fases del ciclo de vida del pedido y eventos (subprocesos) asociados
31
Nota. El grafico representa las fases del ciclo de vida de un pedido
Tomado de “Order promising” y Gestión de Pedidos: una visión de
procesos (p. 8), por F. Alarcón, 2005.
32
2.2.2.2. Pedidos
Un pedido es un documento que une al cliente con la empresa, en
este se presentan los datos necesarios para la que la empresa tome
acción. Entre los principales datos se encuentran aquellos
relacionados con el cliente, producto (calidad esperada, modelo,
descripción de este), cantidad, fecha de entrega. Luego de ello, el
pedido pasa a tener un peso de contrato con la empresa, siendo una
obligación el cumplimiento de las condiciones pactadas; el
incumplimiento de estas obliga a la empresa el pago de
indemnizaciones (Alemany, 2007).
2.2.2.3. Administración de restaurantes
La administración es entendida como una ciencia que tiene el
objetivo de controlar los recursos, dirigir, organizar y planificar las
actividades. Asimismo, esta labor está compuesta por procesos,
siendo el primero, la planeación, en donde se definen las
actividades a ejecutar por parte de la empresa en búsqueda de
cumplir objetivos que también deben plantearse en esta fase inicial,
es importante tener en cuenta que la rentabilidad del restaurante es
primordial. Por otra parte, en la etapa de organización se debe
ubicar a los trabajadores en sus puestos y se les debe asignar un
horario, funciones y responsabilidades. Finalmente, en la etapa de
coordinación, la administración se encarga de evaluar si
33
efectivamente las actividades planteadas se desarrollan
correctamente y se acoplan en la consecución de objetivos
(Galarza, 2016).
Figura 12
Etapa de planeamiento de un restaurante
Nota. El grafico representa la etapa de planeamiento de un restaurante.
Tomado de Administración de restaurante (p. 4), por I. Galarza. 2016.

34
Figura 13
Aspectos de la administración de un restaurante
Nota. El grafico representa los aspectos tomados en cuenta para la
dirección y administración de un restaurante. Tomado de Administración
de restaurante (p. 6), por I. Galarza. 2016.
35
2.2.2.4. Establecimiento comercial
Este hace referencia a todos los puntos de comercio, en donde se
ofrecen un conjunto de bienes, de acuerdo con los intereses del
empresario y objetivos de su institución. A lo que va de la historia han
sido desarrolladas diversos establecimientos y han sido clasificados en
establecimientos de venta de productos alimenticios perecederos o de
larga duración, siendo los restaurantes un establecimiento del primer
tipo. Asimismo, muchos de ellos se han especializado en cierto rubro
como carnicerías o pescaderías, sin embargo, existen aquellos que no
se especializan en ningún rubro en específico ya sea porque
obtendrían un margen comercial bajo o porque no completan su
mínimo de ventas, a estos últimos se les denomina generalistas y aquí
se encuentra a los abarrotes, ultramarinos, etc. (Rebollo, A).
Por otra parte, se presentan ciertas características de un
establecimiento:
 Localización: Este es un aspecto muy importante en la
búsqueda de una máxima productividad del establecimiento,
ya que, si está ubicado en un lugar comercial, existirá una
potencial mayor clientela.
 Edad del establecimiento: Hace referencia a un aspecto muy
importante, el hecho de que la administración conozca a qué
etapa del ciclo de vida ocupa su establecimiento para aplicar
estrategias acordes a ello.
36
 Tipo y tamaño del establecimiento:
Definir el tipo de establecimiento teniendo en cuenta la
localización y el público objetivo es primordial para el éxito
del restaurante, de igual manera, el tamaño del establecimiento
podría generar economías de escala que permita una
disminución de costos (Núñez, 2017).
2.2.2.5. Atención al cliente
Esta es de las principales acciones llevada a cabo por la empresa. Esta
busca complacer todos los requisitos de sus clientes mediante un
incremento de su productividad, lo que incrementa su competitividad
frente a la competencia. Asimismo, la atención al cliente está
compuesta por elementos como la eficiencia, liderazgo, cultura
organizacional y capital humano, el desarrollo de cada uno de los
elementos crea en su conjunto una mejor atención al usuario final. Por
último, es importante remarcar la importancia de la cultura
organizacional dentro de la empresa, el hecho de que todos los
integrantes del equipo de trabajo se identifiquen y se sientan parte de
la organización, genera una motivación en ellos de realizar sus
actividades con calidad y compromiso (Godoy, 2011).
37
Figura 14
Proceso de atención al cliente
Nota. El grafico representa el proceso de atención al cliente en un
restaurante. Tomado de Optimización del proceso de atención al cliente en
un restaurante durante períodos de alta demanda (p. 31), por Schmal, R y
Olave, T. 2016.
2.2.2.6. Personal de una empresa
Son todas las personas que llevan a cabo una serie de labores y en
función a eso asumen responsabilidades dentro de la empresa. De esta
manera, el desempeño del personal de la empresa va a determinar el
éxito o fracaso de esta, por lo que estos deben ser elegidos muy
cuidadosamente, para que una vez contratados presenten una misma
visión de crecimiento de la empresa (Acuña y González).
38
2.2.3. Proceso Racional Unificado (RUP)
Es una guía creada por la empresa Rational Software, perteneciente a
la compañía International Business Machines Corporation, con el fin
de enseñar la aplicación del Lenguaje Unificado de Modelado (ULM).
Asimismo, a través del RUP, se busca automatizar el proceso de
programación y modelado en proyectos de todo tipo de tamaño. Entre
sus beneficios resaltan el incremento en la productividad del equipo y
un mismo lenguaje de flujos que permite un conocimiento pleno del
proyecto (Sánchez, 2017).
2.2.3.1. Principios del RUP
Demostración de valor de forma iterativa
Durante el desarrollo del software, se aplica un enfoque iterativo que
permite la corrección y constante mejora del proyecto, de esta manera, se
reduce el nivel de riesgo de fracaso del proyecto.
Administración de requerimientos
La metodología RUP resalta la importancia de escuchar las
necesidades, en cuestión de recursos, de todos los miembros del
proyecto. Por ello postula los casos de uso como una manera de
atender los requisitos funcionales que permitan el desarrollo del
diseño y las pruebas de software.
39
Arquitectura en base a componentes
La metodología RUP propone que la creación del software sea
dividida por sus componentes, de esta manera se puede revisar de
mejor manera la calidad de cada uno de los componentes y en caso de
alguno falla, sea modificable y en un futuro, permita darle otro uso al
mismo código.
Modelado visual
Este se logra con el uso de modelos gráficos que permitan capturar la
estructura del proyecto y su desempeño junto con sus componentes,
además permite evaluar la coherencia entre el diseño y la aplicación.
2.2.3.2. Fases del RUP
Se pueden reconocer 4 fases: iniciación, elaboración, construcción y
transición. En donde, al fin de cada una de ellas, se obtiene un
producto definido.
40
Figura 15
Ciclo de vida del RUP
Nota. El grafico representa el ciclo de vida del RUP. Tomado de
Desarrollo De Un Sistema Encargado De La Gestión De Información De
Clientes Para La Fundación FUDRINE Usando La Metodología Del
Proceso Racional Unificado RUP. (p. 36), por Contreras, J. 2017.
Figura 16
Ejemplo de flujo de trabajo del RUP
41
Nota. El grafico representa el flujo de trabajo del RUP. Tomado de Diseño
Y Desarrollo De Un Sistema Computacional De Registros Bio-
Psicosociales Y Terapia Ocupacional Para Niños Y Jóvenes Con
Discapacidad Intelectual Para La Fundación Iepni Usando La Metodología
Del Proceso Unificado Racional RUP. (p. 13), por Sánchez, 2017.
2.2.4. SCRUM
Esta es de las metodologías agiles de desarrollo de software más usadas a
nivel mundial. Esta debe su nombre al símil que encontraron sus creadores
en una formación empleada en el Rugby. Asimismo, esta metodología ágil
se centra en trabajos iterativos que permiten la mejora del sistema a través
de ajustes, además de ello está estructurado en etapas del proyecto llamados
Sprints, estos tienen una duración de 1 a 4 semanas y al final de cada Sprint,
el equipo presenta el avance de la construcción del modelo al resto del
equipo para obtener comentarios y observaciones que puedan ser aplicadas o
corregidas en el próximo Sprint (Rodríguez & Dorado, 2015).
42
Figura 17
Roles, artefactos y eventos principales de SCRUM
Nota. El grafico representa la estructura de SCRUM. Tomado de
Implementación de SCRUM en el diseño del proyecto del Trabajo Final de
Aplicación. Usando La Metodología Del Proceso Racional Unificado. (p.
415), por Mariño, S y Alfonzo, P. 2014.
2.2.5. Waterfall
Es un modelo de desarrollo y gestión de proyectos caracterizado por seguir
una secuencia a nivel de etapas, siendo el ejemplar más antiguo dentro de la
ingeniería de software. Asimismo, es necesario que el cliente exprese de
forma clara todos los requerimientos, no aceptando la incertidumbre que
suele existir en los inicios de un proyecto. Por otra parte, a diferencia de
43
otros modelos, en este, el cliente no verá una versión inicial o intermedia del
programa hasta que esté muy próximo a culminarse, motivo por el cual,
cuando el cliente logra ver el resultado, propone cambios o ajustes que
toman tiempo en su ejecución.
Figura 18
Esquema de metodología Waterfall
Nota. El grafico representa un esquema de la metodología Waterfall.
Tomado de Análisis Comparativo Entre Waterfall Y Devops En El
Desarrollo Del Microservicio “Obtener Detalle De Libros En Tienda
Virtual. (p. 23), por Ramírez, M. 2020.
2.2.6. Marco Conceptual
2.2.6.1. Gestión
Se conoce como gestión a toda actividad dedicada a conectar las áreas
de una organización, evaluar resultados y asignar recursos,
eficientemente, para cumplir los objetivos planteados. Asimismo, la
gestión permite una comunicación interna, a través de la recopilación
44
de información y ubicación en una base de datos común (Murray,
2002).
2.2.6.2. PostGreSQL
PostgreSQL es un motor de gestión de base de datos con código
fuente abierto y esta licenciada bajo la licencia de Berkeley Software
Distribution (BSD). Asimismo, este sistema de base datos permite
que los encargados del proyecto puedan colaborar y/o modificar el
modelo de acuerdo con sus requerimientos. Dentro de sus principales
ventajas, se encuentra el hecho de ser un sistema flexible, con buen
rendimiento y estable, además de permitir la compartición de archivos
desde Visual Basic, FoxPro, Delphi, etc. Finalmente, este sistema es
relacional por lo que su almacenamiento es en tablas y reglones,
mientras que la conexión relación entre tablas es posible a través de
las llaves (Ordóñez, 2017).
Figura 19
45
Comparación de PostgreSQL con otras bases de datos
Nota. El grafico representa las características de PostgreSQL y otras
importantes bases de datos. Tomado de PostgreSQL. (p. 3), por Denzer, P.
2002.
2.2.6.3. Spring Boot
Es un framework que maneja gran variedad de configuraciones a
través de su configuración automática, estas configuraciones tienen la
característica de ser repetitivas usando un paradigma de la
programación llamado Convention over Configuration (CoC), de esta
manera se simplifican tareas y aumenta la productividad al obtener
46
valores por defecto. Asimismo, este framework permite la creación de
aplicaciones Spring independientes, din necesidad de un WAR.
Figura 20
Configuración de Spring Boot
Nota.
2.2.6.4. Maven
Maven es un instrumento de gestión de proyectos que tolera la
configuración y modelación de software en la computadora o a través
de IDEs. Asimismo, Maven cuenta con plugins disponibles para
descarga y los archivos desarrollados en esta herramienta presentan la
característica de ser XML. Por otra parte, esta herramienta cuenta con
una serie de pasos como validación y compilación, etapa de prueba,
empaquetado en un archivo WAR, despliegue al servicio de
desarrollo, pruebas de integración, pase al servidor de producción y a
47
la web de documentación. Sin embargo, de encontrarse algún
desperfecto, se debe retroceder un paso y reiniciar su desarrollo en ese
punto (Ulloa, 2019).
Figura 21
Ciclo de Maven
Nota. El grafico representa el ciclo de trabajo en Maven. Tomado de
estudio de la herramienta Maven como gestor de proyectos spring mvc con
el caso de uso aplicación para comercio electrónico. (p. 7), por Ulloa, G.
2019.
2.2.6.5. HTML
El lenguaje de marcado de hipertexto (HTML) es una estructura que
se utiliza para el desarrollo de las páginas web a través de sus
contenidos, división por secciones, imágenes, entre otros formatos de
información. Asimismo, este se construye a través de etiquetas de
inicio y al final, siendo estas instrucciones para organizar el contenido
delimitadas por < y >.
48
Figura 22
Estructura de un documento HTML
Nota. El grafico representa la creación de un documento HTML. Tomado
de Una introducción a HTML, la importancia de conocerlo, la filosofía
subyacente y la sintaxis básica del lenguaje. (p. 4), por Valencia, L. 2013.
2.2.6.6. TypeScript
Considerado como la evolución de Javascript, es un tipo de lenguaje
de programación, el cual fue desarrollado por Microsoft. Asimismo, al
tener frameworks como Angular e Iconic, es uno de los herramientas
más demandados del mercado (Llerena, 2021).
49
2.2.6.7. Git
Es un instrumento de control de versiones que gestiona la
visualización y administración de cada versión desarrollada del
producto. Otras herramientas similares con SourceSafe, PlasticSCM,
CVS, etc. Asimismo, Git se caracteriza por almacenar información
como un grupo de fotografías de un sistema reducido de archivos. Por
otra parte, los archivos de Git se pueden encontrar en tres estados:
Confirmado, haciendo referencia a que el archivo ya se encuentra de
una manera segura en la base, modificado, recalca el hecho de haber
modificado el archivo, pero sin confirmar en la base de datos y
confirmado, al marcar el archivo modificado en su última versión
(Gómez, 2013).
Figura 23
Esquema de versiones en Git
50
Nota. El grafico muestra
el esquema de control de versiones Git. Tomado de Visualización del
rendimiento en equipos de desarrollo Software a través de sistemas de
control de versiones Git. Aniceto, M. 2020.
2.2.6.8. Programación Reactiva
Este tipo de programación es una propiedad de los lenguajes, esta
presenta dos características importantes: el control de eventos a través
del planteamiento de tiempos iniciales como restricciones, además de
responder oportunamente a entradas. Por último, debe tener reacción
frente a los usuarios en tiempo real, capacidad de adaptación
dependiendo del tamaño de información, reacción a eventos como
solicitudes HTTP y resistencia a fallas para permitir su disponibilidad
continua (Rodríguez, 2019).
51
Figura 24
Aplicación de la programación reactiva en proyectos
Nota. El grafico muestra la aplicación de la programación reactiva en
el manejo de proyectos. Tomado de Programación reactiva en la
52
administración de proyectos: aproximación conceptual y aplicaciones
prácticas. Garrido, A. 2013.
CAPÍTULO III: METODOLOGÍA DE INVESTIGACIÓN
3.1. DESARROLLO DE LA METODOLOGÍA
3.1.1. Selección de la metodología
Con el paso del tiempo, los marcos de desarrollo de software continuaron
avanzando y se convirtieron en un componente esencial del desarrollo de
software. Un problema importante, es que numerosos proyectos eligen la
metodología incorrecta o no eligen ninguna, lo que probablemente impide que
se desarrolle el software necesario (Molina, Vite & Davila, 2018). Para
desarrollar soluciones tecnológicas de enorme calidad que cumpla con los
requerimientos recopilados por el cliente, es necesario utilizar la metodología
adecuada.
Utilizar la metodología adecuada permitirá que el software crezca. Esto nos
lleva a considerar la metodología utilizada en el diseño del software. En el que
el término “desarrollo” se refiere a acciones que incluyen la definición,
modificación o renovación de software (Rivas, 2015). Numerosas
metodologías estan actualmente en uso y se pueden clasificar como clásicas,
orientadas a objetos, agiles a más.
Los marcos de trabajo tradicionales o clásicas fueron sugeridos para brindar
más orden en el momento en que se iniciaba el desarrollo del software. Debido
53
a la naturaleza secuencial de proceso de esta metodología y al hecho de que
avanza en una sola dirección sin retroceder, es extremadamente rígida y no
permite cambios (Molina, Vite & Davila, 2018). Como resultado, hay poca
interacción con el cliente y los requisitos que se establecen al comienzo del
proyecto. Una de las metodologías tradicionales más utilizadas es la
metodología Waterfall.
Otro tipo de metodología es la metodología ágil. Las metodologías agiles son
rápidas y adaptables sin dejar de tener la capacidad de actuar, resolver y pensar
problematicas. Este enfoque hace posible que los participantes del proyecto
colaboren entre sí, lo cual es fundamental para el desarrollo de software porque
se requiere afinidad entre la tecnología y el lado operativo del negocio (Micic,
2017). Para lograr el software resultante deseado a través de iteraciones,
revisiones y retroalimentación continua, uno de los marcos de trabajo agiles
más populares es SCRUM. Sus objetivos incluyen la recopilación de
información, la definición de requerimientos, la implementación de iteraciones
que involucren a los usuarios desde el principio y la colaboración del equipo
durante todo el flujo (Cordova, 2018), el total de usuarios estan altamente
comprometidos con el proyecto.
Por otro lado, existen metodologías orientadas a objetivos, estas metodologías
estan estrechamente relacionadas con las notaciones orientadas a objetos, de las
cuales UML es la más utilizada (Capis, 2010). La metodología más conocida
basada en UML es RUP (Proceso Racional Unificado).
54
Debido a que cada tipo de proyecto tiene su metodología más popular
(Waterfall, Scrum y RUP), será necesario realizar un análisis comparativo de
estas tres metodologías antes de elegir una.
Tabla 3
Criterios de selección por metodología
Criterios SCRUM RUP Waterfall
Comunicación con el
Alta (3) Media (2) Media (2)
equipo
Formalidad de las
Baja (1) Alta (3) Alta (3)
reuniones
Equipo
Cantidad de reuniones Alta (3) Media (2) Media (2)
Frecuencia de
Alta (3) Baja (1) Baja (1)
retroalimentación
Cambio de integrantes Riesgo Alto (1) Riesgo Bajo (3) Riesgo Bajo (3)
Complejidad de
Simple (3) Complejo (1) Complejo (1)
entregables y artefactos
Entregables y Cantidad de
Poco (3) Mucho (1) Mucho (1)
Artefactos documentación
Importancia de la
Alta (3) Media (2) Baja (1)
documentación
Comunicación con el
Cliente Alta (3) Media (2) Baja (1)
cliente
55
Autogestión y
autoorganización de roles Si (3) No (1) No (1)
Roles y Tareas y tareas
Cantidad de roles y tareas Baja (1) Alta (3) Alta (3)
Rotación de roles y tareas Si (3) No (1) No (1)
Total 28 22 20
Nota. Esta tabla representa la comparación entre Scrum, RUP y Waterfall.
Adaptado de Criterios de selección de metodología (p. 63), por Espinoza, 2013.
Tabla 4
Factores de análisis
Factores de análisis Puntaje
No, Riesgo Alto, Baja, Complejo,

1
Mucho
Media 2
Si, Riesgo Bajo, Alto, Poco, Simple 3
Nota. Esta tabla muestra los distintos factores de análisis con su respectivo
puntaje. Tomado de Criterios de selección de metodología (p. 63), por
Espinoza, 2013.
56
Utilizando como base la tabla expuesta anteriormente se puede concluir que el
marco de trabajo que se usará en este proyecto deberá ser Scrum, ya que cuenta
con la mayor puntuación en cuanto a los criterios establecidos.
3.1.2. Desarrollo de la metodología
3.1.2.1. Fase de Inicio
Esta fase inicial de Scrum se enfoca en principio en identificar las
necesidades que se estan evaluando y determinar las necesidades
fundamentales que necesita el proyecto para poder lanzar el desarrollo
del trabajo propuesto para el restaurante mientras se define el problema
que han surgido en el campo. Las tareas y actividades para la fase
inicial se mostrarán más adelante.
Tabla 5
Fase de inicio
Actividades Descripción Tareas Roles involucrados
Presentación de la
finalidad del proyecto.

1. Realización de la Especificación del objetivo y Product Owner
Gestación del acta de
visión del proyecto visión del proyecto. Scrum Master
constitución del
proyecto.
Requisitos del cliente.

2. Definir requerimientos Análisis de las necesidades Scrum Master
Establecer el equipo
del proyecto imprescindibles en el proyecto. Development Team
Scrum.
57
Diagrama actual del
Se muestra en detalle los
3. Definir el diagrama de flujo de pedidos. Product Owner
procedimientos realizaros por
proceso del negocio Diagrama con la mejora Development Team
el restaurante.
en el flujo de pedidos.
Nota. Elaboración propia.
Las tareas y entregables de cada actividad en la primera fase se
describirán a continuación:
Actividad 1: Realización de la visión del proyecto
La presente acción brinda una comprensión clara de cómo se
desarrollarán las cosas a través de la revisión de la información de la
empresa, y permite poseer una perspectiva amplia de los pasos a seguir.
Además, se decide que el diseño tendrá un valor agregado.
Entregables:
- Presentación de la finalidad del proyecto.
- Gestación del acta de constitución del proyecto.
Actividad 2: Definir requerimientos del proyecto
Durante esta acción se seleccionará cada miembro del equipo del
proyecto Scrum, este equipo será responsable de brindar los pasos
necesarios para asegurar la vigencia del proyecto y estará a cargo de
validar que los entregables contengan los mínimos condiciones del
proyecto.
58
Entregables:
- Requerimientos funcionales.
- Requerimientos no funcionales.
- Requerimientos comunes de las interfaces.
- Establecimiento del equipo Scrum.
Actividad 3: Definir el diagrama de proceso del negocio
La presente acción se lleva a cabo utilizando la técnica del modelo de
negocio, que se utiliza para identificar los procesos del negocio,
mediante el uso de diagramas, esta técnica permite adquirir una
comprensión amplia en las operaciones o procedimientos necesarios
para el restaurante.
Entregables:
- Diagrama actual del flujo de pedidos.
- Diagrama con la mejora en el flujo de pedidos (TO-BE)
3.1.2.2. Fase de Planeamiento y Estimación
La información recopilada en fases anteriores se examina en esta fase
para identificar las tareas a completar y los datos a organizar para
cumplir con los requisitos que tendrá la solución tecnológica en función
a la administración de los pedidos. Las actividades y tareas donde se
llevará a cabo la fase de planeamiento se enumeran en esta siguiente
tabla:
59
Tabla 6
Fase de Planeamiento y Estimación
Detalle de las especificaciones

1. Construcción de historia Elaboración de historia
necesarias para la implementación
de usuario de usuario.
del producto.
2. Construcción del Análisis del total de historias de Product Owner

Product backlog.
product backlog usuario elaboradas anteriormente. Scrum Master
3. Construcción de Análisis del total de historias de

Product backlog
product backlog usuario elaboradas en fases
priorizado
priorizado anteriores.
4. Construcción de sprint Análisis del product backlog para Puntuar tareas del Scrum Master
del proyecto establecer los sprints sprint. Product Owner
Por lo tanto, se especificarán las actividades y entregables que estan
contenidos dentro del cuadro.
Actividad 1: Construcción de historia de usuario
En la actual acción, examinan la información que necesitara la solución
propuesta en el diseño y, al mismo tiempo, se identifican las funciones
necesarias para tener una mejor comprensión de como quedara el
producto final.
60
Entregables:
- Elaboración de historia de usuario.
Actividad 2: Construcción del product backlog
Para contribuir en la mejor de la toma de decisiones, en esta acción se
examinarán la información necesaria obtenidas del análisis de historias
de usuario, esto permite un listado a detalle del product backlog.
Entregables:
- Product backlog.
Actividad 3: Construcción de product backlog priorizado
El propósito de la acción es desarrollar las funcionalidades y
consideración del total de historias de usuario. Para esto, el dueño del
producto es el que se encarga de realizar la reunión con el equipo del
proyecto scrum y darle prioridad al total de historias de usuario con el
apoyo de las conformidades con los todos que pertenecen al equipo
scrum, para esto, se hizo uso de la técnica de Moscow el cual permite
una adecuada priorización.
Entregables:
- Product backlog priorizado.
Actividad 4: Construcción de sprint del proyecto.
61
Con el fin de elaborar la lista de sprints en esta actividad, se examinará
el product backlog, esto se hará utilizando el análisis anterior, donde el
equipo de desarrollo es responsable de elegir que historias incluir en la
lista de sprints.
Entregables:
- Listado de sprints.
- Puntuar tareas del sprint.
3.1.2.3. Fase de Desarrollo y Diseño
Con esta etapa es en donde se toma forma el proyecto, implica un
análisis del product backlog para el esfuerzo del sprint y, como
resultado, la delegación y ejecución de tareas para diseñar las
maquetas, los diagramas y el modelo de datos necesarios.
Tabla 7
Fase de Desarrollo y Diseño
Especificación del sprint.

1. Sprint 1: Realizar todos los mockups Equipo de desarrollo
Diseñar y validar mockup.
Diseño de interfaz del y flujos con relación al Scrum Master
Implementar interfaz de login.
login login. Product Owner
Implementar API de login.
62
2. Sprint 2: Realizar todo los mockup y Equipo de desarrollo
Diseñar y validar mockup.
Diseño de interfaz del flujos con relación al Scrum Master
Implementar interfaz del
dashboard dashboard. Product Owner
dashboard.
3. Sprint 3: Diseñar y validar mockup.

Realizar todo los mockup y Equipo de desarrollo
Diseño de interfaz del Implementar interfaz del pop-up de
flujos con relación al pop-up Scrum Master
pop-up del registro registro.
de registro de pedido. Product Owner
del pedido Implementar API de registro de
pedido.
4. Sprint 4: Diseñar y validar mockup.

Realizar todo los mockup y Equipo de desarrollo
Diseño de interfaz del Implementar interfaz del pop-up de
flujos con relación al pop-up Scrum Master
pop-up del detalle del detalle.
del detalle del pedido. Product Owner
pedido Implementar API para obtener el
detalle del pedido.
Actividad 1: Sprint 1 Diseño de interfaz del login
En esta actividad, se desarrollarán los diferentes componentes
requeridos el diseño, de la misma manera, se usarán en los mockups
relacionados al login.
63
Entregables:
- Especificación del sprint.
- Diseño vista inicio de sesión.
- Implementar interfaz de inicio de sesión.
- Implementar API de inicio de sesión.
Actividad 2: Sprint 2 Diseño de interfaz del dashboard
Esta acción, desarrolla el total de diseños necesarios con relación al
dashboard, con mockups diseñados y validados en función al uso.
Entregables:
- Diseñar vista del dashboard más componente de logout.
- Implementar interfaz del dashboard.
- Implementar componente de logout.
Actividad 3: Sprint 3 Diseño de interfaz del pop-up del registro del
pedido
En esta actividad, se desarrollará el mockup del pop-up relacionado al
registro del pedido, con la finalidad de establecer diseños visuales.
Entregables:
- Diseñar vista del pop-up del registro del pedido.
- Implementar interfaz del pop-up de registro del pedido.
64
- Implementar API de registro de pedido.
- Implementar API de lista de meseros disponibles.
- Implementar API de lista de platos disponibles.
Actividad 4: Sprint 4 Diseño de interfaz del pop-up del detalle del
pedido
En esta actividad, se desarrollará el mockup para el pop-up del detalle
del pedido, para tener la mejor perspectiva del diseño.
Entregables:
- Diseñar interfaz del pop-up del detalle del pedido.
- Implementar interfaz del pop-up del detalle.
- Implementar API para obtener el detalle del pedido.
- Implementar API para actualizar el estado del pedido.
3.1.2.4. Fase de implementación
Es responsabilidad de esta fase implementar y ejecutar los entregables
que se utilizaran para la implementación futuro, esta fase también
involucra la creación de actividades que mejoraran los procesos del
negocio a través de la ejecución de entregables. De la misma manera, las
tareas y actividades se muestran por separado.
Tabla 8
65
Fase de implementación
Creación del diagrama de base de

Development team
1. Especificación del Diagramar las tablas del datos.
Scrum Master
modelo de datos motor de base de datos Creación del catálogo de base de
Product Owner
datos.
Implementación del módulo

Development team
2. Especificación del Codificar el módulo de frontend del login.
Scrum Master
módulo de login login Implementación del módulo
Product Owner
backend del login.
3. Especificación del Development team

Codificar el módulo del Implementación del módulo
módulo del Scrum Master
dashboard frontend del dashboard.
dashboard Product Owner

4. Especificación del
Codificar el módulo del frontend del pop-up del registro del Development team
módulo del pop-up
pop-up del registro del pedido. Scrum Master
del registro del
pedido Implementación del módulo Product Owner
pedido
backend del registro del pedido.

5. Especificación del
Codificar el módulo del frontend del pop-up del detalle del Development team
módulo del pop-up
pop-up del detalle del pedido. Scrum Master
del detalle del
pedido Implementación del módulo Product Owner
pedido
backend del detalle del pedido.
66
Las actividades que son visibles dentro de la esta fase se describirán a
continuación.
Actividad 1: Especificación del modelo de datos
Con el desarrollo anteriormente descrito el diagrama de base de datos y
continuando con la implementación de esta para su uso y soporte de la
aplicación web.
Entregables:
- Creación del diagrama de base de datos.
- Creación del catálogo de base de datos.
Actividad 2: Especificación del módulo de login
En esta actividad, se implementará el módulo de login, tanto para
frontend como para backend, se siguieron los patrones de arquitectura
orientado a componentes y por capas respectivamente.
Entregables:
- Implementación del módulo frontend del login.
- Implementación del módulo backend del login.
Actividad 3: Especificación del módulo del dashboard
67
En esta actividad, se desarrollará el módulo frontend del dashboard
haciendo uso del patron de arquitectura orientado a componentes.
Entregables:
- Implementación del módulo frontend del dashboard.
Actividad 4: Especificación del módulo del pop-up del registro del
pedido
En esta acción, se codificará el módulo a nivel frontend y backend del
pop-up del registro del pedido siguiendo los estándares de los patrones
de arquitectura orientado a componentes y por capas respectivamente.
Entregables:
- Implementación del módulo frontend del pop-up del registro del
pedido.
- Implementación del módulo backend del registro del pedido.
Actividad 5: Especificación del módulo del pop-up del detalle del
pedido
En esta acción, se desarrollará el módulo a nivel backend y frontend del
pop-up del detalle del pedido siguiendo las buenas prácticas de los
patrones de arquitectura por capas y orientado a componentes
respectivamente.
Entregables:
68
- Implementación del módulo frontend del pop-up del detalle del
pedido.
- Implementación del módulo backend del detalle del pedido.
3.1.2.5. Fase de Revisión y Retroalimentación
Es importante tener información precisa a disposición de los inspectores
durante la fase de Revisión y Retroalimentación para que puedan evaluar
la capacidad y determinar la mejor forma de realizar y correlacionar el
esfuerzo del diseño de la aplicación web con los patrones requeridos para
proporcionar el producto. El objetivo en esta fase es simplificar
efectivamente cada tarea en una línea similar.
Tabla 9
Fase de Revisión y Retroalimentación
Es verificada las
funcionalidades del
producto con el Product Stakeholders

1. Presentar y verificar el Reunión de verificación
Owner y los interesados Equipo de desarrollo
sprint de sprint.
del proyecto para así Product Owner
validar y aceptar el
producto.
Reunión del equipo para Reunión de retrospectiva Equipo de desarrollo

2. Retrospectiva del sprint
identificar y analizar las del sprint. Scrum Master
69
lecciones aprendidas y
puntos de mejora a aplicar
en futuros sprints.
En sucesión, se presentan acciones y entregables expuestas en la tabla
Revisión y Retroalimentación.
Actividad 1: Presentar y verificar el sprint
Es en la actual acción se verifican los entregables, lo que potencia la
confiabilidad de los bienes entregados a los usuarios finales.
Entregables:
- Reunión de verificación de sprint.
Actividad 2: Retrospectiva del sprint
La presente acción es en donde los integrantes del equipo de desarrollo
Scrum son reunidos para argumentar y realizar los sprints, al final de
cada sprint, se anota que partes salieron bien y cuales no para que se
puedan realizar mejoras para los próximos sprints.
Entregables:
- Reunión de retrospectiva del sprint.
70
3.3.2.6. Fase de Despliegue
En esta fase concluyente, se focaliza en el resultado de la solución
propuesta y la entrega de este.
Tabla 10
Fase de Despliegue
Son enviados el total de

Development Team
1. Compartir resultados finalizados y Documentación del
Product Owner
entregables validados por el Product término del proyecto.
Stakeholders
Owner
Actividad 1: Compartir entregables
En la presente acción, es el equipo de desarrollo quien brinda la solución
terminada al restaurante. Adicionalmente, se incluye la documentación
correspondiente con el código fuente en un repositorio.
Entregables:
- Documentación de término del proyecto.
3.4. CRONOGRAMA DE ACTIVIDADES
Tabla 11
71
Cronograma de actividades del proyecto
Nota. Fuente propia.
3.5. PRESUPUESTO
A continuación, se detallan los costes incurridos y soportados por el restaurante en
relación con el desarrollo del proyecto.
3.5.1. Costos
3.5.1.1. Costos de colaboradores / personal
Los requisitos de colaboradores y / o personal del proyecto se enumeran en
a continuación.
Tabla 12
Cuadro de costos de colaboradores
72
Cargo Cantidad Meses Costo (s/) x mes Costo total (s/)
Product Owner 1 6 S/ 10 000 S/ 60 000
Scrum Master 1 6 S/ 7000 S/ 42 000
Desarrollador 2 6 S/ 10 000 S/ 60 000
QA 1 5 S/ 4500 S/ 22 500
Total S/ 184 500
Nota. Fuente propia
3.5.1.2. Costos de hardware
Para llevar a cabo el proyecto se utilizaron los siguientes recursos de
hardware:
Tabla 13
Cuadro de costos de hardware
Descripción Cantidad Costo (s/) x mes Costo total (s/)
PC Intel Core i5 8th Gen 1 S/ 2500 S/ 2500
Laptop 1 S/ 3600 S/ 3600
Tablet 2 S/ 1600 S/ 3200
Total S/ 9300
Nota. Fuente propia.
73
3.5.1.3. Costos de software
Para llevar a cabo el proyecto se utilizaron los siguientes recursos de
software:
Tabla 14
Cuadro de costos de software
Descripcion Cantidad Costo (s/) x mes Costo total (s/)
Intellij Idea (licencia estudiantil) 2 S/ 0.00 S/ 0.00
Postgresql Dbeaver (open source) 2 S/ 0.00 S/ 0.00
Git (open source) 2 S/ 0.00 S/ 0.00
Heroku (hosting gratuito) 1 S/ 0.00 S/ 0.00
Postman (open source) 2 S/ 0.00 S/ 0.00
Figma (open source) 2 S/ 0.00 S/ 0.00
Draw.io (open source) 2 S/ 0.00 S/ 0.00
Aplicaciones de ofimatica Office

2 S/ 0.00 S/ 0.00
(licencia estudiantil)
Total S/ 0.00
Nota. Elaboracion propia.
3.5.1.4. Costos variables
La lista de costos variables incurridos durante la implementación de
este proyecto se expone la siguiente tabla, para cada individuo se
proyecta un periodo mensual.
Tabla 15
74
Cuadro de costos variables
Descripción Cantidad Costo (s/) x mes Costo total (s/)
Agua 6 S/ 60 S/ 360
Electricidad 6 S/ 80 S/ 480
Internet 6 S/ 180 S/ 1080
Total S/ 1920
3.5.1.5. Costos de puesta en marcha
En la tabla siguiente se muestran costos de puesta en marcha, en
detalle de las inversiones presentadas anteriormente.
Tabla 16
Cuadro de costos de puesta en marcha
Tipo de costo Costo total (s/)
Colaboradores S/ 184 500
Hardware S/ 9300
Software S/ 0.00
Variables S/ 1920
Total S/ 195 720
75
3.5.2. Beneficios
3.5.2.1. Beneficios tangibles
Son las bonificaciones que se pueden medir en términos de valor
monetario se incluyen en esta categoría. Estas bonificaciones son el
resultado de la integración del proyecto.
La cantidad promedio de tiempo que le toma a un mesero atender, anotar
y solicitar la preparación de los pedidos se ha reducido con la integración
de la aplicación web, asimismo, se mejoró la eficacia al realizar dichas
actividades.
El coste total con relación al tiempo invertido por el mesero con respecto
a la cantidad de clientes mensuales, esta divido de la siguiente manera:
Tabla 17
Cuadro del beneficio del tiempo invertido por un mesero
Costo vs Beneficio
Total sin aplicación web S/ 150
Total con aplicación web S/ 127.7
Beneficio S/ 22.3
El restaurante tiene en promedio 720 clientes mensuales, es por debido a
ello que el beneficio total mensual será de 720 * 22.3 = S/ 16056.
76
Otro beneficio es la disminución de tiempo que le toma a un cocinero
recibir, preparar y alistar los pedidos, asimismo, se mejoró la eficiencia
de dicho proceso.
El coste total, relacionado al tiempo invertido por el cocinero con
respecto a la cantidad de pedidos mensuales, se divide de la siguiente
manera:
Tabla 18
Cuadro del beneficio del tiempo invertido por un cocinero
Costo vs Beneficio
Total sin aplicación web S/ 120
Total con aplicación web S/ 107.46
Beneficio S/ 12.54
El restaurante tiene en promedio 1200 pedidos mensuales, es debido a
ello que el beneficio total mensual es de 1200 * 12.54 = S/ 15048.
En sucesión, se expone la tabla de los beneficios totales por mes posterior
a implementar la aplicación web.
Tabla 19
Cuadro de beneficios totales por mes
77
Beneficio Total (s/)
Meseros 16056
Cocineros 15048
Total S/ 31104
3.5.2.2. Beneficios intangibles
Mejora en la atención al cliente, disminución de los errores al apuntar
los pedidos. Eliminación de pedidos duplicados, reducción de tiempo
en la entrega de los pedidos, correcta entrega de los pedidos.
Estas mejoras permitirán ofrecer un servicio acorde al mercado y de
alto nivel para cada cliente del restaurante, asimismo, aumentar la
eficiencia de los procesos internos.
3.5.3. Rentabilidad del proyecto
3.5.3.1. Flujo de caja
Luego del pago de la tarifa de la implementación, que puede llegar a
S/ 195720, por la construcción del software, se otorga el periodo de
gracia. Los resultados se obtienen como beneficios tangibles para la
organización, los cuales ascienden a S/ 10020, a partir del periodo
uno, cuando ya se ha implementado el software.
Figura 25
78
Flujo de caja
Como es posible visualizar en la tabla anterior se expone a detalle del flujo
de caja planificado en 12 meses o un año. Se observa que en el setimo mes
se estaria retornando el costo de S/ 195720.
3.5.3.2. Analisis del VAN
Al dar comienzo un proyecto de inversion, se puede determinar cuanto
ganara o perdera utilizando el criterio de inversion del Valor Actual
Neto (VAN). El VAN declara la rentabilidad de un proyecto en
custion de unidades monetarias utilizando la posterior formula:
Figura 26
Calculo del VAN
En donde:
Io: inversion inicial (periodo t = 0), para este proyecto es de S/ 195720
n: cantidad de periodos, en este proyecto es de 12 meses
79
Ft: flujo monetario en el periodo t
k: tasa de interes exigido en la inversion, para este proyecto es de 8%
A traves del VAN se puede decidir si es beneficioso o no invertir en
este proyecto. Mediante estas casuisticas:
VAN > 0: El proyecto es factible, genera ganancias y se recomienda
invertir.
VAN = 0: El proyecto no genera ganancias ni perdidas.
VAN < 0: El proyecto no es factible, genera perdidas y no se
recomienda invertir.
Haciendo uso de estas casuisticas en este proyecto, se realizo el
calculo del VAN utilizando el flujo de caja mostrado en la parte
superior, en el cual se obtuvo el resultado a continuacion.
Tabla 20
Cuadro del Valor Actual Neto a 12 meses
Valor Actual Neto a 12 meses
VAN
S/ 24212.90
Nota. Elaboracion propia
Como se muestra en el cuadro anterior, el resultado del calculo del
VAN es mayor a cero, por lo que es recomendable la ejecucion del
proyecto.
80
3.5.3.3. Analisis del TIR
Es de los indicadores financieros más utilizados para poder cuantificar
la rentabilidad relativa es la Tasa Interna de Retorno (TIR). La TIR
también es definida como la tasa de descuento que es igual al VAN a
cero. Y es calculada utilizando la formula a continuación:
Figura 27
Cálculo de la TIR
En donde:
n: cantidad de periodos, en este proyecto es de 12 meses
Fn: flujo monetario en el periodo n
i: inversión inicial, para este proyecto es de S/ 195720
Las casuísticas de distinción que provee la TIR, se basan en la similitud
de una tasa de descuento k con la TIR, de la manera siguiente:
TIR > k: el proyecto de inversión se debe ejecutar
TIR < k: el proyecto de inversión no se debe ejecutar
81
En el actual proyecto de inversión se calculó la TIR, usando una tasa de
interés no tan exigente sugerido por la Superintendencia de Banca y
Seguros (SBS), la tasa de interes es de 8%.
Tabla 21
Cuadro de la Tasa Interna de Retorno a 12 meses
Tasa Interés de Retorno a 12 meses
TIR 10%
De acuerdo con el cuadro anterior, el resultado del cálculo de la formula
del TIR está por encima que la tasa de interés, debido a ello, se
recomienda ejecutar este proyecto.
CAPÍTULO IV: DESARROLLO DE LA SOLUCIÓN
4.1. PROPUESTA DE SOLUCIÓN
Este capítulo en el actual informa desarrollara las acciones basadas y propuestas por
Scrum para implementar una solución tecnológica para incrementar la eficiencia de la
gestión de pedidos de un restaurante.
4.1.1 Fase de Inicio
Actividad 01: Realización de la visión del proyecto
Siendo la finalidad de esta acción, brindar una línea de medición
para la realización de la presente propuesta. Implica definir el
82
alcance y los objetivos que se mejoraran en el futuro utilizando la
información que se ha adquirido sobre la empresa.
Entregable: Presentación de la finalidad del proyecto
Esta entregable está relacionado con la declaración de la visión del
proyecto, que establece los objetivos generales de la empresa.
Además, se visualizarán las áreas involucradas y el valor que la
empresa espera alcanzar.
Tabla 22
Cuadro de la visión del proyecto
Implementar una aplicación web haciendo uso del framework de trabajo ágil Scrum
Visión del proyecto
con el fin de mejorar la gestión de los pedidos en el restaurante.
Este proyecto permitirá a los meseros y cocineros registrar, solicitar, preparar y

Alcance
recibir los pedidos de los clientes.
- Inobservancia del tiempo de entrega.
Riesgos - Falla del servidor.
- La aplicación sea de difícil mantenimiento.
Responsables - Gerente del restaurante.
- Gestión de pedidos ineficiente.
- Errores al apuntar los pedidos.
Carencias - Pedidos duplicados.
- Demora en la entrega de los pedidos.
- Errores en la entrega de los pedidos.
83
- Mala atención a los clientes.
Aplicación web encargada de mejorar la gestión de los pedidos que permita registrar,
Producto
solicitar, preparar y recibir los pedidos de forma que se incremente la eficiencia.
- Mejorar la gestión de los pedidos.
- Disminución de los errores al apuntar los pedidos.
- Eliminación de los pedidos duplicados.

Valia
- Reducción de tiempo en la entrega de los pedidos.
- Correcta entrega de los pedidos.
- Buena atención a los clientes.
Descripción general del Al término del proyecto se conseguirá una aplicación web con la capacidad de brindar
producto una eficiente gestión de los pedidos de una forma rápida y en tiempo real.
Entregable: Gestación del acta de constitución del proyecto
En el actual resultante estará incluida documentación de la
constitución de la presente propuesta, que incluirá información
sobre el propósito del proyecto, justificación, metas a alcanzar,
riesgos y otros detalles cruciales. El documento se logra observar
en la siguiente figura:
Figura 28
84
Acta de constitución del proyecto
Actividad 02: Definir requerimientos del proyecto
La presente diligencia identificara todos los requisitos de la solución
tecnológica fundamentales para la mejor performance y el
cumplimiento de necesidades expuestas por los meseros y cocineros.
Entregable: Requerimientos funcionales
Tabla 23
Cuadro de requerimientos funcionales
Requerimientos funcionales
85
Sera posible acceder a la aplicación a través de un inicio de sesión, que requerirá un
RF001
usuario y contraseña.
RF002 La aplicación mostrara la organización real del restaurante (las mesas).
RF003 La aplicación permitirá registrar un pedido en caso la mesa no tenga una ya asignado.
RF004 La aplicación permitirá ver el detalle del pedido en caso la mesa tenga una asignado.
RF005 Al acceder a la aplicación con credenciales incorrectas, mostrarle error al usuario.
RF006 La aplicación mostrara el listado de meseros disponibles en el registro de pedido.
RF007 La aplicación mostrara el listado de platos disponibles en el registro de pedido.
RF008 La aplicación permitirá cerrar sesión.
Entregable: Requerimientos no funcionales
Tabla 24
Cuadro de requerimientos no funcionales
Requerimientos no funcionales
RNF001 Para utilizar la aplicación web es necesario tener acceso a internet de forma obligatoria.
Para que los meseros y cocineros utilicen la aplicación es necesario contar con una PC y 2
RNF002
tablets.
RNF003 La aplicación debe ser sencilla de utilizar.
RNF004 La aplicación debe poseer una interfaz amigable.
RNF005 Almacenamiento seguro de la información.
86
Entregable: Requerimientos comunes de las interfaces
Tabla 25
Cuadro de requerimientos comunes de las interfaces
Requerimientos comunes de las interfaces
La aplicación permitirá registrar un pedido en caso la mesa no tenga, caso

RCI001
contrario, permitirá ver el detalle de este.
Entregable: Establecimiento del equipo Scrum
Este entregable identifica cada miembro involucrado en el equipo
Scrum que estan a cargo de hacer realidad el proyecto, el equipo es
responsable de ver que cada fase del proyecto se complete.
Tabla 26
Cuadro del equipo Scrum
Roles Responsable
Product Owner MM, F
Stakeholders Meseros y cocineros
Scrum Master MT, W
Equipo de desarrollo Maza Cerna, Dennis Alexis
Actividad 03: Definir el diagrama de proceso de negocio
87
Para hallar una comprensión integral de los procedimientos involucrados
en el flujo de gestión de pedidos en el restaurante, se utilizará un diseño
gráfico.
Entregable: Diagrama actual del flujo de pedidos
El primer paso es modelar el flujo actual para anotar, solicitar,
preparar y recibir los pedidos, desde la concepción del evento hasta la
recepción del pedido por parte de los meseros. Lo cual brindara una
demostración del estado de estos procesos, como se logra observar en
la siguiente figura:
Figura 29
Diagrama del flujo actual de pedidos
88
Entregable: Diagrama con la mejora en el flujo de pedidos (TO-BE)
Una vez establecidos los procedimientos vigentes en el restaurante para
la gestión de pedidos, se realiza el diseño para mejorar la fluidez de
dichos procedimientos haciendo uso de la solución implementada. Como
muestra la gráfica a continuación:
Figura 30
Diagrama del flujo con la mejora en la gestión de pedidos
Nota. Elaboración propia
89
4.1.2 Fase de Planeamiento y Estimación
Actividad 01: Construcción de historia de usuario
Entregable: Elaboración de historia de usuario
Los requerimientos del cliente se representan en esta tarea a través de
historias de usuario, las cuales tienen un formato compacto para facilitar su
comprensión. Además de la función que debe realizar el sistema se
identifican adicionalmente mediante un código de referencia.
Tabla 27
Cuadro de historia de usuario – Iniciar sesión usuario Administrador
Historia de usuario: HU01 Titulo: Iniciar sesión Administrador
Programador: Dennis Maza Cerna Usuario: ADMINISTRADOR
Descripción: COMO Administrador
QUIERO Contar con un usuario y contraseña única de
administrador que me identifique
PARA Ingresar haciendo login en la aplicación web
 Debe mostrar el logo del restaurante
 Debe mostrar botón de ingresar
Criterios de aceptación:  Debe mostrar los colores representativos de la empresa
 Debe mostrar campo de usuario
 Debe mostrar campo de contraseña
90
Tabla 28
Cuadro de historia de usuario – Iniciar sesión usuario Mesero
Historia de usuario: HU02 Titulo: Iniciar sesión Mesero
Programador: Dennis Maza Cerna Usuario: MESERO
Descripción: COMO Mesero del restaurante
QUIERO Contar con un usuario y contraseña única de mesero
que me identifique
PARA Iniciar sesión en la aplicación web
Tabla 29
Cuadro historia de usuario – Iniciar sesión usuario Cocinero
Historia de usuario: HU03 Titulo: Iniciar sesión Cocinero
Programador: Dennis Maza Cerna Usuario: COCINERO
Descripción: COMO Cocinero del restaurante
91
QUIERO Contar con un usuario y contraseña única de cocinero
que me identifique
PARA Iniciar sesión en la aplicación web
Tabla 30
Cuadro historia de usuario – Inicio de sesión incorrecta
Historia de usuario: HU04 Titulo: Iniciar sesión incorrecta
Programador: Dennis Maza Cerna Usuario: ADMINISTRADOR / MESERO / COCINERO
Descripción: COMO Administrador / Mesero / Cocinero
QUIERO Ver un error al hacer login con credenciales
incorrectas
PARA Acceder con las credenciales correctas
Criterios de aceptación:  Debe mostrar botón de ingresar
 Debe mostrar los colores representativos de la empresa
92
 Debe mostrar mensaje de error por credenciales incorrectas
Tabla 31
Cuadro historia de usuario – Lista de mesas
Historia de usuario: HU05 Titulo: Lista de mesas
QUIERO Visualizar el orden real de las mesas en la aplicación
PARA Ubicar las mesas con mayor facilidad.

Criterios de aceptación:
 Debe mostrar el orden real de las mesas
Tabla 32
Cuadro historia de usuario – Registro del pedido usuario Administrador /
Mesero
93
Historia de usuario: HU06 Titulo: Registro del pedido
Administrador / Mesero
Programador: Dennis Maza Cerna Usuario: ADMINISTRADOR / MESERO
Descripción: COMO Administrador / Mesero
QUIERO Poder registrar un pedido a una mesa
PARA Que los cocineros inicien con la preparación
 Debe mostrarse cuando se de click a una mesa
Criterios de aceptación:  Debe mostrar la lista de meseros disponibles
 Debe mostrar la lista de platos disponibles
 Debe tener un botón registrar
Tabla 33
Cuadro historia de usuario – Registro del pedido usuario Cocinero
Historia de usuario: HU07 Titulo: Registro del pedido Cocinero
Programador: Dennis Maza Cerna Usuario: COCINERO
Descripción: COMO Cocinero
QUIERO Poder ver como se registra un pedido
PARA Saber los datos que necesita el registro
94
 Debe mostrar la lista de meseros disponibles
 Debe mostrar la lista de platos disponibles
 Debe tener un botón de registrar
 No debe poder registrar un pedido
Tabla 34
Cuadro historia de usuario – Detalle del pedido usuario Administrador /
Cocinero
Historia de usuario: HU08 Titulo: Detalle del pedido
Administrador / Cocinero
Programador: Dennis Maza Cerna Usuario: ADMINISTRADOR / COCINERO
Descripción: COMO Administrador / Cocinero
QUIERO Poder ver el detalle del pedido
PARA Preparar los platos solicitados
Criterios de aceptación:  Debe mostrar un estado inicial del pedido
 Debe poder actualizar el estado del pedido
 Debe mostrar un estado inicial de los platos
95
 Debe poder actualizar el estado de los platos
Tabla 35
Cuadro historia de usuario – Detalle del pedido usuario Mesero
Historia de usuario: HU09 Titulo: Detalle del pedido Mesero
Programador: Dennis Maza Cerna Usuario: MESERO
Descripción: COMO Mesero
QUIERO Poder ver el detalle del pedido
PARA Visualizar los pedidos solicitados por mesa
 Debe mostrar el estado del pedido

Criterios de aceptación:
 No debe poder actualizar el estado del pedido
 Debe mostrar el estado de los platos
 No debe poder actualizar el estado de los platos
Tabla 36
Cuadro historia de usuario – Cerrar sesión
96
Historia de usuario: HU10 Titulo: Cerrar sesión
QUIERO Finalizar la sesión en esta aplicación web
PARA Hacer logout de la aplicación.
Criterios de aceptación:  Debe mostrar botón de logout
Actividad 02: Construcción del producto backlog
Entregable: Product backlog
El producto backlog se crea cuando se ha reunido los detalles esenciales
mediante de historias de usuario. Este artefacto le permite ver la
funcionalidad necesaria de la aplicación web con mayor claridad.
Además, esto cambia a medida que avanza el producto.
Tabla 37
Cuadro product backlog
ID Historia Nombre de historia Estado
HU01 Iniciar sesión usuario Administrador Completado
HU02 Iniciar sesión usuario Mesero Completado
97
HU03 Iniciar sesión usuario Cocinero Completado
HU04 Inicio de sesión incorrecto Completado
HU05 Lista de mesas Completado
HU06 Registro del pedido usuario Administrador / Mesero Completado
HU07 Registro del pedido usuario Cocinero Completado
HU08 Detalle del pedido usuario Administrador / Cocinero Completado
HU09 Detalle del pedido usuario Mesero Completado
HU10 Cerrar sesión Completado
Actividad 03: Construcción del product backlog priorizado
Entregable: Product backlog priorizado
Debido al límite de tiempo del proyecto, para llevar a cabo la
priorización del backlog de producto se utilizó una técnica basada en
la priorización de requisitos esenciales. Como tales, estos se logran a
través de una sucesión decreciente: Moscow es una técnica que
emplea frecuentemente palabras que permiten establecer una
prioridad, las palabras que se suelen emplear son:
 Necesarios (M – Must have)
 Fundamental (S – Should have)
 Llamativos (C – Could have)
 Alternativos (W – Won’t have now but Would be later)
98
Tabla 38
Cuadro del product backlog priorizado
ID Historia Nombre de historia Prioridad
HU01 Iniciar sesión usuario Administrador M
HU02 Iniciar sesión usuario Mesero M
HU03 Iniciar sesión usuario Cocinero M
HU04 Inicio de sesión incorrecto M
HU05 Lista de mesas M
HU06 Registro del pedido usuario Administrador / Mesero M
HU07 Registro del pedido usuario Cocinero S
HU08 Detalle del pedido usuario Administrador / Cocinero M
HU09 Detalle del pedido usuario Mesero S
HU10 Cerrar sesión M
Actividad 04: Construcción de sprint del proyecto
Entregable: Listado de sprints
Tras el análisis de la acumulación de productos desarrollados, se
crea una lista de sprints, con cada sprint referenciado por su
99
propia descripción. Esta lista permitirá saber exactamente
cuántos sprints se realizarán.
Tabla 39
Cuadro listado de sprints
SPRINTS
SPRINT NOMBRE DESCRIPCION
Se desarrolla el frontend y
1 Diseño de interfaz de login
backend del login
Se desarrolla el frontend del

2 Diseño de interfaz de dashboard
dashboard
3 Diseño de interfaz de pop-up de registro de pedido backend del registro del
pedido
4 Diseño de interfaz de pop-up de detalle de pedido backend del detalle del
pedido
Entregable: Puntuar tareas del sprint
El total de historias de usuario se estiman con el listado de
sprints utilizando el método Scrum Poker Online, como se
muestra en la figura 31. El equipo de desarrollo se compromete
100
a terminar las tareas de cada sprint gracias a las puntuaciones
que elijan en la plataforma, como se puede ver en la figura 32.
La votación se mantiene en secreto hasta que todo el equipo
haya emitido su voto para prevenir la influencia al grupo, para
tener la estimación más alta.
Figura 31
Scrum Poker Online
Nota. Scrum Poker Online (https://www.scrumpoker.online)
Figura 32
Esquema de puntajes
101
Nota. Scrum Poker Online (https://www.scrumpoker.online)
4.1.3 Fase de Desarrollo y Diseño
Sprint 1: Diseño de interfaz del login
Entregable: Especificación del sprint
Tras el análisis de la acumulación de productos desarrollados, se crea una
lista de sprints, con cada sprint referenciado por su propia descripción.
Esta lista permitirá saber exactamente cuántos sprints se realizará.
Tabla 40
Cuadro de especificación del sprint 1
Sprint 1: Diseño de interfaz del login
Objetivo Desarrollar la interfaz frontend y desarrollar backend del login
Descripción Diseñar componentes necesarios del frontend y backend del login
Criterios de Aceptación  Diagramar el inicio de sesión de usuario Administrador, Mesero y Cocinero
102
 Diagramar el inicio de sesión con credenciales incorrectas
Inmediatamente después de haber prototipado claramente las ideas para el
sprint se completa el backlog del sprint, que enumera las actividades que
se completaron anteriormente.
Tabla 41
Cuadro del sprint backlog 1
SPRINT BACKLOG
SPRINT HISTORIA TAREAS ESTIMACION
HU01 Iniciar sesión usuario Administrador 8
HU02 Iniciar sesión usuario Mesero 5

1
HU03 Iniciar sesión usuario Cocinero 5
HU04 Inicio de sesión incorrecta 3
Entregable: Diseño vista inicio de sesión
Figura 33
103
Diseño vista Inicio de sesión
Entregable: Implementar interfaz de inicio de sesión
Figura 34
Implementación de interfaz de inicio de sesión
104
Entregable: Implementar API de inicio de sesión
Figura 35
Implementación API de login
105
Sprint 2: Diseño de interfaz de dashboard
La determinación del sprint debe incluir el objetivo, la descripción y
criterios de aceptación para proporcionar una mejor comprensión de cómo
se desarrollará el sprint.
Tabla 42
Sprint 2: Diseño de interfaz del dashboard
Objetivo Desarrollar y diseñar la interfaz frontend del dashboard
Descripción Diseñar componentes frontend necesarios para mostrar el orden real de las mesas
Criterios de Aceptación  Mostrar la distribución real de las mesas
 Cada Mesa debe ser clickeable
 Debe compartir vista con el logout
El backlog del sprint, que contiene las historias propuestas anteriormente,
se presentara en detalle una vez se haya definido con precisión el sprint.
Tabla 43
106
SPRINT BACKLOG
HU05 Lista de mesas 8

2
HU10 Iniciar sesión usuario Mesero 3
Entregable: Diseñar vista del dashboard más componente de logout
Figura 36
Diseño vista del dashboard más componente de logout
107
Entregable: Implementar interfaz del dashboard
Figura 37
Implementación de interfaz del dashboard
108
Entregable: Implementar componente de logout
Figura 38
Implementación componente de logout
Sprint 3: Diseño de interfaz del pop-up del registro del pedido
Es necesario tener en cuenta que la información proporcionada permite
tener claridad en cuanto a la definición y otros componentes para entender
cómo se desarrolla el sprint, definición y cada criterio de aceptación.
Tabla 44
Sprint 3: Diseño de interfaz del pop-up del registro del pedido
Objetivo Diseñar interfaz frontend y desarrollo backend del pop-up del registro del pedido
Descripción Diseñar componentes frontend y backend necesarios para el registro del pedido
109
Criterios de Aceptación  Diseño de la vista del pop-up del registro del pedido
 Implementación de la interfaz del registro del pedido
 Implementación de API para realizar el registro del pedido
 Implementación de API de la lista de meseros disponibles
 Implementación de API de la lista de platos disponibles
Una vez que se ha establecido el sprint, se lleva a cabo una acumulación de
sprint detallada que se compone de actividades de sprint junto con historias
de usuario para proporcionar una mejor comprensión.
Tabla 45
SPRINT BACKLOG
Registro del pedido usuario Administrador

HU06 8
3 / Mesero
HU07 Registro del pedido usuario Cocinero 3
110
Entregable: Diseñar vista del popu-up de registro del pedido
Figura 39
Diseño vista del pop-up de registro del pedido
Entregable: Implementar interfaz del pop-up de registro del pedido
Figura 40
Implementación de interfaz del pop-up del registro del pedido
111
Entregable: Implementar API de registro de pedido
Figura 41
Implementación API de registro de pedido
112
Entregable: Implementar API de lista de meseros disponibles
Figura 42
Implementación API de lista de meseros disponibles
Entregable: Implementar API de lista de platos disponibles
Figura 43
Implementación de API de lista de platos disponibles
113
Sprint 4: Diseño de interfaz del pop-up del detalle del pedido
Tabla 46
Sprint 4: Diseño de interfaz del pop-up del detalle del pedido
Objetivo Diseñar de la interfaz frontend y componentes backend del detalle del pedido
Descripción Diseñar componentes frontend y backend necesarios para mostrar el detalle del
pedido y poder actualizar su estado
Criterios de Aceptación  Diseño de la vista del pop-up del detalle del pedido
 Implementación de la interfaz del detalle del pedido
 Implementación de API para obtener el detalle del pedido
 Implementación de API para actualiza el estado del pedido
Tabla 47
114
SPRINT BACKLOG
Detalle del pedido usuario Administrador /

HU08 8
4 Cocinero
HU09 Detalle del pedido usuario Mesero 3
Entregable: Diseñar interfaz del pop-up del detalle del pedido
Figura 44
Diseño vista del pop-up del detalle del pedido
115
Entregable: Implementar interfaz del pop-up del detalle del pedido
Figura 45
Implementación de interfaz del pop-up del detalle del pedido
116
Entregable: Implementar API para obtener el detalle del pedido
Figura 46
Implementación API de detalle del pedido
Entregable: Implementar API para actualizar el estado del pedido
Figura 47
Implementación API de actualización del estado del pedido
4.1.4 Fase de Implementación
Actividad 01: Especificación del modelo de datos
117
Entregable: Creación del diagrama de base de datos
Con el fin de llevar a cabo las muchas entidades, métodos y atributos de
esta actividad, se recopila información sobre el restaurante. Teniendo
como fin el crear una base de datos permitiendo tener un origen de datos
como provisión de registros de la solución tecnológica.
Figura 48
Diagrama de base de datos
Entregable: Creación del catálogo de base de datos
Es establecido para que varias organizaciones pudieran establecer
conexiones entre sí y realizar consultas entre sí. Además, los atributos se
118
describirán mediante cubos, que utilizarán las entidades en una nueva
propuesta para la estructura del proyecto y permitirán el almacenamiento
de componentes necesarios para acceder a los datos almacenados.
Luego de eso, se tiene la tabla “login”, que permitirá el registro de
nuevos usuarios de forma manual, y así, estos logren acceder a la
solución tecnológica, proporcionando sus credenciales.
Tabla 48
Tabla login
Numero Atributo Descripción
1 id Primary key de la tabla
2 username Usuario para ingresar a la aplicación
3 password Contraseña para ingresar a la aplicación
4 role Rol del usuario
5 created_date Fecha de creación
La tabla “waiter”, se implementó para almacenar información de los
meseros disponibles para poder utilizarlos en la vista de registro de
pedido.
Tabla 49
119
Table waiter
2 name Nombre del mesero
La tabla “dish”, es agregada con la función de registrar el total de los
platos que se estan ofreciendo en el restaurante para facilitar la
asignación de estos mismos en la vista del registro del pedido.
Tabla 50
Tabla dish
2 name Nombre del plato
La tabla “restaurant_order”, se agregó con el objetivo de registrar todos
los pedidos por mesa, en esta tabla se colocan datos generales de los
pedidos los cuales son utilizado para las vistas de detalle del pedido.
Tabla 51
Tabla restaurant_order
120
2 status Estado del pedido
3 table_number Numero de mesa
Debido a ello, la tabla “order_detail”, es agregada con el fin de almacenar
el detalle de los pedidos, es esta tabla se registran datos específicos del
detalle de los pedidos, para utilizarlos en la vista de detalle.
Tabla 52
Tabla order_detail
2 restaurant_order_id Foreign key, id de la tabla restaurant_order
3 waiter_code Código del mesero
4 status Estado del detalle
5 products Productos relacionados al pedido
6 products_quantity Cantidad de los productos
121
Actividad 02: Especificación del módulo de login
Entregable: Implementación del módulo frontend del login
En este entregable, se recolectaron todos los requerimientos de cada
colaborador que interactúa directamente con la aplicación web,
especificando a detalle sus solicitudes.
Figura 49
Modulo frontend del login

122
Entregable: Implementación del módulo backend del login
Para este entregable, se levantó toda la lógica de negocio con respecto al
inicio de sesión, adicional a ello, se detallaron los requerimientos
esenciales para tenerlos en cuenta.
Figura 50
Modulo backend del login
123
Actividad 03: Especificación del módulo del dashboard
Entregable: Implementación del módulo frontend del dashboard
Se colecto los requisitos necesarios para la implementación del
dashboard teniendo en cuenta las solicitudes por parte de negocio y de los
colaboradores que interactúan directamente con la aplicación, y así lograr
que la interfaz de fácil uso y de rápido adaptación.
Figura 51
Modulo frontend del dashboard

124
Actividad 04: Especificación del módulo del pop-up del registro del
pedido
Entregable: Implementación del módulo frontend del pop-up del
registro del pedido
Se continuo a recolectar todos los requerimientos a detalle para el
registro del pedido, que datos son los necesarios para esto y la manera
más eficiente de mostrarlos.
Figura 52
Modulo frontend del pop-up del registro del pedido
125
126
Entregable: Implementación del módulo backend del registro del
pedido
En este entregable, se recolecto la lógica de negocio adherida al registro
del pedido y los requisitos fundamentales para esta funcionalidad, para
que así, el proceso sea el necesario y requerido.
Figura 53
Modulo backend del registro del pedido
127
Actividad 05: Especificación del módulo del pop-up del detalle del
pedido
Entregable: Implementación del módulo frontend del pop-up del
detalle del pedido
Se procedió a levantar los requerimientos esenciales del módulo de
detalle del pedido, los campos y datos necesarios para que la interfaz sea
intuitiva y de eficiente uso.
Figura 54
Modulo frontend del pop-up del detalle del pedido
128
Entregable: Implementación del módulo backend del detalle del
pedido
Para este entregable, se levantó la información necesaria en cuanto a
lógica de negocio para que el módulo backend soporte diversas
casuísticas y se tenga cierta flexibilidad al obtener el detalle del pedido.
Figura 55
Modulo backend del detalle pedido
Nota. elaboración propia.

129
4.1.5 Fase de Revisión y Retroalimentación
Actividad 01: Presentar y verificar el sprint
Entregable: Reunión de verificación de sprint
En las reuniones de verificación de sprint, cada miembro clave del
equipo Scrum y los stakeholders participan para admitir entregables
que contengan los requerimientos descritos en las historias de los
usuarios. Estas juntas por la coyuntura eran realizadas mediante video
llamada y se conocían como reuniones de grupo.
Figura 56
Reunión de verificación de sprint
130
Tabla 53
Aceptación de los entregables
Historia de usuario Entregable Validado
 Debe tener el logo del restaurante

HU01: Iniciar sesión usuario
 Debe mostrar los colores representativos de la empresa 
Administrador
HU02: Iniciar sesión usuario Mesero  Debe mostrar los colores representativos de la empresa 

HU03: Iniciar sesión usuario
 Debe mostrar los colores representativos de la empresa 
Cocinero
131
HU04: Inicio de sesión incorrecto  Debe mostrar campo de usuario 
 Debe mostrar mensaje de error por credenciales
incorrectas

HU05: Lista de mesas 
 Debe mostrar el orden real de las mesas
HU06: Registro del pedido usuario  Debe mostrar los colores representativos de la empresa

Administrador / Mesero  Debe mostrarse cuando se de click a una mesa
HU07: Registro del pedido usuario  Debe mostrar la lista de meseros disponibles

Cocinero  Debe mostrar la lista de platos disponibles
 Debe tener un botón de registrar
 No debe poder registrar un pedido
132
HU08: Detalle del pedido usuario  Debe mostrar un estado inicial del pedido

Administrador / Cocinero  Debe poder actualizar el estado del pedido
 Debe mostrar un estado inicial de los platos
 Debe poder actualizar el estado de los platos
HU09: Detalle del pedido usuario  Debe mostrar el estado del pedido

Mesero  No debe poder actualizar el estado del pedido
 Debe mostrar el estado de los platos
 No debe poder actualizar el estado de los platos
HU10: Cerrar sesión  Debe mostrar botón de logout 
Actividad 02: Retrospectiva del sprint
Entregable: Reunión de retrospectiva del sprint
Este resultado, las iteraciones son evaluadas durante la junta de
retrospectiva teniendo el fin de juntar al equipo con el Scrum Master.
En dicha reunión se tiene una discusión abierta sobre lo que salió
bien y los puntos de mejora a lo largo de cada sprint. Con esta
133
experiencia, puede pronosticar que actividades se aplicaran en los
próximos sprints para atacar esas oportunidades de mejora.
Figura 57
Reunión de retrospectiva
Nota. Google Meet (https://meet.google.com).
Tabla 54
Cuadro resultante de la reunión de retrospectiva
Reunión de Retrospectiva
¿Qué hicimos bien? ¿Qué no salió bien? Oportunidades de mejora
134
 Reunión con el Product Owner  Habilitación de CORS para la  Implementar API’s para
cada 15 días comunicación entre frontend y listar meseros y platos
 Guardado de credenciales en local backend disponibles
storage  Implementación de API para obtener
 Diseño de la distribución real de el detalle del pedido
las mesas
4.1.6 Fase de Despliegue
Actividad 01: Compartir entregables
Entregable: Documentación de término del proyecto
Los colaboradores involucrados en el equipo de desarrollo brindan la
solución tecnológica terminado al restaurante en esta actividad. De
igual manera, el código fuente, tanto del backend como del frontend se
incluye en un repositorio privado mediante Github, y su respectiva
documentación pertinente se aloja en un apartado de Google Drive.
Figura 58
Repositorio del código fuente
135
Figura 59
Documentación de termino
Nota. Google Drive (https://drive.google.com).
136
4.2. PROTOTIPO DE LA APLICACIÓN
La solución tecnológica propuesta para este proyecto integró los frameworks de
desarrollo Angular en el frontend y Spring Boot en el backend, Adicionalmente, se
utilizó PostgreSQL para gestionar la base de datos. Como IDE (Integrated
Development Environmet) se utilizó Intellij Idea, como se logra visualizar en la figura
a continuación:
Figura 60
Proyectos Frontend y Backend en Intellij Idea
137
4.2.1. Módulo de inicio de sesión de usuarios
Este proyecto actualmente se encuentra desplegado en el ambiente de producción
y se divide en 4 módulos fundamentales, estos módulos son: Inicio de sesión,
dashboard, registro del pedido y detalle del pedido. Estos módulos serán utilizados
por meseros, cocineros y un usuario administrador.
Figura 61
Vista del login de la aplicación web
4.2.2. Módulo de dashboard
El presente módulo expone la distribución real como se encuentran las mesas
del restaurante para facilitar a los meseros y cocineros en la búsqueda de los
pedidos ya que para ellos es más intuitivo realizarlo de esa manera.
Figura 62
138
Vista del dashboard
4.2.3. Módulo de registro de pedidos
Modulo controlado por los usuarios meseros para el registro de los pedidos por
mesa, ingresando datos esenciales para ello.
Figura 63
Vista del registro de pedido

139
4.2.4. Modulo del detalle del pedido
Por último, se tiene el módulo de detalle del pedido, en donde los usuarios
meseros pueden visualizar el estado de los pedidos, pero más crítico para los
usuarios cocineros ya que es en este apartado de la aplicación web donde
pueden observar los platos a preparar por mesa.
Figura 64
Vista del detalle del pedido
4.3. RESULTADOS
Al término de implementar la aplicación web se alcanzaron los resultados a continuación,
los cuales estan orientados a los objetivos particulares.
OE1: Determinar como la implementación de una aplicación web mejora la
simplificación de la gestión de pedidos en un restaurante.
140
Resultado:
 Se optimizo el procedimiento de la gestión de pedidos simplificando
la cantidad de actividades necesarias desde que el cliente llega al
restaurante.
 Se redujo el tiempo invertido por los meseros y cocineros en el flujo
de gestión de los pedidos, iniciando desde la solicitud por parte del
cliente, traslado de la solicitud al cocinero, preparación y entrega.
Tabla 55
Detalle de mejora en tiempo de la simplificación de la gestión de
pedidos.
Antes - tiempo por pedido Después – Tiempo por

Antes vs después – Aplicación web Mejora (%)
(minutos) solicitud (minutos)
Solicitud del pedido 10 5 200%
Solicitud al cocinero 15 2 750%
Preparación del pedido 25 20 125%
Entrega del pedido 15 5 300%
Figura 65
Gráfico mejora en tiempo – simplificación de la gestión de pedidos
141
OE2: Determinar como la implementación de una aplicación web mejora la
productividad de la gestión de pedidos en un restaurante.
Resultado:
 Al concluir de implementar la aplicación web se puede observar como la
productividad de los meseros y cocineros tuvo un incremento
considerable en el procedimiento de la gestión de pedidos.
 Se transformaron ciertas actividades manuales del flujo de la gestión de
pedidos a un proceso con actividades automáticas y mucho más
eficientes.
Tabla 56
Cuadro de mejora en la productividad de los cocineros
Antes - Cantidad de pedidos Después – Cantidad de pedidos

Antes vs Después – Aplicación web Mejora (%)
x día x día
142
Cocineros 50 70 71%
Figura 66
Gráfico mejora de la productividad de los cocineros por pedido
Tabla 57
Cuadro de mejora en la productividad de los meseros
Antes - Cantidad de clientes Después – Cantidad de clientes

x día x día
Meseros 30 50 60%
Figura 67
Gráfico mejora de la productividad de los meseros por clientes
143
OE3: Determinar como la implementación de una aplicación web mejora la precisión
de la gestión de pedidos en un restaurante.
Resultado:
 Al terminar de implementar la aplicación web, logro comprobarse que
está teniendo una mejora en precisión de la gestión de pedidos, es decir,
disminuyeron notablemente la cantidad de repedidos por parte de los
clientes.
 En los gráficos a continuación se logra observar el número de repedidos
mensuales que se tenía en el restaurante haciendo uso de un flujo manual
versus la cantidad de repedidos utilizando la aplicación web.
Tabla 58
Cuadro de la mejora en la precisión de la gestión de pedidos
Antes - Cantidad de Después – Cantidad de

repedidos x mes repedidos x mes
144
repedidos 10 2 500%
Figura 68
Gráfico de la mejora en la precisión de los pedidos
CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES
Al implementar y desarrollar una aplicación web con característica responsive con el
fin de mejorar la gestión de los pedidos en un restaurante haciendo uso de una metodología o
marco de trabajo que se consiguió a través de diversas iteraciones, se logró simplificar
considerablemente la gestión de los pedidos en el restaurante, es decir, se disminuyeron las
etapas involucradas en el proceso tornándolo más eficiente y eficaz.
145
Al implementar y desarrollar esta aplicación web se logro aumentar la productividad
de los meseros y cocineros, ya que se disminuyo considerablemente el tiempo que se invierte
en el proceso de gestión de los pedidos, y así aumentando la cantidad de pedidos generados y
atendidos al mes.
Al implementar y desarrollar esta aplicación web se logro mejorar la precisión de la
gestión de pedidos, disminuyendo notablemente los repedidos y errores humanos que surgían
en el proceso de gestión de pedidos en el restaurante, y con ello, mejorar la atención a los
clientes y así aumentar la experiencia de estos al realizar sus pedidos.
5.2.RECOMENDACIONES
Instruir a los colaboradores ya establecidos y nuevos constantemente para que efectúen
sus labores de una forma más eficiente haciendo uso de la aplicación web para que así no
disminuya su uso en el tiempo.
Se recomienda seguir implementando de manera constante mejoras en la solución
propuesta para optimizar los procesos manuales restantes con los que cuenta el restaurante,
asimismo, analizar la forma de integrar al cliente final en el flujo.
Se sugiere la migración de la solución propuesta a un ambiente cloud para la mejora del
performance, asimismo, para soportar las mejoras mapeadas, con respecto a todos los flujos del
restaurante.
146
REFERENCIAS
Acuña Agudelo, G. J., & González Hernández, I. D. (2017). Diseño de puestos de trabajo en la
empresa “Soluciones Agropecuarias La Granja SAS”.
https://repositorio.uptc.edu.co/handle/001/2472
Alarcón, F., Alemany, M. M. E., Ortiz, A., & Lario, F. C. (2007). El proceso de gestión
colaborativa de pedidos: Estado del Arte. In Primer Congreso de Logística y Gestión de
la Cadena de Suministro. https://bit.ly/3hqG4rB
Aniceto Caba, M. D. L. L. (2020). Visualización del rendimiento en equipos de desarrollo
Software a través de sistemas de control de versiones Git.
https://idus.us.es/handle/11441/104987
Bravo Ramírez, M. A., Huasasquiche Calmet, P. M., & Ojeda Monzón, C. P. (2020). Análisis
comparativo entre Waterfall y devOps en el desarrollo del microservicio “Obtener detalle
de libros en tienda virtual”. https://repositorio.unp.edu.pe/handle/20.500.12676/2589
Cabrera, L. V. (2013). Una introducción a HTML, la importancia de conocerlo, la filosofía
subyacente y la sintaxis básica del lenguaje.
http://www.cs.us.es/blogs/bd2012/files/2012/09/Introducci%C3%B3nHTML.pdf
Contreras Paredes, J. C. (2017). Desarrollo de un Sistema encargado de la gestión de
información de clientes para la Fundación Fudrine usando la metodología del proceso
racional unificado RUP (Bachelor's thesis, PUCE).
http://repositorio.puce.edu.ec/handle/22000/14411
Cruz Pabón, D. F. (2019). Sistema web dinámico para la gestión de pedidos, fabricación y
entrega de los productos metalmecánicos en la Empresa Minacoples SAS. [Trabajo de
147
Grado, Universidad Distrital Francisco José de Caldas].
https://repository.udistrital.edu.co/handle/11349/22461
Denzer, P. (2002). PostgreSQL. Universidad Técnica Federico Santa María UTFSM.
http://profesores.elo.utfsm.cl/~agv/elo330/2s02/projects/denzer/informe.pdf
Galarza, I. (2016). Administración de restaurante guía de estudio. Ibarra, Ecuador. Universidad
técnica del norte. https://dspace.ups.edu.ec/bitstream/123456789/9957/1/UPS-
GT000982.pdf
Garrido, A., & Carrillo, J. (2013). Programación reactiva en la administración de proyectos:
aproximación conceptual y aplicaciones prácticas. Revista EAN, (74), 72-85.
http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S0120-81602013000100006
Godoy, J. N. (2011). El capital humano en la atención al cliente y la calidad de
servicio. Observatorio laboral revista venezolana, 4(8), 23-35.
https://www.redalyc.org/pdf/2190/219022148002.pdf
Gómez, S. (2013). Introducción a Git y GitHub. https://www.uco.es/aulasoftwarelibre/wp-
content/uploads/2015/11/git-cosfera-dia-1.pdf
Hernández, R. (2014). Metodología de la Investigación. México: Interameriacana Editores.
Hurtado, A., & Robayo, O. (2019). Diseño del sistema de gestión de seguridad de la informacion
-SGSI- para los procesos críticos de la cooperativa Febor basado en la norma ISO
27001:2013. Bogotá: Universidad Piloto de Colombia.
Inoguhi, A., & Macha, E. (2017). Gestión de la ciberseguridad y prevención de los ataques
cibernéticos en las Pymes del Perú, 2016. Perú: Universidad San Ignacio de Loyola.
148
Joyanes, L. (2017). Ciberseguridad: la colaboración público-privada en la era de la cuarta
revolución industrial (Industria 4.0). Madrid: Universidad Pontifica de Salamanca.
Lara, E., & Corella, F. (2018). Comparación de modelos tradicionales de seguridad de la
información para centros de educación. Tierra Infinita Nº4, 20-28.
Llerena Ocaña, L. A., Fernández Villacres, G. E., Viscaino Naranjo, F. A., & Baño Naranjo, F.
P. (2021). Frameworks basados en typescript para el desarrollo de aplicaciones web
interactivas. Dilemas contemporáneos: educación, política y valores, 8(3).
https://www.scielo.org.mx/scielo.php?pid=S2007-
78902021000200023&script=sci_arttext
Mariño, S. I., & Alfonzo, P. L. (2014). Implementación de SCRUM en el diseño del proyecto del
Trabajo Final de Aplicación. Scientia et technica, 19(4), 413-418.
Melgarejo, K. (2019). ¿Porque mi negocio necesita un sistema de restaurante?
Mendoza, L., & Vega, G. (2019). Evaluación de la capacidad de detección y respuesta a riesgos
de ciberseguridad, caso de la empresa SISC. Lima: Universidad del Pacífico.
Murray, P. (2002). Gestión-información-conocimiento. Biblios, 4(14).
Núñez, V. (2017). Impacto de las Tecnologías de la Información en la productividad del
establecimiento comercial minorista. Ene, 11, 39.
https://eprints.ucm.es/id/eprint/40852/
149
Ordóñez, M. P. Z., Ríos, J. R. M., & Castillo, F. F. R. (2017). Administración de Bases de datos
con PostgreSQL (Vol. 19). 3Ciencias. https://www.3ciencias.com/wp-
content/uploads/2017/04/Administraci%C3%B3n-bases-de-datos.pdf
Quiñones, M., Gonzales, V., Torres, R., & Jumbo, M. (2017). Sistema de monitoreo de variables
medioambientales usando una red de sensores inalámbricos y plataformas de Internet de
las Cosas. Enfoque UTE, 329-343.
Rational. (2011). Rational Unified Process. Rational Software White Paper.
https://developer.ibm.com/devpractices/devops/
Rodríguez, N. R., Murazzo, M. A., Chávez, S. B., Runco, T., Medel, D., & Rosenstein, J. (2019).
La programación Reactiva y de Actor en entornos de Internet de las Cosas. In XXI Workshop de
Investigadores en Ciencias de la Computación (WICC 2019, Universidad Nacional de San
Juan). http://sedici.unlp.edu.ar/handle/10915/77207
Rodríguez, J. (2017). Metamodelo para la integración del Internet de las Cosas y Redes sociales.
Oviedo: Universidad de Oviedo.
Sabillon, R., & Cano, J. (2019). Auditorías en Ciberseguridad: Un modelo de aplicación general
para empresas y naciones. Revista Ibérica de Sistemas y Tecnologías de Información, 33-
48.
Sánchez Páez, A. S. (2017). Diseño y desarrollo de un sistema computacional de registros bio-
psicosociales y terapia ocupacional para niños y jóvenes con discapacidad intelectual para la
fundación IEPNI usando la Metodolog ía del Proceso Unificado Racional RUP (Bachelor's
thesis, PUCE). http://repositorio.puce.edu.ec/handle/22000/13774
150
Sanchis Gisbert, R., & Poler Escoto, R. (2018). Las Fases del Proceso de Gestión de Pedidos
según las Estrategias de Cumplimiento de Pedidos.
https://riunet.upv.es/handle/10251/104399
Schmal, R. F., & Olave, T. Y. (2014). Optimización del proceso de atención al cliente en un
restaurante durante periodos de alta demanda. Información tecnológica, 25(4), 27-34.
https://www.scielo.cl/scielo.php?pid=s0718-07642014000400005&script=sci_arttext
School, O. B. (2018). Ciberseguridad y sus fases. Tendencias & Innovación, 2-5.
Seclén, J., & Aspilcueta, A. (2019). Caso: Seguridad en Internet de las Cosas, Gestión de
riesgos, amenazas y vulnerabilidades. Perú: Universidad Nacional Mayor de San Marcos.
Tamayo, M. (2003). El proceso de la investigación científica. México: Noriega Editorial.
Technology, N. I. (2018). Framework for Improving Critical Infrastructure Cybersecurity.
Estados Unidos.
Ulloa Campoverde, G. A. (2019). Estudio de la herramienta Maven como gestor de proyectos
Spring MVC con el caso de uso aplicación para comercio electrónico (Bachelor's thesis).
http://repositorio.utn.edu.ec/handle/123456789/9018
Valero, F. A., Bas, Á. O., Díaz, M. D. M. E. A., & Esteban, F. C. L. (2005, September). “Order
promising” y Gestión de Pedidos: una visión de procesos. In IX Congreso de Ingeniería
de Organización (p. 43). http://adingor.es/congresos/web/articulo/detalle/a/1063
151
ANEXOS
Anexo 1: Matriz de consistencia

TEMA DE Implementación de una aplicación web para mejorar la gestión de pedidos en un restaurante
INVESTIGACION:
PROBLEMA OBJETIVO HIPOTESIS VARIABLES DIMENSIONES INDICADORES DISEÑO METODOLOGICO

GENERAL GENERAL GENERAL
¿Cómo la Implementar una La implementación de Variable independiente: Tipo de investigación:
implementación de una aplicación web para la una aplicación web Aplicación web Complejidad de funcionalidades Aplicada.
aplicación web influye mejora de la gestión de influye notablemente en
en la gestión de pedidos pedidos en un la gestión de pedidos en Según Andrew Nivel de investigación:
en un restaurante? restaurante. un restaurante. Hoffman (2020): Explicativa.
Tecnología Interfaz de usuario
"Aplicación web se Según Hernandez Sampieri (2014): “Los
refiere a la combinación estudios explicativos van más allá de
de diversas tecnologías definir términos o establecer relaciones
que se utilizan para Funcionalidades entre conceptos para abordar las causas
facilitar la ruta más subyacentes de eventos y fenómenos en el
PROBLEMA OBJETIVOS HIPOTESIS eficiente en las mundo físico y social”. Como su nombre
actividades que el lo sugiere, su principal interés está en
ESPECIFICO ESPECIFICOS ESPECIFICA usuario desee realizar.
Rapidez de procesos
explicar por qué ocurre un fenómeno,
En la ingeniería de como se manifiesta o como se relacionan
software se denomina dos o más variables.
aplicación web a Eficiencia Fiabilidad de procesos
aquella herramienta que Enfoque de investigación:
los usuarios pueden Cuantitativo / Cualitativo.
utilizar accediendo a un
servidor web a través de Disponibilidad de procesos Diseño de investigación:
internet" No experimental – Descriptivo.
¿Cómo la Determinar como la La implementación de Variable dependiente:
implementación de una implementación de una la aplicación web Gestión de pedidos Manejo de la aplicación Según Hernandez Sampieri: “Estudios que
aplicación web influye aplicación web mejora la influye notablemente la se llevan a cabo sin la manipulación
en la simplificación de simplificación de la simplificación de la Según Michael Keenan Simplificación Facilidad de uso deliberada de factores y en los que los
la gestión de pedidos en gestión de pedidos en un gestión de pedidos en (2021): "Gestión de fenómenos solo se observan en sus
un restaurante? restaurante. un restaurante. pedidos es el proceso entornos naturales para su análisis”.
Registro de productos
desarrollado en una
152
¿Cómo la Determinar como la La implementación de empresa el cual facilita Área de estudio:
implementación de una implementación de una la aplicación web la simplificación de Tiempos de espera Restaurante.
aplicación web influye aplicación web mejora la influye notablemente la actividades dentro del
en la productividad de productividad de la productividad de la proceso de compra y Población:
Productividad Tiempos de entrega
la gestión de pedidos en gestión pedidos en un gestión de pedidos en venta, aumenta la Un restaurante del cercado de Lima.
un restaurante? restaurante. un restaurante. productividad de las
personas que influyen Tiempos de preparación Muestra:
en dicho proceso ya que No probabilístico.
¿Cómo la Determinar como la La implementación de ayuda a que estas sean Seis trabajadores del restaurante, 4 de ellos
implementación de una implementación de una la aplicación web más eficientes y mejora Rapidez en la atención serán cocineros, y las 2 ultimas serán
aplicación web influye aplicación web mejora la influye notablemente la la precisión de los meseras.
en la precisión de la precisión de la gestión de precisión de la gestión pedidos, debido a que Mejor atención al cliente
Precisión
gestión de pedidos en pedidos en un de pedidos en un procesar pedidos de Instrumentos:
un restaurante? restaurante. restaurante. forma manual lo hace Entrevista / Ficha de observación.
propenso al error Reducción de fallos
humano"
153
Anexo 2: Acta de Constitución del Proyecto
Anexo 3: Matriz de datos
Anexo 4: Validez de los instrumentos de investigación
154

D.Maza Trabajo Suficiencia Profesional Titulo Profesional 2023

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

D.Maza Trabajo Suficiencia Profesional Titulo Profesional 2023

Cargado por

Copyright:

Formatos disponibles

Facultad de Ingeniería

Ingeniería de Sistemas e Informática

Trabajo de Suficiencia Profesional

“Implementación de una aplicación web para mejorar la gestión de pedidos en un

Dennis Alexis Maza Cerna

para optar el Título Profesional de

Ingeniero de Sistemas e Informática

Asesor: Mg. Wilfredo Mamani Ticona

Marzo del 2023

Dedicado a mis padres y hermanas por la paciencia, apoyo,

Ya que son la base de mi vida, me gustaría agradecer a mi

Figura 1: Problema principal, causas y efectos…………………………………………………..3

Figura 2: Línea del tiempo de la evolución de la web…………………………………………..16

Figura 3: Diseño de bases de datos relacionales…………………...……………………………18

Figura 4: Logo de Java……………………..………………………………………………...…20

Figura 5: Logo de Angular………………………………………………………..……………..21

Figura 7: Sistema de gestión de versiones locales………………………………………………23

Figura 8: Sistema de gestión de versiones centralizado………………………………………...25

Figura 9: Sistema de gestión de control de versiones distribuidas……………………………...26

Figura 10: Ejemplo de gestión de pedidos………………………………………………………28

Figura 12: Etapa de planteamiento de un restaurante……………………………….…………..34

Figura 13: Aspectos de la administración de un restaurante…………………………………....35

Figura 14: Proceso de atención al cliente……………………………………………………….38

Figura 15: Ciclo de vida del RUP……………………………………………………………….41

Figura 16: Ejemplo de flujo de trabajo del RUP………………………………………………..41

Figura 17: Roles, artefactos y eventos principales de SCRUM………………………………...43

Figura 19: Comparación de PostGreSQL con otras bases de datos…………………………….45

Figura 20: Configuración de Spring Boot………………………………………………………47

Figura 21: Ciclo de Maven………………………………………………………….…………..48

Figura 22: Estructura de un documento HTML…………………………………….…………..49

Figura 23: Esquema de versiones en Git……………………………………………….……….50

Figura 24: Aplicación de la programación reactiva en proyectos………………………………52

Figura 25: Flujo de caja…………………………………………………………………………78

Figura 26: Calculo del VAN…………………………………………………………………….79

Figura 27: Calculo de la TIR……………………………………………………………………81

Figura 28: Acta de constitución del proyecto…………………………………………………..84

Figura 29: Diagrama de flujo actual de pedidos………………………………………………..88

Figura 30: Diagrama del flujo con la mejora en la gestión de pedidos…………………………89

Figura 31: Scrum Poker Online………………………………………………………………..101

Figura 32: Esquema de puntajes……………………………………………………………….101

Figura 33: Diseño vista Inicio de sesión……………………………………………………….103

Figura 34: Implementación de interfaz de inicio de sesión……………………………………104

Figura 35: Implementación API de login……………………………………………………...105

Figura 37: Implementación de interfaz del dashboard………………………………………...108

Figura 38: Implementación componente de logout……………………………………………109

Figura 39: Diseño vista del pop-up de registro del pedido…………………………………….111

Figura 41: Implementación API de registro de pedido………………………………………...112

Figura 42: Implementación API de lista de meseros disponibles……………………………...113

Figura 43: Implementación de API de lista de platos disponibles…………………………….113

Figura 45: Implementación de interfaz del pop-up de detalle del pedido……………………..116

Figura 46: Implementación API de detalle del pedido………………………………………...117

Figura 47: Implementación API de actualización del estado del pedido……………………...117

Figura 48: Diagrama de base de datos…………………………………………………………118

Figura 49: Modulo frontend del login…………………………………………………………122

Figura 50: Modulo backend del login…………………………………………………………123

Figura 51: Modulo frontend del dashboard……………………………………………………124

Figura 53: Modulo backend del registro del pedido…………………………………………...127

Figura 55: Modulo backend del detalle del pedido……………………………………………129

Figura 56: Reunión de verificación de sprint………………………………………………….130

Figura 57: Reunión de retrospectiva…………………………………………………………..134

Figura 58: Repositorio de código fuente………………………………………………………135

Figura 59: Documentación de termino………………………………………………………...136