Calle 18 No. 118 – 250, Piso 2, Facultad de Ingeniería y Ciencias – Santiago de Cali, Colombia Teléfono +57 (2) 3218200 Ext. 85 Facultad de Ingeniería y Ciencias Acta de Correcciones al Proyecto de Grado Ingeniería de sistemas y computación Fecha: 20 de julio de 2023 Autores: Julian Paredes Conde Nombre del Proyecto de Grado: Chatbot para mejorar la comunicación entre tiendas de barrio y sus proveedores. Director: Juan Pablo García Cifuentes Como indica el artículo 2.27 de las Directrices de Trabajo de Grado, he verificado que los estudiantes indicados arriba han implementado todas las correcciones que los Jurados del Proyecto de Grado definieron que se efectuaran, como consta en el Acta de Calificación correspondiente. ________________________________________ Firma de Director(a) del Proyecto de Grado Nota de Aceptación Aprobado por el Comité de Trabajo de Grado en cumplimiento de los requisitos exigidos por la Pontificia Universidad Javeriana para optar el título de Ingeniero de Sistemas y Computación. _______________________________________ DR. HERNÁN CAMILO ROCHA NIÑO Decano de la Facultad de Ingeniería ________________________________________ ING. GERARDO MAURICIO SARRIA Director Carrera Ingeniería Sistemas y Computación. ___________________________________ ING. JUAN PABLO GARCÍA CIFUENTES Director(a) Trabajo ______________________________ ______________________________ ING. GERARDO MAURICIO SARRIA ING. DIEGO LINARES Jurado 1 Jurado 2 Pontificia Universidad Javeriana Cali Facultad de Ingenieŕıa. Ingenieŕıa de Sistemas y Computación. Proyecto de Grado. Chatbot para mejorar la comunicación entre tiendas de barrio y sus proveedores. Julian Paredes Conde Director: Juan Pablo Garcia Cifuentes 15 de Junio del 2023 Santiago de Cali, 15 de Junio del 2023. Señores Pontificia Universidad Javeriana Cali. Dr. Gerardo Mauricio Sarria Montemiranda Director Carrera de Ingenieŕıa de Sistemas y Computación. Cali. Cordial Saludo. Por medio de la presente me permito informarle que el estudiante de Ingenieŕıa de Sistemas y Computación Julian Paredes Conde (cod: 8918744) trabaja bajo mi dirección en el proyecto de grado titulado “Chatbot para mejorar la comunicación entre tiendas de barrio y sus proveedores.”. Atentamente, Juan Pablo Garcia Cifuentes Santiago de Cali, 15 de Junio del 2023. Señores Pontificia Universidad Javeriana Cali. Dr. Gerardo Mauricio Sarria Montemiranda Director Carrera de Ingenieŕıa de Sistemas y Computación. Cali. Cordial Saludo. Me permito presentar a su consideración el proyecto de grado titulado “Chatbot para mejorar la comunicación entre tiendas de barrio y sus proveedores.” con el fin de cumplir con los requisitos exigidos por la Universidad para llevar a cabo el proyecto de grado y posteriormente optar al t́ıtulo de Ingeniero de Sistemas y Computación. Al firmar aqúı, doy fe que entiendo y conozco las directrices para la presentación de trabajos de grado de la Facultad de Ingenieŕıa aprobadas el 26 de Noviembre de 2009, donde se establecen los plazos y normas para el desarrollo del anteproyecto y del trabajo de grado. Atentamente, Julian Paredes Conde Código: 8918744 Agradecimientos Agradezco primeramente a mis padres por ser un apoyo incondicional durante toda mi carrera y por creer en mı́ siempre, al profesor Juan Pablo Garćıa, por atender mis dudas de la mejor manera, por su apoyo, gúıa e impulso hacia la innovación del uso de nuevas tecnoloǵıas, su orientación y supervisión, haćıa la ejecución teórica y práctica de los objetivos planteados. A la empresa Distri Romel SA por confiar en mı́ y en el desarrollo de este proyecto. También quiero agradecer a todos los profesores de la Pontificia Universidad Javeriana Cali que me formaron como profesional e hicieron de mı́ una mejor persona. Resumen La tecnoloǵıa es una herramienta que resulta ser de suma importancia hoy en d́ıa, la cual nos permite comunicarnos con las demás personas y darnos a conocer para aśı generar un mayor im- pacto en un público objetivo, al trabajar en conjunto con las estrategias de publicidad o marketing existentes. Asimismo, la tecnoloǵıa puede llegar a ser fundamental para impulsar o controlar un negocio, ya que esta consigue aumentar su productividad y eficiencia, al lograr romper la barrera que existe entre un proveedor y su cliente para comunicarse a la distancia. En Colombia se han venido implementando estrategias digitales en las empresas muy lentamente en comparación con otros páıses [1]. De hecho, el COVID-19 y el paro nacional fueron detonantes que obligaron a los negocios, como lo son las tiendas de barrio y sus proveedores, a adaptarse a una nueva era digital en la cual estos pueden llegar a vender, comprar o distribuir sus productos de una manera más eficiente. Sin embargo, dada la crisis económica, la falta de recursos, de comunicación y el desabas- tecimiento que se estaba viviendo en dicho momento, ha sido dif́ıcil generar una transición digital en muchas tiendas de barrio y proveedores de las mismas que lo requieren para impulsar su negocio. Dado que, aunque se han desarrollado distintas aplicaciones móviles o web que buscan servir como intermediarias, estas no abarcan las necesidades de la mayoŕıa de personas o negocios. El presente trabajo de grado buscará crear una solución tecnológica por medio de un Chatbot que permita mejorar la comunicación entre los tenderos y sus proveedores al momento de realizar un pedido, creando una alternativa basándose en sus necesidades, para que estos no solo puedan comunicarse entre śı, sino que también puedan comercializar sus productos de una manera más eficiente, de tal modo que se permita reducir el desabastecimiento en las tiendas de barrio y se logre aportar a la economı́a del páıs. Palabras Clave: Tecnoloǵıa Comunicación Desabastecimiento Arquitectura de software Scrum Abstract Technology is a tool that turns out to be extremely important today, which allows us to com- municate with other people and make ourselves known in order to generate a greater impact on a target audience, by working together with existing advertising or marketing strategies. Technology can also become fundamental to driving or controlling a business, as it can increase its productivity and efficiency by breaking down the barrier between a supplier and its customer to communicate at a distance. In Colombia, companies have been implementing digital strategies very slowly com- pared to other countries [1]. In fact, COVID-19 and the national strike were triggers that forced businesses, such as neighborhood stores and their suppliers, to adapt to a new digital age in which they can sell, buy or distribute their products more efficiently. However, given the economic crisis, the lack of resources, communication and the shortage of supplies that were going through at that time, it has been difficult to generate a digital transition in many neighborhood stores and their suppliers that require it to boost their business. Since, although various mobile or web applications have been developed that seek to serve as intermediaries, they do not cover the needs of most people or businesses. This thesis will seek to create a technological solution by means of a Chatbot that allows to improve communication between shopkeepers and their suppliers at the time of placing an order, creating an alternative based on their needs, so that they can not only communicate with each other, but also market their products in a more efficient way, so that it is possible to reduce shor- tages in local shops and contribute to the economy of the country. Keywords: Technology Communication Shortage of supply Software architecture Scrum Índice general 1. Descripción del Problema 19 1.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.1.1. Formulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.1.2. Sistematización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.2. Objetivos Espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.4. Delimitaciones y Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.4.1. Entregables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2. Desarrollo del Proyecto 25 2.1. Marco de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1. Áreas Temáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.2. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.3. Trabajos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2. Metodoloǵıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.1. Tipo de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.2. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3. Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.1. Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.2. Técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.3. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3. Obtención y Análisis de Requisitos 35 3.1. Estrategias Implementadas para la Educción de Requisitos . . . . . . . . . . . . . . . 35 3.2. Descripción general del Chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4. Diseño del Software 37 4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2. Diagrama de Flujo: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3. Arquitectura del Chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.1. Criterios de elección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 12 Índice general 4.3.2. Arquitectura seleccionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.5. Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.5.1. Aprendizajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5. Tecnoloǵıas Involucradas en el Desarrollo del Chatbot 45 5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.4. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6. Implementación del Software 51 6.1. Proceso de Desarrollo - Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2. Proceso de Desarrollo - Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.3. Proceso de Desarrollo - Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.4. Proceso de Desarrollo - Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.5. Prototipo Final Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7. Pruebas 65 7.1. Pruebas Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Pruebas de Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.2.1. Resultados Usuario Tendero . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.2. Resultados Usuario Proveedor . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.2.3. Comentarios y Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 8. Evidencias 81 8.1. Proceso Levantamiento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8.2. Proceso Metodoloǵıa SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 9. Conclusiones y Trabajos Futuros 91 9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 9.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Bibliograf́ıa 93 10.Anexos 99 10.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 10.1.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 10.1.2. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.2. Prototipos Previos al Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.2.1. Prototipos de vistas usuario Tendero - Registro . . . . . . . . . . . . . . . . . 102 10.2.2. Prototipos de vistas usuario Tendero - Realizar pedido . . . . . . . . . . . . . 107 10.2.3. Prototipos de vistas usuario Proveedor . . . . . . . . . . . . . . . . . . . . . . 114 Índice general 13 10.3. Prototipo Final Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 10.3.1. Registro Usuario Tendero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 10.3.2. Realizar Pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 10.3.3. Visualizar Pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 10.4. Formulario Retroalimentación Chatbot Usuario Tendero . . . . . . . . . . . . . . . . 135 10.5. Formulario Retroalimentación Chatbot Usuario Proveedor . . . . . . . . . . . . . . . 140 10.6. Casos de Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Índice de figuras 1.1. Cartilla de productos, tomada de: Distri Romel S.A. . . . . . . . . . . . . . . . . . . 22 2.1. Metodologia scrum: Fases de un sprint [26] . . . . . . . . . . . . . . . . . . . . . . . 26 2.2. Cronograma de actividades del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3. SMMLV 2022 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4. Costo total del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5. Costo de recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6. Costo de recursos Fisicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Diagrama de Flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Diagrama patrón de diseño Modelo-Vista-Controlador [40]. . . . . . . . . . . . . . . 39 4.3. Modelo Relacional de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4. Vista pantalla principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.5. Vista selección categoŕıa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1. Popularidad del framework ReactJS en la comunidad desarrolladora [45]. . . . . . . 46 5.2. Popularidad del framework ReactJS para la creación de sitios web [46]. . . . . . . . 46 5.3. Preferencia de los diferentes lenguajes de programación en los últimos años [53]. . . 48 5.4. Top de los gestores de bases de datos preferidos en la comunidad desarrolladora [57]. 50 6.1. Implementación de componentes del Front en React. . . . . . . . . . . . . . . . . . . 51 6.2. Contexto del Front. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Definición de rutas Front. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4. Renderizado Front. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5. Estructura de archivos MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.6. Definición del Webhook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.7. Web App dentro del Chatbot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.8. Endpoints importantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.9. Modelo de tablas BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.10. Tablas Creadas Base de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.11. Conexión Base de Datos y Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.12. Diagrama Herramientas Desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.13. Diagrama Herramientas Despliegue. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.14. Vista proceso de Registro Tendero Parte III. . . . . . . . . . . . . . . . . . . . . . . 62 6.15. Vista proceso de Registro Tendero Parte IV. . . . . . . . . . . . . . . . . . . . . . . 62 6.16. Vista proceso Realizar pedido Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . 63 16 Índice de figuras 6.17. Vista proceso Realizar pedido Parte V. . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.1. Caso de prueba CP FUN 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Caso de prueba CP REG 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3. Caso de prueba CP PED 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4. Encuesta Usuario Tendero Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.5. Encuesta Usuario Tendero Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.6. Encuesta Usuario Tendero Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.7. Encuesta Usuario Tendero Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.8. Encuesta Usuario Tendero Parte V. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.9. Encuesta Usuario Tendero Parte VI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.10. Encuesta Usuario Tendero Parte VII. . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.11. Encuesta Usuario Proveedor Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.12. Encuesta Usuario Proveedor Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.13. Encuesta Usuario Proveedor Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.14. Encuesta Usuario Proveedor Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.15. Encuesta Usuario Proveedor Parte V. . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.1. Evidencias foto mapa Distri Romel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8.2. Evidencias logo y catalogo Distri Romel. . . . . . . . . . . . . . . . . . . . . . . . . 82 8.3. Evidencias pruebas con Tenderos y Proveedores. . . . . . . . . . . . . . . . . . . . . 84 8.4. Evidencia Metodoloǵıa Scrum Sprint I. . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.5. Evidencia Metodoloǵıa Scrum Sprint II. . . . . . . . . . . . . . . . . . . . . . . . . . 86 8.6. Evidencia Metodoloǵıa Scrum Sprint III. . . . . . . . . . . . . . . . . . . . . . . . . 87 8.7. Evidencia Metodoloǵıa Scrum Sprint IV. . . . . . . . . . . . . . . . . . . . . . . . . 88 8.8. Evidencia Metodoloǵıa Scrum Sprint V. . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.9. Evidencia Metodoloǵıa Scrum Sprint VI. . . . . . . . . . . . . . . . . . . . . . . . . 89 8.10. Evidencia Metodoloǵıa Scrum Sprint VII. . . . . . . . . . . . . . . . . . . . . . . . . 90 10.1. Requisitos Funcionales del. 1-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 10.2. Requisitos Funcionales del. 11-20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.3. Requisitos Funcionales del. 21-30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.4. Requisitos No Funcionales del. 1-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.5. Prototipo vista de inicio de Telegram. . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.6. Prototipo de inicio de conversación con el Chatbot. . . . . . . . . . . . . . . . . . . 103 10.7. Prototipo conversación Chatbot registro primera parte. . . . . . . . . . . . . . . . . 104 10.8. Prototipo conversación Chatbot registro segunda parte. . . . . . . . . . . . . . . . . 105 10.9. Prototipo conversación Chatbot registro finalizado. . . . . . . . . . . . . . . . . . . 106 10.10.Prototipo vista de inicio de Telegram. . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.11.Prototipo de inicio de conversación con el Chatbot. . . . . . . . . . . . . . . . . . . 108 10.12.Prototipo conversación Chatbot primera parte. . . . . . . . . . . . . . . . . . . . . . 109 10.13.Prototipo conversación Chatbot segunda parte. . . . . . . . . . . . . . . . . . . . . . 110 Índice de figuras 17 10.14.Prototipo vista selección productos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 10.15.Prototipo vista carrito de compras. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 10.16.Prototipo del pedido realizado con éxito. . . . . . . . . . . . . . . . . . . . . . . . . 113 10.17.Prototipo vista grupo Telegram proveedor. . . . . . . . . . . . . . . . . . . . . . . . 114 10.18.Prototipo vista pedidos - grupo Telegram proveedor. . . . . . . . . . . . . . . . . . . 115 10.19.Vista proceso de Inicio Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 10.20.Vista proceso de Inicio Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 10.21.Vista proceso de Inicio Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 10.22.Vista proceso de Inicio Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 10.23.Vista sección Ayuda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 10.24.Vista sección Contáctenos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 10.25.Vista proceso de Registro Tendero Parte I. . . . . . . . . . . . . . . . . . . . . . . . 122 10.26.Vista proceso de Registro Tendero Parte II. . . . . . . . . . . . . . . . . . . . . . . . 123 10.27.Vista proceso de Registro Tendero Parte III. . . . . . . . . . . . . . . . . . . . . . . 124 10.28.Vista proceso de Registro Tendero Parte IV. . . . . . . . . . . . . . . . . . . . . . . 125 10.29.Vista proceso Realizar pedido Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . 126 10.30.Vista proceso Realizar pedido Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . 127 10.31.Vista proceso Realizar pedido Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . 128 10.32.Vista proceso Realizar pedido Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . 129 10.33.Vista proceso Realizar pedido Parte V. . . . . . . . . . . . . . . . . . . . . . . . . . 130 10.34.Vista proceso Realizar pedido Parte VI. . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.35.Vista proceso Realizar pedido Parte VII. . . . . . . . . . . . . . . . . . . . . . . . . 132 10.36.Vista pedido recibido Proveedor Parte I. . . . . . . . . . . . . . . . . . . . . . . . . 133 10.37.Vista pedido recibido Proveedor Parte II. . . . . . . . . . . . . . . . . . . . . . . . . 134 10.38.Encuesta Usuario Tendero Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.39.Encuesta Usuario Tendero Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 10.40.Encuesta Usuario Tendero Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 10.41.Encuesta Usuario Tendero Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.42.Encuesta Usuario Tendero Parte V. . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 10.43.Encuesta Usuario Proveedor Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 10.44.Encuesta Usuario Proveedor Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . 141 10.45.Encuesta Usuario Proveedor Parte III. . . . . . . . . . . . . . . . . . . . . . . . . . . 142 10.46.Encuesta Usuario Proveedor Parte IV. . . . . . . . . . . . . . . . . . . . . . . . . . . 143 10.47.Caso de prueba CP FUN 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.48.Caso de prueba CP FUN 002. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.49.Caso de prueba CP FUN 003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 10.50.Caso de prueba CP FUN 004. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 10.51.Caso de prueba CP FUN 005. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 10.52.Caso de prueba CP FUN 006. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.53.Caso de prueba CP FUN 007. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.54.Caso de prueba CP REG 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 18 Índice de figuras 10.55.Caso de prueba CP PED 001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.56.Caso de prueba CP PED 002. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.57.Caso de prueba CP PED 003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.58.Caso de prueba CP PED 004. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.59.Caso de prueba CP PED 005. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.60.Caso de prueba CP PED 006. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Caṕıtulo 1 Descripción del Problema 1.1. Planteamiento del Problema A pesar de la reactivación económica que se ha venido dando en el páıs después de un largo periodo de pandemia y de los efectos del paro nacional que han afectado directamente al pequeño comercio,un problema que persiste es que las tiendas de barrio aún no se han podido recuperar económicamente. Según la Federación Nacional de Comerciantes (FENALCO), se tiene estimado que más de 11.000 tiendas de barrio pueden desaparecer [2], lo cual puede llegar a afectar más de un millón de familias y cerca de 1.75 millones de empleos que por lo general dependen de estos negocios, lo cual perjudica la economı́a del páıs, debido a su disminución en cuanto a productividad y aporte al desarrollo económico. De acuerdo con los tenderos que participaron en la encuesta realizada por FENALCO, algunos de los obstáculos a los cuales se han enfrentado los tenderos son la poca financiación que han obtenido por parte del gobierno, la falta de apoyo o comunicación con los proveedores, los altos costos por parte de sus intermediarios y el atraso tecnológico con el que cuentan. Por esta razón, poco a poco este gremio ha buscado acoger algunas iniciativas digitales que permitan evitar el cierre de algunos establecimientos que resultan ser claves para poder abastecerse [3]. Asimismo, se debe tener en cuenta que se ha generado un aumento en los precios de los productos debido a que a muchos proveedores de las tiendas de barrio, se les ha dificultado distribuir o elaborar los mismos. Es por esto, por lo que aún la mayoŕıa de estos negocios requieren cierto tipo de apoyo que les permita realizar un cambio o transformación en su negocio con el fin de poder mantenerlos a flote, logrando tener una mayor oferta digital y una mejor comunicación con sus clientes. Una de las grandes dificultades con la que se enfrentan los proveedores y las tiendas de barrio, es la comunicación, ya que esta resulta ser una herramienta clave tanto para el dueño del negocio como para sus clientes potenciales; dado que si se llega a dar algún caso en el que el tiempo de espera para los clientes sea muy largo, si no se les atiende sus llamadas, si no se les resuelven sus preguntas frecuentes, si el personal no está disponible en el momento o incluso si no se toma de manera adecuada la solicitud del cliente; esto, representará una pérdida de oportunidades que se podrá ver reflejada a futuro en la disminución de sus ventas, la pérdida de confianza de los clientes o el posible fracaso de un proyecto importante. Además, a medida que esto se repita, los clientes perderán poco a poco su confianza y v́ınculos con la empresa, debido al poco interés que se les demuestra por resolver sus problemas, lo que conlleva a que estos busquen soluciones en otra parte. Un estudio reciente por parte de Microsoft Colombia ha demostrado como muchas pequeñas empresas han logrado salir adelante con la implementación de nuevas tecnoloǵıas en sus negocios [4]. Entre estas tecnoloǵıas, se encuentra el desarrollo de páginas web o aplicaciones móviles, las cuales 20 Caṕıtulo 1. Descripción del Problema han permitido generar cierto comercio electrónico (e-commerce) para vender sus productos a través del internet. Mientras que, por otra parte, se tiene el comercio conversacional (c-commerce), el cual suele utilizar herramientas como lo son los asistentes virtuales (Chatbots) en las aplicaciones de mensajeŕıa instantánea, para poder realizar el proceso de compra/venta o resolución de preguntas frecuentes de manera automatizada. Sin embargo, un problema clave con el que se enfrenta muchas veces la comunicación de estos negocios, está relacionado con el diseño e interfaz de estas tecnoloǵıas, ya que, si el uso de esta resulta ser complicado o poco intuitivo para el usuario, éste optará por no utilizarla. A pesar de la evolución de los grandes supermercados, las tiendas de barrio siguen siendo el más importante medio de distribución y abastecimiento de los productos de la canasta familiar para los Colombianos [5]. Y aunque en la actualidad existen algunas tecnoloǵıas como SurtiApp[6] y Chiper[7] que han intentado aportar soluciones para establecer una comunicación directa entre proveedores y tiendas, no brindan un servicio personalizado y adaptado a las necesidades de la tienda de barrio t́ıpica colombiana por los motivos que se describen a continuación. Las soluciones existentes no tienen en cuenta que en las tiendas de barrio trabajan, en promedio, entre 1-3 personas [8] y éstas no cuentan con los recursos necesarios para acceder a un plan de datos postpago en su celular, mediante el cual puedan acceder a una aplicación web o móvil que se haya desarrollado. Adicionalmente, según el informe de Fenaltiendas (Programa Social de Apoyo al Tendero de Barrio), creado por la Federación Nacional de Comerciantes (FENALCO) hace más de 21 años, la edad del tendero promedio se encuentra entre los 43 y 44 años [9], lo cual refuerza el hecho de que esta labor la realizan principalmente personas mayores de edad que quizás no se encuentran muy familiarizadas con el uso de nuevas tecnoloǵıas, las cuales por lo general no cuentan con internet en su tiendas y están acostumbradas a realizar todo manualmente, Es por esto, que este público objetivo como lo demuestra la Asociación Colombiana de Empresas de Investigación de Mercados y Opinión Pública (ACEI) [10], por lo general solo hace uso de algunos canales de mensajeŕıa instantánea y redes sociales como lo son Facebook, Whatsapp e Instagram. Lo cual es muy importante tener en cuenta en el momento de pensar en una solución para sus problemas de comunicación. Por otro lado, se tiene que, los chatbots existentes que se pueden generar en plataformas como Twilio[11] y Cliengo[12], aunque permitiŕıan mejorar la comunicación entre los proveedores y las tiendas de barrio, no cuentan con una interfaz dentro de sus bots que sea fácil de utilizar por los tenderos, la cual permita realizar un pedido a un proveedor que cuente con distintos productos y categoŕıas de una manera efectiva. Actualmente algunos canales de chat han venido experimentando e implementando Apis en beta que permiten combinar dentro de su canal aplicaciones web con los bots tradicionales, lo cual permite explorar una nueva herramienta innovadora para los chatbots en la cual se pueda diseñar una interfaz que se ajuste a la necesidades planteadas anteriormente. La implementación de un Chatbot que cuente con una interfaz gráfica intuitiva en una plata- forma de mensajeŕıa instantánea resulta ser un reto llamativo, el cual buscará dar solución a los problemas mencionados anteriormente, dado que este se podrá adaptar a su modelo de negocio y a las necesidades del tendero. Además, este resultará ser mucho más rentable y fácil de utilizar por 1.2. Objetivos 21 cualquier persona, ya que estarán utilizando un software con el que ya se encuentran familiariza- dos. El cual, con la ayuda de la ingenieŕıa de software, permitirá mejorar la comunicación entre los distintos proveedores y tenderos, teniendo en cuenta sus necesidades y su cadena de suministros para poder dejar a un lado los intermediarios. 1.1.1. Formulación ¿Cómo diseñar e implementar un chatbot que permita mejorar la comunicación entre los pro- veedores y tiendas de barrio? 1.1.2. Sistematización ¿Cómo identificar las necesidades de los stakeholders? ¿Cómo diseñar un chatbot que satisfaga las necesidades de los stakeholders? ¿Cómo se implementará el chatbot? ¿Cómo validar los requisitos del chatbot desde el punto de vista funcional y de usabilidad? 1.2. Objetivos 1.2.1. Objetivo General Diseñar e implementar el prototipo de un chatbot que permita mejorar la comunicación entre proveedores y tiendas de barrio. 1.2.2. Objetivos Espećıficos Revisar las necesidades de los stakeholders para poder establecer los requisitos funcionales y no funcionales que se requieren. Diseñar la arquitectura, modelo de datos y elegir las herramientas que se utilizarán para desarrollar el chatbot. Desarrollar el chatbot teniendo en cuenta los requisitos y diseños planteados para este pro- yecto. Validar el chatbot desde el punto de vista funcional y de usabilidad, cumpliendo e implemen- tando los requisitos funcionales de acuerdo con lo planteado. 22 Caṕıtulo 1. Descripción del Problema 1.3. Justificación De acuerdo con las cifras obtenidas por el bolet́ın del primer trimestre del año 2022 a cargo del Ministerio de Tecnoloǵıas de la Información y las Comunicaciones (MinTIC)[13]. Se puede apreciar que Colombia cuenta con alrededor de 76 millones de ĺıneas de telefońıa móvil actualmente, de las cuales solo 18,2 millones de usuarios cuentan con un plan postpago, mientras que los 57,8 millones restantes cuentan con un plan prepago. Esto, considerando que la mayoŕıa de usuarios no son de estratos socioeconómicos altos o prefieren realizar recargas mı́nimas mensuales que les permita tener acceso a ciertas aplicaciones de mensajeŕıa instantánea para comunicarse, ya que estas no consumen datos, funcionan con conexión a alguna red wifi o incluso se dan gratis con la misma recarga. Sumado a esto, según las estad́ısticas de eMarketer [14], el uso de dispositivos móviles se ha vuelto esencial, ya que en primer lugar, alrededor del 45% de las compras de productos en ĺınea se realizan a través de estos dispositivos y en segundo lugar, cerca del 94.8% de usuarios entre los 16 y 64 años de edad que acceden a internet, lo hacen por medio de estos sistemas y pasan un promedio de 5 horas al d́ıa interactuando con ellos. Por lo cual, si se llega a proponer una aplicación web o móvil como solución del problema planteado, dicha solución no abarcaŕıa en su totalidad el público objetivo, ya que si los tenderos no cuentan con un plan de datos, no podŕıan descargar o acceder a la aplicación creada, ni hacer uso de la misma, lo cual seŕıa ineficiente. El proceso que realizan los proveedores para poder promocionar o vender sus productos a los tenderos, resulta ser muy tedioso ya que estos por lo general le pagan a un intermediario para que env́ıe a ciertos vendedores con una cartilla f́ısica de sus productos, como se puede evidenciar en la Figura 1.1, y que estos vayan de tienda en tienda a los barrios tomando los pedidos de cada uno de los tenderos, lo cual toma mucho tiempo para ambas partes e incluso no es competente, ya que este trabajo se podŕıa reemplazar con una tecnoloǵıa que permita agilizar el proceso y que mejore la comunicación entre ellos. Figura 1.1: Cartilla de productos, tomada de: Distri Romel S.A. La implementación de un chatbot para los proveedores de las tiendas de barrio puede ser de gran ayuda, ya que estos podrán interactuar de manera constante con los tenderos, las 24 horas del d́ıa, los 7 d́ıas a la semana, lo cual permitirá reducir el desabastecimiento a través de una buena 1.4. Delimitaciones y Alcances 23 comunicación, mientras mejoran continuamente la calidad de sus respuestas al cliente y logran mantener bajos costos para la empresa; dado que un chatbot cuenta con distintos casos de uso para los cuales puede ser implementado, entre ellos los más comunes y que aportan mayor valor a la empresa se encuentra la atención al cliente, su incorporación en un equipo de ventas y el comercio electrónico [15]. Entre las principales ventajas de un chatbot se encuentra la disminución de la carga operativa para los empleados, ya que este permite eliminar tareas tediosas que lleguen a consumir mucho tiempo, como lo pueden ser las preguntas frecuentes en búsqueda de alguna información o servicio de la empresa. Lo cual, permitirá a los empleados ejercer tareas más significativas y brindarle una mayor comodidad al cliente como se puede evidenciar en las encuestas de Statista realizadas a los encargados del servicio al cliente, en la cual comparten su opinión sobre la implementación de los chatbots. Obteniendo un 72%, de empleados que al trabajar en tareas más complejas sienten que están mejorando sus habilidades y generando un mayor impacto dentro de la compañ́ıa, llegando incluso a incrementar la satisfacción y productividad del 59% de los mismos [16]. La personalización y mejora en tiempos de respuesta que llegan a brindar los chatbots ha resultado ser un éxito rotundo, ya que después de todo, el marketing personalizado y un buen servicio al cliente garantizan buenos resultados. De acuerdo con encuestas realizadas por Accenture [17] y Epsilon [18], se reveló que un 91% de los consumidores eligen con mayor probabilidad marcas que ofrecen ofertas y recomendaciones personalizadas, obteniendo también que, es más probable que el 80% de estos realicen una compra si cuentan con una experiencia personalizada, como la que puede brindar un chatbot [19]. Muchas empresas que residen en Colombia como Tuya, Sura, Banco Falabella, Banco de Bogotá y Bancolombia se han visto beneficiadas con la implementación de los chatbots, dado que estos les han permitido gestionar las principales dudas o interacciones de los usuarios, de una manera más ágil y al alcance de todos. Esto, gracias a la evolución de la inteligencia artificial, la cual permite incluso llegar a simular con gran realismo ciertas conversaciones complejas [20]. Es tanto el valor que puede aportar a una empresa un chatbot que se estima incluso que los ahorros de costos por el uso de estos en la industria bancaria a nivel mundial para 2023 según Juniper Research será de alrededor de $ 7.3 billones, a medida que evolucione la experiencia automatizada del cliente [21]. Por lo tanto, con los avances que se tienen actualmente y los beneficios nombrados, se puede apreciar que es fundamental integrar las herramientas digitales, como lo son los chatbots, a las tiendas de barrio para poder mejorar la comunicación o interacción con sus proveedores, para aśı garantizar una experiencia personalizada que sea fácil de usar y genere valor para ambas partes. 1.4. Delimitaciones y Alcances La población objetivo será la ciudad de Cali. El sistema a desarrollar será implementado y puesto a prueba con un proveedor de la misma ciudad. Se hará uso de la plataforma de mensajeŕıa Telegram debido al crecimiento que ha tenido el 24 Caṕıtulo 1. Descripción del Problema canal actualmente como se puede evidenciar en [22] y a la facilidad de uso de sus API, ya que a diferencia de Whatsapp / Meta, Telegram no solicita la verificación de la empresa para trabajar con sus API. 1.4.1. Entregables Una vez finalizado el proyecto de grado se tiene como propósito entregar los siguientes ı́tems: Código fuente del proyecto. Documentación relacionada con el software. Documento de trabajo de grado. Caṕıtulo 2 Desarrollo del Proyecto 2.1. Marco de Referencia 2.1.1. Áreas Temáticas Las areas temáticas del proyecto son: Software and its engineering →Software creation and management →Designing software →Requirements analysis. Software and its engineering →Software creation and management →Designing software →Software design engineering. Software and its engineering →Software creation and management →Software development process management →Software development methods →Agile software development. Computing methodologies →Artificial intelligence →Natural language processing →Information extraction. Software and its engineering →Software creation and management →Software verification and validation →Software defect analysis →Software testing and debugging. Se pueden encontrar las diferentes áreas temáticas, de acuerdo con las categoŕıas de ACM en el siguiente enlace: (http://www.acm.org/about/class/ccs98-html). 2.1.2. Marco Teórico Para lograr desarrollar el proyecto que se está planteando, es necesario tener conocimiento de todos los conceptos que se van a tratar, entre ellos se encuentran los que abarca la ingenieŕıa de software, las metodoloǵıas ágiles para el desarrollo de software, la arquitectura de software, el diseño de este, tecnoloǵıas, frameworks que se utilizarán, etc. Por lo cual se mencionan algunos de estos conceptos clave que se deben tener en cuenta a continuación: Metodoloǵıas ágiles: los métodos ágiles universalmente dependen de un enfoque iterativo para la especificación, desarrollo y entrega de software, y principalmente fueron diseñados para apoyar al desarrollo de aplicaciones de negocio donde los requerimientos del sistema con normalidad cambian rápidamente durante el proceso de desarrollo. Están pensados para entregar el software funcional de forma rápida a los clientes, quienes pueden entonces proponer 26 Caṕıtulo 2. Desarrollo del Proyecto que se incluyan en iteraciones posteriores del sistema nuevos requerimientos en los mismos [23]. Además, el uso de este tipo de metodoloǵıas, permiten no solo mejorar la calidad del producto que se pretende entregar al final, sino que también estimulan el trabajo colectivo, permiten predecir resultados de una manera más fácil, minimizar los riesgos del proyecto, reducir costos e incluso llegar a brindar una mayor satisfacción al cliente [24]. Scrum: Es una de las metodoloǵıas ágiles más utilizadas en el mercado, se caracteriza por ser incremental e iterativa. Busca siempre estar en contacto con el cliente permitiendo la flexibilidad, efectividad y la comunicación constante durante el desarrollo. La planificación detallada se realiza sobre cortos espacios de tiempo (sprints), lo que permite una constante retroalimentación, que proporciona inspecciones simples y un ciclo de vida adaptable [25].Esta cuenta con ciertos pasos y roles que se deben cumplir en el proceso para poder lograr un objetivo en común, como se describen a continuación: Figura 2.1: Metodologia scrum: Fases de un sprint [26] Design thinking: Es una metodoloǵıa de resolución de problemas adaptado para la in- vestigación de problemas débilmente definidos, centrado en las personas, centrando en las posibilidades e impulsada por hipótesis de valor [27].Esta metodoloǵıa cuenta con 5 etapas importantes que son: • Descubrimiento: se define un reto (desaf́ıo), en este caso un problema de investigación 2.1. Marco de Referencia 27 espećıfica o intencional, al que se le denomina un desaf́ıo de diseño. El desaf́ıo debe ser abordable, comprensible, realizable y estar bien delimitado. • Interpretación: se busca generar conocimientos significativos a partir de lo que se observa, de las visitas de campo o una simple conversación con los objetos de estudio, pares o asesores. No es una tarea fácil ya que implica ordenar y juntar pensamientos hasta encontrar un punto de vista convincente y una clara orientación para la “ideación” o generación de ideas que posteriormente se reflejarán en un modelo de investigación. • Ideación: En esta etapa se desarrollan, no solo las ideas, sino que también se busca obtener una propuesta para generar el modelo de investigación, consolidar los objetivos generales y los espećıficos, aśı como las hipótesis de trabajo. Asimismo, se realiza una revisión de qué tan viable es la propuesta de investigación y la actualidad del tema elegido. • Experimentación: se construyen prototipos o modelos para hacer tangibles las ideas con el fin de poder aprender mientras se construyen y se comparten con otras personas; es una forma de aprender a través de la retroalimentación de otros, para poder seguir mejorando y refinando, las ideas o modelos de investigación. • Evolución: se define como el desarrollo del modelo de investigación. Incluyendo la plani- ficación de los próximos pasos, la comunicación de la idea y documentación del proceso. Es una oportunidad para poder planificar los próximos pasos en el proceso de investi- gación, socializar el tema y con ello construir comunidad con investigadores con temas afines. Principios de usabilidad: La usabilidad se refiere a la simplicidad con las que las perso- nas interactúan con una herramienta para alcanzar un objetivo en concreto. En cuanto al desarrollo web, es la encargada de describir en qué medida una aplicación web resulta fácil de usar para una persona, ya que, si esto se garantiza, los usuarios podrán tener una mejor experiencia para alcanzar sus objetivos dentro de la misma. Los principios de usabilidad, también llamados principios heuŕısticos, son una serie de 10 ideales y fundamentos planteados por Jakob Nielsen, una de las personas más respetadas en el ámbito mundial en cuanto a usabilidad web, estos principios permiten desarrollar productos que al tener en cuenta las necesidades y el comportamiento de los usuarios, logra tener un mayor grado de acogida entre ellos [28],[29]. Estos principios son: • Visibilidad del estado del sistema: Siempre se debe mantener informado al usuario de lo que está sucediendo en la web y hay que brindarle una respuesta en el menor tiempo posible. • Relación entre el sistema y el mundo real: Es importante que la página web o la aplicación utilice el idioma que el usuario entiende, incluyendo expresiones y vocabulario que le resulten familiares. La información presentada también debe seguir un orden coherente y debe ser fácil de comprender para el usuario. 28 Caṕıtulo 2. Desarrollo del Proyecto • Control y libertad del usuario: En caso de realizar alguna opción por error. El usuario debe poder deshacer o repetir una acción previamente realizada. • Consistencia y estándares: Es importante establecer convenciones lógicas y mante- nerlas siempre. Los usuarios no debeŕıan tener que preguntarse si diferentes palabras, situaciones o acciones significan lo mismo. Se recomienda seguir las convenciones de la plataforma y la industria. • Prevención de errores: Diseñar cuidadosamente las interfaces para lograr prevenir cualquier error que pueda cometer el usuario. • Reconocimiento antes que recuerdo: Es importante que en el diseño de un sitio web se muestren claramente las opciones y acciones disponibles, de manera que el usuario no tenga que recordar información entre distintas secciones o partes de este. • Flexibilidad y eficiencia de uso: El sitio web debe estar preparado para todo tipo de usuario, desde los más novatos hasta los más experimentados. • Diseño estético y minimalista: Es importante evitar incluir información irrelevante en las páginas web para no distraer al usuario y evitar que tenga una experiencia negativa durante su navegación. • Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores: Se debe buscar que todos los mensajes de error que puedan aparecer estén expresados en un lenguaje entendible por todos, no por códigos. • Ayuda y documentación: Aunque estos principios intentan siempre que el usuario no tenga que recurrir a un tipo de ayuda o documentación, se recomienda brindar ciertas ayudas a los usuarios para que estos puedan llevar a cabo sus tareas. Técnica de recolección de la información enfoque cualitativo: Recolección de datos, pero sin utilizar la medición numérica y el análisis estad́ıstico. Interpreta la información utili- zando instrumentos espećıficos, con el fin de establecer preguntas de investigación, hipótesis, generar teoŕıas y conocimientos nuevos o novedosos durante el proceso de interpretación. En- tre estas técnicas de recolección de información se encuentran la observación, las entrevistas, las técnicas proyectivas y los grupos focales [30]. Estructura de Software y Arquitectura: Se refiere a la manera en la que se encuentran organizados los componentes que modelan un programa informático denominado como soft- ware, haciendo uso de distintos patrones o gúıas que ayudan a los desarrolladores, analistas y demás cargos relacionados, a cumplir con los requerimientos de una aplicación, dividiendo el software en partes lógicas y funcionales que se relacionan entre śı [31]. • Patrón de diseño: son modelos que funcionan como una gúıa para dar soluciones a problemas comunes que se pueden presentar en el desarrollo de software y otros ámbitos relacionados como el diseño de interacción o interfaces [32]. 2.1. Marco de Referencia 29 • Diseño de interfaz de usuario: Se encarga de garantizar una efectiva interacción entre el humano y la máquina, manteniendo unos principios como el aprendizaje, la familiaridad del usuario y la consistencia, entre otros. API (Application Programming Interfaces): Es un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre dos aplicaciones de software a través de un conjunto de reglas [33]. Chatbot: es un programa informático que permite procesar y simular conversaciones huma- nas usando el procesamiento del lenguaje natural, ya sea de manera escrita o hablada, para permitir a los humanos interactuar con dispositivos digitales como si se estuvieran comuni- cando con una persona real con disponibilidad 24/7. Es una tecnoloǵıa que permite al usuario mantener una conversación a través de un software que puede llegar a integrarse en algún sistema de mensajeŕıa determinado, como, por ejemplo: Facebook, Whatsapp, Telegram, etc. Los chatbots pueden ser tan simples como programas que responden a consultas sencillas con una sola ĺınea de texto o tan complejos como lo son los asistentes digitales que pueden llegar a evolucionar y aprender de manera personalizada, a medida que van reuniendo y procesando mayor cantidad de información [34]. Webhook: Es un mecanismo de comunicación en el desarrollo de aplicaciones web que se basa en el protocolo HTTP para que dos interfaces de programación puedan comunicarse de manera automatizada, permitiendo enviar datos en tiempo real a otra aplicación cuando ocurre un evento espećıfico. Asimismo, un webhook permite ir recibiendo los datos de manera asincrónica de otra aplicación cuando sea necesario generalmente mediante un método POST a la URL predefinida [35]. Comercio Conversacional (C-Commerce): Hace referencia a cualquier clase de conver- sación que se puede llegar a tener en tiempo real entre los distintos clientes y marcas, con el fin de adquirir o vender, tanto un producto, como un servicio, con el fin de llevar a cabo una transacción; haciendo uso de herramientas digitales como las aplicaciones de mensajeŕıa instantánea, ya sea mediante chatbots, inteligencia artificial o personas reales. Lo cual per- mite tener ciertas ventajas tales como brindar un servicio más eficaz al cliente por medio de la automatización de las conversaciones, minimizar ciertas barreras que puedan existir en el momento de efectuar una compra e incluso llegar a influir en las distintas audiencias que pueden formar parte del mercado objetivo [36]. Teniendo en cuenta lo planteado anteriormente se utilizará como metodoloǵıa de desarrollo ágil, la metodoloǵıa Scrum, para el cual se proyectarán 6 sprints, en donde cada sprint será un trabajo mensual con sus respectivas reuniones y pruebas. Además, se hará uso de la ingenieŕıa de software para realizar un levantamiento de requerimientos en el momento en que se recolecta la información por medio de entrevistas a los distintos stakeholders. Kits de desarrollo: 30 Caṕıtulo 2. Desarrollo del Proyecto • React.js: Es una biblioteca Javascript de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página. Es mantenido por Facebook y la comunidad de software libre. Ver [37] • Flask: es un framework minimalista escrito en Python que permite crear aplicaciones web rápidamente y con un mı́nimo número de ĺıneas de código. Está basado en la espe- cificación WSGI de Werkzeug y el motor de templates Jinja2 y tiene una licencia BSD. Ver [38] • Telegram: Es una popular plataforma de mensajeŕıa y VOIP (Voz sobre protocolo de internet), La aplicación está enfocada en la mensajeŕıa instantánea, el env́ıo de varios archivos y la comunicación en masa. Es muy utilizada ya que ofrece algunas funciones mejoradas en cuanto a privacidad y cifrado de mensajes, aśı como soporte para funciones de grandes grupos de chat y es multiplataforma. Ver [39] 2.1.3. Trabajos Relacionados Surtiapp: Es una plataforma tecnológica gratuita que fue desarrollada en Colombia y fun- ciona como intermediaria prestando servicios únicamente de abastecimiento a tiendas, dis- tribuyendo productos para el hogar perecederos y no perecederos. Se puede ver que ofrecen un servicio a domicilio a través de su aplicación web y móvil. El software planteado en este trabajo de grado se diferencia de “Surtiapp” debido a que cuenta con un enfoque distinto, el cual busca apoyar a distintas tiendas de barrio y a sus proveedores, con el fin de brindar un apoyo a estos sectores, para aśı lograr reducir el desabastecimiento y aportar a la economı́a de nuestro páıs [6]. Chiper: Es una aplicación móvil gratuita que fue desarrollada en Colombia y funciona como intermediaria prestando el servicio de abastecimiento a tiendas y generando empleo a aquellas personas que estén interesadas en generar ingresos ayudando a distribuir sus productos en sus domicilios. Al igual que “Surtiapp”, cuenta con un enfoque distinto y distribuyen los mismos tipos de productos para el hogar. El software planteado en este trabajo de grado se diferencia de “Chiper” y de “Surtiapp”, dado que se busca a través del procesamiento natural del lenguaje crear un chatbot que funcione como un C-commerce con el fin de poder facilitar la comunicación e interacción entre los distintos stakeholders al brindar estos servicios [7]. Twilio: Es una una plataforma de comunicaciones desarrollada en San Francisco, California, la cual permite desarrollar aplicaciones que hagan y reciban llamadas, mensajes de texto, elaboren funciones de comunicación y registro, usando APIs, propias del servicio web; con el fin de ayudar a las empresas a vender más gracias al internet, implementando entre sus tecnoloǵıas los chatbots.Una gran diferencia con el software que se quiere implementar en este trabajo de grado, es que sus chatbots no cuentan con una interfaz grafica integrada que resulte ser intuitiva para cualquier usuario y que además permita que estos realicen su pedido a través de ella [11]. 2.2. Metodoloǵıa 31 Cliengo: Es una plataforma tecnológica que fue desarrollada en Argentina, la cual brinda soluciones digitales a sus clientes a través de los chatbots que estos manejan, para distintas aplicaciones de mensajeŕıa instantánea como Whatsapp, Facebook e Instagram, siguiendo un enfoque parecido al que se requiere para este trabajo de grado, pero con la diferencia de que estos se basan en un marketing B2C (Business to Consumer), cuando lo que se necesita realmente es un marketing B2B (Business to Business), el cual tenga en cuenta la experiencia que se le brinda al usuario y la cadena de suministro que existe entre las tiendas de barrio y sus proveedores. Asimismo, al igual que “Surtiapp”, sus chatbots no cuentan con una interfaz gráfica intuitiva para el usuario[12]. 2.2. Metodoloǵıa 2.2.1. Tipo de Estudio La metodoloǵıa de investigación del proyecto es exploratoria, debido a que el éxito de este depende de la comodidad, usabilidad y satisfacción por parte de los stakeholders en el momento en que este sea puesto a prueba. Lo cual, brindará una alternativa innovadora que teniendo en cuenta los requerimientos, permitirá mejorar la comunicación de los proveedores y las tiendas de barrio, logrando reducir el desabastecimiento e impulsando la economı́a del páıs. 2.2.2. Actividades Objetivo 1: Identificar plataformas o aplicaciones con enfoques similares, para revisar las necesidades de los diferentes sectores haciendo uso de la ingenieŕıa de software para poder establecer los requisitos funcionales y no funcionales que requiere el proyecto. • Buscar e identificar las diferentes plataformas o aplicaciones que poseen caracteŕısticas similares a la propuesta planteada. • Realizar consultas e investigaciones pertinentes para verificar procesos de las funciones que realizan dichas plataformas o aplicaciones. Objetivo 2: Definir las estrategias y protocolos para lograr mejorar la comunicación entre los stakeholders de la solución tecnológica planteada. • Analizar los modelos y patrones usados para garantizar una mejor comunicación entre los stakeholders. • Identificar y extraer toda la información relevante del modelo seleccionado para el desa- rrollo del proyecto. • Identificar y extraer los requisitos necesarios para el desarrollo del proyecto. • Identificar y seleccionar las métricas para la evaluación del progreso de este. Objetivo 3: Diseñar los diferentes componentes que se utilizarán. 32 Caṕıtulo 2. Desarrollo del Proyecto • Diseñar la arquitectura de software que mejor se acomode a los requisitos planteados. • Diseñar un modelo de datos que recoja las entidades y atributos planteados en los re- quisitos. Objetivo 4: Desarrollar la solución tecnológica para que se ajuste a los requisitos planteados para este proyecto. • Implementar los diseños previos teniendo en cuenta los requisitos establecidos. • Desarrollar el modelo de datos. • Desarrollar el código correspondiente. • Integración del proyecto Objetivo 5: Analizar los resultados del proyecto • Realizar pruebas de usuario pertinentes. • Realizar encuestas de satisfacción a los stakeholders. • Realizar reuniones. • Realizar correcciones y ajustes. 2.3. Resultados Esperados Documento de trabajo de grado que incluye todos los pasos del diseño, desarrollo y pruebas del software. Chatbot en su fase beta de desarrollo. 2.4. Cronograma Cronograma por semana incluyendo las actividades descritas en la Sección 2.2.2. 2.5. Recursos 33 Figura 2.2: Cronograma de actividades del proyecto. 2.5. Recursos 2.5.1. Humanos Juan Pablo Garcia (Director de Proyecto de Grado), Director Programa de Innovación por Diseño red SUGAR. • Ingeniero de Sistemas y Computación. Pontificia Universidad Javeriana. Cali, 2008. • ME310 Global Team-Based Design Innovation with Corporate Partners - Design Thin- king & Entrepreneurship. Stanford, 2008. • Maǵıster en Administración. Universidad Icesi. Cali, 2013. • Diplomado Educación en Ingenieŕıa. Pontificia Universidad Javeriana. Cali, 2016. Julian Paredes Conde: Estudiante de pregrado de la Pontificia Universidad Javeriana Cali. 34 Caṕıtulo 2. Desarrollo del Proyecto 2.5.2. Técnicos Equipos y materiales necesarios para la realización del proyecto: Zoom: Plataforma de videoconferencias para realizar las reuniones. Brindado por la Univer- sidad Javeriana Cali. Computador proporcionado por el autor del proyecto. Acceso a internet. Biblioteca de la universidad Javeriana Cali. 2.5.3. Presupuesto Presupuesto que incluye los costos de los recursos humanos y técnicos para llevar a cabo el proyecto: Figura 2.3: SMMLV 2022 Figura 2.4: Costo total del proyecto Figura 2.5: Costo de recursos Humanos Figura 2.6: Costo de recursos Fisicos Caṕıtulo 3 Obtención y Análisis de Requisitos 3.1. Estrategias Implementadas para la Educción de Requisitos Lluvia de ideas: Se llevó a cabo una sesión de lluvia de ideas, con el fin de generar una serie de preguntas que permitieran identificar los requisitos necesarios. Estas preguntas se plantearon a los distintos stakeholders, quienes brindaron explicaciones, respuestas o sugerencias. Casos de Uso: Se utilizó un diagrama de casos de uso (Véase en la Figura 3.1) para examinar las distintas acciones que pueden realizar los usuarios y, a partir de esto, se obtuvieron más requisitos que permiten modelar de manera más precisa el comportamiento de los distintos roles que conforman el sistema. Prototipado: Se desarrollaron varios prototipos utilizando la herramienta ”Balsamiq-mockups”, con el objetivo de identificar las funcionalidades que no se hab́ıan contemplado y, de esta ma- nera, poder modelar con mayor exactitud el comportamiento del Chatbot. 3.2. Descripción general del Chatbot El objetivo del Chatbot es mejorar la comunicación y la relación entre los proveedores y las tiendas de barrio, a través de diversas funcionalidades que conectan a ambos tipos de usuarios. Para lograr esto, el Chatbot implementa distintas estrategias para identificar los requisitos necesarios y tener una visión más clara de cómo debe funcionar. Cabe destacar que el Chatbot funciona mediante dos perfiles previamente definidos, que serán: 1. Usuario tendero, quien podrá solicitar información de contacto, ayuda e incluso registrarse, para posteriormente realizar un pedido a un proveedor. 2. Usuario proveedor, quien podrá visualizar los productos solicitados por los tenderos para aśı poder despachar su pedido. El Chatbot debe permitir a un tendero realizar un pedido de manera correcta a un proveedor, lo cual implica que este debe contar con una interfaz intuitiva que permita al tendero interactuar entre las distintas acciones disponibles. Del mismo modo, el Chatbot debe permitir una administración sencilla de los datos de entrada para su regulación y visualización por parte del proveedor, lo que implica que el mismo debe contar con una herramienta que permita al proveedor observar y/o modificar los distintos datos presentes. 36 Caṕıtulo 3. Obtención y Análisis de Requisitos 3.3. Diagrama de casos de uso Este diagrama muestra el comportamiento de todos los objetos involucrados, su estructura y relaciones entre śı. A través de este se pretende representar el funcionamiento del chatbot para los usuarios tenderos y el proveedor. Figura 3.1: Diagrama de casos de uso. 3.4. Requisitos Con el propósito de establecer las pautas y normas para el correcto funcionamiento del “Chat- bot para mejorar la comunicación entre tiendas de barrio y sus proveedores”, se establecieron los requisitos funcionales y no funcionales, obtenidos a través del uso de diversas técnicas de educción de requisitos, planteadas anteriormente en el marco teórico del presente documento. Para ver al detalle los requisitos planteados, es necesario revisar la sección 10.1 del caṕıtulo de Anexos. Caṕıtulo 4 Diseño del Software 4.1. Introducción Este caṕıtulo explicará el diseño del software construido para este proyecto. Empezando con un diagrama de flujo, el cual permite representar y visualizar una secuencia de pasos o actividades que se llevan a cabo en el proceso de la realización de un pedido desde la perspectiva de un tendero. Siguiendo con la arquitectura del chatbot, pues esta representa una parte fundamental del mismo; argumentando la escogencia de su tipo. Continuando con el diagrama de la base datos, el uso que se le dará en el software, su naturaleza y, por qué fue escogida para este proyecto. Para finalmente mostrar los prototipos realizados que se tendrán en cuenta para el desarrollo del Chatbot. 4.2. Diagrama de Flujo: A continuación, en la Figura 4.1, se observa el diagrama de flujo mediante el cual se pretende comprender, modelar o reflejar, de manera visual, una serie de acciones o tareas que se realizan para completar, en este caso, la realización de un pedido a un proveedor por parte de un tendero mediante una conversación que se lleva a cabo con el Chatbot planteado en Telegram. Este tipo de diagramas se emplean para representar y examinar de forma más precisa y sencilla los procedi- mientos existentes, lo que facilita la identificación de dificultades y oportunidades de mejora en el flujo de trabajo. 38 Caṕıtulo 4. Diseño del Software Figura 4.1: Diagrama de Flujo. 4.3. Arquitectura del Chatbot 39 4.3. Arquitectura del Chatbot 4.3.1. Criterios de elección Como punto de partida en el diseño de la arquitectura, se escogieron los siguientes atributos de calidad de acuerdo con los requisitos no-funcionales: Rendimiento Disponibilidad Mantenibilidad Estos atributos cumplen con la mayoŕıa de los requisitos no funcionales mencionados en la Figura 10.4 del caṕıtulo de Anexos, que son RNF-2, RNF-3 y RNF-5, que se refieren a los tiempos de respuesta esperados para realizar ciertas funciones, la necesidad de una alta disponibilidad del software y la facilidad de mantenimiento. Teniendo en cuenta que estos atributos son esenciales para garantizar el correcto funcionamiento del Chatbot a desarrollar. 4.3.2. Arquitectura seleccionada Teniendo en cuenta los criterios mencionados anteriormente, se llegó a la conclusión de que la arquitectura MVC (Modelo–vista–controlador) seŕıa la elegida para realizar el proyecto del Chatbot debido a los grandes beneficios que esta puede llegar a aportar. Figura 4.2: Diagrama patrón de diseño Modelo-Vista-Controlador [40]. En primer lugar, en cuanto a la disponibilidad, al poder tener los componentes de una manera independiente, se puede dar una solución rápida en el caso de que ocurra un fallo en alguno de los elementos de esta arquitectura. 40 Caṕıtulo 4. Diseño del Software En segundo lugar, como se puede apreciar en la Figura 4.2, la separación de responsabilidades entre las diferentes capas de la aplicación proporciona más modularidad y flexibilidad en el diseño. En particular, la capa del modelo maneja la lógica de negocios, la capa de la vista se encarga de la interfaz del usuario y la capa del controlador actúa como intermediario entre las otras dos capas. Además, la arquitectura MVC permite una mayor reutilización del código, lo que reduce el tiempo y el esfuerzo necesarios para desarrollar la aplicación. También facilita el mantenimiento y evolución de la aplicación a lo largo del tiempo, ya que los cambios de la lógica de negocio se pueden realizar en la capa del modelo sin afectar a la vista o el controlador. Por último, la arquitectura MVC permite una mayor escalabilidad de la aplicación y una mejor distribución de la carga de trabajo entre diferentes componentes de la aplicación, lo que puede mejorar el rendimiento y la capacidad de respuesta del chatbot. 4.4. Modelo de datos 41 4.4. Modelo de datos Para gestionar el flujo de información en este proyecto, se utilizó una base de datos relacional debido a su eficacia en el manejo de datos. Puesto que, un sistema de gestión de bases de datos relacional, como lo es PostgreSQL, es capaz de almacenar fácilmente cada tipo de dato y minimizar la presencia de datos vaćıos. La Figura 4.3 muestra el modelo relacional de la base de datos del Chatbot. Dentro de la base de datos relacional, las tablas principales son: Figura 4.3: Modelo Relacional de Datos. Productos: almacena información relevante de los productos con los que cuenta un Proveedor en su inventario. Clientes: almacena la información personal y datos relevantes de los tenderos. Pedidos: almacena la identificación del cliente y los datos relevantes de un pedido. ProductosxPedido: cumple la función de una tabla intermedia que permite almacenar y asig- nar los distintos productos seleccionados previamente a un pedido por medio de su id. 4.5. Prototipo Se utilizó la herramienta ”Balsamiq Mockups”[41] para crear un prototipo del Chatbot, con el objetivo de reunir todas las caracteŕısticas especificadas en los requisitos y obtener un modelo que se asemeje de manera precisa al Chatbot final que se pretende desarrollar. 42 Caṕıtulo 4. Diseño del Software Figura 4.4: Vista pantalla principal. Figura 4.5: Vista selección categoŕıa. Es necesario revisar la sección 10.2 del Caṕıtulo de Anexos para obtener más información sobre los prototipos o ”mockups”que se han desarrollado durante la fase de diseño. Esta sección contiene documentación de todos los prototipos que se han desarrollado antes de empezar a trabajar en el software, y la sección 10.3, donde están las vistas finales que comprende el software. 4.5. Prototipo 43 4.5.1. Aprendizajes Posteriormente a la realización de los prototipos planteados del Chatbot en Telegram, se decidió mostrar los mismos a los stakeholders con el fin de poder recibir una primera retroalimentación, la cual fue muy importante para poder continuar desarrollando el Chatbot de acuerdo con sus necesidades. Por la parte de los Tenderos se obtuvo la recomendación de incluir un botón de contacto que permita al usuario recibir los datos relevantes de su proveedor como lo son la dirección, el correo, teléfonos, redes sociales, etc. Con el fin de poder comunicarse con éste en caso tal de que sea requerido. Asimismo, se recomendó que, en la sección de ayuda, se cuente con alguna ayuda audiovisual (video) que explique el paso a paso de cómo se realizan tanto el proceso de registro, como el de realizar un pedido, lo cual facilitará su proceso de aprendizaje para poder interactuar con el Chatbot. Por la parte de los Proveedores se obtuvieron dos recomendaciones muy valiosas, la primera de ellas es la conexión de la base de datos con alguna herramienta similar a Excel, con el fin de que los Proveedores en un futuro puedan llegar a visualizar y manipular los distintos datos que se están almacenando, esto dado que la mayoŕıa de ellos no cuentan con los conocimientos para acceder a una base de datos robusta a la cual le puedan realizar distintas consultas de acuerdo con su necesidad. La segunda recomendación, tiene más relación con la parte de la interfaz gráfica de la Web App del Chatbot con la que va a interactuar el Tendero, con su funcionalidad y con la experiencia del usuario, en la cual se propuso que al momento de realizar un pedido, debeŕıa de existir una pantalla de carga mientras se termina de completar el proceso del pedido, la cual mantenga informado al usuario de lo que está sucediendo, lo cual se alinea con los principios de usabilidad planteados anteriormente en el marco de referencia. Caṕıtulo 5 Tecnoloǵıas Involucradas en el Desarrollo del Chatbot 5.1. Introducción En este caṕıtulo se explican las razones tomadas con relación a la elección de las distintas tecnoloǵıas utilizadas para desarrollar el Chatbot. El caṕıtulo se divide en tres secciones: frontend, backend y bases de datos. Estas elecciones se justifican teniendo en cuenta la naturaleza de la arquitectura y el enfoque del proyecto. 5.2. Frontend Para el desarrollo de las vistas con las que va a interactuar el usuario dentro del Chatbot, se optó por una tecnoloǵıa que fuera capaz de cumplir con los requisitos funcionales, no funcionales y de calidad especificados anteriormente, es por esto, que se seleccionó el framework de JavaScript creado por Facebook, ReactJS [42]. ReactJS es una opción recomendable, debido a su eficiencia al utilizar la herramienta del ”Vir- tual DOM”, lo que permite actualizar solo algunos componentes o partes de la página, en lugar de recargar toda la página, lo que lo hace muy rápido y eficiente en términos de rendimiento para aplicaciones de una sola página. Además, es muy flexible y se puede integrar fácilmente con otros frameworks y bibliotecas, lo que lo hace fácil de usar junto con otras tecnoloǵıas que pueda necesitar el proyecto. Otro beneficio de usar ReactJS es que como este utiliza componentes para dividir la interfaz de usuario en piezas pequeñas y reutilizables, permite simplificar el proceso de actualiza- ción y mantenimiento del código, logrando una mayor eficiencia en la creación de aplicaciones al construir un gran número de componentes reutilizables para diferentes páginas o secciones [43]. A diferencia de otros frameworks, se puede decir que ReactJS es bastante seguro debido a la manera que está diseñado, ya que este protege sus aplicaciones de los ataques XSS (cross-site scripting) que pueden llegar a realizar para intentar extraer datos de un usuario [44]. 46 Caṕıtulo 5. Tecnoloǵıas Involucradas en el Desarrollo del Chatbot Figura 5.1: Popularidad del framework ReactJS en la comunidad desarrolladora [45]. Figura 5.2: Popularidad del framework ReactJS para la creación de sitios web [46]. Por último, ReactJS tiene una gran comunidad de desarrolladores que trabajan constantemente en nuevas herramientas, bibliotecas y soluciones para diferentes problemas que pueden surgir en el desarrollo del proyecto. Como se puede apreciar en la Figura 5.1 y 5.2, el framework ha generado 5.3. Backend 47 un gran impacto en la comunidad de programadores debido a su curva de aprendizaje, aśı como su rendimiento excepcional, es por esto por lo que hoy en d́ıa aún se puede evidenciar la continua escogencia de esta tecnoloǵıa para diferentes desarrollos de sitios web demostrando ser un framework bastante competitivo y popular en la comunidad desarrolladora [47]. 5.3. Backend Teniendo en cuenta los requisitos funcionales y no funcionales planteados, se decidió utilizar la plataforma de mensajeŕıa Telegram para la creación del Chatbot, esto debido a que Telegram, a diferencia de otras aplicaciones como WhatsApp, cuenta con una API bien documentada que facilita su integración con una aplicación web (WebApp) que permite a los usuarios interactuar directamente con el Chatbot, por lo que ofrece una amplia gama de caracteŕısticas avanzadas y personalizables para los Chatbots, como por ejemplo, la creación de bots con múltiples idiomas, bots de encuestas, bots de juegos, etc. Asimismo, Telegram cuenta con un cifrado de extremo a extremo y medidas de seguridad adicionales que permiten evitar el uso malintencionado de los bots para proteger la privacidad de los usuarios [48]. Luego de indagar entre los distintos lenguajes de programación que tienen compatibilidad con la API de Telegram para la creación de un Chatbot [49], se optó finalmente por utilizar la libreŕıa pyTelegramBotAPI [50] de Python para la realización de este proyecto. Se escogió Python porque es un lenguaje de programación que cuenta con una sintaxis sencilla y fácil de leer, lo cual facilitará la creación y el mantenimiento de los bots que se puedan crear. Sumado a esto, Python cuenta con una amplia variedad de bibliotecas y módulos que permiten su integración con otros servicios, permitiendo su acceso a servicios web y bases de datos como por ejemplo SQL para almacenar información del bot que pueda resultar relevante. Por último, cabe destacar que Python, gracias a su versatilidad, cuenta con una gran comunidad activa de desarrolladores que comparten su conocimiento y brindan ayuda por medio de tutoriales o en distintos foros como Stack Overflow, por lo cual puede ser de gran ayuda por si en el desarrollo del proyecto surge algún inconveniente o duda [51], la Figura 5.3 muestra como Python impulsa a los diferentes desarrolladores a buscar Python después de tener un primer acercamiento básico en comparación con otros lenguajes de programación [52]. 48 Caṕıtulo 5. Tecnoloǵıas Involucradas en el Desarrollo del Chatbot Figura 5.3: Preferencia de los diferentes lenguajes de programación en los últimos años [53]. En el momento de elegir un lenguaje de programación, es importante considerar también un framework que este pueda ofrecer, ya que estos proporcionan un entorno diseñado para simplificar el proceso de programación, puesto que incluyen diversos módulos y libreŕıas con funciones ya implementadas, lo que permite ahorrar tiempo y esfuerzo al crear el código necesario. Además, el uso de un framework puede ayudar significativamente en la estructuración de la lógica de la aplicación y en la conexión con una base de datos. Teniendo en cuenta lo anteriormente planteado y después de investigar minuciosamente sobre la manera en que se va a desarrollar el Chatbot, teniendo en cuenta los requisitos, la arquitectura MVC planteada y que este se comunicara con la API de Telegram por medio de un Webhook en el Backend, se decidió utilizar el framework de Flask, puesto que este es completamente compatible con el patrón MVC y permite realizar un buen manejo de las rutas por medio del controlador. Sumado a esto, se tiene que Flask es un framework minimalista que resulta ser altamente personalizable y flexible, ya que se puede integrar con distintas bibliotecas, extensiones y herramientas que permiten incrementar sus funciones, sin dejar de lado la rapidez y su buen desempeño [54]. Asimismo, Flask no requiere de una infraestructura con un servidor web para la realización de pruebas, dado que este cuenta con uno propio que permite ir observando los resultados que se van obteniendo, lo cual permite agilizar este proceso. Por otro lado, se tiene que Flask cuenta con una curva de aprendizaje rápida dado que cuenta con una excelente documentación que es fácil de seguir y entender, lo cual ha permitido crear una gran comunidad de desarrolladores muy activa, lo que significa que existen muchos recursos y herramientas disponibles que permitirán ayudar en el proceso de desarrollo de la lógica del Chatbot. 5.4. Base de Datos 49 5.4. Base de Datos Con respecto al almacenamiento de los datos con los que trabajará el Chatbot, se optó por usar PostgreSQL, el cual es un sistema de gestión de bases de datos relacional (RDBMS). Esta herramienta manejará: Datos básicos del usuario Tendero que se registra o comunica con el Chatbot. Datos relevantes de los productos que ofrece un Proveedor. Datos necesarios del pedido solicitado por parte del Tendero al Proveedor. Se decidió escoger una base de datos relacional debido a la sencillez que este modelo brinda para permitir manejar grandes cantidades de datos y soportar un alto rendimiento, ya que gracias a su estructura organizada, por medio del lenguaje SQL (Structured Query Language), se pueden realizar distintas consultas para relacionar o manipular los datos de las distintas tablas que se puedan llegar a tener, brindando también una gran flexibilidad y escalabilidad que permitirá asegurar que los datos manejados sean precisos y coherentes [55]. PostgreSQL es un sistema de gestión de bases de datos relacional (RDBMS) robusto, de código abierto y sofisticado que puede resultar beneficioso en el desarrollo de un Chatbot que requiere almacenar y acceder a información de manera eficiente, puesto que este ofrece caracteŕısticas avan- zadas como soporte para consultas complejas y transacciones ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) que garantizan que las transacciones de la Base de Datos se procesen de una manera fiable. Asimismo, PostgreSQL es conocido por manejar grandes volúmenes de datos y altas cargas de trabajo, permitiendo el almacenamiento y consulta de varios tipos de datos, como texto, imágenes e incluso JSON, por lo que puede ofrecer una gran flexibilidad y un rendimiento sólido [56]. Por último, PostgreSQL, según las encuestas realizadas anualmente por Stack Overflow demuestra ser la primera opción a nivel de la comunidad desarrolladora, donde el 46% de casi 49.000 programadores prefiere utilizar este gestor sobre otros existentes (Véase en la Figura 5.4). 50 Caṕıtulo 5. Tecnoloǵıas Involucradas en el Desarrollo del Chatbot Figura 5.4: Top de los gestores de bases de datos preferidos en la comunidad desarrolladora [57]. Caṕıtulo 6 Implementación del Software 6.1. Proceso de Desarrollo - Frontend Debido al buen proceso de selección del framework de desarrollo para la parte “Frontend” del Chatbot propuesto, se podŕıa decir que no hubo complicaciones al respecto. Dado que, tanto la instalación como la implementación del código en React fue sencilla y se adapta muy bien a los requisitos planteados anteriormente, ya que no se presentaron mayores dificultades en la creación de la interfaz del catálogo de productos del Proveedor y el carrito que permite ir almacenando lo que se va a pedir por parte del Tendero, esto gracias a que React cuenta con una amplia variedad de documentación, bibliotecas y herramientas disponibles; como por ejemplo los distintos “hooks” que permiten manipular o reutilizar componentes por medio de funciones, sin necesidad de usar clases. A continuación, se mostrarán algunas secciones importantes del código en “React” que permi- tieron el correcto funcionamiento del Frontend del Chatbot: Figura 6.1: Implementación de componentes del Front en React. Como se puede apreciar en la Figura 6.1, se crean distintos componentes estructurados haciendo 52 Caṕıtulo 6. Implementación del Software uso de una extensión de la sintaxis de JavaScript denominada JSX, la cual permite crear código con una sintaxis muy similar al HTML, mezclándolo con la lógica y demás funciones que ofrece JavaScript, Facilitando aśı el desarrollo de los componentes para la parte del Front. Asimismo, se puede apreciar que para darle estilos a cada uno de los componentes se hace uso de SCSS, el cual es una extensión o procesador CSS (Cascading Style Sheets), que permite generar hojas de estilo, añadiéndoles caracteŕısticas que no tiene CSS, como pueden ser las variables, funciones, herencia, etc. En los componentes creados se cuenta con el componente Home, el cual va a renderizar la página principal en la que se muestran los distintos productos con los que cuenta el proveedor, haciendo uso del componente Card, el cual es una carta que muestra una imagen del producto junto con su descripción, precio y un botón para añadir el producto al carrito. Este funciona en conjunto con la función Products que es la que permite listar y filtrar las distintas categoŕıas de las cartas que se van a mostrar al Tendero en la página. Asimismo, se cuenta con un componente Cart que hace referencia a un carrito de compras en el cual se van a ir agregando distintos productos como se mencionaba anteriormente que se podrán visualizar dentro del carrito mismo gracias al componente ItemCart que es el que contiene la información del producto añadido, la cantidad de este y permitirá añadir o quitar un producto del carrito, para finalmente poder realizar el pedido por medio de un botón. Finalmente, se cuenta con un componente Loader que, como su nombre lo indica, está destinado para que una vez se realice el pedido, mientras se env́ıan los datos necesarios al back, este sea renderizado para mantener informado al usuario de que se está procesando dicho pedido. Figura 6.2: Contexto del Front. 6.1. Proceso de Desarrollo - Frontend 53 En la Figura 6.2, se puede apreciar que se crea un elemento contexto haciendo uso de create- Context, el cual permite establecer una comunicación para compartir datos y funciones entre los distintos componentes que accedan a él, esto se da gracias al provider, que es el que permite que los componentes que lo consumen se suscriban a los cambios del contexto. Permitiendo pasar datos a través del árbol de componentes sin tener que pasar propiedades manualmente en cada nivel. Asimismo, se puede apreciar que dentro del contexto se hacen uso de distintos “Hooks” de React, como useE↵ect y useState, que permiten trabajar con el estado, asignación de variables y los efectos que se le pueden dar a los componentes de React, como se puede apreciar en la ĺınea 32 en la cual se hace un llamado a la función aśıncrona getProducts, que es la que permite traer los distintos productos del proveedor, haciendo uso de la libreŕıa Axios para realizar una solicitud HTTP al endpoint del Backend. Dentro del contexto también se establecen otras funciones importantes que no se llegan a vi- sualizar en la imagen, como la de añadir un producto al carrito de compras, eliminar un producto del carrito de compras y la de realizar el pedido, las cuales son retornadas al final para poder compartirse con los demás elementos por medio del context y el provider. Figura 6.3: Definición de rutas Front. Figura 6.4: Renderizado Front. 54 Caṕıtulo 6. Implementación del Software Como se puede apreciar en las Figuras 6.3 y 6.4, se hace uso de la libreŕıa react-dom y react- router-dom para inicialmente en el archivo App.js declarar la ruta de navegación que se va a utilizar, en este caso para poder acceder al elemento home, envolviéndolo con la información del contexto por medio del provider para que tenga acceso a la misma, exportando finalmente el elemento para que posteriormente sea renderizado junto con su ruta especificada. 6.2. Proceso de Desarrollo - Backend Debido al buen proceso de selección del lenguaje de programación Python junto con su frame- work Flask, a la experiencia y al buen manejo que se posee para desarrollar con este lenguaje, se puede decir que no se presentaron mayores inconvenientes en el proceso de desarrollo de la lógica del Chatbot. Sin embargo, si se tuvo problemas al inicio en la conexión del Chatbot con la lógica del Backend, ya que en un principio se queŕıa hacer uso de una plataforma de comprensión de lenguaje natural de Google muy potente denominada Dialogflow [58], la cual permite diseñar la manera en la que se va a comunicar el usuario con el chatbot y es fácil de integrar con plataformas de mensajeŕıa instantánea como Telegram, pero en el momento de realizar la conexión por medio de un webhook, se observó que Dialogflow cuenta con algunas limitaciones como por ejemplo que no se puede acceder al chatId de la conversación de telegram por lo cual no se le pueden enviar ciertos mensajes o identificar espećıficamente con quién está hablando el Chatbot. Es por esto, que se decidió crear el Chatbot de manera manual haciendo uso de la libreŕıa pyTelegramBotAPI [50], para poder desarrollar el Chatbot de acuerdo con los requisitos y sin ninguna restricción. A continuación, se mostrarán algunas secciones importantes del código en Python, que junto con el framework Flask y la libreŕıa pyTelegramBotAPI, permitieron realizar de manera correcta el “Backend” del Chatbot: Figura 6.5: Estructura de archivos MVC. 6.2. Proceso de Desarrollo - Backend 55 Como se puede apreciar en la Figura 6.5, se estructuran o acomodan los distintos archivos de acuerdo con la arquitectura o patrón de diseño MVC (modelo-vista-controlador), estipulado anteriormente en el caṕıtulo 4 de Diseño del Software. Organizando los distintos archivos dentro de las carpetas que hacen referencia a los componentes del modelo y el controlador, ya que la vista en este caso, que es la interfaz de la Web App que se va a mostrar dentro de la conversación con el Chatbot, se encuentra aparte en la parte del Frontend desarrollado en React y mencionado anteriormente. Asimismo, se puede ver que cada uno de los modelos de las tablas creadas en la base de datos, cuenta con un controlador, el cual cuenta con funciones CRUD (Create, Read, Update, Delete) que pueden ser utilizadas más adelante para manipular los datos de las distintas tablas. Figura 6.6: Definición del Webhook. En la Figura 6.6, se puede ver la función webhook creada, la cual resulta ser fundamental para establecer la comunicación del Chatbot con la Api de Telegram, esta función permite ir recibiendo todo tipo de peticiones o actualizaciones que se realizan al Chatbot durante una conversación, por medio del método “POST”, para poder después procesar dicha información utilizando la libreŕıa pyTelegramBotAPI, para darle una respuesta acertada al usuario que permita continuar con el flujo de la conversación y la lógica establecida. Como se puede percibir en la función cmd start, en la ĺınea 72, la cual es una función que responde al comando “/start” que inicia una conversación por primera vez con un bot de Telegram. 56 Caṕıtulo 6. Implementación del Software Figura 6.7: Web App dentro del Chatbot. Otra sección fundamental del código se puede apreciar en la Figura 6.7, ya que dentro de esta función corroborar cedula, se verifica si un usuario (tendero) ya se encuentra registrado en la base de datos del proveedor, para posteriormente en caso tal de que aśı sea, se le env́ıa un mensaje con un botón el cual es el que permite abrir la Web App especificada en la ĺınea 216 mediante su URL para poder tomar su pedido. Por otro lado, en caso tal de que el usuario no exista en la base de datos, se almacena en un diccionario su cédula y se empezará el proceso de registro correspondiente, preguntando y almacenando en el mismo sus datos requeridos, para poder finalmente completar su registro y almacenarlo en la base de datos. 6.2. Proceso de Desarrollo - Backend 57 Figura 6.8: Endpoints importantes. Por último, en la Figura 6.8 se muestran los endpoints datosbot y recibePedido, los cuales gracias al comportamiento de Flask se pueden declarar aśıncronos, permitiendo crear un hilo de ejecución que ejecuta una corrutina o función aparte, por cada conversación que se está realizando con el Chatbot. Esto permite que, por ejemplo, con la función datosbot se pueda ir almacenando en un diccionario las “sesiones” por medio del chatId que es diferente para cada conversación en Telegram, junto con su identificación o cédula de los usuarios que están interactuando, lo que permite distinguir al Chatbot con qué usuario está tratando en todo momento. Asimismo, la función recibePedido como su nombre lo indica, es la encargada de recibir de la parte del Front un JSON que contiene el pedido con los productos seleccionados por el usuario, junto con su identificación correspondiente, que posteriormente serán datos que serán procesados, almacenados en sus respectivas tablas y enviados al Proveedor para completar la cadena de suministro. 58 Caṕıtulo 6. Implementación del Software 6.3. Proceso de Desarrollo - Base de Datos Para la implementación de la base de datos del Chatbot, se modeló primero el modelo relacional que se puede apreciar anteriormente en la Figura 4.3 del caṕıtulo de diseño del software. Este se realizó haciendo uso del software “draw.io” [59], el cual es un software gratuito y de código abierto desarrollado en HTML5 y Javascript, el cual permite crear distintos tipos de diagramas que pueden ser útiles en el proceso del desarrollo del software y que en este caso fue fundamental para modelar la base de datos creada en PostgreSQL. Para la creación de la base de datos, se puede decir que no hubo inconvenientes gracias a la experiencia previa que se teńıa con el motor de base de datos seleccionado. A continuación, se mostrarán algunas secciones importantes, que permitieron la creación y correcto funcionamiento de la base de datos. Figura 6.9: Modelo de tablas BD. Como se puede apreciar en la Figura 6.9, se utilizaron los modelos establecidos en el código del Backend para la creación de las distintas tablas que se van a utilizar. En este ejemplo se puede ver cómo se crea la clase Producto haciendo uso del kit de herramientas SQL y ORM (Object Relational Mapper) para Python “SQLAlchemy” [60], la cual corresponde a la tabla productos creada posteriormente y que cuenta con atributos como codigo que se define como la primary key, categoria, descripcion, precio, cantidad e imagen. 6.3. Proceso de Desarrollo - Base de Datos 59 Figura 6.10: Tablas Creadas Base de Datos. En la Figura 6.10 se puede evidenciar la creación de las 4 tablas clientes, productos, pedidos y productosxpedido en la base de datos postgres, la cual se encuentra alojada en un servicio de bases de datos relacionales de Amazon (Amazon RDS), el cual se ejecuta “en la nube” y está diseñado para simplificar el funcionamiento, configuración y escalabilidad de una base de datos relacional para su uso en distintas aplicaciones [61]. Figura 6.11: Conexión Base de Datos y Excel. Teniendo en cuenta el requisito funcional con identificación “RF-29”, planteado en la sección 10.1.1 del caṕıtulo 10.1 de Requisitos, en el cual dice que “El chatbot debe poder integrar las bases de datos con Excel para poder facilitar al proveedor modificar el inventario y aśı mismo, poder importar y exportar datos.” Se busca la manera de conectar la base de datos junto con un Excel en Google Drive utilizando una extensión llamada Coefficient [62], la cual es una herramienta que permite conectar las hojas de cálculo de Google con las bases de datos de Salesforce, MySQL y Post- greSQL. Permitiendo actualizar, modificar, importar y exportar datos, e incluso poder programar 60 Caṕıtulo 6. Implementación del Software actualizaciones o alertas que permitan monitorear las distintas tablas. Véase la Figura 6.11. 6.4. Proceso de Desarrollo - Despliegue En el diagrama a continuación se quiso representar las distintas herramientas que se utilizaron para lograr programar el Chatbot y conectarlo a la API de Telegram correctamente, teniendo en cuenta la arquitectura MVC planteada, los distintos requisitos planteados y la interacción del usuario. Véase la Figura 6.12. Figura 6.12: Diagrama Herramientas Desarrollo. En el siguiente Diagrama se muestran las distintas plataformas o herramientas que se utilizaron posteriormente para poder realizar el despliegue del código del Chatbot. Véase la Figura 6.13. Figura 6.13: Diagrama Herramientas Despliegue. Como se puede apreciar en el diagrama, para realizar el despliegue de la parte del “Frontend”, se utilizó la plataforma de Netlify [63], la cual permite alojar y mantener un sitio web estático o aplicación con implementación continua y protocolo HTTPS. Asimismo, para la parte del “Bac- kend”, se hizo uso de la herramienta LocalTunnel [64], la cual permite exponer un servidor web local como el que se tiene en Flask a través de internet de manera temporal, se escogió esta he- rramienta porque a diferencia de otras plataformas como Ngrok [65], LocalTunnel permite crear subdominios de manera gratuita con una URL con certificado HTTPS, única, estática y pública 6.4. Proceso de Desarrollo - Despliegue 61 que se asocia con el servidor local que se quiere exponer. Lo cual resulta conveniente para desplegar y conectar este prototipo del Chatbot de manera correcta, tanto con Netlify como con Telegram que solicita ciertos protocolos para poder conectarse a la API. Por último, se utilizó Google Drive para la creación de las hojas de cálculo que se van a comunicar con la base de datos PostgreSQL mencionada anteriormente en el proceso de desarrollo de la base de datos y que se desplegó en un RDS de AWS (Amazon Web Services). 62 Caṕıtulo 6. Implementación del Software 6.5. Prototipo Final Funcional A continuación, se mostrarán algunas de las vistas relevantes obtenidas del prototipo final del Chatbot funcionando en Telegram. Figura 6.14: Vista proceso de Registro Tendero Parte III. Figura 6.15: Vista proceso de Registro Tendero Parte IV. 6.5. Prototipo Final Funcional 63 Figura 6.16: Vista proceso Realizar pedido Parte IV. Figura 6.17: Vista proceso Realizar pedido Parte V. Para ver detalladamente cada una de las vistas es necesario revisar la sección 10.3 del Caṕıtulo de anexos, donde están las vistas finales que comprende el Prototipo Final. Asimismo, si se desea ver el funcionamiento del Chatbot, se recomienda ver el siguiente video disponible en: https: //youtu.be/0L8cFLV-IIg Caṕıtulo 7 Pruebas 7.1. Pruebas Funcionales La sección presente contiene algunas pruebas funcionales realizadas para verificar el correcto funcionamiento e implementación del Chatbot desarrollado teniendo en cuenta los requerimientos planteados anteriormente. Para ello se efectuaron algunos casos de prueba que teńıan en cuenta diferentes condiciones o variables, que se utilizan para determinar si una aplicación o software funciona de manera aceptable o no. Figura 7.1: Caso de prueba CP FUN 001. 66 Caṕıtulo 7. Pruebas Figura 7.2: Caso de prueba CP REG 001. Figura 7.3: Caso de prueba CP PED 001. Para ver detalladamente cada uno de los casos de prueba, es necesario revisar la sección 10.6 del Caṕıtulo de anexos, donde están todos los casos de prueba que comprende el Prototipo Final. Asimismo, si se desea ver el funcionamiento completo del Chatbot, se recomienda ver el siguiente video disponible en: https://youtu.be/0L8cFLV-IIg 7.2. Pruebas