Capítulo IV
RESULTADOS DE LA INVESTIGACIÓN
CAPÍTULO IV
RESULTADOS DE LA INVESTIGACIÓN
En este capítulo se presentan los resultados provistos por la
investigación, en base a la información obtenida por el instrumento de
recolección de datos el cual fue la entrevista semiestructurada. Además, se
expone la realización de las actividades pautadas en el cronograma de
actividades para realizar la investigación.
[Link]ÁLISIS Y DISCUSIÓN DE LOS DATOS Y RESULTADOS
Fue realizada una entrevista semiestructurada al dueño de la Pizzería
Pronto Pizza C.A. ubicada en Canta Claro. La entrevista contó con 10
preguntas base relacionadas a la investigación y que proveyeron de datos
importantes a la investigación. Dichos datos sirvieron como base para
determinar funcionalidades específicas que cumpliría la aplicación para la
parte administrativa, así como para proveer información sobre los
procedimientos e intereses de la pizzería.
88
89
[Link] DE CADA FASE DE LA INVESTIGACIÓN
La discusión de los resultados se realiza en base a las fases
metodológicas planteadas anteriormente para cumplir con los objetivos del
estudio. Los resultados de cada una de las fases están descritos en los puntos
siguientes.
[Link] I. DESARROLLO DE UN MODELO GENERAL
Para dar cumplimiento al primer objetivo de la investigación Analizar los
procesos operativos llevados a cabo actualmente en Pronto Pizza C.A, se
utilizó la entrevista semiestructurada para adquirir información sobre distintos
tópicos de interés a partir de los cuales conocer los procesos operativos de la
pizzería. Una vez que el equipo de desarrollo ha obtenido conocimiento sobre
los procesos operativos, cada uno de los miembros realiza un modelo básico
en el que describen módulos, características y funcionalidades con los que
contaría el programa ideal.
Las propuestas plasmadas en los modelos abarcan las necesidades
presentadas por la pizzería en base a la información obtenida de la entrevista
(Ver anexo 1). Los modelos presentados por cada uno de los desarrolladores
del equipo de desarrollo están presentados a continuación Estos modelos
abarcan lo que cada uno de los miembros consideraría un programa ideal que
satisfaga las necesidades relacionadas a los procesos operativos de la
pizzería Pronto Pizza C.A.
90
Cuadro 3
Modelo básico por Gutiérrez
Módulo Propiedad Funcionalidad
● Módulo para ● Diseño ● Los clientes de la pizzería
gestionar artículos o responsive. deben poder crear y enviar
inventario. ● Interfaz pedidos.
● Módulo para agradable para el ● Los clientes deben poder
gestionar productos usuario. informarse del estado de su
para la venta. ● Persistenci pedido.
● Módulo para a de la ● La pizzería debería poder
gestionar usuarios. información en ver la información del cliente.
● Módulo para base de datos. ● La página de la pizzería
la atención de ● Notificacio tiene un horario de cierre y
pedidos por parte de nes push. apertura.
la pizzería. ● Las existencias de los
artículos en el inventario
deberían reducirse
automáticamente en función de
los pedidos que se vayan
procesando.
● La aplicación debe ser
responsive para mostrarse en
teléfonos.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
Cuadro 4
Modelo básico por Hidalgo
Módulo Propiedad Funcionalidad
● Módulo de ● Edicion ● Mostrar los productos más
estadística. flexible. vendidos.
● Módulo de ● Integración ● Generar un reporte de
ventas. de pago. ventas semanal.
● Módulo de ● Persistenci ● Mostrar un historial de las
menú. a de información ventas realizadas.
● Módulo de del carrito.
carrito de compra. ● Especificac
ión de productos
mejor vendidos.
91
Cuadro 4
(cont…)
● Mostrar el inventario
general de productos.
● Añadir, eliminar y
modificar productos al inventario.
● Mostrar listado de
productos.
● Mostrar precios de cada
producto.
● Añadir productos al carrito
de compra.
● Redireccionar cliente al
formulario de pago.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
Cuadro 5
Modelo básico por Juliao
Módulo Propiedad Funcionalidad
● Landing page. ● Notificaci ● Para los clientes: poder
● Módulo de ones push. escoger productos para un
pedidos del lado de ● Diseño pedido.
clientes. responsive. ● Poder verificar el estatus
● Módulo de ● Horario de un pedido.
pedidos del lado del de trabajo. ● Para la parte
administrador. administrativa: Gestionar
● Módulo de pedidos y poderlos filtrar por
productos. pedidos actuales, así como
● Módulo de avanzar los pedidos actuales.
artículos. Añadir productos y crearles
● Módulo de recetas que los asocien con un
autenticación. consumo para el inventario.
● Módulo de ● Cerrarse y abrirse basado
estadísticas. en la hora estipulada por la
pizzería.
● Hacer alertas a la
administración cuando un
artículo esté a punto de
acabarse.
92
Cuadro 5
(Cont…)
Modificadores a los
productos en caso de que un
cliente quiera más o menos de
un ingrediente en su pizza.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
A partir de los modelos básicos presentados se realiza un debate entre
los miembros del equipo y se elabora este modelo general de la aplicación que
servirá como base para elaborar la lista de características durante la fase
siguiente de la planificación.
Cuadro 6
Modelo general de la aplicación
Módulo de la Funcionalidades que cumple.
aplicación.
Módulo para la ● Permite al usuario realizar pedidos por medio
creación y revisión de la a aplicación
de pedidos por parte ● Permite enviar comprobantes de pago al
de los clientes. cliente para la compra del producto
● Permite verificar el estado del pedido una vez
realizado
● Permite a la pizzería observar la información
de los clientes.
Módulo para la ● Mostrar un inventario general de los
gestión de productos disponibles.
productos. ● Gestionar los pedidos y mostrar los más
recientes.
● Creación de recetas para descontar
automáticamente artículos del inventario tras
validar un pedido.
93
Cuadro 6
(Cont…)
Módulo para la ● Crear artículos, de forma manual.
gestión de artículos ● Añadir artículos al inventario, junto con su
o del inventario. respectiva cantidad (en gramos).
● Permite consultar, modificar y eliminar los
artículos ya existentes.
Módulo para la ● Revisión de los pedidos entrantes e históricos.
gestión y atención ● Verificar los comprobantes de pago de los
de pedidos. pedidos realizados.
● Confirmar o rechazar pedidos entrantes.
Módulo para la ● Solamente tiene acceso el administrador.
gestión de usuarios. ● Bloqueo y/o desbloqueo de usuarios.
● Consultar los datos de los usuarios.
Módulo para la ● Registro de nuevos usuarios.
autenticación de ● Inicio de sesión de nuevos usuarios.
usuarios. ● Recuperación de contraseña.
● Los usuarios deben de ser permitidos dentro del
sistema por el administrador.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
Las características más relevantes que conformaron el modelo general
de la aplicación fueron: experiencia de usuario agradable, interfaz gráfica
responsive, la notificación push para alertar sobre los pedidos. Algunas
funcionalidades más complejas que podrían surgir a partir de lo observado en
el modelo general sería la implementación de un horario para el cierre y
apertura de la pizzería, así como la asignación de ingredientes para las pizzas
y un sistema de alertas para avisar cuando quede poco inventario.
94
[Link] II. ELABORACIÓN DE LISTA DE CARACTERÍSTICAS
A continuación, se presenta el cuadro con la lista de características,
separadas en cliente (frontend) y servidor (backend) para separar las
características y funcionalidades de acuerdo al ámbito de la aplicación al que
pertenezcan.
Cuadro 7
Lista de características según cliente y servidor
Módulo de la Cliente Servidor
aplicación
Módulo para ● El módulo crea y ● La información
la creación y almacena el pedido recibida se almacena en la
revisión de localmente una vez pasado BDD para poder
pedidos por a la base de datos. posteriormente ser
parte de los ● Una vez se encuentra visualizada en el módulo de
clientes. un pedido almacenado, atención de pedidos.
este escucha al servidor ● Mantiene actualizado
esperando un cambio de al cliente sobre la
estado. información del pedido que
realizó.
Módulo para ● Presenta un ● Almacena en BDD la
la gestión de formulario, con validaciones información de los productos
productos. para los productos que se creados.
muestran posteriormente. ● Asocia un producto
● Crea, recibe, con los ingredientes usados
actualiza y elimina pedidos en su preparación para
mediante solicitudes al crear una “receta”.
servidor.
95
Cuadro 7
(Cont…)
Módulo para ● Se agregan al ● Almacena en BDD la
la gestión de inventario artículos mediante información de los artículos
artículos o del formularios. creados.
inventario. ● Los artículos se pueden ● Ingresar artículos
asociar con un producto para aumenta las existencias en
formar una receta. inventario.
● Se pueden actualizar ● Las existencias se
las existencias de un artículo, reducen en el momento en
además de eliminarlos que un pedido entra en
enviando peticiones al preparación y se descuentan
servidor. según la receta de los
productos en la comanda.
Módulo para ● Presenta una lista ● Recupera de la BDD
la gestión y completa de artículos la información almacenada
atención de paginada, además de del cliente y del pedido para
pedidos. opcionalmente filtrada. su visualización por parte de
● Es el responsable de la pizzería.
solicitar una actualización del ● Altera el estado de un
estado de un pedido al pedido en BDD.
servidor.
Módulo para ● Muestra una lista de los ● Almacena la
la gestión de usuarios registrados en el información de todos los
usuarios. sistema. usuarios trabajadores de la
● Los usuarios pueden pizzería.
ser bajados o subidos de ● El administrador
permisos dependiendo de lo puede bloquear y
que solicite el administrador. desbloquear el acceso a los
demás usuarios.
Módulo para ● Incluye formularios de ● Capta la información
la inicio de sesión, registro y recibida del formulario de
autenticación contraseña olvidada. inicio de sesión y devuelve
de usuarios. ● En caso de ser exitosa un token de autenticación al
alguna de las solicitudes de cliente de la aplicación.
ingreso, guarda un token de ● En rutas protegidas
autorización localmente para del servidor es necesario el
enviar al servidor. envío del token de
autenticación.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
96
[Link] III. PLANIFICACIÓN POR CARACTERÍSTICAS
Cumpliendo con la primera actividad pautada en la tercera fase, se
determina esta secuencia de desarrollo para la construcción de la aplicación.
En este cuadro se agrupan las características en módulos.
Cuadro 8
Secuencia de desarrollo
Fecha (mes y año) para el inicio de Módulo de la aplicación
su desarrollo
Diciembre, 2023 ● Módulo para la gestión de
productos.
Enero, 2024 ● Módulo para la gestión de
artículos o del inventario.
● Módulo para la gestión de
usuarios.
● Módulo para la autenticación
de usuarios.
Febrero, 2024 ● Módulo para la creación y
revisión de pedidos por parte de los
clientes.
● Módulo para la gestión y
atención de pedidos.
Fuente: Gutiérrez, Hidalgo y Juliao (2024)
Siguiendo con la posterior actividad pautada para esta fase, las
características de la aplicación que se han descrito en la lista durante la
segunda fase se asignan a uno de dos mayores conjuntos según el ámbito
de la aplicación al que pertenezcan, siendo estos ámbitos: cliente (frontend)
o servidor (backend). Para completar la última actividad de la fase, a estos
97
conjuntos de la aplicación se les asignó desarrolladores, para el conjunto de
características del cliente se asignó a dos desarrolladores y para el servidor
uno, sin embargo, al momento de conectar las características entre cliente y
servidor los desarrolladores de ambos conjuntos trabajaron en equipo.
[Link] IV. CODIFICACIÓN
En esta fase se logra desarrollar los módulos de la aplicación utilizando
las herramientas de programación establecidas como recursos. Tanto los
desarrolladores de los grupos de frontend como backend utilizaron como
lenguaje de programación “Typescript”, trabajando con los frameworks Angular
17 y NestJS, ambos funcionando a partir de NodeJS.
Este parecido entre las herramientas de desarrollo hizo posible la
programación en parejas, puesto que un desarrollador de un grupo podía
directamente trabajar junto al otro grupo para implementar alguna
funcionalidad de estructura compleja como es el caso de la implementación de
la notificación push la cual conlleva generar unos tokens en el dispositivo que
va a recibir las notificaciones para enviarlos al servidor y que éste los
almacenen en una tabla de la base de datos para su uso posterior durante las
notificaciones de los pedidos o del inventario (ver figura 1).
98
Figura 1. Modelo de base de datos
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
Para desarrollar el resto de las funcionalidades de la aplicación se
realizan pruebas unitarias sobre las funciones de los módulos tanto en el
frontend como el backend con el propósito de asegurar que cada componente
individual de la estructura cliente-servidor maneje los datos correctamente por
su cuenta antes de enviárselos al otro.
99
Para lograr las pruebas unitarias anteriormente descritas, se
aprovecharon los mensajes de error HTTP. En el caso de un error en el manejo
de los datos por parte del frontend, éste recibiría como respuesta un mensaje
de error 4XX (ver figura 2). El error contiene un número de estatus y un
mensaje indicando el error que en el caso de la figura fue el mal manejo y
envío del parámetro “endpoint”.
Figura 2. Consola de desarrollo mostrando el error 400.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
En el caso de un mal manejo de los datos y consecuentemente un error
dentro del lado del backend, la respuesta hubiera contenido un error de estatus
500 (ver figura 3), indicando que el error ocurrió en el lado del servidor sin
indicar más detalles para el grupo de desarrollo en frontend pues los detalles
del error se dan a conocer en el registro de la consola del servidor (ver figura
4).
100
Figura 3. Consola de desarrollo mostrando el error 500.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
Figura 4. Registro de la consola del servidor.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
Para indicar que la operación fue exitosa y por lo tanto que la prueba fue
pasada, el servidor deberá responder con un mensaje de estatus 200 o 201 y
una breve descripción que indique los resultados de la operación realizada (ver
figura 5) además de, por supuesto, los datos contenidos en la respuesta en
caso de que aplique para la ruta que se utilizó al comunicarse con el servidor.
101
Figura 5. Resultados de la operación realizada exitosamente.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
La actividad más destacable de esta fase es la integración continua de
funcionalidades pues en el backend se aprovecha una librería llamada
“Swagger”, dicha librería genera un compendio de las rutas (ver figura 6) y
provee instantáneamente información con respecto a la utilización de las rutas
provistas por el backend. Gracias a esta librería el flujo de trabajo entre los
grupos de desarrollo posee una mejor comunicación pues a través del
compendio generado se comparten las rutas y los parámetros que deben ser
enviados a ellas al utilizarlas, facilitando así la integración del frontend con el
backend (ver figura 7).
Figura 6. Compendio de rutas generado con la librería “Swagger”.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
102
Figura 7. Modelo de datos
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
Desde el lado del frontend, este se puede decir que se estructura de
manera general en diferentes módulos, de los cuales cada uno se encuentra
dividido en dos partes, una para administradores y empleados y otra para la
clientela general de la pizzería. Todos estos módulos son completamente
responsive a diferentes tamaños de pantalla, y en algunos casos pueden
presentar diferencias entre cómo se ven en monitor y como se ven en otras
resoluciones, en cual caso dichas diferencias serán resaltadas a continuación.
Comenzando a hablar de los módulos es pertinente hablar sobre el
primero que se va a encontrar un usuario llegando a la página, el módulo de
la landing page, o la página de destino, en la cual se le presenta al usuario
directamente la opción de realizar un pedido en la página, y en cuya parte
103
superior se presenta por primera vez el componente que aparece de manera
recurrente en toda la aplicación, la barra de navegación, o navbar, que se
encarga de dirigir al usuario a los diferentes apartados que tiene la página.
Figura 8. Landing page en modo escritorio
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
Figura 9. Landing page en dispositivos móviles
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
104
Figura 10. Menú desplegable del sitio web
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
Posteriormente, si el usuario selecciona el botón resaltado en la portada,
o va al apartado de “menú” que aparece en la barra de navegación, será
redirigido al módulo de productos. En este módulo es que comienza el flujo de
procesos principales de la aplicación, como lo son los pedidos. En principio,
se le muestra al usuario el menú principal de selección de productos (ver figura
11), filtrados por categoría entre pizzas, refrescos y postres, además de otros
productos que pueda vender la tienda. Al seleccionar un producto, se le
presenta al usuario la opción del carrito de compras (ver figura 11), en la cual
este puede confirmar su compra para ir directo al apartado de pago.
105
Figura 11. Menú de compra
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
El apartado de pago consiste en un formulario de dos partes, la parte de
información de pedido, que incluye datos como nombre de cliente, número de
cédula, correo electrónico y dirección, y la parte de pagos, en la cual se escoge
un método de pago de las posibles opciones que admite la empresa, se
muestran los datos a los cuales se debe realizar una transacción monetaria
para hacer el pedido en caso de que el método de pago escogido sea
transferencia o pago móvil, se requiere un número de referencia en caso de
que el método de pago escogido sea uno de los dos mencionados,
opcionalmente se solicitan detalles del pago y finalmente se solicita de manera
obligatoria un comprobante para confirmar el pedido.
Una vez concluido el formulario de pagos, al cliente se le redirige a un
apartado de otra manera no disponible si este no ha solicitado un pedido: el
106
apartado de órdenes. En este apartado, se le va mostrando al cliente el estado
de completación que lleva su pedido actual según vaya mandando
actualizaciones el servidor.
Además, en caso de que el usuario acepte recibir notificaciones push en
su navegador (esto puede ser opcional ya que hay navegadores que lo pueden
inhabilitar por defecto), éste será notificado al mismo tiempo que se actualice
el estado de su pedido mediante las mismas. Una vez el pedido del cliente
llegue al estado de completación, se le notificará al cliente y se le redirigirá al
componente principal, en el cual perderá acceso al apartado de órdenes hasta
hacer otro pedido.
Una vez establecida la parte de clientes, toca hablar sobre la parte de los
administradores. A esta parte de la aplicación nada más pueden acceder las
personas con acceso a la URL y los permisos, no se encuentra disponible
mediante la barra de navegación, y primero requiere pasar por uno de dos
formularios, el de registro (ver figura 12) y el de inicio de sesión (ver figura 13).
Figura 12. Inicio de sesión al sistema administrativo
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
107
Figura 13. Creación de un nuevo usuario
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
En caso de haberse olvidado una contraseña, también existe la sección
de recuperación de contraseña, en la cual solo con la combinación de nombre
de usuario y correo electrónico específicas se le mandará al correo de destino
un mensaje para poder recuperar su contraseña antigua (ver figura 14).
Figura 14. Formulario de recuperación de contraseña
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
108
Si mediante los formularios se logra ingresar exitosamente, se le
presenta al usuario la segunda mitad de la aplicación, la parte de empleados
y administradores, con su propia página de destino (ver figura 15) y barra de
navegación (ver figura 16).
Figura 15. Landing page del sistema administrativo
Fuente: Gutiérrez, Hidalgo y Juliao. (2024).
Figura 16. Barra de navegacion
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
109
Para esta sección, al empleado o administrador encargado de la página
se le presentan los diferentes módulos que tiene la misma, incluyendo algunos
que no se presentan en la sección de clientes. Estos son: Productos, Artículos,
Recetas, Inventario, Estadísticas y Órdenes.
Para los módulos de artículos (ver figura 17) y productos (ver figura 18),
la estructura básica es muy similar, un formulario en el cual se ingresan los
datos del ingrediente o producto que se desea vender, con la diferencia de
que, en caso de haber un artículo existente, en la sección de productos existe
opcionalmente la opción de directamente asociar un producto a una receta
específica, es decir, una combinación de artículos que contiene el producto,
mediante la cual se pueden realizar asociaciones y estadísticas e incluso
inhabilitar productos en caso de no haber suficiente de un artículo en reserva.
Figura 17. Formulario de registro de artículos.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
110
También, existe la sección de recetas (ver figura 18), está existiendo en
caso de no haber asociado un artículo a un producto originalmente al haberse
creado, además de proporcionar la función de cambiar la receta de un
producto en caso de que se le desee realizar algún cambio.
Figura 18. Seccion de Recetas.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
Una vez creados los artículos y productos, estos se pueden visualizar en
un apartado diferente, el de inventario (ver figura 19). Esta sección, además,
ofrece opciones para modificar este inventario, con algunas restricciones (no
se puede cambiar la receta de un producto ya que para eso se encuentra el
apartado de recetas separado, por ejemplo), eliminar, incrementar o restar
existencias de artículos y, además, manejar la permisología de los usuarios
registrados en el sistema.
111
Figura 19. Sección de Inventario.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
En el apartado de estadísticas (ver figura 20), se ofrece la opción de
visualizar diferentes gráficos e información dependiendo de varios factores,
como lo pueden ser las ventas generadas semanalmente, productos más
vendidos, horarios más frecuentes para los clientes, entre otras
funcionalidades solicitadas por la empresa para facilitar el manejo de sus
procesos.
Finalmente, se encuentra el apartado de órdenes (ver figura 21). En este
apartado, se encuentra un listado de todos los pedidos realizados en la
pizzeria, filtrados por pedidos en proceso, concluidos y cancelados. Además,
en caso de ser pedidos en proceso, en este apartado es que se envían controla
el estado de los pedidos, enviando un mensaje al servidor cada vez
que se desee avanzar el estado de un pedido, o, en caso de estar procesando
un pago, también se dispone de la posibilidad de rechazarlo.
112
Figura 20. Sección de estadísticas.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
Figura 21. Sección de órdenes.
Fuente: Gutiérrez, Hidalgo y Juliao. (2024)
113
[Link] V. PRUEBAS
La última fase comprende las pruebas de la aplicación, la principal
actividad es la prueba de integración, como estrategia para esta actividad se
empleó el enfoque Top-Down partiendo desde las pantallas principales que
utilizarían la administración y la clientela para luego acceder a los distintos
módulos a los cuales se ramifican estos apartados. Para las pruebas de
validación se realiza una prueba alfa para recibir una evaluación de la
aplicación por parte del cliente.
Por última actividad para concluir con la fase se tiene la revisión final
mediante pruebas de aceptación en colaboración con Pronto Pizza. En esta
actividad se entrega el producto final a la pizzería y la dinámica aplicada es
dar una ventana de tiempo de 6 meses para que ellos reporten algún
inconveniente que solventar o solicitud adicional para ser añadida a la
aplicación antes de que se acabe el tiempo.