Sistema de recomendaciones automáticas de soluciones basado en el ámbito de la gestión de incidencias

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA ESCOLA TÉCNICA SUPERIOR DE ENXEÑARÍA Sistema de recomendaciones automáticas de soluciones basado en el ámbito de la gestión de incidencias Autor: Javier Val Barbeira Directores: Purificación Cariñena Amigo Daniel Ríos Val Grao en Enxeñaría Informática Febreiro 2020 Traballo de Fin de Grao presentado na Escola Técnica Superior de Enxeñaría da Universidade de Santiago de Compostela para a obtención do Grao en Enxeñaría Informática Da. Purificación Cariñena Amigo, Profesora do Departamento de Electrónica e Computación da Universidade de Santiago de Compostela, e D. Daniel Ríos Val, Business Applications Engineer, en ES Field Delivery Spain S.L., INFORMAN: Que a presente memoria, titulada Sistema de recomendacións automáticas de solución baseado no ámbito da xestión de incidencias, presentada por D. Javier Val Barbeira para superar os créditos correspondentes ao Traballo de Fin de Grao da titulación de Grao en Enxeñaría Informática, realizouse baixo nosa dirección no Departamento de Electrónica e Computación da Universidade de Santiago de Compostela. E para que así conste aos efectos oportunos, expiden o presente informe en Santiago de Compostela, a 3 Febreiro de 2020: A directora, O codirector, O alumno, Purificación Cariñena Amigo Daniel Ríos Val Javier Val Barbeira i Agradecimientos A mi mujer, la Dra. Gemma Eibes González. Sin su apoyo, ánimo y paciencia infinita, habría sido imposible finalizar esta titulación. A mis hijos, Xabi y Antón, por disculpar las ausencias cuando tocaba desaparecer en épocas de exámenes. A mis compañeros de clase, por ’adoptarme’ con sorna, pero con cariño. Es de buena gente ayudar a las personas mayores. iii Índice general 1 Introducción 1 1.1 Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Objetivosgenerales.......................... 3 1.3 Detalletécnico ............................ 4 1.3.1 Tecnologías usadas . . . . . . . . . . . . . . . . . . . . . . 4 1.3.2 Metodología de desarrollo . . . . . . . . . . . . . . . . . . 5 1.4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . 5 2 Gestión del proyecto 7 2.1 Alcancedelproyecto ......................... 7 2.1.1 Entregables del proyecto . . . . . . . . . . . . . . . . . . . 7 2.1.2 Criterios de aceptación . . . . . . . . . . . . . . . . . . . . 8 2.1.3 Exclusiones del proyecto . . . . . . . . . . . . . . . . . . . 8 2.2 Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Estructura de Descomposición del Trabajo (EDT) . . . . . 9 2.2.2 Definición de actividades . . . . . . . . . . . . . . . . . . . 10 2.2.3 Planificación temporal (inicial) . . . . . . . . . . . . . . . 12 2.3 Gestión de la configuración . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Sistemas y herramientas de Gestión de la Configuración . . 17 2.3.2 Nomenclatura de ficheros . . . . . . . . . . . . . . . . . . . 18 2.3.3 Estructura del directorio del proyecto . . . . . . . . . . . . 19 2.3.4 Comunicación entre miembros del equipo . . . . . . . . . . 20 2.3.5 Gestión de cambios . . . . . . . . . . . . . . . . . . . . . . 21 2.4 Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1 Costes de recursos humanos . . . . . . . . . . . . . . . . . 21 2.4.2 Costes materiales . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.3 Costes de software . . . . . . . . . . . . . . . . . . . . . . 24 2.4.4 Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.5 Costetotal .......................... 24 2.5 Gestiónderiesgos........................... 24 2.5.1 Identificación de riesgos . . . . . . . . . . . . . . . . . . . 25 2.5.2 Análisis y evaluación de riesgos . . . . . . . . . . . . . . . 25 2.5.3 Matriz probabilidad impacto . . . . . . . . . . . . . . . . . 30 v 2.5.4 Acciones de prevención y contingencia . . . . . . . . . . . 30 2.5.5 Planificación temporal (real) . . . . . . . . . . . . . . . . . 33 3 Análisis de requisitos 35 3.1 Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . 35 3.1.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 36 3.1.2 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . 40 3.1.3 Matriz de dependencia entre requisitos . . . . . . . . . . . 42 3.2 Casosdeuso.............................. 42 3.2.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . 42 3.2.2 Plantillas de descripción textual . . . . . . . . . . . . . . . 43 3.2.3 Matriz de requisitos/casos de uso . . . . . . . . . . . . . . 52 4 Análisis de tecnologías y herramientas 53 4.1 Tecnologías empleadas en el desarrollo . . . . . . . . . . . . . . . 53 4.1.1 Librerías............................ 53 4.1.2 Frameworks.......................... 54 4.1.3 Virtualización......................... 54 4.1.4 Servidorweb ......................... 55 4.1.5 IDE de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.6 Lenguajes ........................... 55 4.2 Tecnologías empleadas en la documentación . . . . . . . . . . . . 55 5 Diseño e implementación 57 5.1 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Gestor de incidencias (módulo cliente) . . . . . . . . . . . . . . . 58 5.2.1 Capa lógica de negocio y presentación . . . . . . . . . . . . 61 5.2.2 Capa base de datos . . . . . . . . . . . . . . . . . . . . . . 66 5.2.3 Capa acceso a datos . . . . . . . . . . . . . . . . . . . . . 68 5.3 Securización mediante Spring Security . . . . . . . . . . . . . . . 70 5.4 Virtualización del sistema en contenedores Docker . . . . . . . . . 71 5.4.1 Adaptación del gestor para ejecución en contenedores . . . 76 5.5 Módulo recomendador de soluciones . . . . . . . . . . . . . . . . . 77 5.5.1 Cluster Elasticsearch . . . . . . . . . . . . . . . . . . . . . 77 5.5.2 Contenedor Logstash . . . . . . . . . . . . . . . . . . . . . 79 5.5.3 Contenedor Kibana . . . . . . . . . . . . . . . . . . . . . . 80 5.5.4 Configuración del pipeline de Logstash . . . . . . . . . . . 81 5.5.5 Creación del índice . . . . . . . . . . . . . . . . . . . . . . 84 5.5.6 Validación de búsquedas sobre Kibana . . . . . . . . . . . 90 5.6 Integración en el gestor . . . . . . . . . . . . . . . . . . . . . . . . 94 5.6.1 Visualización de recomendaciones . . . . . . . . . . . . . . 97 5.6.2 Incorporación de la recomendación en el Crud . . . . . . . 99 5.7 Elaboración del panel de control de seguimiento . . . . . . . . . . 99 vi 5.7.1 Acceso al índice desde Kibana . . . . . . . . . . . . . . . . 99 5.7.2 Creación de visualizaciones . . . . . . . . . . . . . . . . . . 101 5.7.3 Composición del panel de control . . . . . . . . . . . . . . 104 6 Conclusiones y trabajo futuro 107 6.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A Esquemas EDT y Gantt 111 A.0.1 Estructura de Descomposición del Trabajo (EDT) . . . . . 111 A.0.2 Esquemas Gantt . . . . . . . . . . . . . . . . . . . . . . . 113 B Manual de despliegue 115 B.1 Despliegue............................... 115 B.2 Ciclo de una incidencia . . . . . . . . . . . . . . . . . . . . . . . . 121 C Manuales técnicos 125 C.1 Diagramas de clases del sistema gestor de incidencias. . . . . . . . 125 C.2 Árbol de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 C.3 Índice recomendador . . . . . . . . . . . . . . . . . . . . . . . . . 127 C.4 Enlace descarga Imagen Centos 7 . . . . . . . . . . . . . . . . . . 130 Bibliografía 133 vii Tabla 3.10 Requisito funcional RQF-09 . . . . . . . . . . . . . . . . . . 39 Tabla 3.11 Requisito funcional RQF-10 . . . . . . . . . . . . . . . . . . 39 Tabla 3.12 Requisito funcional RQF-11 . . . . . . . . . . . . . . . . . . 39 Tabla 3.13 Requisito funcional RQF-12 . . . . . . . . . . . . . . . . . . 40 Tabla 3.14 Requisito no funcional de rendimiento RNF-01 . . . . . . . 40 Tabla 3.15 Requisito no funcional de rendimiento RNF-02 . . . . . . . 41 Tabla 3.16 Requisito no funcional de disponibilidad RNF-03 . . . . . . 41 Tabla 3.17 Plantilla de descripción textual . . . . . . . . . . . . . . . . 44 Tabla 3.18 Descripción textual CU-01 . . . . . . . . . . . . . . . . . . 44 Tabla 3.19 Descripción textual CU-02 . . . . . . . . . . . . . . . . . . 45 Tabla 3.20 Descripción textual CU-03 . . . . . . . . . . . . . . . . . . 45 Tabla 3.21 Descripción textual CU-04 . . . . . . . . . . . . . . . . . . 46 Tabla 3.22 Descripción textual CU-05 . . . . . . . . . . . . . . . . . . 47 Tabla 3.23 Descripción textual CU-06 . . . . . . . . . . . . . . . . . . 48 Tabla 3.24 Descripción textual CU-07 . . . . . . . . . . . . . . . . . . 49 Tabla 3.25 Descripción textual CU-08 . . . . . . . . . . . . . . . . . . 50 Tabla 3.26 Descripción textual CU-09 . . . . . . . . . . . . . . . . . . 51 xiv Capítulo 1 Introducción 1.1. Motivación del proyecto La mayoría de las corporaciones o grandes proyectos tienen sistemas de ayuda para que sus empleados, clientes o usuarios puedan hacer un correcto uso de los productos o servicios aportados. Estos sistemas de ayuda son atendidos por un sistema de soporte que recopila las incidencias comunicadas para que sean solucionadas por un equipo de técnicos especializados. Cuando el sistema está correctamente organizado, se presentan varios niveles de asistencia, siendo el nivel N1 aquel que está en contacto directo con el usuario, y que recopila y soluciona la incidencia trivial, escalando a un nivel superior (N2) aquellas incidencias para las que no se ve capacitado. Es en este nivel secundario donde un técnico especialista recoge los tickets1asignados y los resuelve o escala en mayor o menor tiempo según su conocimiento. En casi todos estos sistemas, se recomienda al técnico que detalle la solución aplicada para potenciales auditorías ante resultados no esperados o para ser replicada posteriormente. Muchas veces, los técnicos más noveles son incapaces de resolver ciertas incidencias usuales debido a la falta de experiencia en determinadas áreas, haciéndose necesario el consejo o intervención de un técnico senior capacitado para resolver la incidencia. Esto desemboca en una dilatación de los tiempos de resolución de incidencias, que pueden llegar a perjudicar los SLA 2del centro de soporte. Lo que buscamos en este proyecto es recopilar esa base de conocimiento de 1Un ticket hace referencia a la anotación de una incidencia en un sistema gestor de incidencias. Un ticket presenta dos estados, abierto (o en proceso) y cerrado (resuelto). El ticket permanecerá abierto durante todo el seguimiento de la incidencia hasta que se haya resuelto la incidencia 2Acuerdo de nivel de servicio: contrato que describe el nivel de servicio que un cliente espera de su proveedor 1 2CAPÍTULO 1. INTRODUCCIÓN tickets resueltos y ponerla a disposición de todos los técnicos, de manera ágil, para que sea aplicable instantáneamente y reduzca los tiempos de resolución de incidencias, desde que se notifican, hasta que son cerradas por alguno de los niveles del servicio de soporte. Figura 1.1: Representación del Recomendador de Soluciones En la imagen podemos observar como ante una incidencia, el técnico de primer nivel N1 toma nota de esta mediante un gestor de incidencias. El gestor almacena dicha incidencia abierta en una base de datos MySQL[1], a la espera de un técnico de nivel superior, capacitado para su resolución. Esta resolución se puede producir en más o menos tiempo dependiendo de la experiencia del técnico asignado. Las lineas rojas representarían una incidencia abierta (no solucionada). Vemos como nuestro sistema recomendador recoge las incidencias solucionadas y las pone a disposición del técnico de nivel N2 como recomendaciones de solución (lineas naranjas) cuando el técnico consulta sus incidencias abiertas. Una vez resuelta, la incidencia vuelve a la base de datos para ser archivada. 1.2. OBJETIVOS GENERALES 3 1.2. Objetivos generales El objetivo principal de este trabajo es implementar un sistema de recomendación capaz de complementar el proceso de resolución de incidencias, mediante una búsqueda de resoluciones ya aplicadas con un mayor nivel de coincidencia en el título del ticket. Este sistema debe ser adaptable a distintos clientes, sin un coste elevado. Para ello, será necesario abordar unos objetivos previos: Poner en funcionamiento un ecosistema Elasticsearch encargado de recopilar, almacenar, clasificar y ofrecer información sobre los tickets resueltos. Este ecosistema se compone de las herramientas Elasticsearch[2], logstash[3] y Kibana[4], que determinarán también sus objetivos en el proyecto. A este conjunto de herramientas se le conoce como stack ELK 3 Diseñar un sistema de extracción, transformación y carga de los ticket resueltos de la base de datos del cliente. Así como el diseño de un analizador y clasificador de los datos facilitados a la hora de almacenar estos en el índice de Elasticsearch. Para determinar la mejora en el proceso de solución de incidencias será necesario la evaluación y representación de los datos mediante un cuadro de mandos realizado en Kibana. Generación y configuración de un sistema básico de gestión de tickets, para la realización de pruebas y validación del correcto funcionamiento del stack ELK. Este gestor se realizará sobre una base de datos relacional MySQL, utilizando Spring Boot MVC[5] y Thymeleaf[6] sobre un patrón Modelo Vista Controlador[7], utilizando las complementos de Spring Boot JPA[8] Hibernate[9] y Spring Security[10]. Cuando grandes empresas optan a pliegos, concursos públicos o licitaciones, compiten en igualdad de condiciones, ya que la mayoría de ellas pueden dar respuesta de manera eficaz, a las solicitudes propuestas en los pliegos. La mayoría de dichas ofertas presentan un apartado que premia las características o mejoras que puede aportar una empresa aspirante al proyecto. De esta manera se gestó este sistema, como una característica diferenciadora e innovadora, que aportaría un valor añadido en una competición o concurso. 3ELK son las siglas identificativas para tres proyectos open source: Elasticsearch, Logstash y Kibana. Elasticsearch es un motor de búsqueda y analítica. Logstash es un pipeline de procesamiento de datos del lado del servidor que ingesta datos de una multitud de fuentes simultáneamente, los transforma y luego los envía a Elasticsearch. Kibana permite a los usuarios visualizar los datos en cuadros y gráficos con Elasticsearch. 4CAPÍTULO 1. INTRODUCCIÓN 1.3. Detalle técnico 1.3.1. Tecnologías usadas La consecución de estos objetivos ha sido posible utilizando las siguientes tecnologías, aplicaciones y lenguajes de programación:: Docker: [11] Docker es una plataforma de software que permite crear, probar e implementar aplicaciones rápidamente. Docker empaqueta software en unidades estandarizadas llamadas contenedores que incluyen todo lo necesario para que el software se ejecute, incluidas bibliotecas, herramientas de sistema y código. Elasticsearch: Es un motor de analítica y análisis distribuido, open source, para todos los tipos de datos, incluidos textuales, numéricos, geoespaciales, estructurados y desestructurados. Elasticsearch está desarrollado en Apache Lucene y es el componente principal del ELK Stack, un conjunto de herramientas open source para la ingesta, el enriquecimiento, el almacenamiento, el análisis y la visualización de datos. Logstash: Es una herramienta pensada originalmente para recolectar y analizar logs. En el proyecto se utilizará su versatilidad y los plugins disponibles para recolectar información de la base de datos del cliente y añadirlos a un índice. Llamaremos a este proceso ingesta de datos. Kibana: Es un panel de visualización de datos de código abierto para Elasticsearch. Proporciona capacidades de visualización sobre el contenido indexado en un clúster Elasticsearch. Json: [12] Es un formato basado en texto estándar para representar datos estructurados. Es comúnmente utilizado para transmitir datos en aplicaciones. Hibernate: Es una herramienta que facilita el mapeo de atributos en una base de datos tradicional, y el modelo de objetos de un aplicación mediante anotaciones en los beans de las entidades que permiten establecer estas relaciones. Thymeleaf: Motor de plantillas HTML (+XML), implementado sobre Java, sencillo de usar y totalmente integrado con Spring y el patrón MVC (modelo vista controlador). MySQL: Sistema de gestión de bases de datos relacional. En nuestro sistema también utilizaremos su programa de administración MySQL Workbench[13], herramienta visual que integra desarrollo de software, administración, gestión, diseño y mantenimiento de bases de datos. 1.4. ESTRUCTURA DE LA MEMORIA 5 Java: [14] lenguaje de programación independiente de la plataforma, con el que podemos realizar cualquier tipo de programa. En la actualidad es un lenguaje muy extendido y cada vez cobra más importancia tanto en el ámbito de Internet como en la informática en general. Maven: [15] Herramienta que estandariza la configuración de un proyecto en todo su ciclo de vida, como por ejemplo en todas las fases de compilación, empaquetado y distribución de librerías, para que puedan ser utilizadas por otros desarrolladores y equipos de trabajo. Spring Boot: [16] Framework que nace con la finalidad de simplificar el desarrollo de aplicaciones basadas en el framework Spring Core. En el sistema utilizaremos Spring Tool Suite 4, entorno de desarrollo basado en eclipse, customizado para implementar aplicaciones en Spring. YAML: [17] Es un formato de serialización de datos legible por humanos. En nuestro sistema lo utilizaremos para coordinar los múltiples contenedores docker, y que estos se comuniquen entre sí. Docker Compose: [18] Herramienta para definir y desplegar múltiples aplicaciones sobre contenedores docker. Mediante la utilización de un archivo de configuración yaml, se determinarán los servicios a desplegar. 1.3.2. Metodología de desarrollo Se ha optado por un modelo incremental[19], combinando elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. El modelo incremental avanza sumando funcionalidades a la aplicación a desarrollar, aplica secuencias lineales de forma escalonada, mientras progresa en el tiempo de desarrollo. Cada secuencia lineal produce un incremento en el software. En el capítulo 2 se desarrollará y argumentará esta decisión. 1.4. Estructura de la memoria Este documento está divido en capítulos en los que se tratan los siguientes temas: En este Capítulo 1 se hace una breve introducción al proyecto en la que se comentan la motivación del mismo, objetivos y un apartado de detalle técnico. En el Capítulo 2 se documenta todo lo relacionado con la gestión del proyecto: planificación temporal, estimación de costes y gestión de riesgos. 6CAPÍTULO 1. INTRODUCCIÓN En el Capítulo 3 se procederá con la fase de análisis funcional del proyecto, determinando requisitos y casos de uso. En el Capítulo 4 se documentan las tecnologías utilizadas, lenguajes e IDEs implicados, tanto en el desarrollo del sistema, como en la redacción de la documentación. En el Capítulo 5 se describe el proceso de diseño e implementación del sistema recomendador, así como su integración en el gestor de incidencias. Todo ello virtualizado en contenedores Docker. En el Capítulo 6 se comentan las conclusiones del trabajo, con la mirada puesta en posibles mejoras a desarrollar en un trabajo futuro. Se entregarán a modo de apéndices: Los diagramas de Gantt de cada incremento. El manual de despliegue de la aplicación y el ciclo de una incidencia. Los diagramas de clases del gestor de incidencias, su árbol de clases y el índice generado en Elasticsearch. Capítulo 2 Gestión del proyecto 2.1. Alcance del proyecto El objetivo es implementar un sistema de ingesta de datos configurable y adaptado a la base de datos del cliente, un sistema capacitado para recoger información de tickets de incidencias resueltas y almacenar estas soluciones en un índice de Elasticsearch. Este índice de soluciones debe ser accesible mediante consulta en tiempo real desde el gestor de tickets del cliente o aplicación equivalente, para ofrecer soluciones aplicables, desde el histórico de tickets resueltos, a las nuevas incidencias que se plantean. También se planifica el desarrollo de un panel de control que permita al cliente validar la implantación y uso del sistema recomendador de soluciones en su gestor de incidencias, así como otras métricas de su interés. Como módulo de pruebas, se plantea entregar un gestor básico de incidencias sobre una base de datos relacional, que integrará y validará todo el funcionamiento del sistema recomendador. 2.1.1. Entregables del proyecto Una vez finalizado el proyecto, se entregará lo siguiente: E1. Un gestor de incidencias básico, con roles y usuarios, capaz de un proceso CRUD1sobre las incidencias. También se entregará un conjunto de 1CRUD es el acrónimo de ’Crear, Leer, Actualizar y Borrar’ (del original en inglés: Create, Read, Update and Delete), que se usa para referirse a las funciones básicas en bases de datos o la capa de persistencia en un software. 7 8CAPÍTULO 2. GESTIÓN DEL PROYECTO incidencias de prueba, almacenadas en la base de datos relacional. E2. Un conjunto de scripts que permitan la virtualización de todo el sistema en contenedores docker. E3. Un conjunto de scripts que permitan generar, dentro de la virtualización anterior, un stack ELK, para la ingesta, indexación y visualización de datos. E4. Incorporación del sistema recomendador al gestor de incidencias. E5. Un panel de control en el que se muestra la implantación del sistema de recomendación mediante una serie de gráficas y estadísticas. E6. Memoria del proyecto y manual de despliegue del sistema. 2.1.2. Criterios de aceptación Se dará por finalizado el proyecto cuando se consigan los siguientes hitos: CA1. Se puede lanzar una ingesta de datos de incidencias recuperadas de la base de datos del cliente, que pasan a ser indexadas en un índice determinado de Elasticsearch. CA2. Ante la apertura de una nueva incidencia, el técnico asignado recibe una serie de recomendaciones de solución recuperadas del índice Elasticsearch. CA3. Ante el cierre de una nueva incidencia, esta es recuperada de la base de datos del cliente, transformada y almacenada en el índice de Elasticsearch. CA4. Disponemos de un panel de control en el que se muestra la implantación del sistema de recomendación mediante una serie de gráficas y estadísticas. 2.1.3. Exclusiones del proyecto Quedan fuera del alcance de este proyecto la generación de un gestor de tickets más allá de su uso para la validación del correcto funcionamiento del sistema, así como el diseño de la base de datos de tickets. Han sido desarrollados, gestor y base de datos, de una manera funcional, para facilitar la visualización del ciclo completo de un ticket. No han sido desarrollados buscando la robustez del sistema gestor, ni su completa funcionalidad. 2.2. PLANIFICACIÓN DEL PROYECTO 9 2.2. Planificación del proyecto Se determina un trabajo diario aproximado de 5 horas, de lunes a viernes, pudiéndose variar por causas justificadas la carga de un día, siendo recuperado en la misma semana el tiempo sacrificado. Esto implica unas 25 horas semanales de trabajo aproximadamente, estimando un total de 17 semanas para la conclusión del proyecto. En total implicaremos unas 425 horas que incluyen trabajo autónomo, reuniones informativas y de control, así como tutorías, evaluación de los avances y entregas. 2.2.1. Estructura de Descomposición del Trabajo (EDT) Mediante esta representación estructural (EDT)2procedemos a visualizar la planificación del proyecto, definiendo y organizando el alcance total aprobado. Observamos los principales conjuntos de actividades que determinan el trabajo a desarrollar. 2Consiste en la descomposición jerárquica del trabajo a ser ejecutado por el equipo de proyecto, para cumplir con los objetivos de éste y crear los entregables requeridos, donde cada nivel descendente de la EDT representa una definición con un detalle incrementado del trabajo del proyecto. 16 CAPÍTULO 2. GESTIÓN DEL PROYECTO Incremento 1: Implementación de Bases de datos y gestor de tickets Con una duración estimada de tres semanas, en este incremento se abordará la creación de la base de datos de tickets, así como las tablas necesarias para la gestión de usuarios y roles del gestor de tickets. Durante este incremento también se desarrollará todo el gestor de incidencias, controladores, vistas y accesos a repositorios. Se pueden consultar los gráficos Gantt de las tareas determinadas en estos incrementos en el apéndice C. Incremento 2: Migración del sistema a contenedores (virtualización) En este incremento, de duración estimada de 2 semanas, se procederá a migrar la base de datos y el gestor desarrollado en local a contenedores Docker, creando a su vez los contenedores necesarios para el stack ELK y la red que conectará todos ellos. Todo el sistema se virtualizará sobre una imagen de Centos 7. Incremento 3: Configuración y operatividad del entorno ELK Recuperando los contenedores creados sobre los que se despliega el stack de Elastic, Logstash y Kibana, procederemos a configurar la ingesta de datos, la creación del analizador y el índice. Posteriormente integraremos la consulta de búsqueda en el gestor, así como la representación de resultados. Incremento 4: Elaboración de un panel de control Como incremento final, con un tiempo estimado de una semana, se presenta el desarrollo de un panel de control en Kibana, que permitirá al cliente realizar un seguimiento de la implantación del sistema recomendador y su utilidad en la reducción de tiempo consumido en la resolución de cada ticket. 2.3. Gestión de la configuración Para el correcto desarrollo del proyecto se hace necesario llevar un control de cambios, así como disponer del versionado de cada nueva entrega. Estos procesos nos permitirán asegurar la calidad de todo el software desarrollado. 2.3. GESTIÓN DE LA CONFIGURACIÓN 17 2.3.1. Sistemas y herramientas de Gestión de la Configuración El código utilizado para la creación del gestor de tickets será controlado mediante un repositorio de github3. Para la gestión de los archivos del proyecto se utiliza una cuenta en Google Drive con un almacenamiento extendido de 100 GB con un coste de 2eal mes. Esto se debe a que se realizan copias periódicas de backup de la imagen virtualizada de Centos 7, para evitar posibles errores de corrupción, y facilitar el trabajo remoto en múltiples ordenadores. Los archivos de uso común, como la estructura de Docker se guardarán manteniendo su estructura en Google Drive. El servicio de almacenamiento posee un sistema de versionado automático, generando un historial de archivos con cada actualización que se realice sobre el archivo, siempre y cuando se mantenga idéntico nombre. De esta manera si es necesario recuperar un archivo anterior, simplemente se accede al histórico de almacenamiento de ese archivo en cuestión. 3GitHub es una plataforma de desarrollo colaborativo de software para alojar proyectos utilizando el sistema de control de versiones Git 18 CAPÍTULO 2. GESTIÓN DEL PROYECTO Figura 2.3: Sistema de versionado de Google Drive 2.3.2. Nomenclatura de ficheros Todos los archivos se identificarán siguiendo el patrón definido en la siguiente imagen: Figura 2.4: Patrón de nomenclatura de archivos Se identifica el Proyecto como Trabajo fin de grado (TFG), la fecha en formato año, mes, día, el nombre identificativo del archivo, su versionado en 2 dígitos 2.3. GESTIÓN DE LA CONFIGURACIÓN 19 Código Documento relativo a BBDD Base de datos DKR Docker SPR Spring Boot | JPA | Security MEM Redacción elaboración de la memoria VID Vídeo presentación DTF Gestión administrativa TFG DGP Gestión del proyecto EDT Descomposición de tareas GNT Gantt PGC Costes del proyecto IMG Elemento visual BBL Bibliografía Tabla 2.1: Tabla de identificadores de archivos. con 2 decimales y un comentario, no obligatorio, para aportar información adicional. También se añade un campo identificador de 3 a 4 caracteres que permite determinar la naturaleza del archivo. En la tabla 2.1 detallamos su clasificación. 2.3.3. Estructura del directorio del proyecto SE puede observar en la siguiente imagen una captura de la estructura de directorios almacenada en el repositorio de Google Drive. 20 CAPÍTULO 2. GESTIÓN DEL PROYECTO Figura 2.5: Estructura de directorios Dentro de la carpeta ’Desarrollo’, se encuentran, por ejemplo, las carpetas relativas a los elementos implementados. Si se visualiza la carpeta correspondiente a bases de datos, se puede apreciar la nomenclatura de ficheros establecida. Figura 2.6: Nomenclatura definida 2.3.4. Comunicación entre miembros del equipo Se mantendrán reuniones semanales con el cotutor, manteniendo informada a la tutora de la evolución mensual. Las reuniones semanales serán mayoritariamente presenciales, ya que el cotutor comparte espacio de trabajo, siendo necesario el contacto vía Skype, cuando este se encuentre en itinerancia por motivos laborales. Para la comunicación con el tutor, se emplearán correo electrónico mayoritariamente, vídeos demostrativos de la evolución del proyecto y reuniones presenciales 2.4. ESTIMACIÓN DE COSTES 21 en el despacho. 2.3.5. Gestión de cambios Dadas las características del proyecto, siendo un equipo de desarrollo unipersonal, con un contacto semanal con el cotutor, se decidió que el uso de plantillas para la gestión de cambios eliminaría la agilidad, sobrecargando de documentación el proyecto. Se tiene presente la necesidad y utilidad de estas en proyectos de mayor envergadura, pero para nuestro desarrollo ágil se discutirán las solicitudes de cambio y su prioridad durante las reuniones semanales, valorando si serán necesarios o no dichos cambios. 2.4. Estimación de costes Para determinar el coste del proyecto, se analiza cada tipo de coste presente durante el desarrollo. 2.4.1. Costes de recursos humanos Para determinar el coste de recursos humanos, acudimos al convenio colectivo aplicable a las empresas de consultoría (XVII Convenio colectivo estatal de empresas de consultoría, y estudios de mercados y de la opinión pública) publicado en el BOE el martes 6 de marzo de 2018.4Según este, un desarrollador correspondiente al área 3 grupo D nivel I percibirá de salario base 16.548,44eplus convenio de 1.167,21elo que derivaría en un salario total de 17.715,65e La jornada laboral será de 25 horas semanales, lo cual aplica un porcentaje del 62,5% del sueldo marcado por el convenio. Aplicamos una mejora para compensar la carga irregular de horas, ofreciendo un 65 % del sueldo efectivo, gestando una mejora sobre el convenio colectivo que deberá ser aceptada por el empleado al firmar el contrato por obra. La duración del contrato será de 6 meses, para adaptarse a la duración del proyecto, quedando unos 15 días desde la finalización del proyecto, hasta la finalización del contrato, que serán compensados como vacaciones retribuidas. Se genera una nómina de ejemplo para determinar los costes para la empresa: 4https://www.boe.es/boe/dias/2018/03/06/pdfs/BOE-A-2018-3156.pdf 22 CAPÍTULO 2. GESTIÓN DEL PROYECTO Figura 2.7: Nómina tipo mensual Sobre la base de cotización de 959,60eaplicaremos los porcentajes a la Seguridad Social a cargo de la empresa 23,6% de contingencias comunes 5,5% prestación por desempleo 3,5% accidentes de trabajo / enfermedad profesional 0,6% formación profesional 0,2% aportación FOGASA Lo cual genera un coste para la empresa de 831,54e+ 320,50e= 1152e mensuales. Al finalizar los 6 meses de contrato, debemos abonar una extra correspondiente y el equivalente a 6 días trabajados en concepto de finiquito por finalización 2.4. ESTIMACIÓN DE COSTES 23 de contrato (12 días por año trabajado). El coste total quedará de la siguiente manera 1152e* 6 + 768,32e+ 291,20e= 7971,52e. 2.4.2. Costes materiales Para el cálculo de los costes materiales de activo fijo imputamos el equipo utilizado para el desarrollo del proyecto, un ordenador portátil, con 2 años de antigüedad, un monitor externo, y un trackball. Para estos activos calculamos el coste de amortización, sin presentar costes derivados de reparaciones ni mantenimiento. Cuando se compra un equipo, este no puede ser imputado como un coste por su totalidad en el mismo momento de la compra, ya que se le estima una vida útil de ciertos años. Se hace necesario calcular la cuota de amortización imputable anualmente, siempre sin sobrepasar un porcentaje marcado por el estado. Para los equipos informáticos, este porcentaje asciende como máximo al 25 % anual del valor de adquisición, pudiendo ser amortizado a lo largo de 8 años como máximo.5 Esta cuota de amortización (CA) que nos permite imputar a un ejercicio fiscal viene determinado por la fórmula: CA = (Valor de adquisición – Valor residual) / Node años de vida útil Se debe pues determinar previamente el valor residual de los activos (el valor que tendrán una vez finalice su vida útil, calculado en base a su depreciación), así como el número de años de vida útil. Se determinan los cálculos pormenorizados para uno de los activos en modo de ejemplo. La cuota de amortización anual para el portátil es de (1000-300)/4 = 175e. Se debe de tener en cuenta que nuestro equipo se puede utilizar en otros proyectos durante el desarrollo de nuestra aplicación, así como en los 6 meses restantes del año, por lo que debemos prorratear esta cuota a lo largo de las horas de todo el año (40 horas semana por 52 semanas = 2080 horas) si nuestro proyecto tiene una estimación de 425 horas, la cuota amortizable, el coste imputable sobre el ordenador, debido al proyecto es de 35,75e. Finalmente quedan de la siguiente manera los costes imputables de los activos empleados. 5https://www.agenciatributaria.es/ 24 CAPÍTULO 2. GESTIÓN DEL PROYECTO Activo vida útil valor residual coste imputable Portátil 4 años 300e35,75e Monitor 8 años 50e3,8e Trackball 8 años 15e0,3e Tabla 2.2: Vida útil, valor residual y coste imputablede los activos Por lo tanto, el coste total de materiales sería en torno a 40e. 2.4.3. Costes de software Para el desarrollo del software se utilizaron aplicaciones de software libre, sin coste alguno, excepto la suscripción ampliada al servicio de almacenamiento Google Drive, para los backups de las imágenes de Centos 7. El coste de la suscripción es de 2emes, durante 6 meses, lo que implica un coste imputable de 12e. 2.4.4. Costes indirectos Son aquellos recursos necesarios para la elaboración del proyecto, pero que no pueden ser imputables únicamente a este en su totalidad, tales como la electricidad, calefacción o agua corriente. Al ser difícilmente mensurables los consumos para cada proyecto, se suele determinar un porcentaje imputable a éstos sobre el total del coste del proyecto. A modo de ejemplo la Universidad de Santiago de Compostela asigna un 21 % del coste total a los costes indirectos. Así nuestro coste indirecto será el siguiente. Costes indirectos = (7971,52+40+12)*0,21 = 1.685e 2.4.5. Coste total Una vez calculados los costes materiales, indirectos y de recursos humanos, el total del coste del proyecto asciende a: Costes totales = (7971,52+40+12+1685) = 9708,52e 2.5. Gestión de riesgos Cuando hablamos de gestión de riesgos, se debe determinar el plan de gestión que identificará, analizará y clasificará los potenciales eventos o amenazas que 2.5. GESTIÓN DE RIESGOS 25 explotarán una vulnerabilidad de un activo, afectando de manera negativa al desarrollo del proyecto. Mediante este estudio se determinan un número de riesgos que se clasifican como más probables, y con mayor impacto. Sobre ellos se realizará un análisis pormenorizado que buscará determinar medidas para su prevención, o contrarrestar su impacto una vez producidos. 2.5.1. Identificación de riesgos Se clasifican los riesgos identificados mediante la abreviatura ’RSG’ seguido de una numeración de 2 cifras, generando la siguiente plantilla en la que se determinará nombre, descripción, probabilidad (materialización del riesgo analizado) e impacto (consecuencias del riesgo en el devenir del proyecto). En apartados posteriores analizaremos las acciones de prevención y contingencia. RSG-01: Imposible cumplir con la planificación del proyecto. RSG-02: Conocimiento insuficiente para finalizar etapas de implementación. RSG-03: Reducción de las horas imputables al proyecto. RSG-04: Se presentan nuevos requisitos. RSG-05: Cambios en los requisitos ya establecidos. RSG-06: La gestión de configuración no está siendo aplicada. RSG-07: Imposibilidad de reunión con el cotutor o tutor. RSG-08: Incidencias en software. RSG-09: Incidencias en hardware. RSG-10: Estimación errónea del período de una tarea. RSG-11: Corrupción en archivos del proyecto. 2.5.2. Análisis y evaluación de riesgos Se aplica la siguiente plantilla para señalar con más detalle los riesgos anteriores, determinar su probabilidad e impacto. Posteriormente estableceremos acciones preventivas y de contingencia sobre los riesgos principales señalados en la matriz de probabilidad-impacto. Seguiremos el siguiente modelo: 32 CAPÍTULO 2. GESTIÓN DEL PROYECTO Identificador - nombre RSG-11 - Corrupción en archivos del proyecto. Acción de prevención Sistema de backup incremental durante el trabajo, realizando backup total al finalizar el día, manteniendo la notación de versiones. Acción de contingencia Recuperación del backup versionado inmediatamente anterior. Tabla 2.20: Actuación sobre RSG-11 Identificador - nombre RSG-03 - Reducción de las horas imputables al proyecto. Acción de prevención Desarrollar una planificación realista que tenga en cuenta posibles eventos que reduzcan las horas disponibles para dedicar al proyecto. Acción de contingencia Dilatar el plazo de finalización del proyecto, o reducir el alcance. Tabla 2.21: Actuación sobre RSG-03 Identificador - nombre RSG-04 - Se presentan nuevos requisitos.. Acción de prevención La definición de requisitos debe ser amplia y detallada. Acción de contingencia Dilatar el plazo de finalización del proyecto, o reducir el alcance. Tabla 2.22: Actuación sobre RSG-04 Identificador - nombre RSG-05 - Cambios en los requisitos ya establecidos. Acción de prevención La definición de requisitos debe ser amplia y detallada. Acción de contingencia Dilatar el plazo de finalización del proyecto, o reducir el alcance. Tabla 2.23: Actuación sobre RSG-05 2.5. GESTIÓN DE RIESGOS 33 Identificador - nombre RSG-06 - La gestión de configuración no está siendo aplicada. Acción de prevención Revisiones periódicas de la correcta utilización de la gestión. Acción de contingencia Determinar el porqué de la no utilización de la gestión de configuración y encaminar su solución. Tabla 2.24: Actuación sobre RSG-06 2.5.5. Planificación temporal (real) Los plazos de desarrollo de las tareas se calcularon con holgura. La etapa de gestión se finalizó antes de tiempo, comenzando la etapa de formación con una mayor disponibilidad temporal. Aun con esta ventaja de tiempo desde el inicio se atisbo posibles lagunas en la formación, que se completarían durante el desarrollo de dichas tareas en la etapa de implementación. Durante esta etapa el desarrollo el gestor se salió de plazo. Se manifestaron dos de los riesgos más probables (RSG-02, RSG-10) lo que desembocó en la implementación de un gestor menos sólido de lo esperado. Bien es cierto que este no era un objetivo principal del proyecto, lo cual resta impacto a dichos riesgos. Algunas decisiones tomadas, por ejemplo la de utilizar la versión más actual de MySQL se tornaron contraproducentes, debido a que sus mejoras en seguridad implican un nivel de desarrollo desde el gestor que complicaba la puesta en funcionamiento con los conocimientos Spring obtenidos. Claramente se manifiesta un nuevo riesgo (RSG-08). Para la conexión JPA se optó por eliminar el cifrado, y para la conexión logstash se optó por bajar la versión del conector a la 5.14 para facilitar el proceso, obteniendo avisos en la ejecución, debido a que la conexión entre los servicios no es codificada. Digamos que la securización de todo el proceso recomendador es una tarea pendiente a investigar en un entorno de producción, y sería un trabajo futuro que se debería abordar. Finalmente, se produjo un incidente durante el movimiento de archivos de la imagen virtualizada de Centos 7 a la hora de copiar su contenido para presentar el trabajo ante el cotutor (RSG-11). recurriendo al sistema de versionado de Google Drive el incidente no repercutió en los tiempos de manera señalable. Capítulo 3 Análisis de requisitos Antes de proceder con la implementación del proyecto, debemos detenernos y analizar el objetivo a resolver por nuestra aplicación. Este paso es necesario para determinar cómo se dará solución a dicho problema, definir y especificar requisitos para dar solución a las necesidades del usuario. 3.1. Especificación de requisitos La especificación de requisitos determinará el comportamiento final del proyecto, los compromisos que se deberán cumplir para satisfacer los requerimientos del cliente. Para especificar estos requisitos, los dividiremos entre funcionales y no funcionales, determinando para cada uno de ellos su importancia y prioridad. Aunque en este proyecto hemos construido el gestor de incidencias, el supuesto teórico es que partimos de un gestor ya operativo en el cliente, sobre el que se deberán realizar pequeñas modificaciones para introducir la conexión con el sistema recomendador. Es por esto que no aparecerán requisitos sobre la implementación del gestor, pero sí sobre su adaptación. Se aplica la plantilla mostrada en la figura 3.1: 35 36 CAPÍTULO 3. ANÁLISIS DE REQUISITOS Identificador RQF-XX | RNF-XX Nombre Nombre Descripción Descripción Importancia alta media baja Urgencia alta media baja Tabla 3.1: Plantilla para especificación de requisitos 3.1.1. Requisitos funcionales Estos requisitos determinan funcionalidades útiles para el usuario. Identificador RQF-01 Nombre Acceso e ingesta de datos. Descripción El sistema debe estar capacitado para conectar con la base de datos del cliente, transferir los datos a indexar (para la ingesta) y de realizar anotaciones para facilitar el seguimiento de la implantación. Importancia alta Urgencia alta Tabla 3.2: Requisito funcional RQF-01 Identificador RQF-02 Nombre Indexación de los datos. Descripción La aplicación ha de ser capaz de analizar la información recibida. Importancia alta Urgencia alta Tabla 3.3: Requisito funcional RQF-02 3.1. ESPECIFICACIÓN DE REQUISITOS 37 Identificador RQF-03 Nombre Filtrado durante el análisis. Descripción El sistema será capaz de eliminar términos que no aporten valor en la búsqueda. Importancia alta Urgencia media Tabla 3.4: Requisito funcional RQF-03 Identificador RQF-04 Nombre Gestión de la consulta de búsqueda. Descripción El sistema gestará la consulta de búsqueda del título del ticket seleccionado. Se debe modificar el código del gestor, para capacitar el rescate del título del ticket, y enviarlo como una consulta de búsqueda al analizador del sistema de recomendación Importancia alta Urgencia alta Tabla 3.5: Requisito funcional RQF-04 Identificador RQF-05 Nombre Aplicación de sinónimos. Descripción Durante la gestión de la consulta se aplicarán sinónimos. Importancia media Urgencia media Tabla 3.6: Requisito funcional RQF-05 38 CAPÍTULO 3. ANÁLISIS DE REQUISITOS Identificador RQF-06 Nombre Aplicación de búsqueda borrosa. Descripción Durante la gestión de la consulta se aplicará búsqueda borrosa. Importancia alta Urgencia media Tabla 3.7: Requisito funcional RQF-06 Identificador RQF-07 Nombre Integración del resultado de búsqueda. Descripción Los resultados recomendados se integran en el interfaz del gestor. Importancia alta Urgencia alta Tabla 3.8: Requisito funcional RQF-07 Identificador RQF-08 Nombre Realimentación del proceso y seguimiento. Descripción El sistema integrará la recomendación nuevamente en la base de datos del gestor en el momento en que se selecciona de entre las recomendaciones y se cierra el ticket, marcando la solución como recomendada para facilitar el seguimiento. Importancia alta Urgencia alta Tabla 3.9: Requisito funcional RQF-08 3.1. ESPECIFICACIÓN DE REQUISITOS 39 Identificador RQF-09 Nombre Visualización de tiempos de resolución. Descripción El sistema integrará un visualizador de tiempos de resolución de incidencias. Importancia media Urgencia baja Tabla 3.10: Requisito funcional RQF-09 Identificador RQF-10 Nombre Visualización de tiempos medios de resolución por semana. Descripción El sistema integrará un visualizador de tiempos medios de resolución de incidencias por semanas. Importancia media Urgencia baja Tabla 3.11: Requisito funcional RQF-10 Identificador RQF-11 Nombre Visualización de utilización del recomendador. Descripción El sistema integrará un visualizador de utilización del recomendador para dar solución a la incidencia. Importancia media Urgencia baja Tabla 3.12: Requisito funcional RQF-11 40 CAPÍTULO 3. ANÁLISIS DE REQUISITOS Identificador RQF-12 Nombre Panel de control aglutinador de visualizaciones. Descripción El sistema integrará un panel de control que permitirá aglutinar todas las visualizaciones de control. Importancia baja Urgencia baja Tabla 3.13: Requisito funcional RQF-12 3.1.2. Requisitos no funcionales Estos requisitos determinan restricciones en el diseño o la implementación del sistema que delimitan la calidad del sistema. Estos requisitos pueden ser de rendimiento, disponibilidad, datos de entrada, estabilidad o funcionalidad entre otros. Requisitos de rendimiento Identificador RNF-01 Nombre Ingesta de datos periodificable y no intrusiva. Descripción La ingesta de datos debe ser periodificable y no requerir la parada de la base de datos del cliente. Importancia alta Urgencia alta Tabla 3.14: Requisito no funcional de rendimiento RNF-01 3.1. ESPECIFICACIÓN DE REQUISITOS 41 Identificador RNF-02 Nombre Procesamiento de la consulta en tiempo real. Descripción En el momento en que se selecciona la incidencia para su solución debemos recuperar las recomendaciones. Importancia alta Urgencia alta Tabla 3.15: Requisito no funcional de rendimiento RNF-02 Requisitos de disponibilidad Identificador RNF-03 Nombre El índice debe estar distribuido. Descripción El índice debe de estar distribuido en un cluster de al menos dos máquinas. Importancia alta Urgencia alta Tabla 3.16: Requisito no funcional de disponibilidad RNF-03 48 CAPÍTULO 3. ANÁLISIS DE REQUISITOS Identificador CU-06 Nombre / Actor Solucionar ticket / Técnico Nivel 2. Descripción El TN2 cumplimenta el cuadro de solución y cierra el ticket. Precondición El actor debe haber seleccionado previamente el ticket. Secuencia El actor TN2 cubre el campo solución con el texto necesario para la solución. El actor puede seleccionar una solución de la lista de recomendaciones, pero decide NO hacerlo El actor selecciona la opción de cerrar el ticket. Postcondición El sistema computa el ticket como cerrado, añade la solución a la base de datos, pero marca esta como solucionada sin utilizar el recomendador Excepciones Ninguna. Tabla 3.23: Descripción textual CU-06 3.2. CASOS DE USO 49 Identificador CU-07 Nombre / Actor Seleccionar recomendación para solución/ Técnico Nivel 2. Descripción El TN2 cumplimenta el cuadro de solución mediante una solución recuperada por el recomendador. Precondición El actor debe haber seleccionado previamente el ticket. Secuencia El actor selecciona una solución de la lista de recomendaciones. El campo solución se cumplimenta automáticamente con el contenido de la solución recomendada y seleccionada por el actor. El actor selecciona la opción de cerrar el ticket. Postcondición El sistema computa el ticket como cerrado, añade la solución a la base de datos, y marca esta como solucionada utilizando el recomendador Excepciones Ninguna. Tabla 3.24: Descripción textual CU-07 50 CAPÍTULO 3. ANÁLISIS DE REQUISITOS Identificador CU-08 Nombre / Actor Periodifica o lanza una ingesta de datos / Administrador. Descripción El administrador procede a cargar los tickets marcados como solucionados en el índice de Elasticsearch. Precondición El actor se conecta a la máquina Logstash. Secuencia El actor ejecuta la invocación necesaria para arrancar un pipeline de carga unitaria o periodificada. El pipeline accede a la base de datos. El pipeline recupera los tickets marcados como cerrados. El pipeline conecta con el índice Elasticsearch y añade los nuevos datos. El actor finaliza el pipeline y se desconecta de la máquina. Postcondición Los nuevos tickets quedan a disposición del analizador. Excepciones El proceso expone un error si no están operativas la base de datos o el servidor Elasticsearch. Tabla 3.25: Descripción textual CU-08 3.2. CASOS DE USO 51 Identificador CU-09 Nombre / Actor Visualizar informe / Gestor. Descripción El gestor accede al cuadro de mandos para ver la implantación del recomendador. Precondición El sistema Kibana debe estar operativo y en conexión con Elasticsearch. Secuencia El actor ejecuta la invocación necesaria para visualizar el panel de control. El panel de control recopila las visualizaciones. La visualizaciones gestionan la consulta y recuperan la información desde el índice. Se visualizan las gráficas de implantación. Postcondición El panel de control muestra las gráficas de implantación del recomendador. Excepciones Si el índice no está disponible se visualiza un aviso de error. Tabla 3.26: Descripción textual CU-09 52 CAPÍTULO 3. ANÁLISIS DE REQUISITOS 3.2.3. Matriz de requisitos/casos de uso Mediante esta matriz podemos observar la relación entre los casos de uso y los requisitos, detallando dependencias entre ellos. Figura 3.3: Matriz Casos de uso Capítulo 4 Análisis de tecnologías y herramientas Se procede a describir aquellas tecnologías empleadas en el desarrollo, tanto del sistema gestor de incidencias, como en la puesta en funcionamiento del sistema recomendador, así como las empleadas para la elaboración de gráficas, figuras y redacción de la memoria. 4.1. Tecnologías empleadas en el desarrollo 4.1.1. Librerías QueryDSL[20] nos permite generar consultas de una manera rápida, consistente y segura. Esta librería fue en principio diseñada para HQL Hibernate pero hoy en día soporta varias tecnologías de persistencia de datos, como: JPA, JDBC, Lucene, MongoDB, etc. API Elasticsearch + Java High Level REST Client implementado en la versión 6 y superiores, viene a substituir al cliente de transporte (TransportClient) anterior, que implicaba la gestión REST a base de peticiones generadas por nosotros. El nuevo cliente acepta todas las peticiones disponibles en la API de Elasticsearch GSON[21] es un API en Java, desarrollada por Google, que se utiliza para convertir objetos Java a JSON (serialización) y JSON a objetos Java (deserialización). Facilitará el trabajo de presentación de la información devuelta por la consulta formada con el cliente de Elasticsearch. 53 54 CAPÍTULO 4. ANÁLISIS DE TECNOLOGÍAS Y HERRAMIENTAS 4.1.2. Frameworks Spring boot nace para simplificar los pasos de creación de un proyecto, descarga de dependencias y despliegue en un servidor, dejando al desarrollador todo el tiempo necesario para la creación de la aplicación. Se seleccionó este framework debido a tres de sus características que lo hacen tremendamente popular. •Configuración: Spring Boot cuenta con un complejo módulo que configura automáticamente todos los aspectos de nuestra aplicación para poder ejecutar esta, sin tener que definir absolutamente nada. •Resolución de dependencias: Con Spring Boot solo hay que determinar qué tipo de proyecto estaremos utilizando y él se encarga de resolver todas las librerías/dependencias para que la aplicación funcione. •Despliegue: Spring Boot se puede ejecutar como una aplicación Standalone, pero también es posible ejecutar aplicaciones web, ya que es posible desplegar las aplicaciones mediante un servidor web integrado, como es el caso de Tomcat, Jetty o Undertow. Thymeleaf es un motor de plantillas Java para web, construido sobre estándares HTML5 e integrado con spring framework de manera sencilla. Se recomienda su uso si el proyecto se desarrolla utilizando el patrón MVC, ya que la integración es casi transparente para el desarrollador. Maven es una herramienta para proyectos Java que facilita enormemente la administración de dependencias, construcción y empaquetado de aplicaciones. Instalado con spring boot suite se utilizó para realizar de manera mucho más fácil el proceso de integración de funcionalidades y librerías, simplemente añadiendo sus dependencias en el archivo pom.xml. 4.1.3. Virtualización VMware Workstation es una suite de VMware Inc, filial de EMC Corporation que proporciona software de virtualización disponible para ordenadores compatibles X86. En nuestro desarrollo utilizaremos VMware Player 15, aplicación de virtualización que la empresa pone a disposición de manera gratuita (en proyectos de uso no comercial), y sobre la que se monta una distribución Centos 7. Docker es un sistema de virtualización, que permite ejecutar aplicaciones en ’contenedores’, pero sin necesidad de incluir la imagen completa de un sistema operativo, únicamente librerías y configuraciones necesarias para hacer funcionar el software contenido, ya que los contenedores comparten 4.2. TECNOLOGÍAS EMPLEADAS EN LA DOCUMENTACIÓN 55 el kernel del sistema anfitrión. De esta manera se consiguen sistemas ligeros, autocontenidos, que garantizan que el software siempre responderá de igual manera. Esto permitirá la portabilidad del sistema, y ahorrará mucho tiempo en la configuración de las máquinas contenedoras de los servicios a desplegar. 4.1.4. Servidor web Apache Tomcat es el servidor embebido en Spring Boot, framework empleado para la realización del gestor de tickets, que será desplegado en un jar, sobre un contenedor con una imagen de java 8. Al ser un servicio embebido, se facilita la configuración del servidor web. 4.1.5. IDE de desarrollo Spring tool suite (STS4) es un IDE de código abierto basado en Eclipse. Mediante la adición de diferentes módulos se adapta su funcionalidad al proyecto a desarrollar. En nuestro caso se aplicaron los módulos de Spring MVC, para implementar el patrón modelo-vista-controlador, el módulo Hibernate, para facilitar la interacción con la base de datos, y el módulo de seguridad, para la creación de roles y perfiles de acceso a la aplicación 4.1.6. Lenguajes 1. Java Para la programación del gestor de incidencias 2. Mysql Para la gestión de la base de datos e importación y exportación de los tickets 3. HTML5 Para la creación de las vistas en thymeleaf 4. CSS Para la maquetación de las plantillas Thymeleaf 5. Yaml Para la configuración de contenedores y red de contenedores 6. QueryDSL Para las consultas a la base de datos mediante Hibernate 4.2. Tecnologías empleadas en la documentación TeXstudio IDE1(sobre LaTeX2)Para la elaboración de la documentación necesaria, utilizando las plantillas facilitadas por la USC, se utilizó una instalación de LaTeX sobre Centos 7. Para facilitar la gestión de archivos 1https://www.texstudio.org/ 2https://www.latex-project.org/ 56 CAPÍTULO 4. ANÁLISIS DE TECNOLOGÍAS Y HERRAMIENTAS se utilizó el IDE TeXstudio, que facilita la exportación a PDF de los documentos generados. WBSTool3, generador On-line de esquemas EDT empleado en la redacción del anteproyecto y posteriormente en el apartado de gestión del proyecto. Microsoft Project4software de gestión de proyectos de Microsoft. Se ha empleando la versión de prueba para la realización de los diagramas de Gantt y la planificación del proyecto. Visual Paradigm5software de generación de diagramas que admite una amplia variedad de disgramas comerciales y técnicos. Se utilizó su versión gratuita online para la realización de los diagramas de casos de uso. Notepad++6editor de textos con utilidades avanzadas. Se usó para la elaboración de scripts o para tomar notas cuando no se disponía de los programas adecuados. MySQL Workbench cliente hábil para la realización de labores administrativas sobre una base de datos Mysql. Se utilizó para la creación de las tablas, importación de registros ficticios, exportación de scripts y la mayoría de la interacción con la base de datos Mysql. OBS Studio7aplicación gratuita para la grabación de vídeos. Utilizada para para recoger en vídeo pequeñas presentaciones de los incrementos finalizados, para comunicar la evolución del proyecto a la tutora. Google Drive8servicio de alojamiento de archivos de Google. Se utiliza para el versionado de archivos y de la imagen de trabajo Centos 7. Una de las funciones más utilizada ha sido la posibilidad de compartir archivos mediante enlace privado, para presentar los vídeos evolutivos del avance del proyecto. 3http://www.wbstool.com/ 4https://products.office.com/es-es/project/project-management-software 5https://www.visual-paradigm.com/ 6https://notepad-plus-plus.org/ 7https://obsproject.com/es 8https://www.google.com/intl/es_ALL/drive/ Capítulo 5 Diseño e implementación 5.1. Arquitectura del sistema Mediante la siguiente figura se determina cómo funciona el sistema a desarrollar. Figura 5.1: Arquitectura del sistema Se señalan dos módulos diferenciados: 57 64 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Figura 5.9: Llamada al método Spring MVC - Vista Para la creación de vistas se utiliza el motor de plantillas Thymeleaf que ofrece un set completo de integración que facilita su incorporación dentro del patrón MVC. Mediante atributos propios podemos ejecutar de manera muy sencilla interacciones con los objetos manejados desde el controlador. En la siguiente captura del formulario de creación de un ticket se observa alguno de los atributos más característicos. Figura 5.10: Código vista del formulario de creación de un ticket Se observa como el atributo th:action mediante la expresión de enlace @ redirecciona a la vista addticket, utilizando el atributo th:object y la expresión variable $indicamos el objeto que recibirá la información recopilada. Tenemos 5.2. GESTOR DE INCIDENCIAS (MÓDULO CLIENTE) 65 dos atributos de ese objeto que, usando las etiquetas th:field se completan con los valores determinados mediante expresiones de selección,“*{ }”, a una de ellas se le determina un valor estático por defecto con el atributo th:value=”abierto” (todos los tickets se crean por defecto como abiertos). Más adelante vemos como se utiliza nuevamente este atributo para completar el título del ticket, recogiendo su valor del campo title con una expresión de variable ${title}. Para recuperar los técnicos asignables a este ticket, se hace lectura de los valores proporcionados por un array enviado desde el controlador. Este array se itera mediante th:each, indicando el nombre del objeto por el que iterar ${Listasoportistas}. Esto se mostrará en un desplegable con los valores de la lista th:text=”${soportista}” y sus valores subyacentes en un th:value. El elemento seleccionado se adjuntará en el campo designated del objeto th:object=${ticketModel}” a enviar al controlador mediante el atributo th:field=”*{designated}” Spring MVC - Controlador El controlador es el punto de unión entre el modelo y la vista. Encauza los datos hacia las vistas a mostrar, así como recopila los datos enviados desde la vista para actuar en consecuencia (vincularlos a un repositorio, hacer una consulta, etc.). Para crear un controlador en Spring simplemente se añade la anotación @Controller a una clase java y se anotan los métodos que queramos relacionar con las peticiones http con @RequestMapping o con alguna de sus abreviaturas (@GetMapping,@PostMapping, etc). En la siguiente captura se aprecia una sección de la clase ticketController, que muestra la petición @PostMapping a la hora de actualizar un ticket. Figura 5.11: Petición @PostMapping en actualización de ticket 66 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN 5.2.2. Capa base de datos El gestor simulado almacenaría sus tickets sobre una base de datos MySql. Se seleccionó este motor debido a su universalidad, pero se debía tener en cuenta que el potencial cliente podría presentar cualquier otro (Postgres, SQL Server, Oracle o con menos certeza, aunque también posible, MongoDB u otra base no relacional). A la hora de diseñar la base de datos, se opta por reducirla a lo más básico. Una tabla de tickets y las tablas necesarias para la gestión de los usuarios, que vendrá determinada por las necesidades del sistema Spring Security. Para diseñar la tabla de tickets, primero se debe definir qué elementos conformarán el ticket básico. De entrada se mostrará el título del ticket (title), a qué técnico se asignará (designated), el estado del ticket (state), su resolución (resolution) y los campos ya no visibles de Id, fecha de apertura, actualización y cierre, así como un cálculo del tiempo transcurrido entre su apertura y cierre, que se almacenará en el campo tiempo medio. También se añade un campo que indicará si el ticket se ha solucionado utilizando el recomendador. Para poblar de contenido la tabla de tickets, se procedió a buscar algún tipo de base de conocimiento que nos proporcionara tickets de referencia reales. Esta tarea a priori sencilla dilató el proceso más de lo deseado, ya que no es tarea trivial, como sí lo es por ejemplo en entornos big data, encontrar un repositorio útil. Finalmente se encontró un archivo train_tickets.csv proveniente de un servicio helpdesk que pudo ser de utilidad, realizando sobre él ciertas modificaciones antes de importarlo a la base de datos. El archivo csv presentaba 4 campos (id, title, resolution y class) del que únicamente se aprovecha title y resolution. De manera aleatoria se genera el campo designated, con los tres técnicos creados para la aplicación (Bob, Charles, Danna). Para el total de tickets importados, se asume que su estado es cerrado (ya han sido solucionados, al tener contenido en el campo resolution). Para poblar los campos de fecha, especialmente fecha de apertura y cierre del ticket, se procede a generar entre una fecha inicial y final, todo un rango de valores aleatorios. Con estos valores se completa el campo fecha_open. Para poblar las fechas de cierre de los tickets, se genera un nuevo valor aleatorio sobre la fecha de apertura, con un rango máximo de 3 horas. Posteriormente se procede a poblar los tickets realizando una importación del csv desde MySQL Workbench y generando el código para los inserts. El tiempo medio de cierre de ticket se calculó con una operación aritmética en la base de datos. UPDATE tickets SET tiempo_medio = timestampdiff(minute, fecha_open, fecha_close); UPDATE tickets 5.2. GESTOR DE INCIDENCIAS (MÓDULO CLIENTE) 67 SET usa_recomendacion = 0; Todo este proceso fue necesario para poblar inicialmente la tabla de tickets. Para las nuevas incidencias que se crearán desde el gestor, el propio código de este, y los campos autocompletados de la tabla se encargarán de poblar las fechas. El código de creación de la tabla queda de la siguiente manera: Figura 5.12: Script creación tabla de tickets El diseño de las tablas se aprecia en la siguiente captura. Figura 5.13: Diseño de tablas del gestor 68 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN 5.2.3. Capa acceso a datos Para facilitar el acceso a la base de datos MySQL se utiliza la tecnología Spring JPA con Hibernate. Para añadir estas funcionalidades, se debe descargar las dependencias necesarias y añadirlas al archivo pom.xml para que Maven se ocupe del proceso de descarga y disposición para el proyecto. Se añade el siguiente código al archivo pom.xml. Figura 5.14: Dependencias JPA y conector Mysql La primera dependencia es el starter de spring JPA y segunda es el artefacto de conexión a una base de datos MySQL. El siguiente paso será desde un terminal, acceder al workspace y lanzar el comando maven clean install, para descargar las dependencias añadidas. Antes de acceder a la base de datos, se debe cubrir la configuración del starter para dar acceso al conector de MySQL. Dentro del archivo aplication.properties se asigna username y password, así como la url de conexión con la base de datos. También se debe indicar la validación por parte de Hibernate de la coincidencia entre entidades creadas y tablas accedidas. Si no es así, actualizará las tablas. JPA mostrará en el log de la aplicación las consultas sql. Figura 5.15: Detalle de la configuración del aplication.properties Para que el proyecto pueda interactuar con la base de datos, se deben crear las entidades con las que trabajará Hibernate. Para el proyecto , se creará la entidad Ticket con anotación @Entity en la que se indica la tabla con la que se corresponde. Se añaden los campos, indicando @Column para determinar el nombre de la columna correspondiente, @Id para señalar la clave primaria y @GeneratedValue para recuperar el siguiente valor si se trata de un campo 5.2. GESTOR DE INCIDENCIAS (MÓDULO CLIENTE) 69 autogenerado. Figura 5.16: Entidad Hibernate El siguiente paso será crear un interfaz repositorio que comunicará controlador y entidad, presentando los métodos que estarán disponibles en la implementación. Se debe anotar como @Repository señalando el nombre identificativo del bean para el controlador y extender la interfaz de JpaRepository, para disponer de todos los métodos útiles de JPA que se encargarán de gestionar y formalizar las consultas necesarias para buscar en la tabla de tickets. Figura 5.17: Interfaz del repositorio 70 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Para hacer uso de este interfaz, en el controlador se debe añadir la inyección de dependencias, mediante la anotación @Autowired, seleccionando el nombre del bean con la anotación @Qualifier. Es importante, por motivos de calidad de software a la hora de trabajar con JPA, que los controladores no interactúen directamente con entidades ya que el objetivo final de estas es mapear contenido contra la base de datos, no ser utilizadas para la representación de ese contenido en una vista (puede que alguno de los campos de la base de datos no pueda ser serializable). Es por ello que se recomienda crear una clase que convierta nuestras entidades en modelos y viceversa. En el proyecto, crearemos la clase TicketConverter que contendrá dos métodos, uno transformará de entity recibida como argumento a model, y el siguiente de model a entity. 5.3. Securización mediante Spring Security Para la gestión de usuarios y roles de manera segura, se implementa el módulo Spring Security, añadiendo sus dependencias al archivo pom.xml y ejecutando nuevamente el comando de Maven clean install. Figura 5.18: Dependencias del módulo Spring Security Hasta ahora en el proyecto, la validación para los accesos se incluía en el código. Para añadir cierto nivel de seguridad, estos accesos deben ser cifrados y almacenados en tablas de nuestra base de datos. Será necesario crear nuevas entidades, repositorios y servicios para tramitar el acceso de los usuarios. Estas entidades mapearán los campos creados en las tablas users y user_roles. El servicio creado, tendrá un método que recibe un string por parámetro (nombre de usuario). El servicio llamará al repositorio, que ejecutará la consulta de búsqueda por nombre de usuario, devolverá una entidad usuario y roles, que serán transformados en los objetos específicos requeridos por Spring Security (UserDetails y lista de GrantedAutority). La potencia del módulo permitiría dar complejidad a la gestión de cuentas, añadiendo disponibilidad de usuarios (activos, inhabilitados), credenciales expiradas, cuentas bloqueadas, etc. Pero dejaremos de lado todas estas opciones ya 5.4. VIRTUALIZACIÓN DEL SISTEMA EN CONTENEDORES DOCKER71 que se escapan del alcance y no son necesarias en el desarrollo del gestor de incidencias. También se gestiona la securización de los request generados (exceptuando css e imágenes) así como el proceso de login, añadiendo la clase SecurityConfiguration con las anotaciones @Configuration para manejar configuraciones adicionales no disponibles en el archivo aplication.properties y@EnableWebSecurity, para habilitar la seguridad web. Esto implicará que los logins de usuarios deben facilitarse cifrados, para lo que nos vemos en situación de obtenerlos mediante un clase adicional que nos facilite los passwords que se almacenan en la tabla de usuarios. En un gestor completo y funcional, este proceso lo desarrollaría la interfaz de creación de usuarios, lo que implicaría generar todo un CRUD para los usuarios que se prescinde de implementar, ya que no aporta en el proyecto; simplemente daremos de alta cuatro usuarios y generaremos sus passwords cifrados mediante una clase auxiliar TestCrypt, que devolverá por consola el usuario cifrado, que se añade manualmente a la base de datos. En las clases de los controladores se activa mediante las anotaciones @EnableGlobalMethodSecurity() y@Preauthorize el acceso a determinados métodos únicamente en caso de la presencia del rol indicado en el usuario autenticado, de esta manera, podemos facilitar el acceso a la creación de tickets únicamente a los usuarios autenticados con el rol de administrador. Figura 5.19: Método solo autorizado a roles tipo administrador 5.4. Virtualización del sistema en contenedores Docker En el momento en que el gestor de incidencias está validado en un entorno local, es necesario empaquetar su funcionalidad en un archivo .jar que sea factible de despliegue en un entorno virtualizado, utilizando contenedores Docker. A modo de introducción rápida, tenemos que definir ciertos términos para entender mejor la tecnología que estamos utilizando. 72 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Dockerfile e imágenes docker Dockerfile es un archivo de configuración que se utiliza para crear imágenes. En dicho archivo indicamos qué es lo que queremos que tenga la imagen, y los distintos comandos para instalar las herramientas. Ejecutando el comando docker build sobre ese DockerFile, se creará la imagen correspondiente, lista para desplegar un contenedor. Muchas empresas de software ponen a disposición de los usuarios imágenes de sus productos para acceso libre; de esta manera, podemos descargar dichas imágenes y generar los contenedores necesarios para operar en nuestra aplicación de manera mucho más rápida. Contenedores Son instancias en ejecución de una imagen. A partir de una única imagen, podemos ejecutar varios contenedores. Volúmenes Los volúmenes suponen el modo en el que Docker permite persistir los datos de una aplicación. Los datos se alojan fuera del propio contenedor, en el sistema de archivos del host donde está corriendo Docker, de tal manera que se puede cambiar, apagar o borrar el contenedor sin que afecte a los datos almacenados en el volumen. Hay que tener en cuenta que estos volúmenes persisten ante un borrado del contenedor, no se dispone de un “recolector de basura” que limpie volúmenes huérfanos de contenedores eliminados, se debe gestionar el espacio adecuadamente a la hora de usar esta funcionalidad. Para la instalación de Docker en la imagen de Centos 7 se debe instalar previamente una serie de utilidades, siguiendo las recomendaciones de la propia página de Docker.3 $ sudo yum install -y yum-utils device-mapper-persistent-data lvm2 El siguiente paso será añadir el repositorio oficial: $ sudo yum-config-manager --add-repo https://download.docker.com /linux/centos/docker-ce.repo Una vez completados estos pasos, procedemos a instalar la versión de la comunidad (Docker Engine - Community), versión no de pago, con menos funcionalidades, pero perfectamente válida para nuestro proyecto. 3https://docs.docker.com/install/linux/docker-ce/centos/ 5.4. VIRTUALIZACIÓN DEL SISTEMA EN CONTENEDORES DOCKER73 $ sudo yum install docker-ce Se debe añadir nuestro usuario al docker group: $ sudo usermod -aG docker $(whoami) Para completar la instalación, ejecutamos los comandos que habilitan e inicializan Docker: $ sudo systemctl enable docker.service $ sudo systemctl start docker.service Si todo se ha completado correctamente, podremos crear nuestra primera imagen mediante el archivo de configuración Dockerfile. Para desplegar el jar contenedor del proyecto, se creará y ejecutará el siguiente archivo: FROM java:8 LABEL maintainer=“[email protected]” EXPOSE 8080 COPY soporte-0.0.1-SNAPSHOT.jar soporte-0.0.1-SNAPSHOT.jar ENTRYPOINT ["java","-jar","soporte-0.0.1-SNAPSHOT.jar"] El comando From es obligatorio al comienzo del archivo, indica cual es la imagen base que utilizaremos (imagen de java en versión 8). Label añade metadatos sobre la imagen, en le archivo se indica maintainer para señalar el creador de la imagen. Es un campo prescindible. Expose indica el puerto de entrada:puerto de salida (en este caso únicamente el puerto de entrada) Copy realiza la copia del archivo indicado desde la máquina local al contenedor Entrypoint indica el comando que se ejecutará en el contenedor una vez que se arranque este. En el proyecto se lanza el gestor mediante la ejecución java del archivo jar. Hay que recordar que hemos modificado el gestor para que no busque la base de datos Mysql en local, si no que esta también se ejecutará en un contenedor. La idea final es que el sistema recomendador también resida en contenedores, lo que plantea la necesidad de interconectar todos los contenedores mediante un sistema aglutinador. Para ello utilizaremos Docker-compose. 80 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN a la base de datos, en el contenedor docker mysql se está desplegando la versión 8.0.17. por tanto se debe copiar este conector a la carpeta de plugins del contenedor Logstash (etc/logstash/plugins). También se copia el pipeline (órdenes de trabajo) a la carpeta de ejecución. Como paso final de este Dockerfile, se añade una ejecución “fantasma” que mantendrá el contenedor a la espera del comando a introducir para ejecutar el arranque del motor de ingesta de datos. La configuración necesaria del docker-compose será la siguiente. Se indica ruta al Dockerfile para que se proceda a la generación, nombre del contenedor, volumen, puertos entrada:salida y red. Figura 5.23: Detalle del servicio Logstash en el archivo docker-compose 5.5.3. Contenedor Kibana Para la creación de este contenedor, se lanza todos sus parámetros desde el archivo docker-compose. Se indica imagen base en version 6.2.4, y se añade la dependencia con el servicio elasticsearch, así como volumen, puertos y red. Figura 5.24: Detalle del servicio kibana en el archivo docker-compose 5.5. MÓDULO RECOMENDADOR DE SOLUCIONES 81 5.5.4. Configuración del pipeline de Logstash Logstash es un motor de procesamiento y recopilación de datos basado en plugins. Incluye una gran variedad de plugins que permiten configurarlo fácilmente para recopilar, procesar y reenviar datos en muchas arquitecturas diferentes. El procesamiento se organiza en uno o más pipelines. En cada pipeline, uno o más plugins de entrada reciben o recopilan datos que luego se colocan en una cola interna. De manera predeterminada, esta es pequeña y se almacena en la memoria, pero puede configurarse para ser más amplia y permanecer en el disco para mejorar la confiabilidad y la persistencia. Uno de los primeros pasos que realizaremos a la hora de poner en marcha el recomendador será la ingesta inicial de datos. Se accede a la base de datos del cliente para recopilar todos los tickets resueltos que posteriormente serán enviados a Elasticsearch para pasarlos por el analizador y almacenarlos en un índice distribuido. Los hilos de procesamiento leen datos de la cola y los procesan a través de cualquier plugin de filtro configurado en secuencia. Logstash viene de fábrica con una gran cantidad de plugins destinados a tipos específicos de procesamiento, y así es como se analizan, procesan y enriquecen los datos. Una vez que se procesan los datos, los hilos de procesamiento envían los datos a los plugins de salida correspondientes, que son los responsables de formatear y enviar los datos, en nuestro caso, a Elasticsearch. Los plugins de entrada y salida también pueden tener un plugin de códec configurado. Esto permite formatear datos antes de colocarlos en la cola interna o antes de enviarlos a un plugin de salida. La manera más fácil de arrancar Logstash es crear un único pipeline basado en un solo archivo de configuración. lanzar el motor de ingesta arrancando Logstash e indicando la ruta al archivo de configuración: logstash -r -f /usr/share/logstash/pipeline/logstash.conf En nuestro caso no utilizaremos plugins intermedios para procesar los datos, simplemente aplicaremos un plugin de entrada, para recopilar los datos de mysql y un plugin de salida para enviar estos a Elasticsearch. 82 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Figura 5.25: Configuración del pipeline de Logstash El plugin de entrada será el conector jdbc, que se debe configurar con los siguientes parámetros: jdbc_connection_string Indica la ruta y puerto al contenedor mysql, así como el nombre de la base de datos. jdbc_user / jdbc_password Indica usuarios y password de conexión. jdbc_driver_library / jdbc_driver_class El plugin no posee el paquete de librerías JDBC, se debe determinar su ruta y la clase a cargar. Siguiendo una sintaxis similar a la de cron, se puede periodificar la ejecución del comando statement para lanzar la ingesta de datos. En el proyecto la configuración “* * * * *” equivale a una periodicidad de un minuto. Cada minuto logstash accederá a la base de datos y ejecutará el comando statement. Para una ingesta diaria de datos se aplicaría la configuracion “0 0 * * *” que lanzaría en el minuto cero de la hora cero de todos los días del año la sentencia statement. statement Es la sentencia que se ejecutará contra base de datos. Con una consulta como la siguiente, recuperaremos toda la información de aquellos tickets cerrados posteriores al 8 de octubre a las 19:30 horas. "SELECT * FROM tickets where fecha_update > ’2019-10-08 19:30:00’ and state =’cerrado’" 5.5. MÓDULO RECOMENDADOR DE SOLUCIONES 83 Esto no sería un problema si únicamente lanzamos una carga por ejemplo mensual y vamos actualizando la fecha de este select con el paso del tiempo. Se presentaría un problema si se periodifica la carga sin alterar la fecha del select. Con cada nueva ejecución del pipeline estaríamos cargando datos duplicados. Para solucionar esta eventualidad, utilizamos el parámetro sql_last_value dentro del select a ejecutar. "SELECT * FROM tickets where state =’cerrado’ and fecha_update > :sql_last_value order by fecha_update" Para el correcto funcionamiento de sql_last_value, se deben añadir ciertos parámetros. last_run_metadata_path Ruta dentro del contenedor que albergará el archivo de metadata que almacena el valor sql_last_value. tracking_column Columna de la tabla sobre la que se realiza el seguimiento de continuidad, en nuestro caso “fecha_update”. tracking_column_type Tipo de la columna sobre la que se realiza el seguimiento, en nuestro caso timestamp. record_last_run Activamos la opción de guardado en el archivo de metadata, de la última ejecución sql sobre dicha columna. En el archivo logstash_jdbc_last_run_t_data.txt se almacenará una anotación como esta: --- 2019-12-08 22:19:00.286698000 Z La siguiente vez que se ejecute el pipeline, se cargarán aquellos tickets con fecha posterior a la indicada en el metadata. clean_run Esta parametrización activada a true implica el reseteo del archivo metadata a fecha 1 Enero 1970, lo que implica que se cargarán todos los tickets desde el inicio. En el ejercicio permanece activa por motivos de estudio de carga completa, pero en un pìpeline de producción deberá conmutarse a false. 84 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Los plugins de salida serán stdout utilizando el codec jason_lines por motivos de debugging (permite ver por consola como se van enviando los datos recuperados) y el plugin Elasticsearch para enviar los tickets al índice elastic. La parametrización del plugin de salida Elasticsearch es la siguiente: id Se indica el id del índice a ingestar. hosts Nombre del host que contactaremos para encontrar el índice. Se puede indicar un array para balancear la entrada, evitando apuntar a los dedicated master nodes5si es que utilizamos esta configuración para controlar el cluster. index Nombre del índice a poblar. document_type Esta opción está marcada para su desaparición. Indica el tipo de documento en el que se escribirán los eventos. En el sistema, una vez que tenemos copiada la configuración del pipeline durante la creación del contenedor, lanzaremos la ingesta de datos accediendo a la carpeta de binarios dentro del contenedor Logstash, y ejecutando la aplicación indicando el pipeline adecuado. docker exec -it contenedor_id /bin/bash cd /usr/share/logstash/bin logstash -r -f /usr/share/logstash/pipeline/logstash.conf 5.5.5. Creación del índice Antes de lanzar la ingesta de datos, es importante crear y configurar el índice que se encargará de mapear y almacenar toda la información proveniente de la base de datos de tickets. En nuestro sistema aplicaremos las configuraciones por defecto a la hora de crear un índice, en lo referente al número de shards, verificación de integridad, codificación y compresión de datos, número de réplicas, asignación de shards a nodos, etc. Prestaremos especial atención al proceso de análisis, el proceso de conversión del input de entrada en tokens o términos que serán añadidos al índice de búsqueda. Partiendo del analizador por defecto, se crea un analizador específico, adaptado al sistema de incidencias del cliente. 5Un dedicated master node en contraposición a un data node en Elasticsearch son aquellos nodos no dedicados a tareas de almacenamiento de datos si no a tareas de administración y estabilidad de un cluster. 5.5. MÓDULO RECOMENDADOR DE SOLUCIONES 85 Creación del analizador Los analizadores pueden ser aplicados tanto a la hora del indexado, como a la hora de la búsqueda. En el sistema recomendador se incide en personalizar el analizador de indexado, aplicándolo en ambos procesos para optimizar los resultados. Elasticsearch ofrece en su configuración un abanico de analizadores a nuestra disposición, más allá del analizador estándar. También ofrece la posibilidad de crear y customizar un analizador, conociendo su estructura. La anatomía base de un analizador está formada por tres elementos. Los filtros de caracteres, los tokenizadores y los filtros sobre tokens. Filtros de caracteres Un filtro de caracteres recibe un texto como un todo y es capaz de transformar este añadiendo, cambiando o eliminando caracteres. Por ejemplo, podemos cambiar caracteres no latinos de numeración de un texto recibido por sus equivalentes latinos antes de almacenar el texto en el índice, o eliminar caracteres típicos de HTML como las marcas de etiquetas si hemos parseado una web y nos interesa limpiar el string recibido antes de almacenarlo. En nuestro sistema prescindiremos de configurar filtro de caracteres. Tokenizadores Un tokenizador recibe un texto y lo divide en tokens (elementos mínimos con sentido, usualmente palabras). Elasticsearch proporciona multitud de tokenizadores, por ejemplo whitespace, que divide el texto recibido por espacios en blanco, o letter, que genera un token en el momento que detecta un caracter no alfabético. Utilizaremos el tokenizador estándar que realiza la división de tokens en base a la especificación del Unicode Standard Annex #296 Desde la consola de Kibana, podemos lanzar un análisis de un texto cualquiera, para observar el funcionamiento de un tokenizador estándar 6http://unicode.org/reports/tr29/ 86 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN (a) Análisis estándar (b) División en tokens Figura 5.26: Análisis de un texto y su tokenizado Es habitual combinar los tokenizadores con los filtros tokenizadores para obtener el resultado buscado a la hora de realizar el análisis. Filtros sobre tokens Un filtro aplicado a un token permite realizar modificaciones (por ejemplo, pasarlo a minúsculas), eliminaciones (suprimir las denominadas stopwords) o añadir tokens nuevos (utilizando sinónimos). Trabajaremos y configuraremos los siguientes filtros que actuarán sobre la salida del tokenizador estandar: Filtro lowercase Normaliza los tokens transformándolos a minúsculas. Filtro asciifolding Transforma aquellos caracteres no pertenecientes a “Basic Latin” en su equivalente ASCII. Elimina acentos, diéresis, cedillas y los reduce a caracter latino, para facilitar el token. 5.5. MÓDULO RECOMENDADOR DE SOLUCIONES 87 Filtro default_english_stemmer Este filtro permite reducir una palabra a su raíz (stem) para así aumentar la devolución de resultados potencialmente útiles en una búsqueda. Por ejemplo, una consulta sobre ’bibliotecas’ también devolvería documentos en los que solo aparezca ’bibliotecario’, porque el stem de las dos palabras es el mismo (’bibliotec’). El filtro stemmer utiliza el algoritmo más común para stemming, el algoritmo de Porter.7 Se debe señalar que, en el sistema recomendador aplicamos el filtro stemmer indicando el idioma inglés como base del índice, asumiendo que todas las incidencias se reportan en ese idioma. En caso de detectar múltiples idiomas, se debería generar un índice diferente para cada idioma, tanto a la hora de analizar y almacenar los tokens, como a la hora de realizar las búsquedas. En esta situación, seguramente sería aplicable algún proceso de filtrado durante el trabajo de ingesta de datos en logstash, aplicando un filtro intermedio entre el input y el output, discriminando por idioma, y redireccionando el resultado a un índice u otro. Filtro adapted_english_stopwords Es un filtro personalizado sobre el filtro stop words inglesas. Un filtro de tipo stop elimina determinados tokens presentes en una lista preconfigurada de tokens. Esta lista puede ser ampliada o reducida a nuestras necesidades. Elasticsearch tiene predefinidos multitud de lenguajes sobre los que aplica stop words, en nuestro filtro partimos de la matriz de tokens ingleses siguiente: a, an, and, are, as, at, be, but, by, for, if, in, into, is, it, no, not, of, on, or, such, that, the, their, then, there, these, they, this, to, was, will, with Sobre esta lista se añaden determinados tokens que pueden aparecer en los asuntos del correo, que no aportan a la hora de hacer la búsqueda, como los indicadores de reenvío de correo, palabras como ’help me’ o ’please’, y pronombres como ’my’. Finalmente la lista de tokens quedará como sigue, siendo siempre abierta a añadir más tokens según se afinen los resultados de búsquedas en el sistema. [ "a", "an", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with", "re", "fw", "my", "i", "help", "me" ] 7http://snowball.tartarus.org/algorithms/porter/stemmer.html 88 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN La principal ventaja con la eliminación de estos tokens es el rendimiento. Elastic determina las recomendaciones a presentar calculando una puntuación de relevancia. No es lo mismo calcular la relevancia para 20 resultados que para 200, debido a que en estos resultados se incluyen todos los documentos que presenten el token RE debido a que simplemente el correo llega rebotado, o que el usuario, presa del pánico, incluye un ’help me please’ en el asunto. Filtro synonym Al aplicar este filtro, parece que contradecimos el uso del filtro anterior, ya que añadimos resultados “adicionales” cuando determinado token se presenta en el texto a analizar. Esto es debido a que, en determinadas circunstancias, es interesante que estos resultados también sean devueltos para su ponderación ya que aportan significado. Así, si un usuario escribe “cosmos” podemos añadir los resultados que aparezcan relativos a “universe”, si el usuario escribe “i pod” también añadiremos los resultados de “i-pod” e “ipod”, siendo equivalentes en ambas direcciones. Para nuestro analizador, simplemente hemos añadido un pequeño grupo de sinónimos directamente en la especificación del filtro. Para un uso más intenso, podemos indicar la ruta a un archivo de sinónimos en la configuración el filtro. La lista aplicada de sinónimos es la siguiente: "synonyms" : ["inet, internet","can’t, can not","don’t, do not"] En nuestro sistema, debido a que la base de datos de incidencias encontrada estaba en inglés, se ha trabajado toda la configuración del analizador en este idioma. En caso de trabajar con incidencias en español, se debería prestar atención a un filtro a mayores, el filtro fonético, que permitiría reducir los tokens a su expresión fonética, para evitar así errores ortográficos a la hora de identificar tokens. Para activar este filtro, es necesario instalarlo previamente como un plugin adicional, y añadirlo a la lista de filtros. Esta solución tiende a multiplicar tokens, generando los sinónimos posibles. Por ejemplo ’barquito’ devolvería resultados de ’varquito’. Otra opción para solucionar este problema, es utilizar búsqueda borrosa a la hora de componer la consulta desde el gestor de incidencias, pero esta opción se estudiará más adelante, cuando lleguemos a ese punto. Si realizamos la siguiente consulta desde Kibana, aplicando nuestro analizador: 5.5. MÓDULO RECOMENDADOR DE SOLUCIONES 89 (a) Análisis adaptado (b) División en tokens Figura 5.27: Análisis de un texto mediante analizador configurado Vemos cómo se han eliminado en el análisis, ’RE’ ’FW’ ’help’ ’me’ ’my’, aún presentándose los dos primeros tokens en mayúsculas, ya que el filtro lowercase ha realizado su trabajo. El stemmer ha acortado el token a su raíz ’credenti’. El filtro de sinónimos se aplica también devolviendo resultados no apostrofados de “do not”. 96 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN de Damerau-Levenshtein9(número mínimo de operaciones requeridas para transformar una cadena de caracteres en otra) que indicaremos en la configuración del parámetro10. Como ya comentamos, esta configuración ha de tomarse con precaución y debe ser ensayada, ya que puede tornarse incluso en perjudicial para el rendimiento del sistema. Analyzer Podemos indicar el analizador que se utilizará para la consulta de búsqueda. Como se vio durante las pruebas en la consola de Kibana, es interesante indicar el mismo analizador que personalizamos para la indexación. Una vez que tenemos listo el QueryBuilder, se lo indicaremos al SearchSourceBuilder. Aquí también podemos señalar ciertas configuraciones interesantes, sobre todo la que determina cuántos resultados queremos cargar en el List de recomendados. Mediante el parámetro size() indicaremos que devuelva los cinco primeros resultados con mayor puntuación ’score’. Finalmente indicaremos a la petición de búsqueda (searchRequest) su constructor de búsqueda (searchRequest). Utilizando el cliente REST generado, se produce el searchRequest y se espera el searchResponse, que devolverá un Json que deberemos recorrer y transformar en objetos ticketModel con ayuda de los métodos proporcionados por Gson, para poblar el List que finalmente devolverá el método. 9https://en.wikipedia.org/wiki/Levenshtein_distance 10https://www.elastic.co/guide/en/elasticsearch/reference/6.2/commonoptions.html#fuzziness 5.6. INTEGRACIÓN EN EL GESTOR 97 Figura 5.36: Transformación de elementos Json en objetos TicketModel Este nuevo servicio implementado será llamado en el momento en que un técnico accede a revisar sus tickets asignados. Es por ello que debemos añadir en el controlador TicketController la inyección de dependencias para poder usar el servicio. Figura 5.37: Inyección de dependencias del servicio Elastic Así, el controlador poblará una nueva sección en la vista, en la que mostrará los tickets devueltos por el recomendador y almacenados en un atributo adicional del model. Figura 5.38: Un nuevo atributo almacenará las recomendaciones 5.6.1. Visualización de recomendaciones Para poder visualizar los resultados devueltos por el recomendador y almacenados como un atributo en el model, debemos crear una iteración que recorrerá 98 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN ese objeto List, mostrando id del ticket, título y resolución, así como un pequeño botón que al pulsar, añadirá la solución recomendada al campo resolución del ticket. Figura 5.39: Iteración en la vista para obtener las recomendaciones Podemos ver como quedaría el resultado final de la vista en la siguiente captura: Figura 5.40: Ticket con recomendaciones de solución 5.7. ELABORACIÓN DEL PANEL DE CONTROL DE SEGUIMIENTO 99 5.6.2. Incorporación de la recomendación en el Crud En el momento en que el técnico asigna la solución pulsando el botón de su derecha, poblará el campo ’resolution’ y el atributo usa_recomendacion. Figura 5.41: Botón de recomendación en la vista Cuando cierre el ticket y lo actualice, la información se guardará en base de datos, marcando el ticket como cerrado y solucionado mediante el uso del servicio recomendador. Esto permitirá el seguimiento de la implantación del recomendador como sistema útil a la hora de solucionar y cerrar los tickets. En el momento que el ticket se marca como cerrado, estará disponible para la próxima ingesta de datos en el índice elastic y, por tanto, pasará a ser una solución recomendada para futuras incidencias coincidentes. 5.7. Elaboración del panel de control de seguimiento Para que el cliente pueda validar la implantación del sistema de recomendación, y aprovechando que tenemos disponible el contenedor con Kibana, procederemos a crear un panel de control con el que podrá visualizar gráficas de implantación, tiempos medios de resolución, tickets asignados a cada técnico, tickets cerrados mediante solucionador, o cualquier requerimiento de información que aporte utilidad a la hora de tomar decisiones por parte del cliente. 5.7.1. Acceso al índice desde Kibana El primer paso será acceder a la sección management de Kibana, para indicar un modelo de índice que pueda reconocer elasticsearch como un índice de datos. En nuestro caso, elastic solo tiene un índice creado, y conocemos su nombre, así que indicamos el nombre tick y Kibana realiza la conexión sin problemas. 100 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Figura 5.42: Reconocimiento del índice por Kibana El siguiente paso será filtrar los datos por un valor temporal. En un sistema real, aquí sería interesante seleccionar la opción @timestamp si la ingesta de tickets cerrados se hace en tiempo real. En nuestro caso, hemos realizado una ingesta de datos instantánea (todos los datos han entrado en una única carga), lo que generaría un idéntico timestamp para la mayoría de los tickets, por tanto nos vemos forzados a seleccionar un campo fecha de los disponibles en los propios tickets, por ejemplo el fecha_close para tener una línea temporal con un rango de fechas utilizable para la visualización. Figura 5.43: Filtrado por un campo temporal Se nos mostrará entonces el resultado de los campos recogidos del índice, y si estos pueden ser utilizados para búsquedas o agregaciones. 5.7. ELABORACIÓN DEL PANEL DE CONTROL DE SEGUIMIENTO 101 Figura 5.44: Campos presentes en el índice Si acudimos a la sección Discover, podremos visualizar nuestros datos, siempre y cuando previamente hayamos modificado las fechas de visualización, adaptándolas al período de datos cargados. Recordemos que en caso de utilizar una ingesta en tiempo real, y utilizando @timestamp, no sería necesario acudir a la variación de fechas de visualización, ya que podríamos ver en tiempo real la creación de datos en el índice. Figura 5.45: Timeline de datos ordenados por el campo filtrado 5.7.2. Creación de visualizaciones El siguiente paso será la creación de las visualizaciones que iremos añadiendo al cuadro de mando. Las visualizaciones son distintos tipos de gráficas que podemos generar con Kibana. Para crear nuestra primera visualización, acudimos a la sección Visualize, y creamos una nueva visualización desde el botón Create a visualization. Debemos seleccionar el tipo: Basic Chart, Data, Maps o Time Series. 102 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN En nuestro caso realizaremos Basic Charts y Data. Comenzaremos seleccionando el clásico gráfico de tarta. Figura 5.46: Tipos habituales de visualizaciones Podemos crear el gráfico desde una búsqueda guardada, o componerlo desde el índice. En nuestro caso seleccionamos el índice. Ahora debemos configurar la sección de métricas y buckets. Los buckets serán “cubos de datos” resultantes de la métrica selecionada. En nuestro ejemplo crearemos una métrica básica de tipo count, contaremos los tickets resueltos por cada técnico. En la sección Metrics seleccionamos Count y en la sección Buckets marcaremos split slices, definiendo la agregación en base a terms, seleccionando el campo designated (que indicaba el técnico al que se le asignaba el ticket). Ordenamos la representación por cantidad (no es muy influyente en este caso en la presentación de los datos) en orden descendente y mostrando como máximo 5 valores en la tarta (solo disponemos de tres técnicos). Una vez configurado, presionamos el icono de play y tenemos nuestra representación gráfica. 5.7. ELABORACIÓN DEL PANEL DE CONTROL DE SEGUIMIENTO 103 (a) Configuración de la visualización (b) Visualización de tickets asignados a cada técnico Figura 5.47: Visualización básica de tipo tarta El paso final será guardar nuestra visualización con un nombre identificativo, cubriendo el campo Save visualization. Una visualización con mayor aporte informativo para el gestor sería por ejemplo la cantidad de tickets que han aplicado el recomendador para su cierre. En la siguiente imagen podemos apreciar su configuración y gráfica. 104 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN (a) Configuración de la visualización (b) Visualización Figura 5.48: Visualización de tickets resueltos con recomendador La gráfica muestra la cantidad de tickets resueltos por semana (marcados en verde) y cómo después de la implantación del sistema recomendador los tickets cerrados con su ayuda (color violeta) comienzan a tener protagonismo. 5.7.3. Composición del panel de control Para facilitar la visualización al gestor, generaremos un único cuadro de mando que aglutinará las visualizaciones diseñadas. El acceso al panel se proporcionará desde un enlace independiente del área de trabajo de Kibana. Accedemos a la sección ‘dashboard’ para crear un panel vacío. Mediante el botón Add añadiremos las visualizaciones, que seleccionamos de las ya generadas. Figura 5.49: Un panel vacío necesita visualizaciones para mostrar 5.7. ELABORACIÓN DEL PANEL DE CONTROL DE SEGUIMIENTO 105 Figura 5.50: Seleccionamos las visualizaciones disponibles Se guardará el panel creado con un nombre identificativo y se procede a seleccionar la opción compartir, para obtener el enlace que facilitar al gestor. Figura 5.51: Desde la etiqueta Share obtenemos el enlace Finalmente el gestor puede visualizar el panel sin mayor complicación. 113 A.0.2. Esquemas Gantt Figura A.2: Diagramas de Gantt correspondientes a los tres primeros incrementos 114 APÉNDICE A. ESQUEMAS EDT Y GANTT Figura A.3: Diagrama de Gantt correspondiente al cuarto incremento Apéndice B Manual de despliegue A continuación se describe el proceso de puesta en funcionamiento de la aplicación, partiendo del material suministrado. Como requerimiento previo, el sistema operativo anfitrión debe tener instalado de manera satisfactoria las aplicaciones Docker y Docker-compose. B.1. Despliegue Se describe el proceso de despliegue sobre una maquina virtual Centos 7 con instalación completada de Docker y Docker-compose 1. El primer paso consistirá en copiar a nuestro sistema anfitrión la estructura de carpetas ’TICKER’ suministrada. Dentro de esta encontraremos todos los archivos de configuración necesarios para desplegar el sistema. Figura B.1: Estructura de carpetas TICKER. 115 116 APÉNDICE B. MANUAL DE DESPLIEGUE 2. Una vez dentro de ella, ejecutamos el comando que levantará todos los contenedores Docker necesarios. Apreciamos como se van descargando las imágenes, creando los volúmenes y contenedores. docker-compose up Figura B.2: Lanzamiento del archivo docker-compose.yml Una vez finalizados los procesos de creación, comienzan a arrancar los servicios señalados en el archivo compose. Entre ellos podemos apreciar como arranca el sistema gestor de incidencias ticker server. Figura B.3: Puesta en funcionamiento del servicio Spring. Podemos validar que todos los servicios están levantados ejecutando el comando Docker que lista los contenedores operativos. Es importante prestar atención a la columna ’CONTAINER ID’ que nos ofrece información sobre los códigos identificadores de los contenedores. B.1. DESPLIEGUE 117 docker ps -a Figura B.4: Contenedores en funcionamientro tras el despliegue. 3. El siguiente paso será poblar la base de datos con el dataset de tickets de ejemplo. Desde la carpeta ticker se ejecutan los comandos siguientes: docker cp dumptotal.sql d073:/data/mysql docker exec -it d073/bin/bash Con la primera línea, se copia el backup de la base de datos en el interior del contenedor MySQL. En la siguiente línea se accede al bash del contenedor para poder ejecutar el acceso a la base de datos. Nótese que para acceder al contenedor no es necesario indicar todo el container id, simplemente las cuatro primeras cifras nos permiten acceder sin problemas. Una vez dentro del contenedor se vuelca el backup en la base de datos creando a la vez la base de datos contenedora, mediante el comando siguiente: mysql -u root -p mydb </data/mysql/dumptotal.sql El sistema nos solicita la password que habremos detallado en el archivo Dockerfile de creación del contenedor Mysql. Para validar la correcta creación de las tablas, se accede a la base de datos. mysql -u root -p Una vez autenticados en el sistema, se indica la base de datos que se desea utilizar y se solicitan las tablas que forman la base de datos, mostrándose la tabla de tickets, usuarios y roles. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9 Server version: 8.0.17 MySQL Community Server - GPL 118 APÉNDICE B. MANUAL DE DESPLIEGUE Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the current input statement. mysql> use mydb Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +----------------+ | Tables_in_mydb | +----------------+ | tickets | | user_roles | | users | +----------------+ 3 rows in set (0.00 sec) mysql> 4. Una vez poblada la base de datos, se procede a crear el índice de Elasticsearch. Este debe ser creado antes de realizar la primera ingesta de tickets. Mediante la utilidad ’CEREBRO’ (http://localhost:9000/#/connect) se puede administrar de manera visual los índices actuales en Elastic. Para ello se debe indicar la dirección de conexión al cluster. B.1. DESPLIEGUE 119 Figura B.5: Utilidad de administración de índices CEREBRO Se puede observar como en estos momentos no tenemos ningún índice creado. Simplemente se aprecian los dos nodos creados en el cluster desplegado Figura B.6: Estado actual del cluster Elastic Se accede al servicio Kibana desde http://localhost:5601/app/kibana para la creación del índice. Seleccionando en la barra izquierda el icono de una llave inglesa, se accede a la consola, en la que se debe pegar el código facilitado para la creación del índice que se encuentra en la carpeta Kibana de la estructura de carpetas inicial. Una vez pegado, se presiona el pequeño icono verde de ’play’, que lanza la ejecución en la consola de Kibana. Si no se produce ningún error, devuelve un mensaje de ejecución correcta 120 APÉNDICE B. MANUAL DE DESPLIEGUE Figura B.7: Correcta creación del índice tick Se puede validar la creación, recuperando la pantalla de cerebro, para observar como se ha generado un índice, distribuido sobre dos nodos de cinco shards (valor por defecto) cada uno. El índice utiliza únicamente 5 shards, que distribuye sobre los nodos de manera alternativa. Es importante señalar que el número de documentos es cero, ya que no hemos reallizado la ingesta todavía. Figura B.8: Distribución del índice sobre los nodos del cluster 5. Para trasladar los tickets cerrados desde la base de datos, se debe configurar y lanzar la ingesta desde el contenedor de Logstash. Para ello, primero se B.2. CICLO DE UNA INCIDENCIA 121 procede a copiar el archivo de configuración del pipeline a lanzar. Desde la carpeta logstash/config abrimos terminal y copiamos el archivo logstash.conf a la carpeta de pipelines del contenedor Logstash. Accedemos al contenedor, y dentro de este a la carpeta que almacena el bin ejecutable de Logstash. Desde alli, lanzamos el programa, indicando la configuración del pipeline deseado. docker cp logstash.conf 9d19:/usr/share/logstash/pipeline docker exec -it 9d19 /bin/bash logstash -r -f /usr/share/logstash/pipeline/logstash.conf Se aprecia como arranca el programa, realizando la conexión y comenzando la ingesta. Si se visualiza a la vez la aplicación cerebro podemos apreciar como se incrementa el número de documentos inyectados en el índice. Figura B.9: Población del índice con los documentos ingestados En estos momentos el sistema ya está plenamente operativo. Para validar el funcionamiento, se puede realizar un ciclo completo de creación, acceso, recomendación y solución de una incidencia. B.2. Ciclo de una incidencia Se representa a continuación el ciclo completo de una incidencia, para validar el funcionamiento operativo de los sistemas. C.1. DIAGRAMAS DE CLASES DEL SISTEMA GESTOR DE INCIDENCIAS.129 130 APÉNDICE C. MANUALES TÉCNICOS C.2. Árbol de clases Figura C.4: Árbol de clases del gestor de incidencias C.3. ÍNDICE RECOMENDADOR 131 C.3. Índice recomendador Figura C.5: Cuerpo del índice recomendador C.4. Enlace descarga Imagen Centos 7 Imagen virtual VMWare Centos 7 con los materiales para el despliegue Bibliografía [1] MySQL Reference. Versión 8.0. Página del producto (https://dev.mysql.com/doc/refman/8.0/en/). Consultado por última vez el 2 de enero de 2020. [2] Elasticsearch Reference. Versión 6.2.4. Página del producto (https://www.elastic.co/guide/en/elasticsearch/reference/6.2/index.html). Consultado por última vez el 2 de enero de 2020. [3] Logstash Reference. Versión 6.2.4. Página del producto (https://www.elastic.co/guide/en/logstash/6.2/index.html). Consultado por última vez el 2 de enero de 2020. [4] Kibana Reference. Versión 6.2.4. Página del producto (https://www.elastic.co/guide/en/kibana/6.2/index.html). Consultado por última vez el 2 de enero de 2020. [5] Amuthan Ganeshan, Spring MVC Beginner’s Guide, 2aedición, Packt Publishing; Edición: 2nd Revised edition (29 de julio de 2016). [6] Thymeleaf. Version 3.0.4. Página del proyecto (https://www.thymeleaf.org/documentation.html). Consultado por última vez el 2 de enero de 2020. [7] GAMMA, Erich et al. , Patrones de Diseño: elementos de software orientado a objetos reutilizable., Madrid: Addison-Wesley, 2002. ISBN 84-7829-059-1. [8] Spring Data JPA. Version 2.2.3.RELEASE, 2019-1204. Página del proyecto (https://docs.spring.io/springdata/jpa/docs/2.2.3.RELEASE/reference/ht). Consultado por última vez el 2 de enero de 2020. [9] Reference Guide. 1.0.0.Final. Página del proyecto (https://docs.jboss.org/hibernate/jpamodelgen/1.0/reference/enUS/html_single). Consultado por última vez el 2 de enero de 2020. 133 134 BIBLIOGRAFÍA [10] Spring Security Reference. 5.2.2.BUILD-SNAPSHOT. Página del proyecto (https://docs.spring.io/spring-security/site/docs/5.2.2.BUILDSNAPSHOT/reference/htmlsingle/). Consultado por última vez el 2 de enero de 2020. [11] Docker community edition. Página del producto (https://docs.docker.com/install/). Consultado por última vez el 2 de enero de 2020. [12] Introducción a JSON. Página del proyecto (https://www.json.org/jsones.html). Consultado por última vez el 2 de enero de 2020. [13] MySQL Workbench. Versión 8.0.19. Página del producto (https://www.mysql.com/products/workbench/). Consultado por última vez el 2 de enero de 2020. [14] Java. Version 8. Página del producto (https://www.java.com/es/about/whatis_java.jsp). Consultado por última vez el 2 de enero de 2020. [15] Apache Maven Project. Versión 3.6.3. Página del proyecto (https://maven.apache.org/). Consultado por última vez el 2 de enero de 2020. [16] Spring Boot Reference Guide. 2.1.12.BUILD-SNAPSHOT. Página del proyecto (https://docs.spring.io/spring-boot/docs/2.1.12.BUILDSNAPSHOT/reference/html/). Consultado por última vez el 2 de enero de 2020. [17] YALM. Versión 1.2.(3rd Edition) Página del proyecto (https://yaml.org/). Consultado por última vez el 2 de enero de 2020. [18] Overview of Docker Compose. Versión 1.25.0. Página del producto (https://docs.docker.com/compose/). Consultado por última vez el 2 de enero de 2020. [19] Roger S Pressman Ingeniería del Software. Un enfoque práctico., Ed. Mc Graw Hill, España. 2005. ISBN: 970-10-5473-3. [20] Querydsl Reference Guide. Versión 4.1.3. Página del proyecto (http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/). Consultado por última vez el 2 de enero de 2020. [21] A Java serialization/deserialization library to convert Java Objects into JSON and back. Versión 2.8.6. Página del proyecto (https://github.com/google/gson). Consultado por última vez el 2 de enero de 2020. BIBLIOGRAFÍA 135 [22] The Apache Lucene project develops open-source search software. Versión 8.4.1. Página del proyecto (https://lucene.apache.org/). Consultado por última vez el 2 de enero de 2020. [23] Redmine. Página del producto (https://www.redmine.org/). Consultado por última vez el 2 de enero de 2020. [24] RT (Request Tracker). Página del producto (https://bestpractical.com/request-tracker). Consultado por última vez el 2 de enero de 2020. [25] OTRS. Página del producto (https://otrs.com/es/home/?lang=es). Consultado por última vez el 2 de enero de 2020. [26] C-desk. Página del producto (http://www.cdesk.in/). Consultado por última vez el 2 de enero de 2020. [27] Aprendizaje autónomo Elasticsearch. Página del producto (https://www.elastic.co/es/what-is/elasticsearch-machine-learning/). Consultado por última vez el 2 de enero de 2020. [28] GitHub plugin detector de idioma sobre Logstash. Página del proyecto (https://github.com/thehybridtechnician/logstash-filter-language). Consultado por última vez el 2 de enero de 2020. [29] Publicaciones de Pablo Gamallo Otero. Página del investigador (https://citius.usc.es/equipo/persoal-adscrito/pablo-gamallo-otero/). Consultado por última vez el 2 de enero de 2020. [30] Entendiendo el proceso de búsqueda. (https://www.blog.google/products/search/searchlanguage-understanding-bert/). Consultado por última vez el 2 de enero de 2020. [31] Miguel A. M., Desarrollo Web con Spring Boot , https://www.udemy.com/course/desarrollo-web-con-spring-framework4-de-cero-a-ninja/ (12 de diciembre de 2016).