Sistema RPA para gestión de consumos de licencias y sistemas internos

Universidad de Valladolid Escuela Técnica Superior Ingenieros de Telecomunicación Trabajo Fin de Grado GRADO EN INGENIERÍA DE TECNOLOGÍAS DE TELECOMUNICACIÓN Sistema RPA para gestión de consumos de licencias y sistemas internos Autor: D. Juan José Hernanz Fernández Tutores: D. Rubén Mateo Lorenzo Toledo Valladolid, 01 de julio de 2021 Título: Sistema RPA para gestión de consumos de licencias y sistemas internos Autor: D. Juan José Hernanz Fernández Tutores: D. Rubén Mateo Lorenzo Toledo Departamento: Teoría de la Señal y Comunicaciones e Ingeniería Telemática Tribunal Presidente: Evaristo J. Abril Domingo Vocal: Rubén M. Lorenzo Toledo Secretario: Patricia Fernández del Reguero Fecha: 01 de julio de 2021 Calificación: Resumen del TFG En este trabajo se presenta el desarrollo de dos soluciones software para la automatización de procesos de una empresa. El resultado son 2 sistemas que tienen en común muchas de sus partes fundamentales. La funcionalidad básica de ambos es un bot basado en la librería puppeteer de Node.js. Este software simula sesiones en la web para extraer y almacenar datos de interés para la empresa. A través de las herramientas de Google Sheets yData Studio estos datos se visualizan en informes que serán consumidos por diferentes departamentos. Las diferencias en los sistemas vienen determinadas por la naturaleza de estos datos. Un sistema representará gráficas de consumos de licencias del software de Acoustic, mientras que el otro estará orientado a visualizar tiempos de carga de una página web medidos a través de sesiones de Acoustic. El contenido de este documento pretende ser un repaso completo de todo el proceso llevado para el desarrollo de estas soluciones. Palabras clave Automatización de Procesos Robóticos, Puppeteer, web-scraping, Inteligencia de Negocio, visualización, analítica de datos. iii Abstract This project presents the development of two software solutions for the automation of a company’s processes. This results in 2 systems that have many of their essential pieces in common. The basic feature of both is a bot based on the puppeteer library of Node.js. This software simulates web sessions to extract and store valuable data for the company. Through Google Sheets and Data Studio tools, these data are displayed in reports that are then consumed by different departments. The differences between the systems are determined by the nature of this data. One system will represent graphs of licence consumption of the Acoustic software, while the other will be focused on visualising web page load times measured through Acoustic sessions. The content of this document is intended to be a complete overview of the whole process carried out to develop these solutions. Keywords Robotic Process Automation, Puppeteer, web-scraping, Business Intelligence, visualization, data analytics. iv Agradecimientos A mis padres, por su confianza plena. A mis abuelos, porque sé que estarían muy orgullosos. A mis hermanos y círculo cercano, por haberme soportado en esta etapa. A mis amigos de la carrera, por ser la motivación diaria para continuar. A Jimena, por apoyarme cada día. A PJ, por estar siempre en mi equipo. A Rubén, por guiarme en este proceso. A Azu y mis compañeros de LUCE, por darme esta oportunidad. v vi Índice general Índice general VII Índice de figuras XI Índice de tablas XV 1. Introducción 1 1.1. Motivación .................................... 1 1.2. Objetivosyalcance................................ 2 1.3. Metodología.................................... 3 1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Estado del arte 5 2.1. Introducción.................................... 5 2.2. SistemasRPA................................... 5 2.2.1. TiposdeRPA .............................. 6 2.2.2. RPA basados en web-scraping ...................... 8 2.3. Inteligencia de Negocio (BI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Dashboards ................................ 11 2.4. Experiencia de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. Real User Monitoring (RUM)...................... 12 2.4.2. Navigation Timing API ......................... 13 vii viii ÍNDICE GENERAL 2.4.3. Nuevas Tendencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Discusión y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Planificación y Análisis del sistema 17 3.1. Introducción ................................... 17 3.2. Visióndelsistema ................................ 17 3.3. Definición de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Requisitos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Diagramas de Flujo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.1. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.2. DFDdenivel0.............................. 26 3.4.3. DFDsdenivel1 ............................. 28 3.5. Conclusiones ................................... 35 4. Diseño e Implementación 37 4.1. Introducción.................................... 37 4.2. Tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.1. Tealeaf .................................. 37 4.2.2. Node.js y Puppeteer . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2.3. Google APIs y GoogleSheets . . . . . . . . . . . . . . . . . . . . . . 39 4.2.4. DataStudio................................ 39 4.3. Diseño....................................... 40 4.3.1. Sistema de Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.2. Sistema de Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4. Implementación ................................. 53 4.4.1. Sistema de Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2. Sistema de Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 60 ÍNDICE GENERAL ix 4.4.3. Ficheros config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.4. SistemadeLOG ............................. 68 4.5. Despliegue..................................... 70 4.6. Conclusiones ................................... 70 5. Conclusiones y líneas de trabajo futuro 73 5.1. Conclusiones del trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . 73 5.2. Líneas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Referencias 75 Referencias 75 xvi ÍNDICE DE TABLAS Capítulo 1 Introducción 1.1. Motivación Muchas de las tareas llevadas a cabo por los trabajadores de una empresa resultan poco estimulantes y tediosas por su carácter manual y repetitivo. Esto no sólo tiene un impacto sobre la motivación de los trabajadores, sino también sobre la producitividad de la propia empresa. Los sistemas de automatización de procesos robóticos, o RPA por sus siglas en inglés (Robotic Process Automation), nacen con el objetivo de mitigar estos procesos ineficientes, simples y tediosos [Tau20]. De esta forma, constituyen una nueva fuerza de trabajo que será fuente de valor de la empresa y que está adquiriendo una importancia cada vez mayor. Esta nueva industria está ganándose la atención de empresas, inversores e, incluso, de los propios empleados. Como una primera aproximación, entendemos RPA como la tecnología software capaz de emular interacciones de humanos con sistemas digitales para realizar un proceso empresarial de manera automática. El diseño e implementación de un RPA es el objetivo que nos concierne en este Trabajo de Fin De Grado (TFG). Surge como una oportunidad de negocio en el transcurso de mis prácticas en la empresa LUCE Innovative Technologies1.LUCE IT es una entidad que ofrece soluciones tecnológicas a sus clientes especializada, sobre todo, en Data y Automatización. Por ello, entre sus múltiples servicios incluye la automatización de procesos de negocio y de operaciones mediante soluciones RPA. Como empresa tecnológica, además de acompañar a sus clientes en en su transformación digital, incorpora estas nuevas tecnologías en sus propios procesos productivos. En este contexto, yo he colaborado con el departamento de data desempeñando tareas de analítica de datos enfocadas a la experiencia del cliente. En el desarrollo de mis tareas, surgió la oportunidad de implementar un sistema RPA basado en web-scrapping2y herramientas de visualización para agilizar procesos del equipo de negocio. Además, suponía una oportunidad de negocio a la hora de ofrecer nuevas soluciones de análisis de datos a los clientes de la empresa. La puesta en marcha de esta idea vino motivada por la existencia de Puppeteer3. Se 1https://luceit.com/es/ 2Técnica de extracción de información de un sitio web mediante un programa software. 3https://pptr.dev/ 1 2CAPÍTULO 1. INTRODUCCIÓN trata de una librería de Node.js que proporciona una API de alto nivel para controlar Chrome oChromium a través del Protocolo DevTools4. Dicho en otras palabras, es un software que permite automatizar acciones sobre los navegadores de Google. Si además tenemos en cuenta que está desarrollada por Google, estamos ante una herramienta tremendamente potente para resolver problemas de Automatización,Big Data y análisis de rendimiento. Y esto, como hemos visto, son pilares fundamentales de la empresa. Teniendo todo lo anterior en cuenta, se plantea en el presente Trabajo de Fin de Grado el análisis, diseño e implementación de un sistema RPA en el seno de la empresa LUCE IT. Dicho bot deberá automatizar las tareas de extracción de datos de la web de Acoustic Experience Analytics5, el procesado de esos datos, su publicación y actualización en un conjunto de datos y, en última instancia, la visualización de esos datos en dashboards6para poder ser analizados. 1.2. Objetivos y alcance El objetivo del TFG será implementar un sistema RPA que, mediante dashboards, permita visualizar y analizar datos que previamente haya extraído de la web de Tealeaf . Gracias a su flexibilidad, este sistema permitirá agilizar tareas a nivel interno en la empresa. Pese a que el desarrollo de este proyecto podría emplarse para infinidad de aplicaciones, el alcance del trabajo estará delimitado a implementar las siguientes soluciones: Extraer, almacenar y visualizar los datos del consumo mensual de licencias de Tealeaf. Consistirá en un dashboard utilizado a nivel interno por el Equipo de Negocio para controlar que no se exceda el límite mensual contratado. Extraer, almacenar y visualizar datos de rendimiento de un sitio web a partir de los datos recogidos en Tealeaf. Consistirá en la creación de 3 dashboards donde el departamento de Optimización de Rendimiento Web tenga acceso a toda la información relativa a los tiempos de carga percibido por los usuarios en la web. La consecución de estos objetivos reportará interesantes beneficios a las partes implicadas: Se agilizarán procesos internos gracias a la automatización. Esto hará que los empleados no pierdan tiempo y esfuerzos en tareas simples y repetitivas. Mejoras del control del consumo licencias del software de Tealeaf por parte de la empresa. Esto contribuye a una mayor calidad de la información de la que se dispone a la hora de tomar decisiones futuras. 4https://chromedevtools.github.io/devtools-protocol/ 5También referida como Tealeaf, es una herramienta para la analítica de experiencia de usuario a través de la captura de sesiones web. Web: https://www.acoustic.com/products/tealeaf. 6Traducido habitualmente como cuadro de mandos, es una herramienta de visualización de métricas o indicadores que dan información del estado de una empresa, máquina o proceso. 1.3. METODOLOGÍA 3 El desarrollo de este sistema puede utilizarse como punto de partida para automatizar otras muchas tareas y procesos que mejoren la productividad de la entidad. Al utilizarlo como solución en la prestación de sus servicios, la empresa adquiere una oportunidad de negocio de la que podrá obtener rentabilidad si es capaz de paquetizarla y comercializarla entre sus clientes. Desde la perspectiva del usuario final, recibe un servicio más rápido y que aporta un mayor valor al dato. Para el desarrollo de todo el sistema se han utilizado diferentes tecnologías. El bot consiste en un proyecto de Node.js que utiliza la librería de Puppeteer para la emulación de navegaciones y extracción de datos y la librería de Google Sheets API para poder editar hojas de cálculo de Google. Por último, para la visualización de dashboards se ha utilizado Google Data Studio. 1.3. Metodología Al tratarse de un Trabajo de Fin de Grado asociado a una empresa, el desarrollo software ha formado parte de la metodología Agile que utiliza LUCE IT en la gestión de sus proyectos. Se trata de una aproximación iterativa e incremental de desarrolo software que parte de un plan detallado y requiere una fuerte comunicación entre los equipos [Tau20]. Dentro de este modo Agile de trabajo se utilizan los modelos Scrum yKanban en la gestión de proyectos. La metodología Scrum divide el trabajo en equipos auto-organizados, que realizan pequeñas tareas clasificadas por prioridad y esfuerzo estimado y todo ello en iteraciones de dos semanas denominadas sprints. Gracias a la aproximación Kanban se visualiza el estado de las tareas dentro de un proyecto al clasificarlas en columnas [HK10]. Para completar los objetivos del presente TFG, se ha dividido el trabajo en diferentes tareas integradas dentro de distintos proyectos de la empresa y se ha seguido el modelo iterativo incremental descrito en el párrafo anterior. Además, para organizar el contenido del documento se ha utilizado la división en cinco fases del Ciclo de Vida del Desarrollo de Sistemas, SDLC por sus siglas en inglés (Systems Development Life Cycle) que se muestran en la Figura 1.1 y que se describen a continuación: Planificación: fase inicial en la que se fijan los objetivos que se pretenden conseguir y se propone un primer planteamiendo del problema. Análisis: A partir de los objetivos, se definen de manera uniforme los requisitos del sistema que vendrán dados por el cliente o usuario final y que sirven para definir la interacción entre las partes del sistema. También se crean los Diagramas de Flujo de Datos. Diseño: que consta de dos partes diferenciadas. Por un lado el diseño del sistema, en el que se analizan y deciden las diferentes partes que lo componen. Por otro lado En esta fase, se definen las tareas que han de completarse, la estimación de esfuerzo de cada una de ellas y su prioridad. 4CAPÍTULO 1. INTRODUCCIÓN Implementación: fase de desarrollo del software. Consiste en la ejecución de las tareas. Acapara la mayor parte del tiempo. Despliegue y Manenimiento: paso a producción del sistema una vez pasados los tests. Los cambios a partir de este momento son inusuales. Figura 1.1: Ciclo de Vida del Desarrollo de Sistemas (SDLC) [JSV17]. Todas estas fases se han llevado a cabo durante los mencionados sprints. Al incio del sprint se organizan las tareas que se quieren completar en el período de 2 semanas. Durante el sprint, tienen lugar a diario unas reuniones cortas de equipo, denominadas daily Scrum en las que se revisa el proceso y se analizan posibles obstáculos. Al final de cada sprint se evalúa la consecución o no de estas tareas, se ajustan tiempos si es necesario y se crean nuevas tareas. [Sch02] 1.4. Estructura del documento Este documento está dividido en cinco capítulos teniendo en cuenta este primero que ha sido introductorio. A continuación, en el Capítulo 2, se profundiza en los sistemas RPA y, particularmente, en aquellos basados en web-scrapping. Además se pone en valor la importancia del dato aplicado a la Experiencia de Usuario (UX)7y a la Inteligencia de Negocio (BI)8en las empresas actuales. Después, en el Capítulo 3, se detalla todo lo referido a la Planificación y el Análisis del sistema. Se incluye un primer acercamiento al sistema así como sus requisitos y Diagramas de Flujo de Datos. Más tarde, en el Capítulo 4, se describen todas las tecnologías utilizadas y se detallan los procesos de Diseño, e Implementación del sistema RPA. Finalmente, en el Capítulo 5 encontramos las conclusiones relativas al trabajo realizado y sus potenciales siguientes pasos. 7UX por sus siglas en inglés (User Experience), hace referencia a la calidad percibida por los usuarios en su interacción con un sistema. 8BI por sus siglas en inglés (Business Intelligence), hace referencia a uso de los datos por parte de los equipos de negocio para transformarlos en conocimiento y mejorar la información en la toma de decisiones de la empresa. Capítulo 2 Estado del arte 2.1. Introducción Los sistemas RPA constituyen uno de los puntos clave para el aumento de la productividad de una empresa a través de la automatización de sus procesos. La clave consiste en tranferir la ejecución de aquellas tareas más repetitivas y simples desde los humanos hasta las máquinas. Esta transición hacia la automatización supone una mayor fuente de valor si se aplica sobre procesos de toma de decisiones de la empresa. Pero el abanico de posibilidades que nos brinda esta tecnología es muy variado. Por ejemplo, veremos cómo podemos aplicar la RPA sobre la Experiencia de Usuario, una disciplina que actualmente está tomando más importancia que nunca en las páginas web y aplicaciones. Este capítulo consta de 4 partes principales: en la Sección 2.2 se explica en profundidad el concepto de RPA, su historia y la proyección futura de la industria. Además en la subsección 2.2.1. se propone una tipología de RPA y en la 2.2.2. se introduce la técnica de web-scraping. En la Sección 2.3. se explican los fundamentos de la Inteligencia de Negocio o BI y su relación con la RPA. En la subsección 2.3.1. se pone énfasis en las herramientas de visualización denominadas dashboards. Más adelante, la Sección 2.4 está dedicada a la Experiencia de Usuario. A su vez este apartado está dividido en 3 subsecciones: en la 2.4.1. se introduce la técinca de Real User Monitoring, en la 2.4.2. nos detenemos en la importante API de Navigation Timing y finalizamos con un repaso de las nuevas tendencias en las métricas de la Experiencia de Usuario en la subsección 2.4.3. Finalmente, en la Sección 2.5 se recopila toda la información expuesta referente al estado del arte y se propone una relación entre todos los conceptos tratados a modo de conclusión. 2.2. Sistemas RPA En el Capítulo 1 se recoge un primer acercamiento a la automatización de procesos robóticos. Para entender mejor el fundamento de estos sistemas, resulta apropiado repasar sus términos. El adjetivo robóticos no hace referencia a un artefacto físico, sino más bien a un robot basado en software (comúnmente denominado bot). El término procesos bien 5 6CAPÍTULO 2. ESTADO DEL ARTE podría ser sustituido por tareas, entendidas como un conjunto de acciones para la consecución de un objetivo [Tau20]. Por último tenemos la palabra automatización, que se refiere a la técnica aplicada sobre un sistema para que opere de manera automática [SM19]. Recopilando todo esto, describimos un sistema RPA como la tecnología software capaz de emular interacciones de humanos con sistemas digitales para realizar un proceso empresarial de manera automática. Pese a que algunas proyecciones actuales predicen que el mercado de RPA estará saturado en 20231, estas tecnologías tan solo llevan conviviendo con nosotros desde principios de los años 2000 [Tau20]. A continuación, se hace un repaso de su breve historia. El concepto de automatización dista mucho de ser novedoso, pero su aplicación en ejemplos de la vida real ha sido ampliamente impulsada durante los últimos 70 años gracias a la aparición de los ordenadores. Automatización y ordenadores son conceptos que están estrechamente ligados y han evolucionado conjuntamente sentando las bases de las tecnologías RPA. Las primeras computadoras eran enormes máquinas que sólo las grandes empresas se podían permitir, pero resultaban sumamente últiles en la gestión de sus funciones centrales. Con los avances en los microprocesadores y los sistemas operativos llegó la Revolución del PC que permitió a cualquier empresa automatizar sus procesos. Todo esto sentó los pilares de la RPA, que tuvo su origen a principios de siglo. Inicialmente no atrajo mucha atención, por una parte por ser considerada como baja tecnología y, por otra, porque el foco estaba puesto en el incipiente mercado de la nube. Alrededor del 2012 esta tendencia cambió y el mercado de RPA comenzó a atraer a entidades e inversores erigiéndose a día de hoy como la tecnología de mayor crecimiento dentro de la industria software. Esto no fue más que el resultado de la convergencia de muchas tendencias como la búsqueda de reducir costes para hacer frente a las secuelas de la crisis financiera, el interés por la transformación digital o la sofisticación de la tecnología, entre otros [Tau20]. Si miramos al futuro del sector las proyecciones son igualemente prometedoras. Según la consultora global McKinsey & Company2, el impacto financiero de la RPA podría alcanzar los 6,7 billones de dólares en el año 2025. Además, afirmó que, tan sólo en el primer año, las empresas que adopten esta tecnología tendrán un retorno de inverión potencial de entre el 30 y el 200%. 2.2.1. Tipos de RPA En función su naturaleza, podemos dividir a la tecnología RPA en 3 clases distintas. Además, estas clases se han diferenciado de manera natural con la constante evolución de la tecnología. Es decir, podemos asociar cada clase a una generación de RPA [Tau20]: RPA asistida: el software porporciona asistencia en ciertas tareas en colaboración con una persona. Es la primera forma de RPA que surgió alrededor del 2003. RPA desatendida: los procesos se automatizan sin la necesidad de ningún tipo de 1https://www2.deloitte.com/ro/en/pages/technology-media-and-telecommunications/articles/deloitteglobal-rpa-survey.html 2https://globalpayrollassociation.com/blogs/technology/what-the-history-of-rpa-technology-says- about-its-future 2.2. SISTEMAS RPA 7 intervención humana. Se trata de la segunda generación de RPA. RPA cognitiva (también conocida como Automatización Inteligente de procesos o IPA): el sistema RPA incluye Inteligencia Artificial que le permite aprender por sí solo. De esta manera, no es necesaria la intervención humana incluso en la toma de algunas decisiones. Se trata de la última generación de RPA. Una de las preguntas que más se hacen tanto desarrolladores como empleados y gestores es: ”¿Qué procesos deben automatizarse y cuáles deberían ser realizados por humanos?” La Figura 2.1 arroja luz a esta pregunta. La línea azul representa la distribución de procesos susceptibles de ser automatizados mediante RPA. Se tiene en cuenta la frecuencia con la que han de realizarse (eje y) los distintos procesos (eje x). Esta función sigue una distribución de Pareto en la que se indica que el objetivo de la automatización se centra en el 20% de los procesos que son los más frecuentes. La parte final del gráfico representa los procesos menos frecuentes que necesitan ser realizados por humanos. En la parte central se encuentran procesos repetitivos pero no demasiado frecuentes. Esto hace que sean susceptibles de ser automatizados siempre y cuando sea económicamente viable [vdA18]. En la actualidad, con la incorporación de la Inteligencia Artificial y el Machine Learning a la tecnología RPA, la posición de estos umbrales se está modificando en favor de una mayor proporción de procesos automatizados. Figura 2.1: Posicionamiento de RPA [vdA18]. Por lo tanto el objetivo de la RPA es sustituir a los humanos en las tareas más repetitivas para que su productividad aumente. Pese a que el abanico se está expandiendo, a continuación se enumeran algunas de las tareas que tradicionalmente han sido automatizadas [Tau20]: 8CAPÍTULO 2. ESTADO DEL ARTE El traspaso de información de unas plataformas a otras mediante la técnica de copiapega. Abrir una web y hacer el login. Abrir, o reenviar e-mails, La lectura y escritura de una base de datos. La extracción de contenidos de docmentos, gráficas o formularios. El uso de cálculos y flujos de trabajo. 2.2.2. RPA basados en web-scraping En su objetivo de automatizar un proceso, un sistema RPA puede hacer uso de tantas tecnologías software como sean necesarias. De entre todas estas, resultan interesantes las herramientas de web scraping.Web scraping es una herramienta que se basa en la construcción de un agente software para descargar, analizar y organizar los datos de una web de manera automatizada [SvB18]. Si lo enmarcamos en el contexto de una empresa, la técnica de web scraping resulta muy potente para automatización de muchas tareas que precisan de datos que se encuentran expuestos en la web. En este punto resulta interesante plantear la siguiente pregunta: Si el web scraping se utiliza para recuperar datos que se encuentran en un sitio web concreto, ¿no es justo eso lo que nos permiten las Application Programming Interface (APIs)? La respuesta es que sí, las APIs proporcionan un medio para que el mundo exterior tenga acceso a un conjunto de datos de un sitio, de una manera estructurada. Sin embargo, el web scraping encuentra su fundamento precisamente en las carencias de las APIs. En términos generales, siempre será más adecuado utilizar una API para extraer un conjunto de datos de la web, pero esto no siempre va a ser posible debido a diferentes factores: El sitio web no ofrece una API. La API tiene un coste que no queremos asumir. Existen limitaciones a las peticiones que se pueden realizar. Los datos que nos interesan, no están disponibles a través de la API. El web scraping surge como solución a todos los problemas descritos [SvB18]. Si bien es una forma de atacar el problema más compleja y costosa, es también mucho más flexible y completa. Al fin y al cabo, si puedes ver datos en la web, puedes extraerlos. La recopilación automática de datos presentes en Internet es probablemente tan antigua como la propia Internet. La cantidad de datos que en la red están incluidos es inconmensurable, por ello la técnica de web scraping es utilizada ampliamente por distintos agentes con propósitos muy dispares. Por ejemplo, muchos de los productos de Google se han beneficiado de esta técnica (el Google Translate se entrena a sí mismo con datos que extrae de la propia web). También se puede utilizar con muchos fines sociológicos: una 2.3. INTELIGENCIA DE NEGOCIO (BI) 9 simple recopilación de mensajes de Twitter puede ser suficiente para conocer las tendencias políticas de la población o incluso para prevenir suicidios, como se hizo en un estudio realizado en Canadá3. En un contexto más empresarial, algunos ejemplos actuales del uso de esta técnica serían la recopilación de datos de competidores (como sus precios) o la creación de conjuntos de datos a partir de información procedente de distintos canales web. Para conseguir recopilar estos datos de Internet, el bot debe tomar el control del navegador emulando sesiones tal y como lo haría un ser humano, automatizando los clicks, la escritura de campos y el resto de interacciones posibles. En la actualidad existen dos herramientas que son las más utilizadas con este propósito. La primera y más conocida es Selenium4que permite la automatización de navegadores y es comúnmente utilizada para el testing de aplicaciones web. La segunda, ya mencionada en el Capítulo 1, es Puppeteer, una librería de Node.js que proporciona una API de alto nivel para controlar Chrome o Chromium a través del Protocolo DevTools. A pesar de que existen numerosas diferencias entre ellas, ambas pueden ser empleadas para el problema que nos concierne. Selenium es mucho más popular entre los usuarios, lo que le hace tener una comunidad más sólida, además de ser compatible con todos los navegadores. Por su parte Puppeteer cuenta con menos popularidad, pero su uso está creciendo en los últimos meses. Su ventaja principal es que ha sido desarrollada por el gigante Google y es una herramienta muy potente para la automatización de este navegador en concreto. Elijas cualquiera de las dos, u otra herramienta alternativa, lo que se pone de manifiesto es la importancia que tiene este tipo de software en la actualidad, contando con el desarrollo de enormes empresas y ampliando las opciones de evolución de los sistemas RPA. 2.3. Inteligencia de Negocio (BI) En los procesos de decisión de la empresa, el Equipo de Negocio tomará decisiones más acertadas cuanta mayor información tenga a su disposición. Con el objeto de recopilar la mayor cantidad de información posible y con el foco puesto en la calidad de esta información, surgen los Sistema de Apoyo a la Decisión (DSS por sus siglas en inglés). Definidos por primera por Gorry yScott-Morton en 1971, los DSS son ”sistemas informáticos interactivos, que ayudan a los responsables de la toma de decisiones a utilizar datos y modelos para resolver problemas no estructurados”. En otra definición clásica de DSS, Keen yScott-Morton añadieron que ”los sistemas de apoyo a la toma de decisiones combinan los recursos intelectuales de los individuos con las capacidades del ordenador para mejorar la calidad de las decisiones” (1978). Estamos por lo tanto ante un término sin una definición aceptada universalmente y que por ello puede tener diferentes significados para distintas personas. Como norma general, se utiliza el concepto DSS para describir cualquier sistema que proporciona apoyo en la toma de decisiones de una organización [RS14]. Con los avances de la tecnología, surgió una nueva generación de gestores mucho más cómodos con el uso de herramientas software que encontraron en estas un potente aliado 3https://www.sas.com/en_ca/insights/articles/analytics/using-big-data-to-predict-suicide-risk- canada.html 4https://www.selenium.dev/ 16 CAPÍTULO 2. ESTADO DEL ARTE ella se producen, repercutiendo en última instancia en las rentabilidades e ingresos de la empresa. Por ello, es posible encontrar una relación entre estos datos de rendimiento y la Inteligencia de Negocio, por ejemplo a través del sistema de Administración de Relaciones con el Cliente (CRM) o mediante la creación de dashboards. Además, los procesos de recogida o análisis de estos datos son susceptibles de ser automatizados a través la RPA. Teniendo en cuenta todo lo anterior, en el presente TFG se propone la creación de una solución RPA que permita consumir a nivel interno dashboards que presenten datos que proceden del análisis de sesiones de Tealeaf. Estos datos disponibles en la web se recopilarán de manera automática mediante la técnica de web-scraping, además se procesarán y publicarán en una base de datos que será la fuente utilizada por los dashboards. Estos paneles de control son considerados herramientas de BI que aportarán información referente a: (i) el consumo de licencias del software de Tealeaf entre los diferentes clientes de la empresa y (ii) datos (RUM) de rendimiento web proporcionados por la API Navigation Timing y medido en sesiones reales a través de Tealeaf. El cumplimiento de estos requisitos contribuirá, por un lado, a una mejora en la productividad de la empresa por la agilización de los procesos y, por otro lado, a una mejora en la calidad de la información disponible para el Equipo de Negocio a nivel cuantitativo y cualitativo. En los próximos capítulos se explicará en detalle el análisis y diseño de este sistema. Capítulo 3 Planificación y Análisis del sistema 3.1. Introducción En este Capítulo se refleja todo el contenido referente a las fases iniciales del Ciclo de Vida del Desarrollo de Sistemas descritas en la metodología del Capítulo 1. Concretamente las fases de Planificación y Análisis. La Planificación del sistema se aborda en la Sección 3.2 de este Capítulo. En este apartado se resumen las actividades de identificación y selección del proyecto. Se propone un primer planteamiento del problema a resolver y se responde a las necesidades principales que debe cubrir el sistema. Al final de la Sección se definirán, por primera vez, las dos soluciones diferentes que se van a desarrollar. La fase de Análisis se recoge en los sucesivos apartados del Capítulo. La Sección 3.3 está dedicada a la definición formal de los requisitos funcionales y no funcionales de los sistemas. Toda esta información se organiza en la Sección 3.4 a través de los Diagramas de Flujo de Datos que representan los sistemas de más alto a más bajo nivel. 3.2. Visión del sistema La Planificación consitituye la fase inicial del SDLC. Principalmente abarca las actividades de identificación y selección de potenciales proyectos de desarrollo [JSV17]. En lo que a este proyecto respecta, ya se ha ahondado ampliamente en esta fase en los las secciones 1.1, 1.2 y 2.5. A modo de resumen, se recuerda que el proyecto se ha desarrollado durante las prácticas en una empresa tecnológica. Su puesta en marcha vino motivada originalmente por la existencia de Puppeteer, un software que proporcionaba la posibilidad de implementar una RPA para agilizar procesos de la empresa. Concretamente aquellos que tienen que ver con la recopilación y visualización de grandes cantidades de datos por parte del sistema de Business Intelligence. Además, el proyecto se seleccionó porque el desarrollo y aprendizaje de estas tecnologías generaría una oportunidad de negocio al poder comercializar este tipo de servicios entre los clientes de la empresa. 17 18 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA En esta fase inicial, se realizó un primer acercamiento al problema que se pretende solucionar y que se representa en la Figura 3.1. Mediante el desarrollo del sistema RPA, se recopilan, procesan y almacenan datos de la visibles en la web de Tealeaf y se generan informes para la visualización, análisis e interacción de los datos. Datos en la Web RPA Informes de visualización Figura 3.1: Visión del problema. Elaboración propia. La pregunta más importante que debemos hacernos durante la planificación es: ¿cuál es el problema? O dicho de otra forma: ¿por qué no podemos consumir los datos directamente desde la web de Tealeaf? Y la respuesta es que si bien es cierto que Tealeaf recopila y permite visualizar los datos, presenta ciertas limitaciones: Tiene un límite de filas representadas en sus tablas. Operaciones de agregado de datos muy limitadas. Número muy restringido de tipos de gráficos. Escasa personalización de los gráficos. Escasa personalización de generación de informes. Dificultad para realizar filtrado de datos. Todas estas limitaciones, no las encontramos en herramientas específicamente dedicadas a la visualización como en nuestro caso es Data Studio. Por lo tanto, el objetivo del sistema será poder extraer los datos de la web para visualizarlos en una herramienta de visualización que nos ofrezca todas las funcionalidades de análisis sobre los datos. Existen otras cuestiones importantes relativas al sistema que deben resolverse en esta fase y que nos ayudarán a definir los requisitos en la Sección 3.3. Estas preguntas son: 1. ¿Quiénes van a ser los usuarios?: los usuarios son las personas que van a consumir los informes de visualización. Habitualmente los informes estarán dirigidos a: Personal del equipo de negocio encargados de tomar decisiones. Analistas de datos. Otros departamentos. Potencialmente (si se comercializa esta solución) los usuarios serán los clientes. 3.3. DEFINICIÓN DE REQUISITOS 19 2. ¿Qué tipo de datos se van a recopilar?: los datos se van a extraer de tablas y gráficos que se muestran en la web de Tealeaf de la empresa. Concretamente vamos a implementar la solución para la extracción de dos tipos de datos: Consumo mensual de licencias de Tealeaf por parte de la empresa. Datos de rendimiento de un sitio web recopilados en Tealeaf. 3. ¿Cómo se utiliza el sistema?: al ser un sistema automatizado, el bot se ejecutará como una tarea programada a diario. De esta forma, los datos de los informes de visualización se actualizarán cada día de forma transparente para sus usuarios y sin la necesidad de intervención humana. 4. ¿Cómo interactúan los usuarios con el sistema?: los usuarios, a través de cualquier dispositivo con acceso a Internet, podrán visualizar los informes e interactuar con los datos por ejemplo mediante aplicación de filtros o creando nuevos gráficos. Como hemos visto, se implementarán dos soluciones diferentes en función del tipo de datos que queremos analizar. Todos los fundamentos descritos hasta este punto del informe son comunes a ambas soluciones. Sin embargo, existen ciertas diferencias entre ambos casos que harán preciso diferenciarlos sobre todo en las próximas fases de Análisis, Diseño e Implementación. Por todo ello, de ahora en adelante y sólo cuando sea necesario, distinguiremos ambos sistemas con la siguiente denominación: Sistema de Licencias: solución RPA para extracción de datos del consumo de licencias de Tealeaf de las distintas organizaciones que tiene contratada la empresa. El objetivo es mostrar una gráfica con el consumo acumulado de cada organización frente al máximo de licencias contratadas. De esta forma se llevará un histórico del consumo mensual y, además, servirá de alerta para los administradores en caso de superar el máximo. Sistema de Rendimiento: solución RPA para extracción de datos de rendimiento de un sitio web asociado a la empresa. El objetivo es elaborar informes que muestren los tiempos de carga experimentados por usuarios reales medidos con Tealeaf a través de la API de Navigation Timing. Estos datos se tienen que poder filtrar por fecha,país yplataforma (ordenador o móvil) en todas sus combinaciones posibles. 3.3. Definición de requisitos Siguiendo con el Ciclo de Vida del Desarrollo de Sistemas, la siguiente fase a abordar es la del Análisis, que tiene como propósito determinar qué información y qué servicios de procesamiento de información son necesarios para apoyar los objetivos y funciones seleccionados [JSV17]. A su vez, podemos definir dos subetapas dentro del Análisis: 1. Definición de Requisitos. A la que dedicamos esta Sección. Consiste en la recopilación de las características que debe ofrecer nuestro sistema. 20 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA 2. Estructuración de Requisitos. A la que dedicamos la Sección 3.4. En esta subetapa se producen las actividades de organización de toda la información (en forma de requisitos) generada en la subetapa anterior. Para tal efecto haremos uso de la representación del Diagrama de Flujo de Datos (DFD). Fruto de distintas reuniones con los usuarios finales en las primeras semanas del proyecto, se recopiló toda la información en torno a sus necesidades y las características que debían tener las diferentes soluciones del sistema. A partir de esa información, se especifican los Requisitos Funcionales (FR, functional requirement) y los Requisitos No Funcionales (NFR, non-functional requirement). Ambos tipos de requisitos responden a las necesidades que tiene el sistema en torno a su funcionalidad,fiabilidad,rendimiento, soporte,diseño,implementación,integración yhardware [Ste15]. 3.3.1. Requisitos Funcionales Los Requisitos Funcionales son descripciones detalladas de las capacidades deseadas del proyecto [Ste15]. En la Tabla 3.1 se recopilan los requisitos funcionales indicando, además, si se aplican al Sistema de Licencias, al Sistema de Rendimiento o a ambos. Tabla 3.1: Requisitos Funcionales de los dos sistemas. Requisitos Funcionales ID Descripción Licencias Rendimiento FR01 El sitema deberá superar el proceso de login de Tealeaf y su barrera de doble autenticación. Sí Sí FR02 El sistema deberá simular una navegación automática hasta el lugar de la web donde se muestran los datos. Sí Sí FR03 El sistema deberá extraer de manera automática los datos de interés la web. Sí Sí FR04 El sistema deberá procesar internamente los datos extraídos. Deberá estructurarlos y eliminar aquellos que no necesita. Sí Sí FR05 El sistema deberá ejecutarse de manera automática según un período deseado. Diario Semanal FR06 El sistema deberá actualizar los datos de manera estructurada mediante campos en un spreadsheet. Sí Sí FR07 El sistema deberá almacenar en el spreadsheet un histórico de todos los datos. No Sí FR08 El sistema deberá comparar los datos extraídos con los del spreadsheet y actualizar aquellos campos que hayan cambiado. Sí No 3.3. DEFINICIÓN DE REQUISITOS 21 Continuación de la Tabla 3.1. ID Descripción Licencias Rendimiento FR09 El sistema deberá mostrar a los usuarios informes con gráficas con los datos extraídos. Sí Sí FR10 El sistema deberá actualizar los informes de visualización de manera simultánea a las actualizaciones de la fuente de datos (spreadsheet). Sí Sí FR11 El sistema deberá tener la opción de exportar los informes de visualización en formato PDF. Sí Sí FR12 El sistema deberá incluir unos parámetros de configuración de la ejecución. Los podrá modificar el desarrollador a través del fichero config.json Sí Sí FR13 El sistema deberá permitir a los usuarios que tengan acceso a los informes e interactuar con los datos a través de filtros. No Sí FR14 El sistema deberá permitir editar las gráficas de los informes a aquellas personas que tengan permiso de edición. Sí Sí FR15 Los informes de visualización han de incluir filtros por fecha, país y plataforma (ordenador o móvil). Y todas las posibles combinaciones que existan entre ellos. No Sí FR16 El sistema deberá poder desplegarse en una máquina de los sistemas internos de la empresa. Sí Sí FR17 El sistema deberá poder ejecutarse en un servidor en modo headless. Esto es, en un entorno sin interfaz gráfica. Sí Sí 3.3.2. Requisitos no Funcionales Los Requisitos No Funcionales son descripciones sobre la calidad de comportamien- to del sistema o sobre sus restricciones a la hora de producir un resultado. Con carácter general, se centran en las características de rendimiento,fiabilidad yseguridad [Ste15]. En la Tabla 3.2 se recopilan los requisitos no funcionales del sistema. 22 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA Tabla 3.2: Requisitos No Funcionales de los dos sistemas. Requisitos No Funcionales ID Descripción Licencias Rendimiento NFR01 El sistema deberá tener un control de permisos de propiedad, edición y visualización sobre los informes. Sí Sí NFR02 El sistema deberá ejecutarse de manera que su rendimiento no afecte negativamente a la memoria de la máquina. Sí Sí NFR03 El sistema deberá ser robusto frente a errores. Sí Sí NFR04 El sistema deberá incluir distintos niveles de LOG para poder hacer un seguimiento del proceso de ejecución. Sí Sí NFR05 La interacción con los informes de visualización deberán ser intuitivos. Sí Sí NFR06 La información mostrada en los informes de visualización debe poder ser entendida por cualquier usuario, aunque no tenga conocimientos técnicos. Sí Sí NFR07 Los informes de visualización deberán ser accesibles a través de cualquier dispositivo móvil, tableta u ordenador con acceso a internet. Sí Sí NFR08 La fuente de datos (spreadsheet) sólo podrá ser modificada por el sistema y su propietario. Sí Sí 3.4. Diagramas de Flujo de Datos La segunda subetapa del proceso de Análisis es la Estructuración de los Requisitos definidos en la Sección 3.3. Para ello haremos uso de los Diagramas de Flujo de Datos (DFD, Data Flow Diagram) que son una herramienta que permite representar de manera coherente la información recopilada en los requisitos [JSV17]. El análisis a través de DFDs permite: Modelar cómo fluyen los datos a través del Sistema de Información. Representar las relaciones entre los flujos de datos. Describir cómo los datos llegan a almacenarse en diferentes lugares. Mostrar los procesos que transforman los datos. Estos DFDs se llaman modelos de proceso porque concentran el movimiento de datos 3.4. DIAGRAMAS DE FLUJO DE DATOS 23 entre distintos procesos [JSV17]. En nuestro caso, el flujo de datos se lleva a cabo mediante un sistema software de RPA. Antes de representar los DFDs para nuestras dos soluciones, se explica qué representa cada elemento del diagrama y cómo se interpretan. Precisamente, uno de los atractivos que tienen estos diagramas es que son muy sencillos de interpretar, pues sólo se utilizan 4 símbolos distintos. Existen diferentes estándares respecto a esta simbología, pero en este informe se utilizan los símbolos propuestos por Gane y Sarson [CG79] que se representan en la Figura 3.2. proceso almacén de datos fuente/sumidero flujo de datos Figura 3.2: Símbolos de Gane y Sarson para representar DFDs [JSV17]. Se repasa a continuación qué representa cada elemento: Flujo de datos. Representa datos en movimiento desde un lugar del sistema a otro. Tiene forma de flecha y se etiqueta con un nombre significativo del movimiento de datos. Almacén de datos. Representan datos en reposo dentro del sistema a través de un rectángulo al que le falta el lado derecho. En la caja izquierda se numera y en la parte derecha se utiliza un nombre significativo para el almacén. Proceso. Representan acciones realizadas sobre los datos. Pueden ser operaciones de transformación,almacenamiento odistribución. Su símbolo es un rectángulo con esquinas redondeadas. En la parte superior se indica el número del proceso y en la parte inferior su nombre. Fuente/Sumidero. Son el origen y/o destino de los datos. Son entidades externas que están fuera del sistema. Se representan con un rectángulo y tienen el nombre del agente externo al que definen. Además se ha de tener en cuenta que los DFDs tienen que seguir ciertas reglas en su representación que se recogen en la Figura 3.3. 24 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA Figura 3.3: Reglas de elaboración de los Diagramas de Flujo de Datos [JSV17]. En las siguientes subsecciones se representan los Diagramas de Flujo de Datos creados durante la etapa de Análisis del proyecto. Serán de gran utilidad para entender los sistemas y los analizaremos de manera iterativa comenzando por diagramas alto nivel y profundizando cada vez más en los detalles. A este proceso se le denomina descomposición funcional, que consiste en fragmentar la perspectiva del sistema en partes cada vez más concretas [JSV17]. 3.4. DIAGRAMAS DE FLUJO DE DATOS 25 3.4.1. Diagrama de contexto El Diagrama de contexto representa la vista de todo el sistema en su conjunto al más alto nivel. Esta representación del flujo de datos tiene un un único proceso, etiquetado con un 0. Las fuentes/sumideros representan las fronteras del sistema. No se representan almacenes de datos porque conceptualmente están dentro del proceso. En realidad, el resultado del Diagrama de Contexto será similar a la representación del problema que vimos en la Figura 3.1. Tanto en esta representación de más alto nivel como en los niveles sucesivos, vamos a separar los diagramas para los dos soluciones que vamos a desarrollar. Por un lado representaremos los diagramas referentes al Sistema de Licencias y por otro los diagramas referentes al Sistema de Rendimiento. Esto es lógico, ya que la principal diferencia entre ambos sistemas son los datos con los que trabajan. A continuación, se muestran los Diagramas de Contexto de los dos sistemas que son objeto de estudio. En la Figura 3.4 se representa el Sistema de Licencias al más alto nivel. Lo mismo ocurre con el Sistema de Rendimiento en la Figura 3.5. Se han separado porque, ya en este nivel, existen diferencias: Respecto a las fronteras de ambos sistemas, la fuente es la misma, etiquetada como Web de Acoustic, pero vemos que los sumideros son distintos. En el caso de la Figura 3.4 los datos se proporcionan al Equipo de Negocio, mientas que en la Figura 3.5 se muestra como los datos son consumidos por el equipo de WPO (Web Performance Optimization). Como ya hemos notado, los datos con los que trabajan ambos sistemas son diferentes y por eso vemos esas diferencias en sus flujos de datos. En Sistema de Licencias trabaja con datos de los consumos de licencias medidos en Millones de Interacciones Mensuales (MMI), mientras que el sistema de rendimiento trabaja con tiempos promedios de carga de los usuarios en la web. Además, el nombre del proceso único de cada diagrama es distinto porque engloba toda la funcionalidad de cada sistema y, como veremos en los siguientes niveles, estos subprocesos son distintos entre sistemas. Figura 3.4: Diagrama de contexto del Sistema de Licencias. 32 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA Figura 3.11: DFD de nivel 1 del proceso 1 del Sistema de Rendimiento. En esta página y la siguiente se recogen los DFDs de nivel 1 que se han elaborado para el análisis del Sistema de Rendimiento. En la Figura 3.11 se representa el DFD de nivel 1 del primer proceso del sistema. El análisis que se ha hecho para la Figura 3.8 es válido, pues ambos diagramas son idénticos a excepción de los flujos de datos, como era de esperar. Del mismo modo que para el Sistema de Licencias, se ha considerado que el proceso 2 del Sistema de Rendimiento, representado en la Figura 3.7, no necesita una mayor descomposición al tratarse de una función única de formateo de datos. 3.4. DIAGRAMAS DE FLUJO DE DATOS 33 Figura 3.12: DFD de nivel 1 del proceso 3 del Sistema de Rendimiento. El proceso 3 del sistema sí que ha sido objeto de una descomposición en su Diagrama de Flujo de Datos de nivel 1 representado en la Figura 3.12. Concretamente, se descompone en 3 procesos: 1. Separación de datos por su naturaleza. A este objeto se representa el proceso 3.1. del sistema. Como flujo de entrada recibe los datos de los tiempos extraídos y formateados del proceso anterior y genera dos flujos de salida de datos. Al final de este proceso tendremos perfectamente diferenciados los tiempos generales de carga por un lado y, por el otro, el detalle del tiempo de processing que hemos comentado anteriormente y que se denomina tiempos de render en los diagramas. 2. Añadir tiempos generales a la Tabla del Histórico correspondiente (proceso 3.2). Notar que se usa el verbo ”añadir” y no el verbo ”actualizar” como se hacía en el Sistema de Licencias. Esto es porque en este sistema no hay un proceso de lectura del histórico y comparación previa, sino que simplemente se añaden al final de la tabla los datos extraídos de la web. 3. El proceso 3.3 es idéntico al descrito en el 3.2, pero es necesario separarlos porque son operaciones que se realizan sobre flujos de datos diferentes. 34 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA Figura 3.13: DFD de nivel 1 del proceso 4 del Sistema de Rendimiento. En la Figura 3.13 representa la descomposición de nivel 1 del proceso número 4 del Sistema de Rendimiento. Vemos que el DFD está compuesto por 5 procesos y es necesario hacer unos comentarios al respecto: 1. Los procesos 4.1 y4.2 de nuevo representan la misma funcionalidad del sistema pero para flujos de datos distintos. Esta funcionalidad es la de Conectar sus respectivas Tablas Históricas como fuentes de datos de las herramientas de visualización. 2. Los procesos 4.3 y4.4 también difieren únicamente en los flujos de datos con los que operan. Abstraen las operaciones del crear tablas y gráficos del sistema de una forma muy similar a la descrita en el proceso 5.2 de la Figura 3.10. 3. El proceso 4.5 representa la funcionalidad del sistema que permite combinar las tablas y gráficos procedentes de dos fuentes distintas en los mismos Informes de Tiempos de carga. Con estas gráficas hemos alcanzado el DFD primitivo de nuestro proceso de análisis para el Sistema de Rendimiento. Esto significa el final del Análisis a través de los Diagramas de Flujos de Datos. 3.5. CONCLUSIONES 35 3.5. Conclusiones Se han presentado las fases iniciales del Ciclo de Vida de Desarrollo del Sistema. A pesar de que puedan parecer fases poco productivas, pues durante ellas no encontramos avances en el desarrollo software como tal, es muy importante invertir tiempo en llevar a cabo la Planificación y el Análisis del proyecto de la manera más precisa posible. Muchos de los mayores bloqueos y errores dentro del SDLC se producen por no haber realizado el Análisis previo del sistema de una manera rigurosa. Por tanto, una buena planificación es vital para un desarrollo ágil y eficiente del sistema. A modo de ejemplo, durante estas fases se ha hecho evidente la necesidad de separar nuestro sistema en dos soluciones distintas. Como consecuencia, durante el análisis se ha realizado un doble esfuerzo por discernir entre las similitudes y diferencias de ambas soluciones. Como ventaja, en las fases sucesivas esta individualización permitirá abordar la implementación de las soluciones de una manera mucho más adecuada. Además, se ha comprobado la importancia que pueden llegar a tener los diagramas a la hora de atacar un problema y diseñar su solución. No obstante debemos utilizarlos de manera racional y comedida, ya que las figuras y gráficos se crean con el objetivo de ayudar tanto al desarrollador como a los interesados en entender el sistema. Si una representación gráfica no favorece ninguno de estos objetivos, por resultar complejos y/o poco intuitivos, su creación supone un obstáculo en lugar de un apoyo. Finalizadas estas primeras fases, nos situamos en disposición de atacar las siguientes. En el próximo Capítulo se abordan las fases de Diseño e Implementación de los sistemas que nos atañen. 36 CAPÍTULO 3. PLANIFICACIÓN Y ANÁLISIS DEL SISTEMA Capítulo 4 Diseño e Implementación 4.1. Introducción El contenido de este capítulo se dedica a las fases finales del SDLC de los sistemas bajo estudio. En particular, las fases de Diseño e Implementación. Antes de eso, en la Sección 4.2 se recopilan las tecnologías involucradas en el desarrollo de los sistemas y se introducen brevemente cada una de ellas. Posterioremente, se describe el proceso de Diseño en la Sección 4.3. Se ofrece una visión tanto del Sistema de Licencias como del Sistema de Rendimiento. Además, se presenta el Diagrama de Flujo del programa que gobierna ambos sistemas y todas las acciones de diseño relativas a los conjuntos de datos y las gráficas de visualización. Finalmente, en la Sección 4.4 se pretende explicar la etapa de Desarrollo de lo sistemas desde una perspectiva comprensible para el lector. Se hace de forma separada para los dos sistemas, aunque siempre destacando los puntos en común. De especial importancia son las secciones en las que se explica le creacción de los proyectos Node.js así como las Figuras que muestran los resultados de las visualizaciones. 4.2. Tecnologías utilizadas 4.2.1. Tealeaf Tealeaf , conocida también en la actualidad como Acoustic Experience Analytics, es una herramienta para la analítica de la Experiencia de Usuario a través de captura de sesiones en la web. Es decir, como ellos mismos dicen en su página web1, sirve para interpretar el comportamiento del cliente y cómo este impacta en el negocio a través del análisis de sesiones. 1https://www.acoustic.com/products/tealeaf 37 38 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Esta herramienta constituye una solución completa de analítica ofreciendo versiones tanto en la nube como on-premise. En nuestro caso se ha utilizado su versión en la nube accesible a través de la web. No profundizaremos demasiado en su configuración porque en nuestros sistemas simplemente actúa como la fuente de la que extraer los datos de la web. No obstante, veremos que en todo sistema hay que tener en cuenta cómo se disponen estos datos y cómo se accede hasta ellos. Por ello, veremos que la parte inicial del desarrollo se centra en la preparación y configuración de tablas de datos de Tealeaf. Para la creación de estas tablas se han utilizado conocimiento previos de la herramienta así como la documentación oficial [Aco]. Además, es importante destacar que esta herramienta es el objetivo de uno de nuestros sistemas, en concreto del Sistema de Licencias. Es decir, la empresa como cliente de esta herramienta paga una precio a cambio de su uso. Ese uso está limitado a una cuota, a la que nos referimos como licencia. La utilización en exceso de la herramienta provoca una extralimitación de la cuota que puede acarrear altos costes económicos. El Sistema de Licencias precisamente nace con el propósito de monitorizar este consumo a través de los datos disponibles en Tealeaf para tener una mayor seguimiento y control. Veremos que la licencia contratada permite un máximo de 12 millones de interacciones mensuales en la herramienta. Por lo tanto, Tealeaf tiene una doble importancia en el desarrollo: Por un lado, constituye el origen del que extraer los datos de ambos sistemas. Esos datos han de disponerse en tablas de forma adecuada para que el bot pueda acceder a ellos. Por otro lado, monitorizar el consumo mensual que se hace de esta herramienta es el objetivo principal del Sistema de Licencias 4.2.2. Node.js y Puppeteer Los scripts que componen el proyecto están basados en el lenguaje de programación JavaScript. Se trata de un lenguaje interpretado cuyo uso está muy extendido entre las páginas web, pero que es también utilizado en entornos fuera del navegador, como ocurre en nuestro caso. Concretamente, los núcleos de nuestros sistemas se han concebido como proyectos que utilizan la tecnolgía de Node.js.Node.js es un entorno de ejecución multiplataforma de JavaScript para la capa del servidor. Está basado en el motor V8 de Google (el núcleo del navegador) y es de código abierto [Nod]. Su característica de open-source, su escalabilidad y la ventaja que ofrece unificando el desarrollo de aplicaciones web en torno a un único lenguaje, han hecho que haya sido una de las tecnologías que más ha crecido en popularidad en los últimos años. A esto, hemos de sumar su gestor de paquetes (el Node Package Manager) que simplifica mucho la instalación y actualización de librerías. De entre una infinidad de librerías, destaca Pupeeteer. Como ya se ha introducido previamente en los Capítulos 1 y 2, esta librería de Node.js proporciona una API de alto nivel para controlar Chrome oChromium a través del Protocolo DevTools. El bot que da ”vida” a nuestros sistemas está basado en esta librería y por ello ha sido preciso realizar un estudio de su documentación [Pup] previo 4.2. TECNOLOGÍAS UTILIZADAS 39 al desarrollo. Concebida para todas las acciones que tengan que ver con la simulación de sesiones del navegador, utilizaremos esta librería para implementar todos los requisitos funcionales que se refieran a la extracción de datos. 4.2.3. Google APIs y GoogleSheets Siguiendo el orden lógico, tras introducir las tecnologías utilizadas en el origen de los datos (Tealeaf ) y en el núcleo del sistema (Puppeteer), repasamos a continuación las tecnologías empleadas en el destino de los flujos de datos. De la definición de Requisitos de la Sección 3.3, así como de los Diagramas de Flujo de Datos de la Sección 3.4, emerge la necesidad de almacenar los datos extraídos en unas tablas. La tecnología utilizada para ello es Google SpreadSheets, una herramienta de hojas de cálculo basada en web. Sus funcionalidades son muy similares al popular software de Microsoft Excel. Ello sumado a que únicamente la utilizaremos como almacén de datos, provoca que no sea necesaria una explicación de las funcionalidades más complejas que puede ofrecer esta herramienta. Se mencionan a continuación las características que han hecho que nos decantemos por esta herramienta frente a sus alternativas: Está basada en web. Lo que nos permite una mayor accesibilidad de los datos a través de la red. Google ofrece esta herramienta de manera gratuita. Existen conectores tanto con las tecnologías del core (Node.js) como con las tecnologías de visualización (Data Studio). Esto facilita la integración de todos los componentes del sistema. Precisamente, esta última característica es la que hace que esta herramienta sea tan potente. La conexión de los sheets de Google con Data Studio se hace en cuestión de segundos. Sin embargo, la publicación de los datos extraídos mediante Puppeteer en estas hojas de cálculo es una tarea más compleja que precisa de una tecnología intermedia: las Google APIs. Se trata de Interfaces desarrolladas por Google para integrar sus servicios con otros servicios. En el caso de nuestros sistemas basados en Node.js, nos interesa la API de Google Sheets para realizar peticiones simples desde Node.js a nuestras hojas de cálculo. Gracias a eso nuestro bot podrá leer datos históricos almacenados en las hojas, así como actualizar los datos recogidos en estas tablas. Más adelante se detalla cómo se han implementado estas funcionalidades gracias a la documentación [Gsh]. 4.2.4. Data Studio Sin salir de las herramientas ofrecidas por Google, se ha escogido Data Studio como herramienta de visualización de los datos de los sistemas. Es una herramienta que permite crear informes y dashboards a partir de distintas fuentes de datos. Constituirá la parte final del desarrollo y será la única parte visible de los sistemas para los usuarios finales. Son muchas las bondades que tiene esta herramienta, las principales por las que se ha elegido son: 40 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Posee conexión directa con Spreadsheets de Google. Es gratuita. Permite generar informes a partir de distintas fuentes. Lo que será útil para combinar las tablas del Sistema de Rendimiento. Fácil de compartir información y colaborar. Gran interactividad con los gráficos. Para resumir, es una herramienta de bajo coste que cumple con todos los Requisitos Funcionales y No Funcionales referidos a la visualización. 4.3. Diseño El Diseño constituye la siguiente fase del SDLC en la que el desarrollador y el usuario interactúan para concretar cómo va a operar el sistema [JSV17]. Gracias a la información recopilada y generada en las fases previas de Análisis y Planificación, en la fase del Diseño se plantea la solución final que se quiere desarrollar, utilizando las tecnologías seleccionadas y teniendo en cuenta esos requisitos funcionales, no funcionales y los flujos de datos de las fases previas. Además, al Diseño le sucede la fase de Desarrollo del sistema propiamente dicho, por ello se deben especificar claramente todas las necesidades previas a la configuración de cada tecnología. Como se viene haciendo en este TFG, también separaremos la fase de Diseño para las 2 soluciones: el Sistema de Licencias y el Sistema de Rendimiento. 4.3.1. Sistema de Licencias A continuación, se detallan todas las actividades llevadas a cabo durante la fase de Diseño del Sistema de Licencias. Visión del Sistema de Licencias Para diseñar un sistema, es fundamental definir los elementos que lo conforman, las tecnologías que utilizan y cómo interactúan e intercambian datos. Por ello, es muy importante tener en cuenta los Diagramas de Flujo de Datos generados durante la fase del Análisis en la Sección 3.4. Partiendo del DFD de nivel 0 de la Figura 3.6 se diseña el Sistema de Licencias que vemos en la Figura 4.1. Se puede comprobar que está compuesto de 4 elementos principales (en cajas redondeadas) que interactúan entre ellos para el correcto funcionamiento. Esta relación entre los elementos se representa mediante flechas. Observamos dos tipos de flechas. Las flechas continuas representan acciones que un elemento realiza sobre otro. Las flechas discontinuas representan el intercambio de datos entre elementos. 4.3. DISEÑO 41 Report Tealeaf Dataset en Google Sheets Dashboard en Data Studio Proyecto Node.JS zAdmin Organization 1 Organization 2 Navegación Automatizada Fuente de datos Leer datos Actualizar datos Datos de la tabla (HTML) Figura 4.1: Visión del Sistema de Licencias. Elaboración propia. Cada uno de los elementos constituye una parte del sistema y utiliza diferentes tecnologías. El elemento principal del sistema es el Proyecto Node.js que engloba todos los ficheros JavaScript necesarios para la creación del bot de Puppeteer. En la sección de Desarrollo veremos cómo está configurado este proyecto. Lo que se extrae de la Figura 4.1 es que este elemento, a través de una navegación automatizada, interactúa con el elemento Report de Tealeaf y obtiene los datos de la tabla HTML que está en la web. Por otro lado, el elemento se interrelaciona con el Dataset de Google Sheets leyendo los datos históricos almacenados y actualizando la tabla de datos con los nuevos datos. Por último, el elemento Dashboard en Data Studio utiliza las tablas del Dataset como fuente de datos. En los siguientes apartados se profundiza en el diseño de cada uno de los elementos que conforman el sistema. Diagrama de Flujo del programa El proyecto de Node.js finalmente se materializa en un programa que deberá llevar a cabo diferentes acciones de la lógica del sistema. Estas acciones se producirán de manera secuencial y antes de programarlas es preciso diseñar el flujo que deberá seguir el programa. Esto es lo que se representa en la figura 4.2 La Figura 4.2 representa la secuencia del programa que constituye el núcleo del Sistema de Licencias. Se ha elaborado teniendo en cuenta que será implementado en Node.js a través de programación asíncrona y que debe de ir en concordancia con los Diagramas de Flujo de Datos de nivel 0 y de nivel 1 elaborados en la Sección 3.4. En azul se representan las acciones oestados de actividad y en amarillo los nodos de decisión. 48 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Dataset desde el punto de vista de Google Sheets. Son los datos que extrae y almacena el sistema. Está compuesto únicamente por campos originales. Dataset desde el punto de vista de Data Studio. Incluye todos los valores que son susceptibles de utilizarse en las gráficas de visualización. Esto son tanto los campos originales como las métricas calculadas. Los campos asociados a los tiempos generales constituyen el conjunto de datos denominado general_performance. El desglose de los tiempos de render y sus campos asociados se recogen en el conjunto de datos denominado processing_detallado. A continuación representamos los tablas para cada dataset desde el punto de vista de Data Studio. Tabla 4.2: Dataset: general_performance Campos Originales Campo Tipo Descripción 01_redirectTime_avg Número Tiempo promedio transcurrido desde que comienza una redirección hasta que se recibe el último byte de la respuesta de la última redirección. 01_unloadTime_avg Número Tiempo promedio transcurrido desde que el navegador comienza la descarga (unload) del documento previo hasta que la finaliza. 02_appCacheTime_avg Número Tiempo promedio que emplea en recuperar recursos de cualquier caché de aplicación relevante. 03_DnsTime_avg Número Tiempo prmedio empleado para la resolución de nombres de dominio. Coincidirá con el 02_appCacheTime si la resolución de nombres se recupera a través de la caché. 04_TcpTime_avg Número Tiempo promedio que se tarda en establecer la conexión con el servidor para obtener el documento. 05_requestTime_avg Número Tiempo promedio que transcurre desde que el navegador comienza su petición HTTP del documento hasta que recibe el primer byte de la respuesta del servidor. 06_responseTime_avg Número Tiempo promedio que transcurre en el navegador entre la recepción del primer byte y el último byte de la respuesta del servidor. 4.3. DISEÑO 49 Continuación de la Tabla 4.2 Campo Tipo Descripción 07_processingTime_avg Número Tiempo promedio desde que el navegador comienza el parseo de documento hasta que termina de cargar todos los recursos asociados al mismo. 08_onLoadTime_avg Número Tiempo promedio de duración del even- to onLOAD. Durante este tiempo se ejecutan los scripts asociados a este evento. country País País asociado a los tiempos. date Texto Fecha asociada a los tiempos. day_hour Fecha Día y Hora asociados a los tiempos. last_change Fecha y Hora Fecha y Hora de la última actualización de datos realizada sobre una fila concreta de la tabla ocurrences Número Tamaño de la muestra sobre el que se realiza el promedio de cada tiempo platform Texto Plataforma asociada a los tiempos. row Número Fila de la tabla del Report de Tealeaf asociada a los tiempos Métricas Calculadas 01_redirectTime_total_avg Número Métrica final que se representa en las gráficas. Consiste en calcular el tiempo según el peso que tenga a la contribución total de la media. Se calcula como: SUM(01_redirectTime_avg * ocurrences) / SUM(ocurrences) 01_unloadTime_total_avg Número SUM(01_unloadTime_avg * ocurrences) / SUM(ocurrences) 02_appCacheTime_total_avg Número SUM(02_appCacheTime_avg * ocurrences) / SUM(ocurrences) 03_DnsTime_total_avg Número SUM(03_DnsTime_avg * ocurrences) / SUM(ocurrences) 04_TcpTime_total_avg Número SUM(04_TcpTime_avg * ocurrences) / SUM(ocurrences) 05_requestTime_total_avg Número SUM(05_requestTime_avg * ocurrences) / SUM(ocurrences) 06_responseTime_total_avg Número SUM(06_responseTime_avg * ocurrences) / SUM(ocurrences) 50 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Continuación de la Tabla 4.2 Campo Tipo Descripción 07_processingTime_total_avg Número SUM(07_processingTime_avg * ocurrences) / SUM(ocurrences) 08_onLoadTime_total_avg Número SUM(08_onLoadTime_avg * ocurrences) / SUM(ocurrences) totalTime_avg Número (01_redirectTime_total_avg + 02_appCacheTime_total_avg + 03_DnsTime_total_avg + 04_Tc- pTime_total_avg + 05_request- Time_total_avg + 06_response- Time_total_avg + 07_processing- Time_total_avg + 08_onLoadTi- me_total_avg) Tabla 4.3: Dataset: processing_detallado Campos Originales Campo Tipo Descripción 01_domLoadingToDom- Interactive_avg Número Tiempo promedio desde que el navegador comienza el parseo de documen- to (domLoading) hasta que termina de parsear y todos los recursos bloqueantes. 02_domInteractiveToDomCon- tentLoadedEventStart_avg Número Tiempo promedio desde que la página es interactiva (domInteractive) hasta que se completa la ejecución de los scripts que fueron cargados con defer (domContentLoadedEventStart). 03_domContentLoadeEvent- StartToDomContentLoaded- EventEnd_avg Número Tiempo promedio de ejecución de los scripts asociados al evento domContentLoaded. 04_domContentLoadedEvent- EndToDomComplete_avg Número Tiempo prmedio que tardan en cargarse el resto de recursos no mencionados de la página (imágenes, ficheros, css no bloqueante, etc.). 05_domCompleteToLoad- EventStart_avg Número Tiempo promedio que transcurre entre domComplete y onLoadEventStart que marca el inicio del evento onLOAD. 4.3. DISEÑO 51 Continuación de la Tabla 4.3 Campo Tipo Descripción 07_processingTime_avg Número Tiempo promedio desde que el navegador comienza el parseo de documento hasta que termina de cargar todos los recursos asociados al mismo. country País País asociado a los tiempos. date Texto Fecha asociada a los tiempos. day_hour Fecha Día y Hora asociados a los tiempos. last_change Fecha y Hora Fecha y Hora de la última actualización de datos realizada sobre una fila concreta de la tabla ocurrences Número Tamaño de la muestra sobre el que se realiza el promedio de cada tiempo platform Texto Plataforma asociada a los tiempos. row Número Fila de la tabla del Report de Acoustic asociada a los tiempos Métricas Calculadas 01_domLoadingToDom- Interactive_total_avg Número Métrica final que se representa en las gráficas. Consiste en calcular el tiempo según el peso que tengan a la contribución total de la media. Se calcula como: SUM(01_domLoadingToDom- Interactive_avg * ocurrences) / SUM(ocurrences) 02_domInteractiveToDom- ContentLoadedEventStart- _total_avg Número SUM(02_domInteractiveToDomCon- tentLoadedEventStart_avg * ocurrences) / SUM(ocurrences) 03_domContentLoadeEvent- StartToDomContentLoaded- EventEnd_total_avg Número SUM(03_domContentLoadeEvent- StartToDomContentLoaded- EventEnd_avg * ocurrences) / SUM(ocurrences) 04_domContentLoadedEvent- EndToDomComplete_total- _avg Número SUM(04_domContentLoadedEvent- EndToDomComplete_avg * ocurrences) / SUM(ocurrences) 05_domCompleteToLoad- EventStart_total_avg Número SUM(05_domCompleteToLoad- EventStart_avg * ocurrences) / SUM(ocurrences) 07_processingTime_total_avg Número SUM(07_processingTime_avg * ocurrences) / SUM(ocurrences) 52 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Diseño de gráficos de visualización Desde el departamento de Web Performance Optimization se describieron los puntos que debían seguir los informes de visualización. Tras un intercambio de correos la propuesta inicial era la siguiente: Poder sacar informes (exportar en PDF desde Google Data Studio) y enviarlos cada 2 semanas. Poder dar acceso a otros departamentos (ya sea de Web, Medición o Informática) para su consumo propio. (A medio plazo) Poder relacionarlo con métrica Core Web Vitals de Google. El objetivo impuesto era ”Por vuestro lado habíamos pensado en mostrar el desglose de los tiempos de carga (y poder segmentarlo por dispositivo/país). Y en una página control inicial que ofrezca las peores/mejores combinaciones”. En base a esto, el equipo de WPO propuso un primer diseño de los informes basándose en las gráficas disponibles en Acoustic. A continuación, en las Figuras 4.6 y 4.7 se muestran estas primeras propuestas. Figura 4.6: Diseño del informe de tiempos generales propuesto por el equipo de WPO. En cuanto al informe inicial que se menciona, el proceso de diseño era más abierto y recaía sobre mi lado. Se decidió que constaría de 3 partes: 4.4. IMPLEMENTACIÓN 53 Figura 4.7: Diseño del informe de tiempos de render propuesto por el equipo de WPO. En la primera parte, unas gráficas que mostrasen los datos de las plataformas con mejores tiempos. En la segunda parte, unas gráficas que mostrasen los datos de los países con mejores tiempos. En una tercera parte, se crearía una tabla de doble entrada (o matriz) que mostrase las mejores y peores combinaciones de país/plataforma 4.4. Implementación La Implementación es la fase más costosa y la que más tiempo consume de todo el SDLC. En esta fase, las especificaciones físicas del diseño deben convertirse en código, que debe ser testado hasta que la mayoría de los errores hayan sido detectados y corregidos. En los dos siguientes apartados se pretende documentar esta etapa del desarrollo software para las dos soluciones que nos conciernen. Se trata de un contenido con mayor carácter técnico que el visto hasta ahora. Sin embargo, el objetivo es dar una visión global de las principales configuraciones que se han tenido que llevar a cabo para la creación de los sistemas. 4.4.1. Sistema de Licencias Durante esta etapa del desarrollo, se ha hecho un uso constante de todos los diagramas, tablas y requisitos producidos durante las fases previas. Así pues, para la implementación del Sistema de Licencias será muy importante tener siempre en mente la visión del sistema 54 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN de la Figura 4.1 y del diagrama del flujo del programa de la Figura 4.2. El contenido se ha dividido en diferentes apartados que siguen el orden lógico de la secuencia de las acciones del sistema. Conexión con la API de Google Sheets Como paso previo al desarrollo del script, será necesario habilitar el cliente de la API de Google Sheets a través de nuestra cuenta de Google. Este paso tan sólo se realizó una vez y es válido para poder usar esta API en nuestras dos soluciones. Los pasos son los siguientes: 1. Vamos a https://console.developers.google.com y creamos un proyecto con nuestra cuenta de Google. 2. Clicamos en el proyecto y habilitamos la API de Google Sheets. 3. Creamos las credenciales asociadas al proyecto. Vemos un ejemplo en la Figura 4.8. Figura 4.8: Credenciales necesarias para habilitar la API de Google Sheets. 4. Descargamos el fichero XXX.json que se genera. Lo movemos a nuestra carpeta de trabajo y lo renombramos como keys.json. 5. Con nuestra cuenta de Google debemos crear un spreadsheet y una Hoja que será nuestro conjunto de datos. Importante: De la URL obtenemos el spreadsheetId que es un identificador único. Debemos tener en cuenta el nombre de la hoja que vamos a editar. Por ejemplo, Hoja 1. Hay que dar permisos de edición del sheet al client mail creado en el paso anterior. En nuestro caso: servicemanlicencias-305208.iam.gserviceacount.com 4.4. IMPLEMENTACIÓN 55 Creación del proyecto de Node.js El primer paso para poder desarrollar un proyecto de Puppeteer, como es lógico, es tener instalado el programa Node.js e instalar la librería de Puppeteer. Hay que tener en cuenta que la programación es asíncrona, por lo que se ha sido muy cuidadoso a la hora de gestionar los tiempos de espera y se ha puesto mucho énfasis en la robustez del código. El proyecto consta de varios ficheros: licencias.js: es el fichero principal que implementa toda la lógica del programa. keys.json: ficheros con las credenciales necesarias para utilizar el cliente de la API de Google Sheets y que el programa pueda editar las hojas de cálculo. config.json: fichero con los principales parámetros de configuración del sistema. Más adelante se le dedica un apartado. Otros ficheros de configuración del proyecto: package.json,package-lock.json y el directorio node_modules. Sobre estos ficheros no entraremos porque se generan de manera automática. El desarrollo de licencias.js implementa la secuencia descrita en la Figura 4.2. Se ha utilizado tanto la documentación de puppeteer [Pup] como la de Google APIs [Gsh]. Sus partes más importantes son: 1. Simular la navegación en Chrome hasta la URL que contiene los datos. Para ello hay que: a)Instanciar un nuevo navegador y lanzar una nueva página. Lo vemos en la Figura 4.9. Al lanzar el navegador se pueden configurar parámetros como las dimensiones de la pestaña, si estará o no visible, el tipo de navegador y un path para cargar datos de usuario del navegador. Figura 4.9: Código JavaScript para instanciar un navegador. b)Simular navegación hasta los datos. Para acceder a la tabla del consumo de licencias de, por ejemplo, la 5ªorganización de Acoustic hay que seguir los siguientes pasos: Login >Click en la Organización nº5 >Click en Usuario >Click en Admin >Click en MMI Report. Esto se consigue mediante un análisis exhaustivo del código HTML de las páginas por las que queremos navegar y haciendo 56 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN un uso adecuado de los métodos page.click(),page.type(),page.goto() opage.waitForSelector(), entre otros. Además, como buena práctica de desarrollo software, se ha creado una función por cada tarea del programa. Esta parte del proceso se ejecuta a través de las funciones: 1) async function login(page, usr,pswd, loglevel). Simula el proceso de login en la web de Acoustic haciendo uso de los parámetros de usuario y contraseña que recibe. 2) async function tabledata(page, org, loglevel). Comprende toda la simulación de la navegación descrita arriba hasta la tabla de datos. El parámetro org sirve para seleccionar la organización de la que queremos extraer los datos. Además, como se especificó en el diagrama de flujo, si se falla en el primer intento de acceder hasta la tabla se vuelve a llamar una segunda vez a esta función. Si todo ha ido bien, hemos conseguido llegar hasta la tabla que vimos en la Figura 4.3 2. Lectura de datos. En este caso, como vemos en la Figura 4.10, la tabla tiene un identificador único: #mmiGrid. Esta tarea del programa se ha separado también en una función:async function dataexport(page,loglevel). En esta función esperamos a que aparezca el selector #mmiGrid y mediante el método page.evaluate() pasamos un callback donde añadimos el código necesario para obtener los datos que guardamos en la variable data. Lo hacemos a través de un bucle for que extrae todos los datos de las celdas de la tabla. Lo vemos en la Figura 4.11. Figura 4.10: Tabla web que contiene los datos de licencias en la página de Acoustic. Figura 4.11: Porción de código dentro de la función que extrae datos del HTML. 4.4. IMPLEMENTACIÓN 57 3. Actualización de los datos en el sheet de Google. Antes de programar esta acción, es importante tener habilitada la API de Google Sheets tal y como se ha descrito en el apartado anterior. Superado eso, en el script se programan las siguientes acciones. a)Importar la API de GSheets y las credenciales del cliente como se muestra en la Figura 4.12. Figura 4.12: Importar la API de GSheets y las credenciales del cliente. b)Crear el cliente y comprobar que autenticamos sin errores. Se detalla en la Figura 4.13. Figura 4.13: Instanciación del cliente y comprobación de autenticación. c)En caso de autenticación correcta, podemos realizar acciones sobre el Sheet de Google. Esto lo hacemos a través de la función async function gsupdate(cl, input, organization, loglevel). Primero, hay que leer los datos que hay en la la hoja Meses como vemos en la Figura 4.14. Luego hay que adecuar los datos que queremos añadir o modificar (a través de la función function compare(oldvalues, res)). Esta función compara los datos antiguos de la tabla tras leerlos (oldvalues) con los datos nuevos extraídos de la web (res). En caso de que haya diferencias entre ambos, habrá que actualizar las filas de la tabla que tengan 64 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN una línea roja. Finalmente, en la parte inferior del informe se sitúan 9 gráficas de evolución temporal de cada uno de los tiempos que contribuyen al tiempo total. Se indica también el tiempo medio de cada uno en un recuadro gris. Como podemos ver, la mayor contribución al tiempo de carga es el Processing Time, por ello la necesidad de desglosarlo en el segundo informe. Redirect Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 20 40 60 Unload Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 0.5 1 1.5 App Cache Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 10 20 30 DNS Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 10 20 30 TCP Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 20 40 60 Request Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 200 400 600 Response Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 50 100 150 Processing Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 500 1K 1.5K onLoad Time (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 2 4 6 Acoustic Tiempo de Carga Avanzado Apr 25, 2021 - May 8, 2021 ▼ Plataforma ▼ País ▼ Sesiones totales. 4.6M 10.4% 32.99 ms 1.13 ms 22.4 ms 23.47 ms 85.47 ms 55.38 ms 440.57 ms 1,336.6 ms 2.55 ms A pr 25, 2021 A pr 26, 2021 A pr 27, 2021 A pr 28, 2021 A pr 29, 2021 A pr 30, 2021 May 1, 2021 May 2, 2021 May 3, 2021 May 4, 2021 May 5, 2021 May 6, 2021 May 7, 2021 May 8, 2021 0 1K 2K 3K (ms) Total Time (avg) 1,999.44 Figura 4.21: Informe de tiempos generales del Sistema de Rendimiento. 4.4. IMPLEMENTACIÓN 65 Informe del processing time detallado. Este informe sigue exactamente la misma estructura que el anterior, pero únicamente para los tiempos que contribuyen al processing time. Lo vemos en la Figura 4.22. La necesidad de este informe surge de profundizar en este tiempo de procesamiento, que es el más crítico entre los tiempos de carga de una página web. domLoadingToDomInteractive (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 200 400 600 800 domInteractiveToDomContentLoade… Apr 25 Apr 28 May 1 May 4 May 7 0 25 50 75 100 domContentLoadeEventStartToDom… Apr 25 Apr 28 May 1 May 4 May 7 0 10 20 30 domContentLoadedEventEndToDom… Apr 25 Apr 28 May 1 May 4 May 7 0 200 400 600 800 domCompleteToLoadEventStart (avg) Apr 25 Apr 28 May 1 May 4 May 7 0 1 2 3 Acoustic Processing Time Detallado Apr 25, 2021 - May 8, 2021 ▼ Plataforma ▼ País ▼ Sesiones totales. 4.6M 10.4% 560.14 ms 73.44 ms 26.02 ms 679.34 ms 0.74 ms Apr 25, 2021 Apr 26, 2021 Apr 27, 2021 Apr 28, 2021 Apr 29, 2021 Apr 30, 2021 May 1, 2021 May 2, 2021 May 3, 2021 May 4, 2021 May 5, 2021 May 6, 2021 May 7, 2021 May 8, 2021 0 500 1K 1.5K 1,436.86 msProcessing Time (avg) Figura 4.22: Informe del processing time detallado. 66 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Informe de Control. El diseño de este informe no estaba tan definido, aunque sí los datos que se querían mostrar. En la Figura 4.23 se muestra el resultado final. Plataforma Acoustic Control Tiempo de Carga Avanzado Apr 25, 2021 - May 8, 2021 ▼ Plataforma ▼ País ▼ 0 500 1K 1.5K 2K 2.5K Bot Desktop Web Mobile Web País 0 1K 2K 3K 4K united states mexico spain germa… costa rica Mobile Web Desktop Web Bot Android (App) 33.1% 64.4% Tiempo Total (ms) Sesiones united states mexico spain germany costa rica others 37.5% 22.3% 21.8% Top 5 - Tiempo Total (ms) Top 5 - Sesiones Al menos 30 sesiones Al menos 30 sesiones País Al menos 30 sesiones Bot Desktop Web Mobile Web malta san m… monaco tunisia bermu… latvia virgin i… gibraltar iceland --------- - 646.26 - 913.53 931.08 979.23 - 1,302.85 1,054.6 591.52 - 647.07 - - - 1,011.41 873.48 - País / Tiempo Total Platform 1,448.56 1,652.83 2,192.39 591.52 646.26 647.07 913.53 931.08 979.23 1,011.41 1,014.93 1,054.6 Grand total Grand total 1,995.19 Tiempo Total (ms) Mejores Combinaciones Mobile Web Desktop Web Bot korea (… singap… venezu… nigeria hong k… philipp… cape v… bahrain india - - 5,174.57 5,498.78 - - 5,498.7 1,426.17 4,765.37 8,452.73 7,386.26 7,904.1 8,338.5 6,440.37 5,664.58 5,869.52 10,140.33 4,916.33 --------- País / Tiempo Total Platform 2,192.39 1,652.83 1,448.56 8,452.73 7,386.26 6,602.32 6,490.74 6,440.37 5,664.58 5,620.38 5,258.79 4,874.42 Grand total Grand total 1,995.19 Peores Combinaciones Figura 4.23: Informe de Control de Tiempo de Carga del Sistema de Rendimiento. Como vemos, en la parte superior se vuelven a mostrar los 3 controles de filtrado de datos: rango de fechas, plataforma y país. En la parte superior se muestra el tiempo de carga total desglosado para las 3 plataformas principales. Además, en un diagrama de sectores, se completa la información representando 4.4. IMPLEMENTACIÓN 67 el volumen de sesiones que acumula cada plataforma sobre el total. De estas gráficas podemos interpretar que: si bien las sesiones realizadas con bot sobre la web bajo estudio son las que menores tiempos de carga experimentan, estas representan un volumen muy bajo de sesiones respecto del total. De forma análoga representamos los tiempos y el volumen de sesiones desglosados por países. Por último, en la parte inferior del informe, se muestran dos tablas de doble entrada (país/platforma) que mapean el tiempo total de carga. Las mejores combinaciones serán aquellas que tienen menores tiempos de carga (en verde) y las peores, las que tienen mayores tiempos de carga (en rojo). Por ejemplo, podemos descubrir que las sesiones móviles desde Malta tardan, en media, menos de 0,6 segundos en cargar la página, mientras que las sesiones realizadas desde ordenador en Baréin acumulan tiempos de carga promedio superiores a 10 segundos. 4.4.3. Ficheros config.json Como fase final del desarrollo, se decidió separar las variables más relevantes de cada proyecto en un fichero denominado config.json. Con esto se cumple el FR12 que decía que ”El sistema deberá incluir unos parámetros de configuración de la ejecución. Los podrá modificar eldesarrollador a través del ficheroconfig.json”. El uso de este tipo de ficheros es muy habitual en el desarrollo software de sistemas modernos, ya que permite centralizar todos los paramétros de configuración en un único lugar y hace los sistemas más flexibles desde el punto de vista del desarrollador. A modo de ejemplo, se proporciona la Figura 4.24 en la que se ven los parámetros que podemos configurar para la solución del Sistema de Licencias. Figura 4.24: Fichero de configuración config.json para el Sistema de Licencias. En la Figura 4.24, vemos como podemos configurar las credenciales que se usan en el login de Acoustic, la organización sobre la que queremos obtener los datos, diferentes opciones del navegador o el log_level, al cual dedicamos la siguiente Sección. 68 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN 4.4.4. Sistema de LOG En un esfuerzo por mejorar la calidad de la información que emite el script y como práctica para mejorar la depuración de la secuencia del programa, he configurado un sencillo sistema de LOG. Gracias a ello, cumplimos también con el NFR04. A través de la función: function setlog(page, level), se define la cantidad de información que va a emitir el programa al ejecutarse, a través del argumento level. Este nivel puede ser configurado por el usuario a través del valor log_level del fichero config.json. En la Figura 4.25, se representa la tabla que se creó para definir los diferentes niveles de LOG que se iban a implementar asociados a los eventos sobre los que se emitiría información. Figura 4.25: Eventos asociados a los diferntes niveles de LOG. Elaboración propia. Se diseñó un sistema de 5 niveles de información que son acumulativos. Es decir, si escogemos el nivel 2, se mostrarán los mensajes asociados al nivel 0, al nivel 1 y al nivel 2. Los niveles que recogen en la Figura 4.25 son los siguientes: log_level = 0 (rojo): errores fatales producidos en el navegador o en la lógica del programa que hacen imposible seguir con la secuencia. El sistema no se terminará de ejecutar en ningún caso. 4.4. IMPLEMENTACIÓN 69 log_level = 1 (naranja): errores en alguna función de la lógica del programa que podrían no terminar con su ejecución si está concebido dentro de la secuencia. log_level = 2 (verde): avances fluidos de la lógica del programa. Avisan de los clicks, las escrituras de campos, o los éxitos de ejecución de las funciones. log_level = 3 (azul): se muestran además los tiempos de espera de la secuencia del programa. log_level = 4 (morado): asociados con la información relativa a eventos relacionados con la simulación de la página del navegador. Para más información sobre los eventos del sistema de LOG, se recomienda leer la columna de description redactada en inglés. A modo ilustrativo, se muestran tres capturas de la información que proporciona la terminal al ejecutar el script en diferentes escenarios. En la Figura 4.26, se representa la salida por la terminal de la ejecución con errores de licencias.js, para un nivel 2 de LOG. En la Figura 4.27, se representa la salida de la terminal del mismo caso anterior, pero en este caso ejecutado sin errores. Podemos ver en la Figura 4.28 que la cantidad información que muestra por terminal, amplía para una ejecución con nivel 3 de LOG. Figura 4.26: Captura de la terminal al ejecutar licencias.js con un nivel 2 de LOG y para unas credenciales incorrectas. Figura 4.27: Captura de la terminal al ejecutar sin errores licencias.js con un nivel 2 de LOG 70 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Figura 4.28: Captura de la terminal al ejecutar sin errores licencias.js con un nivel 3 de LOG 4.5. Despliegue A través del proceso de Despliegue se consigue que los sistemas de información desarrollados estén en funcionamiento y disponibles para su uso. Por la metodología de desarrollo de la empresa, esta fase es llevada a cabo por el Equipo de Sistemas y no por los Desarrolladores. Es por ello que esta fase no es contenido de este TFG. El despliegue de los sistemas tiene pensado llevarse a cabo en una de las máquina de la infraestructura interna de la empresa. La intención es ubicar los proyectos en una de esas máquinas y lanzarlos con cierta periodicidad a través de un software de programación de tareas. El despliegue de los sistemas está planteado realizarse en el corto plazo por no suponer a penas un incremento del uso de recursos. 4.6. Conclusiones Con este Capítulo se pone fin a las fases de desarrollo de los sistemas implementados durante el Trabajo de Fin de Grado. Sin duda las fases de Diseño y Desarrollo han sido las que han concentrado la mayor parte de los esfuerzos. Además, es importante mencionar que, en muchos de los casos, estas fases han sucedido de forma paralela e iterativa. Por ejemplo, nos dimos cuenta de que necesitábamos representar algún dato a mayores en los informes una vez estaban desarrollados los scripts, lo que provocó modificaciones sobre todos los elementos del sistema (incremento de los datos mostrados en la web, incremento de las columnas de la tabla, incremento de filas de datos, etc.). 4.6. CONCLUSIONES 71 Aunque no se ha mencionado, se han encontrado algunos obstáculos durante la etapa de Desarrollo. El mayor de ellos fue el fallo que se producía al simular el login en Acoustic, ya que utiliza procesos de autenticación en dos pasos. Esto obligó a cargar las cookies del usuario en el navegador para conservar datos del usuario y conseguir sobrepasar este proceso. Otro de los problemas que más se ha manifestado durante el desarrollo del código es la difictultad de trabajar con funciones asíncronas, así como con simuladores de navegación. La red es dinámica y cambios en la conexión pueden provocar que la ejecución del mismo programa, en momentos distintos, provoque resultados distintos a causa de una conexión más lenta, por ejemplo. Esto ha hecho necesario una programación muy robusta a fallos y con un gran número de comprobaciones a lo largo delo flujo del programa. Por último, considero de gran relevancia mencionar el resultado de los informes finales. Todo el sistema que se ha construido por detrás para obtener los datos carece de sentido si no se consigue obtener valor de ellos. Los gráficos son el producto final y deben recibir la atención que merecen. Para su desarrollo hay que tener siempre en mente los requisitos impuestos por el usuario final. Además, en nuestro caso, teníamos reuniones periódicas para obtener feedback y reajustar los dashboards hasta obtener los que se han presentado en este Capítulo. Sin duda, los usuarios finales han quedado muy satisfechos y se ha conseguido obtener valor de los datos. Por ejemplo, gracias al informe del Sistema de Licencias de la Figura 4.17, el Equipo de Negocio ha detectado que, durante los dos últimos meses con datos, se ha sobrepasado la cuota de licencias, lo que ha desembocado en una serie de acciones encaminadas a revertir esta situación. 72 CAPÍTULO 4. DISEÑO E IMPLEMENTACIÓN Capítulo 5 Conclusiones y líneas de trabajo futuro 5.1. Conclusiones del trabajo realizado En los últimos años, las empresas están dirigiendo una parte importante de sus activos a la transformación digital y la automatización de procesos empresariales. Gracias a ello, las soluciones RPA se han ido haciendo un hueco de unos años a esta parte adquiriendo una importancia cada vez mayor. En este Trabajo de Fin de Grado, se ha mostrado todo el proceso llevado a cabo para la creación de dos soluciones de esta naturaleza como resultado de una combinación de diferentes tecnologías actuales. En primer lugar, queda demostrado que, gracias a la inmensa cantidad de tecnologías disponibles en la actualidad, es posible desarrollar este tipo de soluciones a coste casi nulo. Además, tras obtener los informes de visualización, uno se da cuenta de la relevancia que tiene presentar la información de una forma clara y fácil de interpretar. Los mismos datos, presentados de dos formas diferentes, aportan un valor muy distinto. Sin duda, el momento de interactuar con los informes completamente montados, es una de las cosas más emocionantes que he experimentado durante todo el desarrollo del sistema. Sin embargo, durante el camino también han aparecido obstáculos que ponían en entredicho el consecución del objetivo. El mayor de ellos, sin duda, ha sido el problema derivado de la doble autenticación que aplica Tealaeaf al realizar el login en su web. Su solución supuso un gran esfuerzo en entender qué ocurría y decidir qué alternativa era la menos mala. Aún en el estado actual del proyecto, este obstáculo impone ciertas limitaciones, sobre todo a la hora de automatizar la ejecución de los sistemas. El hecho de haber trabajado en JavaScript y, además, utilizando una programación asíncrona, ha supuesto un importante reto para mí, pues no sólo he sido capaz de producir todo el código, sino que lo he hecho a la vez que aprendía este lenguaje. Los errores más comunes al trabajar con este tipo de código que simula acciones del navegador son los que están relacionados con las situaciones cambiantes de la web. A veces la conexión es más lenta, a veces el HTML de una página es modificado, a veces un mismo proceso lleva más tiempo... Por todo ello, como se ha comentado previamente, he trabajado en producir un 73