JunCo: Una aplicación web para automatizar configuraciones de switches, routers y equipos de red

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA Menci´on en Ingenier´ıa del Software JunCo: Una aplicaci´on web para automatizar configuraciones de switches, routers y equipos de red Alumno: Enrique Garc´ıa Nieto Tutor: Yania Crespo Gonz´alez-Carvajal A todas las personas que han hecho de mi camino un agradable paseo I II AGRADECIMIENTOS Agradecimientos A mi padre, por haber hecho todos los esfuerzos que me han permitido llegar al final de esta carrera. A mis amigos, por haber estado siempre apoyando y haber sido uno de mis pilares de apoyo en todos estos a˜nos, tanto en esta situaci´on como en muchas otras. A Jos´e Lu´ıs y Mamen, por haber sido mi segundo hogar durante tantos a˜nos. A Daniel Barba, por ser una motivaci´on acad´emica y un espejo donde poder mirarme en muchos aspectos. A Javier Alaguero, cuyas indicaciones y paciencia me han sacado de m´as de un apuro durante la carrera, y por haberme ense˜nado el interesante mundo del front-end. A mi equipo de trabajo, quienes desde el primer d´ıa se han esforzado en integrarme y en ense˜nar, pese a lo complicado de la situaci´on del teletrabajo. A todas las personas que han supuesto para m´ı m´as un hogar que una amistad y a aquellas que me han ayudado en cada parte de este camino. Finalmente a Irene, mi principal apoyo en esta vida, por estar siempre ah´ı cuando m´as lo he necesitado y a quien durante muchos, muchos a˜nos, espero poder devolver todo lo que ha hecho por m´ı. III AGRADECIMIENTOS IV RESUMEN Resumen El objetivo de este proyecto es facilitar la gesti´on, administraci´on y aplicaci´on de configuraciones en dispositivos de red, ya sean routers, switches o firewalls. El proyecto est´a enfocado a los administradores de redes y sistemas que d´ıa a d´ıa tienen que operar con estos dispositivos, para facilitar as´ı su trabajo, aportando una interfaz para operar con estos dispositivos, adem´as de a˜nadir m´ultiples funcionalidades que pueden ser de gran utilidad como aplicar una misma configuraci´on a varios dispositivos de manera autom´atica, mantenimiento de una base de datos de los dispositivos utilizados, adem´as de otras operaciones como b´usqueda de tablas ARP o ver la configuraci´on interna de cada dispositivo sin tener que conectarse directamente a ´este a trav´es de l´ınea de comandos. Por ´ultimo, la motivaci´on a la hora de desarrollar este proyecto es ahorrar tiempo a la hora de realizar tareas repetitivas que se pueden automatizar, aumentando la productividad del personal encargado de administrar estos equipos y aumentando la facilidad de uso de ´estos a trav´es de una interfaz intuitiva. El proyecto se ha construido utilizando el framework Vue.js, Javascript, HTML5 y CSS para el frontend, Python para backend y MySQL para la capa de persistencia. En cuanto a la metodolog´ıa para el seguimiento y el control del proyecto, se ha realizado adaptando el marco de trabajo para desarrollo ´agil Scrum al contexto de este proyecto. V RESUMEN VI ABSTRACT Abstract The objective of this project is to facilitate management, administration, and application of configurations in network devices, whether these are routers, switches, or firewalls. The project is focused on network and system administrators who, commonly, operate with these devices, thus easing their work by providing a graphical interface to manage these devices. Moreover, the project aims to deliver a set of useful functionalities such as running batch configuration among a number of devices automatically as well as maintaining a device database, performing ARP table searches, or recovering remote configuration without the need for a CLI interface mechanism. The motivation for this project comes from the nature of this kind of device operations, which are usually repetitive and time consuming. CLI interfaces tend to be rough and hard to master, also implies some risk, whereas graphical interfaces reduce complexity by hiding some procedures behind an easy to use application and an intuitive interface. The project has been developed using the following technology stack. Frontend side uses the Vue.js framework, Javascript, HTML, and CSS. Backend has been coded in Python. Finally, for the persistence layer the project uses MySQL as DBMS and is interfaced with the backend using SQL Alchemy as ORM. The project has been developed using an adapted Scrum agile development framework for this context. VII ´ INDICE GENERAL XIV LISTA DE FIGURAS Lista de Figuras 2.1. RolesenScrum[11] ................................ 9 3.1. Workflow del algoritmo de b´usqueda ARP (1/2) . . . . . . . . . . . . . . . . 27 3.2. Workflow del algoritmo de b´usqueda ARP (2/2) . . . . . . . . . . . . . . . . 28 3.3. Workflow completo del algoritmo de b´usqueda ARP (detalle por partes en las Figuras3.1y3.2).................................. 29 3.4. Modelodedominiofinal.............................. 31 4.1. VCSm´asusados[63]................................ 34 4.2. Evoluci´on de las preguntas en Stack Overflow [63] . . . . . . . . . . . . . . . . 34 4.3. Los tres estados de Git [55] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Ramas en Git (fuente: NobleDesktop) . . . . . . . . . . . . . . . . . . . . . . 36 4.5. Sistemas gestores de bases de datos m´as usados (2019) [1] . . . . . . . . . . . 40 4.6. Ciclo de vida de una instancia en Vue [39] . . . . . . . . . . . . . . . . . . . 43 5.1. Elementos del patr´on MVVM, obtenida en [10] . . . . . . . . . . . . . . . . . 48 5.2. Diagrama de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3. Boceto de la vista “Devices” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.4. Boceto de la vista “Configlets” . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.5. Boceto de la vista “Apply Configlets” . . . . . . . . . . . . . . . . . . . . . . 56 5.6. Boceto de la vista “Login” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 XV LISTA DE FIGURAS 5.7. Boceto de la vista “ARP Search” . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.8. Boceto del componente Dialog en el caso de A˜nadir/Editar dispositivo . . . . 58 5.9. Boceto del componente Dialog en el caso de Eliminar dispositivo . . . . . . . 59 5.10. Boceto del componente Alert de prop´osito general . . . . . . . . . . . . . . . 59 5.11. Aplicaci´on de configlets a un dispositivo . . . . . . . . . . . . . . . . . . . . . 60 5.12. Validaci´on de configlets correcta . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.13. Validaci´on de configlets incorrecta . . . . . . . . . . . . . . . . . . . . . . . . 61 5.14. Aplicar un configlet a varios dispositivos . . . . . . . . . . . . . . . . . . . . . 62 5.15. Diagrama de despliegue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.16. Diagrama de despliegue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.1. Modelo de dominio inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.2. Modelo de dominio versi´on 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3. Modelo de dominio sin Configlets . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.4. Modelo de dominio definitivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.5. Modelo relacional de la base de datos (1) . . . . . . . . . . . . . . . . . . . . 79 6.6. Modelo relacional de la base de datos (2) . . . . . . . . . . . . . . . . . . . . 80 6.7. Modelo relacional de la base de datos (3) . . . . . . . . . . . . . . . . . . . . 81 6.8. Modelo relacional de la base de datos final . . . . . . . . . . . . . . . . . . . . 82 7.1. Tareas seg´un su estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.1.VistadeLogin ................................... 120 A.2.VistaHome..................................... 120 A.3. Vista de About (Sobre esta p´agina) . . . . . . . . . . . . . . . . . . . . . . . . 121 A.4.Selecci´ondeidioma................................. 121 A.5. Vista All devices, en la que se muestran todos los dispositivos . . . . . . . . . 122 A.6. Vista All devices, con un dispositivo seleccionado . . . . . . . . . . . . . . . . 123 XVI LISTA DE FIGURAS A.7. Componente para a˜nadir un dispositivo . . . . . . . . . . . . . . . . . . . . . 124 A.8. Componente para editar un dispositivo . . . . . . . . . . . . . . . . . . . . . . 124 A.9. Componente para eliminar dispositivos . . . . . . . . . . . . . . . . . . . . . . 125 A.10.Vista para realizar b´usqueda ARP . . . . . . . . . . . . . . . . . . . . . . . . 126 A.11.Vista que muestra un resultado de una b´usqueda ARP . . . . . . . . . . . . . 126 A.12.Vista que muestra los configlets disponibles. . . . . . . . . . . . . . . . . . . . 127 A.13.Configuraci´on de un configlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.14.Vista para aplicar un configlet a varios dispositivos . . . . . . . . . . . . . . . 128 A.15.Vista para introducir los par´ametros en cada uno de los dispositivos seleccionados129 A.16.Validaci´on incorrecta de, al menos, un configlet. . . . . . . . . . . . . . . . . . 130 A.17.Validaci´on correcta de configlets. . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.18.DispositivosJuniper ................................ 131 A.19.Vista para aplicar uno o m´as configlets sobre un dispositivo concreto . . . . . 132 A.20............................................. 132 XVII LISTA DE FIGURAS XVIII LISTA DE TABLAS Lista de Tablas 2.1. P.H. asociados a n´umero de horas (Fibonacci) . . . . . . . . . . . . . . . . . . 11 2.2. Distribuci´on inicial de sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Descripci´on de historias de usuario H.U.: Historia de Usuario . . . . . . . . . 15 2.4. Tabla de puntuaci´on de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5. Riesgo1....................................... 16 2.6. Riesgo2....................................... 16 2.7. Riesgo3....................................... 17 2.8. Riesgo4....................................... 17 2.9. Riesgo5....................................... 17 2.10.Riesgo6....................................... 17 2.11.Riesgo7....................................... 18 2.12.Riesgo8....................................... 18 2.13.Riesgo9....................................... 18 2.14.Riesgo10 ...................................... 18 6.1. Bater´ıa de pruebas (Modelo de dominio 1) . . . . . . . . . . . . . . . . . . . . 86 7.1. Sprint 1: 08/02/2021 - 14/02/2021 . . . . . . . . . . . . . . . . . . . . . . . . 90 7.2. Sprint 2: 15/02/2021 - 21/02/2021 . . . . . . . . . . . . . . . . . . . . . . . . 92 7.3. Sprint 3: 22/02/2021 - 28/02/2021 . . . . . . . . . . . . . . . . . . . . . . . . 94 XIX LISTA DE TABLAS 7.4. Sprint 4: 01/03/2021 - 07/03/2021 . . . . . . . . . . . . . . . . . . . . . . . . 95 7.5. Sprint 5: 08/03/2021 - 14/03/2021 . . . . . . . . . . . . . . . . . . . . . . . . 96 7.6. Sprint 6: 15/03/2021 - 21/03/2021 . . . . . . . . . . . . . . . . . . . . . . . . 97 7.7. Sprint 7: 22/03/2021 - 28/03/2021 . . . . . . . . . . . . . . . . . . . . . . . . 99 7.8. Sprint 8: 29/03/2021 - 04/04/2021 . . . . . . . . . . . . . . . . . . . . . . . . 100 7.9. Sprint 9: 05/04/2021 - 11/04/2021 . . . . . . . . . . . . . . . . . . . . . . . . 101 7.10. Sprint 10: 12/04/2021 - 18/04/2021 . . . . . . . . . . . . . . . . . . . . . . . . 102 7.11. Sprint 11: 19/04/2021 - 25/04/2021 . . . . . . . . . . . . . . . . . . . . . . . . 103 7.12. Sprint 12: 26/04/2021 - 02/05/2021 . . . . . . . . . . . . . . . . . . . . . . . . 104 7.13. Sprint 13: 03/05/2021 - 09/05/2021 . . . . . . . . . . . . . . . . . . . . . . . . 106 7.14. Sprint 14: 10/05/2021 - 16/05/2021 . . . . . . . . . . . . . . . . . . . . . . . . 107 7.15. Sprint 15: 17/05/2021 - 23/05/2021 . . . . . . . . . . . . . . . . . . . . . . . . 108 7.16. Sprint 16: 24/05/2021 - 30/05/2021 . . . . . . . . . . . . . . . . . . . . . . . . 110 7.17. Sprint 17: 31/05/2021 - 06/06/2021 . . . . . . . . . . . . . . . . . . . . . . . . 111 7.18. Tareas por cada Historia de Usuario . . . . . . . . . . . . . . . . . . . . . . . 114 7.19. Horas por cada Historia de Usuario . . . . . . . . . . . . . . . . . . . . . . . . 114 XX CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on 1.1. Contexto El principal objetivo de este trabajo de fin de grado es crear, desarrollar y poner en funcionamiento una aplicaci´on web dedicada a la gesti´on de configuraciones, obtenci´on de datos y automatizaci´on de tareas de equipos de redes, tanto switches como routers o firewalls. Est´a destinada a administradores de dispositivos de red, quienes podr´an disfrutar de varias ventajas al utilizar esta aplicaci´on web en lugar de configurar equipos u obtener la informaci´on necesaria por l´ınea de comandos. Si nos fijamos en los puntos favorables que podemos obtener al utilizar esta herramienta, podemos destacar (1) la seguridad, al tener software que valide la configuraci´on antes de aplicarse a uno o varios dispositivos, (2) la comodidad y la automatizaci´on de tareas, que permite realizar una misma configuraci´on en un lote de varios dispositivos de red, lo que facilitar´a el trabajo reduciendo el tiempo de tareas rutinarias y comunes, adem´as de evitar problemas como, por ejemplo, actualizar un dispositivo con una configuraci´on que provoque un mal funcionamiento del mismo. Por otro lado, si nos fijamos en las cuestiones relacionadas con las configuraciones de equipos, la aplicaci´on utilizar´a la API de Junos Space y, para cuestiones de autenticaci´on y autorizaci´on, la API de la plataforma ClearPass. Tambi´en utilizamos APIs para conectarnos a dispositivos Juniper a trav´es de PyEZ, mientras que los dispositivos de Juniper utilizan Netmiko para conectarse a sus dispositivos. Estas ´ultimas APIs nos permiten conectarnos a los equipos a trav´es de SSH o Telnet y realizar llamadas para obtener informaci´on sobre sus configuraciones. Por ´ultimo, mencionar que tanto el enfoque ´agil como las tecnolog´ıas empleadas se ajustan al contexto del Trabajo de Fin de Grado, junto a la elaboraci´on del presente documento a modo de memoria [60]. 1 1.2. MOTIVACI ´ ON 1.2. Motivaci´on La principal idea de este proyecto surgi´o al ver las tareas que realizaban mis compa˜neros del grupo de trabajo. El grupo de trabajo donde me encuentro actualmente se dedica al mantenimiento, administraci´on y soporte de dispositivos de redes, tales como switches, routers o firewalls. Ellos son los que se encargan de modificar la configuraci´on de la red a petici´on de otros usuarios, comprobar incidencias, realizar mantenimiento de todos los equipos, cambios en las topolog´ıas de red y realizar un seguimiento del funcionamiento de todos estos equipos. Tras trabajar unos cuantos meses con ellos y adquirir algo de conocimiento sobre el dominio de redes y dispositivos de red, identifiqu´e varias tareas que son muy mec´anicas, requiren gran cantidad de tiempo y, sobre todo, son repetitivas a lo largo del tiempo. Esto quiere decir que, peri´odicamente, se emplea una cantidad significativa de tiempo en realizar estas tareas y, por lo tanto, se puede ofrecer una soluci´on software para facilitar las tareas a mi equipo de trabajo no s´olo en cuanto a tiempo invertido, sino tambi´en respecto a otros aspectos como la facilidad o la seguridad a la hora de realizar este tipo de trabajos. 1.3. P´ublico objetivo Al no existir alternativas y al estar concebido para uso ´unico y exclusivo dentro del marco empresarial de mi equipo de trabajo, el p´ublico objetivo se compone de los administradores de equipos de red que a diario reciben peticiones para aplicar configuraciones y modificaciones en dichos dispositivos. Debido a esta situaci´on, el tratar d´ıa a d´ıa con los potenciales usuarios de esta aplicaci´on me va a permitir tener una retroalimentaci´on constante en aspectos como la interfaz de usuario, la experiencia de usuario o decisiones sobre el dise˜no de las herramientas de la aplicaci´on o del propio dise˜no de ´esta. 1.4. Aplicaciones similares Al ser una aplicaci´on con un prop´osito espec´ıfico, si hubiera una aplicaci´on que pudiese cubrir estas necesidades ya habr´ıa sido adquirida. Aun as´ı, esta aplicaci´on s´ı se nutre de funcionalidades de aplicaciones ya existentes, adem´as de APIs de otros programas y aplicaciones como los siguientes: SecureCRT: propiedad de la empresa de software VanDyke, SecureCRT es un cliente de terminal tanto de SSH como de Telnet, con el cual podemos acceder a la terminal de dispositivos de red de manera remota. SecureCRT permite la introducci´on de comandos por terminal para ver, modificar o eliminar datos y configuraciones, lo cual tambi´en est´a incluido como funcionalidad inicial en mi proyecto [61]. Adem´as de lo anterior, tambi´en permite guardar las sesiones del usuario para conectarte a los dispositivos (usuario y contrase˜na), de tal manera que permite ver todos los dispositivos a los que puedes acceder. 2 CAP´ ITULO 1. INTRODUCCI ´ ON Junos Space: es la herramienta de los equipos Juniper que permite administrar, ver detalles y aplicar configuraciones remotas en los dispositivos. Tambi´en cuenta con una API sobre la que podemos hacer peticiones REST y operar con ella, de modo que parte de sus servicios los podemos integrar en nuestra aplicaci´on [37]. 1.5. Objetivos En esta secci´on voy a desarrollar por una parte los objetivos a nivel de requisitos que quiero cumplir con este proyecto y, por otro, qu´e espero aprender personalmente en mi carrera profesional realiz´andolo. 1.5.1. Objetivos t´ecnicos El primero de los objetivos t´ecnicos que se intenta cumplir con esta aplicaci´on es facilitar el realizar varias tareas de manera autom´atica a los administradores de redes. Hay multitud de tareas que se repiten en el tiempo y que conllevan mucho tiempo que se pueden realizar de una manera m´as simple, permitiendo al usuario introducir los par´ametros necesarios para realizar la configuraci´on deseada. La automatizaci´on de tareas suele traducirse en reducci´on de costes operacionales, aumento de productividad, disponibilidad, fiabilidad y rendimiento, por lo que atacar a este objetivo puede llevarnos a conseguir ´exito en varios de los campos anteriores [26]. Junto a esto, otro objetivo que se cumple al reunir todas las caracter´ısticas propuestas es la centralizaci´on de configuraciones y extracci´on de datos. En vez de utilizar distintas herramientas para realizar configuraciones, mostrar datos o a˜nadir o eliminar dispositivos, con esta aplicaci´on se podr´a acceder de una manera m´as c´omoda a todas las funcionalidades, aportando comodidad a los usuarios. Esto va a facilitar tanto la consulta como la ejecuci´on de tareas desde un mismo lugar, ahorrando tiempo y a˜nadiendo facilidad de uso. Por ´ultimo, tambi´en se a˜nade seguridad debido a la facilidad a la hora de realizar tareas. Al evitar que el usuario tenga que introducir par´ametros por consola directamente en los terminales, adem´as de las herramientas de validaci´on extras que podemos incluir, se reduce considerablemente el fallo humano [42]. Junto a lo anterior, tambi´en se a˜nade una autenticaci´on frente al servidor de ClearPass, lo que a˜nade un factor extra de seguridad. En el servidor de ClearPass se encuentran registrados los grupos de usuarios y los permisos de cada uno de ellos, de modo que si un usuario se registra, podemos decidir qu´e permisos tendr´a a la hora de realizar peticiones o ejecutar cierto tipo de tarea. En resumen, los objetivos principales de nuestra aplicaci´on se centran en la facilidad de uso,centralizar las funcionalidades que antes estaban recogidas en otras plataformas, automatizar algunas tareas y, por ´ultimo, a˜nadir un factor extra de seguridad. 3 2.1. MARCO DE DESARROLLO ´ AGIL Sprint: un sprint es un bloque de tiempo en el cual se desarrolla el trabajo en s´ı mismo. Como recomendaci´on, la duraci´on de ´estos debe ser constante y definida por el equipo o por el Scrum Master. Al finalizar el sprint, el equipo debe presentar la situaci´on actual del proyecto, el progreso de ´este as´ı como el resultado obtenido. Dicho resultado consiste en un incremento de producto que se puede considerar como “terminado”, que se puede entregar al cliente. Durante el sprint se recomienda no agregar objetivos adicionales a no ser que la ausencia de ´estos pongan en peligro la funcionalidad del proyecto entregable. El sprint debe, en la medida de lo posible, mantener unos requisitos predefinidos y unos objetivos claros e inmutables durante su desarrollo. Si se quiere a˜nadir algo, debe intentar incluirse en otro sprint posterior, aunque puede hacerse en el mismo. El sprint est´a limitado a una duraci´on no mayor de un mes. En nuestro caso, la duraci´on de cada sprint se ha fijado en una semana. Sprint planning: esta planificaci´on del sprint consiste en organizar el trabajo a realizar durante el tiempo de duraci´on del sprint. Este trabajo lo lleva a cabo el Developement Team. Durante esta fase tambi´en tiene lugar la asignaci´on y estimaci´on de carga de trabajo a cada tarea. Dicha asignaci´on se denomina Punto de historia (Story Point), denominado con las siglas PH oSP. Cada punto de historia equivale a una cantidad determinada de horas que el equipo de desarrollo debe emplear para realizar todas las tareas del punto de historia en cuesti´on. Story Points o Puntos de historia: como hemos visto antes, un punto de historia es una unidad de esfuerzo asignada a cada historia de usuario. Los puntos dan idea del tama˜no y el esfuerzo que se necesita para realizar dichas tareas dentro de un sprint. Debido a esto, son una buena manera de expresar el esfuerzo en t´erminos de tiempo de trabajo que puede llevar cada tarea. Los puntos de historia se pueden fijar con varios m´etodos. Uno de ellos es la escala lineal, en la cual un punto equivale a un n´umero predefinido de horas, y si la cantidad de puntos de historia para una historia de usuario aumentan, lo har´an de manera proporcional las horas de trabajo asociadas. En este proyecto he cre´ıdo conveniente establecer la serie de Fibonacci, donde el siguiente n´umero en la escala de los PH es la suma de los dos anteriores. De esta manera, una distribuci´on de puntos de historia siguiendo la sucesi´on de Fibonacci queda as´ı reflejada como se muestra en la Tabla 2.1: Daily Scrum o Daily Standup: llamado tambi´en Scrum diario, es una peque˜na reuni´on entre cinco y quince minutos con el motivo de mantener informados al resto de miembros del equipo de desarrollo. De esta manera, ellos sabr´an qu´e problemas se han encontrado desde el ´ultimo scrum diario, qu´e se espera encontrar o en qu´e est´a trabajando cada miembro del equipo. Si se requiere ampliar un tema, se debe hacer posteriormente tras el scrum diario. En resumen, esta reuni´on pone en com´un el progreso del equipo y los esfuerzos se centran en sincronizar a todos los miembros del equipo para alcanzar correctamente la meta del sprint. En nuestro caso, como el Development Team est´a formado por una persona, no se ha cre´ıdo necesario realizar esta Daily Standup. Sprint Review (revisi´on del sprint): el prop´osito de esta reuni´on es que, al final de cada sprint, el equipo realice tanto la revisi´on del sprint como su retrospectiva. En la 10 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON P.H. Node horas 1 1 2 2 3 3 4 5 5 8 6 13 7 20 8 33 9 53 Tabla 2.1: P.H. asociados a n´umero de horas (Fibonacci) reuni´on dedicada a la revisi´on, se presentan los trabajos completados en ese lapso de tiempo. El tiempo recomendado no debe superar las 4 horas para un sprint de un mes. Durante este evento, el Scrum Team y los stakeholders implicados deben inspeccionar qu´e ha cambiado en el entorno del proyecto y, bas´andose en esta informaci´on, se planifica qu´e hacer para el siguiente sprint. Consecuentemente, el Product Backlog debe ser ajustado para dar cabida a estos nuevos cambios Sprint Retrospective (retrospectiva del sprint): al igual que la revisi´on vista anteriormente, se lleva a cabo al finalizar el sprint. En la retrospectiva, todos los miembros del equipo dejan sus impresiones sobre el sprint reci´en superado como, por ejemplo, qu´e problemas han tenido o sugerencias de mejoras para optimizar el trabajo. El Scrum Team debe identificar los cambios m´as significativos para mejorar su eficacia. Las mejoras que puedan suponer un mayor cambio positivo son las que primero deben adoptarse para los siguientes sprints. Esta sesi´on da por conclu´ıdo el sprint. Debe limitarse a un m´aximo de tres horas para un sprint de un mes, siendo m´as corto para sprints con menor duraci´on. Sprint Goal (objetivo del Sprint): el objetivo del sprint es una meta establecida para dicho sprint. A medida que el equipo trabaja, debe hacerlo con la meta o el objetivo del sprint siempre en mente para as´ı intentar satisfacer el objetivo aportando la funcionalidad necesaria. El objetivo del sprint puede desglosarse en User Stories (U.S.) o Historias de Usuario (H.U.) del Backlog. 2.1.4. Artefactos de Scrum Dentro del marco Scrum, los artefactos son aquellos que generan valor al producto. Representan trabajo o valor en diversas formas que son ´utiles para proporcionar transparencia en el desarrollo. Los artefactos relevantes dentro de Scrum son los siguientes: [57] Product Backlog (lista de producto): lista ordenada de todos los requisitos del producto. Es la ´unica fuente de requisitos para cualquier cambio que deba realizarse en el 11 2.2. PLANIFICACI ´ ON producto. Comienza con un Backlog inicial, donde se ponen las tareas que se pretenden realizar a lo largo del ciclo de desarrollo de un proyecto. Estas tareas deben citarse posteriormente en el Product Backlog. El Product Backlog empieza con una visi´on inicial del producto y crece y evoluciona durante el desarrollo del producto. Debido a esta naturaleza, el Product Backlog es cambiante y siempre est´a sujeto a modificaciones. Esta lista de producto nunca est´a completa. Su desarrollo m´as temprano s´olo refleja los objetivos m´as generales y m´as f´acilmente comprensibles. A medida que se hacen los sprints y se obtiene retroalimentaci´on, esta lista se va ampliando y los requisitos son m´as largos y exhaustivos. Las personas encargadas de trabajar en el Product Backlog son los integrantes del Development Team. Sprint Backlog: registra los requisitos desde el punto de vista de los desarrolladores. Es la lista de tareas pendientes durante un sprint para llevar a cabo el incremento deseado, es decir, el Sprint Backlog es un subconjunto del Product Backlog, puesto que el primero est´a compuesto de elementos del segundo que se han seleccionado para el sprint. Al contrario que el Product Backlog, el Sprint Backlog es est´atico no se modifica mientras el sprint se encuentra en desarrollo. El sprint backlog permite ver las tareas necesarias para alcanzar el Sprint Goal. Incremento: es el resultado de a˜nadir todos los elementos del Product Backlog que se han llevado a cabo en el sprint. Al final de un sprint, el nuevo incremento debe estar terminado, es decir, debe estar disponible y operativo para ser utilizado. 2.2. Planificaci´on 2.2.1. Adaptaci´on de Scrum al proyecto El marco general de Scrum debe ser aplicado al contexto de este Trabajo de Fin de Grado. De esta manera, debemos ver c´omo podemos aplicar Scrum a las caracter´ısticas de ´este. En primer lugar, vamos a hablar de los roles de Scrum. En nuestro caso, las personas que desempe˜nan los distintos roles est´an claramente diferenciadas. Scrum Master: este rol lo desempe˜na Yania, mi tutora de TFG, encarg´andose de tareas como que se cumplan los plazos, que cada iteraci´on a˜nada una funcionalidad ´util para el Product Owner, que la documentaci´on sea adecuada, etc. Tambi´en es ella quien se encarga de fijar las reuniones (tanto Sprint Planning como Sprint Review, adem´as de la Sprint Retrospective aunque, al ser sprints de una semana, estas reuniones se unifican realiz´andose todas el mismo d´ıa) y dar algo de retroalimentaci´on en cuanto al porcentaje del proyecto completado y aspectos generales del proyecto. No obstante, en cuanto al Product Backlog, es el alumno quien se encargar´a de completarlo, siendo ella la que simplemente supervise este artefacto de Scrum. Product Owner: en este caso, como el proyecto se realiza bajo un entorno empresarial para el uso por parte de un equipo de administradores de redes, el Product Owner ha 12 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON sido el coordinador del equipo donde he estado trabajando. De esta manera, he podido tener retroalimentaci´on constante de las funcionalidades, tanto de aquellas que fueron expresamente pedidas por ´el como otras propuestas por m´ı. Al igual que con el Scrum Master, acordamos al inicio del proyecto fijar un d´ıa por semana para revisar c´omo se desarrollan las funcionalidades, ver nuevas posibilidades y posibles ampliaciones y cambios en la funcionalidad. Development Team: por ´ultimo, como es obvio, el Development Team est´a compuesto ´unicamente por una persona, es decir, por m´ı. Al ser un proyecto personal, soy el ´unico encargado de desarrollarlo. Tambi´en he sido el responsable para redactar la lista de historias de usuario del Product Backlog. Para el desarrollo del c´odigo, he decidido utilizar Git como sistema de control de versiones. Como los datos que trato en mi TFG son considerados informaci´on sensible, no he podido tener todo el repositorio subido de manera inicial. Al finalizar el proyecto, he subido la versi´on final para poder consultarlo, por lo que simplemente he utilizado Git de manera local hasta la versi´on final. Por otro lado, para las historias de usuario, he utilizado Jira como herramienta para seguimiento de tareas. Al ser tambi´en una herramienta de dominio empresarial, en cada tarea pon´ıa como supervisor al Product Owner, es decir, a m´ı coordinador. De esta manera, he ido anotando el desarrollo de las tareas, el tiempo que me han llevado, as´ı como algunas tareas que eran suficientemente grandes como para dividirse en dos, incidencias que surg´ıan, impedimentos, etc. En definitiva, como ´unico integrante del Development Team, he utilizado Git como herramienta de desarrollo para llevar un seguimiento y un control de versiones, y Jira para controlar el progreso de cada tarea o historia de usuario. Para ver estas tecnolog´ıas con m´as detalle adem´as de otras utilizadas durante el proyecto, consultar el Cap´ıtulo 4. 2.2.2. Planificaci´on inicial de los Sprints La realizaci´on de la asignatura Trabajo de Fin de Grado tiene asignados 12 cr´editos ECTS, los cuales suponen aproximadamente 300 horas lectivas [60], las cuales he decidido junto a mi tutora dividirlas en 10 sprints de 30 horas cada uno. El sprint est´a configurado para durar una semana, de lunes a domingo, por lo que la carga de trabajo ser´a tambi´en 30 horas semanales. Adem´as, dos de los sprints ser´an de refuerzo, siendo cercanos a la fecha de finalizaci´on del proyecto. Esto no quiere decir que este n´umero de sprints sea fijo. Quiz´a en algunas semanas se pueda meter m´as carga de trabajo o, por el contrario, se puedan a˜nadir m´as sprints si el tiempo no es suficiente o si se a˜nade m´as funcionalidad, hay alg´un problema con las historias de usuario, etc. La distribuci´on inicial de los sprints queda reflejada en la Tabla 2.2. Como vemos en ella, la distribuci´on de tiempo se divide en 10 sprints como hemos comentado antes. A su vez, se dividen en 8 sprints normales y se dejar´an 2 sprint de refuerzo, que suelen utilizarse para tareas de refactoring, correcci´on de bugs, o prevenci´on de la posible repercusi´on en el desarrollo de cualquier aparici´on de problemas a lo largo del proceso. 13 2.2. PLANIFICACI ´ ON Sprint Comienzo Finalizaci´on Detalles Sprint 1 08/02/2021 14/02/2021 Sprint 2 15/02/2021 21/02/2021 Sprint 3 22/02/2021 28/02/2021 Sprint 4 01/03/2021 07/03/2021 Sprint 5 08/03/2021 14/03/2021 Sprint 6 15/03/2021 21/03/2021 Sprint 7 22/03/2021 28/03/2021 Sprint 8 29/03/2021 04/04/2021 Sprint 9 05/04/2021 11/04/2021 Posible sprint de refuerzo Sprint 10 12/04/2021 18/04/2021 Posible sprint de refuerzo Tabla 2.2: Distribuci´on inicial de sprints 2.2.3. Descripci´on de historias de usuario Las historias de usuario (H.U.) se abordar´an m´as detenidamente a lo largo del seguimiento de los sprints, en el Cap´ıtulo 7. No obstante, podemos ver en la Tabla 2.3 todas las H.U. que componen el Product Backlog. Tambi´en se dan detalles a modo de resumen que muestran en qu´e consiste cada H.U. 2.2.4. Plan de riesgos y estimaci´on de coste Para hablar de riesgos, primero necesitamos definir qu´e es un riesgo. El riesgo se puede definir como un evento o condici´on incierta que, en caso de ocurrir, puede afectar (positiva o negativamente) al proyecto [19]. Los riesgos se pueden dividir en: Riesgos de proyecto: relacionados con aspectos inherentes al proyecto, como no conseguir los objetivos propuestos o no alcanzar una cota adecuada de satisfacci´on de requisitos. Riesgos de negocio: relacionados con temas econ´omicos y de mercado. Aqu´ı se incluyen riesgos de ventas, popularidad del producto, recepci´on de ´este, etc. Para poder controlar en medida de lo posible estos riesgos, existen una serie de pautas y acciones a realizar para medir, estimar y reducir el impacto de los riesgos. En primer lugar habr´ıa que identificar los riesgos y, una vez identificados, analizar qu´e aspectos son prioritarios frente a otros. Una vez hecho esto, se deben medir los riesgos mediante una escala predefinida para, posteriormente, monitorizar y controlar los riesgos. 14 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON H.U. Nombre Detalles 01 Ver dispositivos Juniper disponibles. Como usuario quiero ver los dispositivos Juniper disponibles en Junos Space para ver a cu´ales puedo aplicar configlets. 02 Ver configlets disponibles. Como usuario quiero consultar qu´e Configlets hay disponibles para poder aplicarlos a dispositivos Juniper. 03 Ver datos de un configlet. Como usuario quiero ver contenido del configlet para ver qu´e se va a aplicar en un dispositivo. 04 Login. Como usuario quiero hacer login en la aplicaci´on para poder utilizar sus funciones. 05 Tablas ARP. Como usuario quiero consultar la ubicaci´on de una direcci´on IP o MAC para ver en qu´e lugar f´ısico se encuentra. 06 Aplicar configlets. Como usuario quiero aplicar uno o m´as configlets a un dispositivo Juniper para modificar su configuraci´on. 07 A˜nadir dispositivo. Como usuario quiero a˜nadir un dispositivo de cualquier fabricante para que est´e disponible en la base de datos. 08 Eliminar dispositivo. Como usuario quiero eliminar uno o varios dispositivos de la lista para que no aparezcan dispositivos obsoletos. 09 Selecci´on de idioma. Como usuario quiero elegir un idioma entre los dos disponibles (Espa˜nol e Ingl´es) para comprender mejor el texto de la aplicaci´on. 10 Ver config. dispositivo Juniper. Como usuario quiero ver la configuraci´on de un dispositivo Juniper de Junos Space para ver qu´e configuraci´on refleja la API. 11 Seleccionar configlet. Como usuario quiero ver la lista de configlets disponibles para aplic´arsela a uno o varios dispositivos Juniper disponibles. 12 Eliminar configlet. Como usuario quiero seleccionar un configlet disponible y eliminarlo para que no se pueda aplicar a ning´un dispositivo. 13 Logout. Cpmo usuario, una vez logueado, quiero finalizar sesi´on para que sus datos sean borrados del LocalStorage. 14 Editar dispositivo. Como usuario quiero editar la informaci´on de uno de los dispositivos mostrados para actualizarla. 15 Mostrar todos los dispositivos. Como usuario quiero ver todos los dispositivos de todos los fabricantes para comprobar sus datos. 16 Mostrar la configuraci´on de un dispositivo. Como usuario quiero ver la configuraci´on de un dispositivo de cualquier fabricante para saber algunos par´ametros determinados. 17 Validar configlet. Como usuario quiero ver si la configuraci´on de un configlet es v´alida para poder aplicarla. Tabla 2.3: Descripci´on de historias de usuario H.U.: Historia de Usuario 15 2.2. PLANIFICACI ´ ON Riesgos encontrados En nuestro caso, todos los riesgos encontrados han sido riesgos de proyecto, pues el producto desarrollado no se ha concebido como un producto comercial del que se vayan a esperar beneficios con su salida o venta en el mercado. Como se mencion´o anteriomente, es necesario asignar a cada riesgo una probabilidad de ocurrencia y un impacto en una escala num´erica. De esta manera, la escala ser´a una escala num´erica, y cada valor equivalen a una valoraci´on cuantitativa como podemos ver en la Tabla 2.4: Valor Probabilidad de ocurrencia Impacto 1 Muy poco probable Muy leve 2 Poco probable Leve 3 Probabilidad media Medio 4 Probable Importante 5 Muy probable Cr´ıtico Tabla 2.4: Tabla de puntuaci´on de riesgos A continuaci´on vamos a ver qu´e riesgos hemos encontrado a la hora de planificar el proyecto. De la Tabla 2.5 a 2.13, podemos ver su descripci´on, probabilidad de ocurrencia, impacto, plan de mitigaci´on y, por ´ultimo, plan de contingencia. Riesgo Falta de conocimiento de tecnolog´ıas de red Probabilidad 5 Impacto 2 Plan de mitigaci´on Formaci´on y aprendizaje gradual Plan de contingencia Preguntar dudas a mi equipo de trabajo Tabla 2.5: Riesgo 1 Riesgo Falta de conocimiento de tecnolog´ıas de desarrollo Probabilidad 3 Impacto 3 Plan de mitigaci´on Seleccionar tecnolog´ıas sobre las que tenga m´as conocimiento a la hora de desarrollar Plan de contingencia Preguntar a un experto o consultar en manuales y foros Tabla 2.6: Riesgo 2 16 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON Riesgo El proyecto se alarga m´as de lo debido Probabilidad 3 Impacto 4 Plan de mitigaci´on Reevaluar en cada sprint planning los puntos de historia y ver la situaci´on en la que se encuentra el desarrollo del proyecto Plan de contingencia Redefinir las Historias de Usuario y realizar una nueva estimaci´on de Puntos de Historia Tabla 2.7: Riesgo 3 Riesgo No me puedo comunicar con los equipos Probabilidad 2 Impacto 4 Plan de mitigaci´on Revisar los logs en las configuraciones para ver si se ha aplicado una nueva configuraci´on recientemente Plan de contingencia Hablar con el responsable que ha aplicado esa nueva configuraci´on recientemente Tabla 2.8: Riesgo 4 Riesgo Apag´on en la sede donde se aloje la m´aquina virtual Probabilidad 1 Impacto 5 Plan de mitigaci´on S´olo se puede intentar evitar dejar mucho trabajo para d´ıas donde no haya personal de emergencia en estos casos Plan de contingencia Esperar a que el personal de emergencia solucione la incidencia Tabla 2.9: Riesgo 5 Riesgo Imposibilidad de conectarme a la m´aquina virtual Probabilidad 2 Impacto 4 Plan de mitigaci´on Intentar trabajar con la m´aquina virtual siempre que haya un administrador de redes disponible Plan de contingencia Contactar con el administrador de las m´aquinas virtuales que est´e disponible en ese momento Tabla 2.10: Riesgo 6 17 2.3. ESTIMACI ´ ON DE COSTES DEL PROYECTO Riesgo Retraso en el desarrollo de tareas Probabilidad 3 Impacto 2 Plan de mitigaci´on Planificar mejor el sprint a medida que se va adquiriendo conocimiento y fijar sprints de refuerzo Plan de contingencia Realizar las tareas en el siguiente sprint Tabla 2.11: Riesgo 7 Riesgo Mi estancia en la empresa finaliza antes de poder desarrollar el proyecto Probabilidad 3 Impacto 4 Plan de mitigaci´on Consultar mi posibilidad de continuaci´on y mi situaci´on actual Plan de contingencia Preparar la informaci´on para poder realizar mocks en los dispositivos que simulen una comunicaci´on real Tabla 2.12: Riesgo 8 Riesgo Cambio en la pol´ıtica de Login Probabilidad 1 Impacto 4 Plan de mitigaci´on Eliminar en medida de lo posible la dependencia entre este componente y el resto Plan de contingencia Documentarme y adquirir la informaci´on sobre el nuevo protocolo para implementarlo en mi proyecto Tabla 2.13: Riesgo 9 Riesgo Cambio de fabricante de dispositivos Probabilidad 1 Impacto 3 Plan de mitigaci´on Realizar la arquitectura del proyecto lo m´as modular posible para generar menos dependencias Plan de contingencia Adaptar el c´odigo para obtener la misma informaci´on pero de otro tipo de fabricante Tabla 2.14: Riesgo 10 2.3. Estimaci´on de costes del proyecto Para estimar el coste que puede tener este proyecto, lo primero que se ha realizado es consultar el sueldo de un programador analista. Seg´un el Bolet´ın Oficial del Estado (BOE), 18 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON un ingeniero de software corresponde a la categor´ıa Analista programador; Dise˜nador pagina web (Grupo III) [43]. Seg´un el BOE, a un trabajador perteneciente a esta categor´ıa, le corresponder´ıa una cuant´ıa de 22.993,74 euros anuales, lo que supone un total de 1.438,08 euros mensuales. Suponiendo que la empresa contribuye a la Seguridad Social con un importe que constituye un 30 % del sueldo del trabajador [12], el coste total para la empresa por la contrataci´on de un trabajador de esta categor´ıa supone 29.891.862 euros anuales. Suponiendo que las horas anuales de un trabajador de esta categor´ıa se ajustan a un m´aximo de 1.800 horas anuales [43] por lo que, dividiendo el sueldo anual total entre las horas totales anuales, nos da un resultado de 16.60 euros/h que deber´ıa cobrar un trabajador de este tipo. Si suponemos las 300 horas que se estiman en la gu´ıa docente del TFG [60] como tiempo previsto en el que se realizar´a el presente proyecto, el coste de contrataci´on de un trabajador de esta categor´ıa asciende a 4.980 euros durante la duraci´on de este proyecto. Como la situaci´on actual de pandemia ha resultado en un teletrabajo como forma diaria de operar en esta empresa, no se computan gastos fijos ni variables a la empresa. Adem´as, todas las licencias para el desarrollo de este proyecto son o bien gratuitas o bien libres. El GitLab donde se alojar´a la versi´on final del c´odigo del proyecto es una versi´on para la Escuela de Ingenier´ıa Inform´atica asociada a la Universidad de Valladolid, por lo que la empresa tampoco paga ninguna licencia de este tipo. De esta manera, el coste por este proyecto, si se realizara en las 300h estimadas en un principio, ser´ıa de 4.980,00 euros. No obstante, he preferido estimar las horas en 450 frente a las 300 horas iniciales y, para evitar problemas derivados de sobrecostes, la nueva cuant´ıa asciende a 7.470 euros. 2.4. Modificaciones finales respecto a la planificaci´on inicial Por ´ultimo, antes de dar por finalizado este cap´ıtulo, vamos a comentar qu´e aspectos respecto a la planificaci´on se han cambiado que hayan tenido el suficiente impacto en el desarrollo de este proyecto. El primero de ellos es el n´umero de sprints. Ya sea por algunos problemas a la hora de conectarme a algunos dispositivos, como por estimaci´on insuficiente del n´umero de horas para realizar algunos aspectos de las historias de usuario, como la ampliaci´on de la funcionalidad de la aplicaci´on, el n´umero inicial de 10 sprints ha sido insuficiente, llegando a alcanzar 17 sprints para finalizar el proyecto. Otro de ellos ha sido las historias de usuario. Inicialmente se pens´o las historias de usuario para trabajar con dispositivos Juniper, los cuales tienen su propia plataforma que nos permite automatizar tareas. Sin embargo, al ir trabajando d´ıa a d´ıa con estos equipos, me hizo coger soltura y pude a˜nadir otras tareas ´utiles sugeridas por el Product Owner, tales como mostrar la configuraci´on de cualquier tipo de dispositivo, o llevar un inventario de todos los dispositivos que se vayan anotando en un fichero com´un, con las acciones correspondientes (a˜nadir, editar o eliminar un dispositivo). Este c´umulo de eventos ha hecho que 19 3.1. AN ´ ALISIS GENERAL DE LA FUNCIONALIDAD Cisco tiene distintos formatos entre versiones, formatea sus tablas de distinta manera y permite una serie de formatos que Juniper no permite. La ´unica soluci´on ha sido extraer la informaci´on mostrada como texto y darle el formato deseado, por lo que a veces puede ser insuficiente con las reglas que he creado. Contar con una bater´ıa de pruebas proporcionada por el Product Owner en estos casos ha sido de gran utilidad, pues ha permitido detectar algunos dispositivos que ten´ıan versiones distintas de sistema operativo y, por tanto, mostraban las tablas de manera distinta. La tabla Neighbors muestra informaciones diferentes al ejecutar el comando para obtenerla entre los distintos fabricantes. Esto ha supuesto que se haya tenido que crear una tabla en la base de datos adaptada a los campos que se necesitan. 26 CAP´ ITULO 3. AN ´ ALISIS Figura 3.1: Workflow del algoritmo de b´usqueda ARP (1/2) 27 3.1. AN ´ ALISIS GENERAL DE LA FUNCIONALIDAD Figura 3.2: Workflow del algoritmo de b´usqueda ARP (2/2) 28 CAP´ ITULO 3. AN ´ ALISIS Figura 3.3: Workflow completo del algoritmo de b´usqueda ARP (detalle por partes en las Figuras 3.1 y 3.2) 29 3.2. MODELO CONCEPTUAL DEL DOMINIO 3.2. Modelo conceptual del dominio En la Figura 3.4 podemos ver el modelo conceptual del dominio. Ha sido realizado tras analizar bien las Historias de Usuario del Backlog, recoger suficiente informaci´on sobre c´omo funciona la b´usqueda a trav´es de entradas ARP y tener la experiencia necesaria para realizar estas consultas con una conexi´on a la terminal de los dispositivos. En la imagen se muestran las entidades necesarias para cumplir todas las necesidades anotadas en el backlog. Podemos ver una clase principal, llamada Devices, sobre la cual giran el resto de clases. He representado tambi´en las tablas mencionadas anteriormente en la b´usqueda ARP a la hora de explicar el algoritmo de b´usqueda, que est´an conectadas a estos dispositivos. A su vez, tambi´en he incluido enums para saber el fabricante y el tipo de conexi´on del propio dispositivo. Por ´ultimo, destacar que el tipo de dispositivos es una generalizaci´on de la clase Device del tipo disjoint, lo que significa que un dispositivo s´olo puede ser de la clase de una de las instancias a la vez. Esto tiene sentido, pues un dispositivo es un router, un switch o un firewall y, aunque algunos dispositivos puedan hacer parte de las funciones de otros, no son el mismo tipo de dispositivo. 30 CAP´ ITULO 3. AN ´ ALISIS Figura 3.4: Modelo de dominio final 31 3.2. MODELO CONCEPTUAL DEL DOMINIO 32 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Cap´ıtulo 4 Tecnolog´ıas utilizadas En este cap´ıtulo se presenta un resumen de las tecnolog´ıas utilizadas tanto para la gesti´on del proyecto, como para el desarrollo. Comenzaremos viendo las tecnolog´ıas utilizadas principalmente para gestionar y documentar el proyecto, adem´as de las necesarias para llevar d´ıa a d´ıa un seguimiento de ´este. Continuaremos hablando de los lenguajes de programaci´on utilizados y, por ´ultimo, comentar´e algunas de las librer´ıas importantes que han sido necesarias para llevar a cabo las tareas m´as cr´ıticas del proyecto. 4.1. Herramientas y programas utilizados 4.1.1. Jira Comencemos hablando de Jira. Jira es una herramienta creada por Altassian orientada a la planificaci´on de proyectos ´agiles. Permite planificar, supervisar, crear flujos de trabajo y categorizar tareas, adem´as de a˜nadir issues en ´estas. En cada tarea, se puede llevar a cabo un seguimiento por parte del usuario que tiene el rol de encargarse de ´esta, ofreciendo la opci´on de poner un informador y un supervisor cada tarea, adem´as de a˜nadir comentarios e ir cambiando el porcentaje completado a medida que se avance en dicha tarea [35]. Tambi´en permite permite integraci´on y entrega continuas pero, en este caso, no se ha hecho uso de estas capacidades de Jira. En mi caso personal, he utilizado Jira para crear una tarea por cada H.U. aunque, tambi´en, he utilizado esta plataforma para otras tareas utilizadas en mi grupo de trabajo no relacionadas con este proyecto, lo cual me ha permitido comprender mejor esta herramienta. Una vez que la historia de usuario se completa, se cambiaba el porcentaje de completitud de la tarea a 100 % para, despu´es, mover la tarea a la columna de completados. Esta acci´on notifica al supervisor, cuya tarea es comprobar que la documentaci´on es correcta y ver que esa tarea, efectivamente, ha sido realizada y funciona correctamente. 33 4.1. HERRAMIENTAS Y PROGRAMAS UTILIZADOS 4.1.2. Git Para hablar de Git, comencemos hablando de los Sistemas de Control de Versiones (com´unmente conocidos como Version Control System VCS). Un VCS es un sistema que permite realizar un seguimiento de los cambios realizados en el c´odigo de un conjunto de archivos seleccionados por un usuario de tal manera que se cree un repositorio para que el usuario pueda volver atr´as y recuperar versiones anteriores de ese mismo c´odigo [6]. Aunque suene simple, se ha desarrollado tanto y de tal manera que permite una lista inmensa de posibilidades, adem´as de integraci´on con otras plataformas y herramientas que ampl´ıan todav´ıa m´as las capacidades de esta tecnolog´ıa. Hay m´ultiples sistemas de control de versiones. De todos ellos, el m´as popular a nivel mundial es Git. Desarrollado por Linus Torvald en 2005 [2], el creador de Linux, este VCS gratuito de c´odigo abierto se ha convertido en el m´as popular [18] y el que m´as crecimiento ha tenido en el mundo de la inform´atica, como podemos ver en las Figuras 4.1 y 4.2. Figura 4.1: VCS m´as usados [63] Figura 4.2: Evoluci´on de las preguntas en Stack Overflow [63] 34 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Git opera bajo los siguientes principios [55]: Copias instant´aneas, no diferencias: en vez de manejar los cambios que se han hecho en cada archivo, Git maneja sus datos como un conjunto de im´agenes hechas en un instante. Cada vez que se confirma un cambio y se guarda, se genera una imagen de ese archivo y guarda la referencia a esa imagen generada, de tal manera que si el archivo no se ha modificado, Git no almacena el archivo de nuevo, sino que mantiene el enlace anterior que apunta a la imagen generada. Casi todas las operaciones son locales: Git no necesita una plataforma remota para operar, puesto que se puede utilizar de manera local. No obstante, cuenta con plataformas donde puedes almacenar repositorios de manera remota, como GitHub o Gitlab. Integridad: antes de almacenar cada archivo, Git verifica ´este previamente mediante una suma de comprobaci´on. De esta manera, no se puede perder informaci´on durante la transmisi´on o sufrir corrupci´on de datos sin que Git pueda detectarlo. Git generalmente solo a˜nade informaci´on: al a˜nadir informaci´on, es muy dif´ıcil que una acci´on no se pueda deshacer o volver a un estado anterior. Esto permite trabajar de una manera segura, pudiendo siempre revertir estados no deseados en los proyectos. Los tres estados: aqu´ı reside el n´ucleo de la filosof´ıa de Git. Este VCS funciona a trav´es de tres estados principales en los que se puede encontrar uno o varios archivos. Los estados son Commited,Modified yStaged, haciendo referencia, en castellano, a confirmado, modificado y preparado, respectivamente. Cuando un archivo dentro del directorio de trabajo (Working Directory) se modifica, su estado cambia. Aqu´ı podemos a˜nadir el archivo para la siguiente confirmaci´on, lo cual cambia su estado a Staged y, por ´ultimo, cuando est´e todo ya hecho, si confirmamos los cambios, todos los archivos modificados que se hayan marcado para incluirlos en la pr´oxima confirmaci´on, pasan al estado confirmado. En la Figura 4.3 podemos ver este proceso de una manera m´as gr´afica. Figura 4.3: Los tres estados de Git [55] 35 4.2. LENGUAJES DE PROGRAMACI ´ ON Y FRAMEWORKS UTILIZADOS Antes de terminar de hablar de Vue.js y, en especial, de su filosof´ıa Single File Components, debemos mencionar que cada secci´on de ´estos (HTML, CSS o l´ogica) pueden mantenerse en ficheros externos y, desde el componente, hacer referencia a este fichero. No obstante, no es del todo recomendable para no romper en la medida de lo posible esta filosof´ıa. 4.2.6. NPM Node Package Manager, m´as conocido por sus siglas NPM, es un gestor de paquetes desarrollado en el lenguaje Javascript, del que hemos hablado antes. NPM nos permite agregar dependencias de forma simple, gestionar y distribuir paquetes en un entorno de directorios y controlar y administrar los m´odulos de un proyecto. En nuestro caso, NPM ha permitido instalar algunas dependencias necesarias para, entre otras cosas, desarrollar test unitarios, test end-to-end, paquetes de lenguaje, o instalar librer´ıas de componentes [45]. Para hablar de los paquetes de NPM utilizados, podemos consultar el apartado siguiente. All´ı hablaremos de paquetes, APIs, librer´ıas, etc., que hemos utilizado en nuestro proyecto. 42 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Figura 4.6: Ciclo de vida de una instancia en Vue [39] 43 4.3. PAQUETES, APIS, LIBRER´ IAS, ETC. 4.2.7. Flask Flask es un framework escrito en Python que permite crear aplicaciones web conectadas a un back-end con una cantidad de l´ıneas de c´odigo muy baja respecto a otros frameworks [21]. Como nuestro proyecto necesitaba algunas librer´ıas en Python, la elecci´on del lenguaje para el back-end estaba condicionada por esto y, como Flask permite realizar las vistas en Vue y conectarse con la API del back-end mediante llamadas Axios, escog´ı este framework para el desarrollo del back-end. 4.2.8. SQLAlchemy Para hablar de SQLAlchemy, primero habr´ıa que definir qu´e es un ORM. Un ORM, de las siglas Object Relacional Mapping, es una utilidad que permite interactuar con una base de datos como si fuera un objeto [56]. De esta manera, se pueden ejecutar queries y otras acciones sobre la tabla de datos sin utilizar el lenguaje habitual SQL (aunque podemos hacer llamadas con ese lenguaje si lo necesitamos). La ventaja de un ORM es que es independiente del motor de base de datos a utilizar. SQLAlchemy es un ORM que se puede implementar en Python y permite gestionar todos los aspectos de la base de datos, desde la declaraci´on de las tablas de dominio, querys, la conexi´on con ´esta, etc. Entre las ventajas que ya hemos comentado, podemos a˜nadir que proporciona un nivel de abstracci´on adicional al usuario, sobre todo en cuanto a la gesti´on del pool de conexiones, adem´as de aportar mucha flexibilidad al trabajar con la base de datos. Tambi´en permite utilizar un propio lenguaje para las consultas a la base de datos en vez de utilizar SQL nativo, gestionando de una manera m´as “natural” para el programador a la hora de utilizar filtros en las consultas. Otra de las grandes ventajas que tiene es que devuelve los resultados en modo de objeto, pudiendo manipularlo de una manera m´as sencilla y ampliando las posibilidades que trae por defecto cualquier motor SQL. As´ı pues, gracias a SQLAlchemy, podemos disponer de una mayor flexibilidad y comodidad al tratar las tablas de la base de datos como objetos, lo que facilita el tratamiento y uso de estos datos, ya sea para obtenerlos o para inyectarlos en la propia base de datos. 4.3. Paquetes, APIs, librer´ıas, etc. En este cap´ıtulo, una vez hemos hablado de los lenguajes, frameworks y tecnolog´ıas utilizadas, vamos a hablar de otros elementos tambi´en importantes a lo largo del desarrollo de nuestro proyecto. 4.3.1. APIs En primer lugar, debo mencionar la API de la plataforma Junos Space [38]. Esta API nos permite extraer datos de los dispositivos, configlets y, adem´as, realizar llamadas con los 44 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS m´etodos HTTP (Post, Get, Put, Delete...). De esta manera, facilitamos al usuario realizar acciones remotas desde nuestra web, implementando una interfaz m´as amigable. Aunque esta API permite multitud de operaciones, tiene algunas limitaciones. Por ejemplo, no se permite crear configlets con peticiones a la API al ser una tarea demasiado compleja y requerir m´ultiples comprobaciones. Aun as´ı, si un usuario creara un configlet dentro de la plataforma Junos Space, este configlet se podr´ıa borrar o aplicar en uno o varios dispositivos desde la aplicaci´on gracias a las opciones que permite esta API. 4.3.2. Paquetes, librer´ıas y protocolos Tacacs plus Tacacs plus (o Tacacs+) es un protocolo derivado de TACACS (Terminal Access Controller Access-Control System) que permite controlar servicios relacionados con la seguridad, tales como la autorizaci´on y la seguridad[8]. Es un protocolo AAA, cuyas siglas significan Authentication, Authorization and Accounting [3]. Tacacs se implementa en los dispositivos de red para realizar una comprobaci´on de la autenticaci´on de un usuario contra unos servidores Active Directory (AD), quienes se encargan de comprobar qui´en es el usuario que se est´a autenticando, si tiene los permisos necesarios y si est´a introduciendo bien la contrase˜na. De esta manera, he creado un servicio mediante el m´odulo disponible en PyPi [58] que implementa una llamada con este protocolo a la IP del servidor AD que devuelve un mensaje HTTP 200 en caso de una autenticaci´on v´alida, mientras que devuelve un HTTP 400 en caso de que el nombre del usuario o la contrase˜na sean incorrectos o, por otro lado, si son correctos pero el usuario no tiene permiso para acceder a estos servicios. Paquetes de NPM i18n: este plugin de Node nos permite internacionalizar los textos en los idiomas que deseemos. Para ello debemos crear un fichero de Javascript por idioma y, en ´el, debemos definir las variables que incluir´an la cadena de texto que deseemos mostrar. De esta manera, convenientemente en cada fichero tendremos el mismo n´umero de variables pero el contenido de dichas cadenas estar´a en el idioma que deseemos representar [29]. mdi: el paquete de Node MDI hace referencia a Material Design Icons, iconos utilizados en la aplicaci´on, tanto en botones como en otras funcionalidades [41]. Vuetify: tambi´en de la mano de Material Design, es un framework de componentes que simplifica la implementaci´on de ´estos en un entorno web. Evita que el desarrollador tenga que crear, por ejemplo, botones, sliders o selects, permitiendo importarlos con una funcionalidad y una estructura que podemos cambiar, pero facilitando enormemente la gesti´on de ´estos [32]. En estos componentes se incluyen los MDI vistos anteriormente. Aunque Vuetify nos brinde la facilidad a la hora de implementar componentes, es el usuario quien decide en ´ultima instancia qu´e l´ogica deber´ıa tener el componente y, consecuentemente, implementar el c´odigo correspondiente. 45 4.3. PAQUETES, APIS, LIBRER´ IAS, ETC. Router: uno de los plugins m´as importantes de Vue, pues facilita la creaci´on y gesti´on de las rutas Vue [64]. Declarando las rutas en un archivo router.js, facilita la l´ogica de la aplicaci´on al cambiar de rutas en la URL. Este plugin, a diferencia de otros, puedes decidir a˜nadirlo al crear el proyecto. Cypress: este plugin es el que se ha usado para test end-to-end en la aplicaci´on. Es el plugin que incluye Vue por defecto [17]. Pandas Pandas es una librer´ıa de Python que nos permite utilizar estructuras de datos similares a los dataframes del lenguaje R. Se utiliza para tratamiento de datos, pues pueden representarse de manera tabular (con columnas, tipos, etc) o con series temporales [48]. Pandas es ´util, pues permite leer y escribir datos en distintos formatos (por ejemplo, SQL, CSV, o Microsoft Excel), tratar estos datos y seleccionarlos en funci´on de un valor o de la posici´on que ocupen, unir y separar datos, etc. En mi caso, he utilizado Pandas debido a la facilidad de manejar tablas y manipularlas. Al leer tablas y datos de los dispositivos, Pandas tiene utilidades que permiten ir poblando tablas y, posteriormente, manipular estos datos para guardarlos en una base de datos. 4.3.3. Junos PyEz Librer´ıa para Python del fabricante Juniper para conectar de manera remota con dispositivos Juniper [36]. Con ella podemos abrir conexiones y ejecutar comandos, ya sea para aplicar configuraciones o extraer tablas de datos. La ventaja frente a otras librer´ıas es que permite extraer los datos encapsulados en un objeto, lo que facilita acceder a ciertos datos (por ejemplo, si queremos acceder a los datos de una de las columnas). As´ı pues, PyEz nos brinda bastantes facilidades a la hora de conectarse y poblar las tablas de la base de datos gracias a algunos m´etodos presentes en esta librer´ıa. 4.3.4. Netmiko Al igual que hemos visto con Junos PyEz, necesitamos una manera de conectarse de manera simple a los dispositivos de Cisco y otros vendedores [47]. Pues bien, esta librer´ıa nos permite establecer conexiones con dispositivos de redes del fabricante Cisco. Pese a que es muy ´util a la hora de permitirnos conectar con estos dispositivos, ya sea por el protocolo SSH o Telnet, no incluye funciones como el encapsulamiento de datos a la hora de hacer un get de una tabla del dispositivo, por lo que tenemos que inyectar nosotros a mano los datos de esa cadena de texto en una tabla que posteriormente ser´a guardada en la base de datos. 46 CAP´ ITULO 5. DISE ˜ NO Cap´ıtulo 5 Dise˜no En el dise˜no arquitect´onico de este proyecto se utiliza, principalmente, el patr´on MVVM, desarrollando un dise˜no basado en componentes. A lo largo de este cap´ıtulo, vamos a presentar este modelo, adem´as de otros elementos importantes como los bocetos de las vistas, las vistas finales de la aplicaci´on o el modelo de despliegue, entre otros. 5.1. Model-View-ViewModel (MVVM) MVVM, en espa˜nol Modelo-Vista-Modelo de vista, es un patr´on de arquitectura de software que consiste en la separaci´on interfaz de usuario - l´ogica de la aplicaci´on [54]. Este patr´on fue descrito al p´ublico en 2005 por John Gossman [31] como variaci´on del patr´on MVC (Modelo-Vista-Controlador) ajustando a WPF (Windows Presentation Foundation). MVVM consta de tres elementos que describiremos a continuaci´on: 1. Modelo (Model): se define como Modelo al conjunto de estructuras de datos que se utilizan para representar, entre otras cosas, el estado, el funcionamiento y la l´ogica de negocio de la aplicaci´on. 2. Vista (View): elemento que se asocia con la interfaz de usuario. Esta capa se encarga de mostrar los elementos contenidos en la l´ogica al usuario y capturar los eventos que ocurran por parte del usuario con estos elementos. 3. Modelo de vista (ViewModel): ya hemos visto qu´e es el Modelo y qu´e es la Vista; pues bien, el modelo de vista se encarga de enlazar la interfaz de usuario con el modelo. Para ello, utiliza todos los m´etodos necesarios para comunicar al modelo la ocurrencia de una interacci´on o un evento capturado en la interfaz de usuario. En la Figura 5.1 podemos comprobar c´omo interact´uan estos 3 elementos explicados anteriormente. 47 5.1. MODEL-VIEW-VIEWMODEL (MVVM) Figura 5.1: Elementos del patr´on MVVM, obtenida en [10] Como hemos visto, el patr´on consiste en una separaci´on entre 3 componentes. Esta separaci´on tambi´en aporta algunas ventajas, entre ellas: Separar el desarrollo de la interfaz de usuario del resto de c´odigo. El desacoplamiento permite que la l´ogica pueda ser f´acilmente testeada con test unitarios. Estas ventajas hacen que el patr´on MVVM sea ´util cuando se est´en desarrollando aplicaciones multiplataforma, pues nos aportar´a gran desacoplamiento para poder desarrollar con m´as facilidad. Una vez visto esto, podemos centrarnos en la pregunta ¿c´omo se enlaza la vista con el Modelo?. Aqu´ı entra el elemento estrella del patr´on MVVM, el binding. El binding consiste en el enlace entre la Vista y el ViewModel. Gracias a este elemento, los datos del modelo se actualizan autom´aticamente cada vez que el usuario realice alguna acci´on que modifique dichos datos en la vista. Esto supone una mayor flexibilidad al tratar los cambios de estos datos. 5.1.1. Aplicaci´on del patr´on MVVM en este proyecto. Como vimos en el Cap´ıtulo 4, el framework utilizado para desarrollar la interfaz de usuario ha sido Vue.js. Este framework facilita enormemente la aplicaci´on del patr´on MVVM ya que cada instancia de Vue est´a pensada para actuar como ViewModel. As´ı, se aprovecha el binding bidireccional que proporciona este patr´on. Para poder implementar este patr´on, Vue.js pone a su disposici´on una serie de directivas que permiten relacionar los datos del modelo con elementos visuales de la interfaz de usuario, permitiendo (gracias al binding) manipular estos ´ultimos mostrando los cambios en el modelo. A continuaci´on, vamos a explicar algunas de las directivas m´as importantes que hemos utilizado en nuestro proyecto al aplicar este patr´on: v-if: esta directiva condicional act´ua como un controlador de flujo. Si el contenido que hay dentro de la directiva se cumple, los elementos visuales asociados a ella se 48 CAP´ ITULO 5. DISE ˜ NO mostrar´an en la interfaz de usuario; por el contrario, si no se cumple, todo lo que haya a continuaci´on no se mostrar´a al usuario por pantalla, no incluy´endose en el DOM virtual de Vue. Esta directiva puede ir, opcionalmente, acompa˜nada de las directivas v-else-if yv-else. v-for: equivale a un bucle for. Nos permite, en nuestro caso, rellenar algunas tablas de manera autom´atica seg´un los datos de un array existente en el data del modelo, estableciendo una relaci´on de ´unica direcci´on hacia esos datos. v-bind: esta directiva es la encargada de establecer una relaci´on entre una variable l´ogica y un elemento de la interfaz de usuario unidireccional (es decir, la relaci´on va desde el modelo a la vista). En nuestro caso lo hemos utilizado para realizar una asociaci´on en elementos muy concretos y poder observar los cambios que suceden en ese elemento. v-show: similar a v-if. La diferencia reside en que, en esta directiva, el elemento asociado s´ı se incluye en el DOM, pero s´olo se mostrar´a en la interfaz del usuario si se cumple la condici´on contenida en esta directiva. v-model: permite relacionar un elemento visual con una variable pero, a diferencia de v-bind, se har´a de manera bidireccional. double moustache binding: esta directiva se representa con dos llaves de apertura y dos llaves de cierre. Dentro de ellas, ir´a la variable que queramos mostrar en la interfaz de usuario. Gracias a esta directiva, podemos realizar un binding a variables y mostrarlas junto a elementos HTML est´aticos. De esta manera, aunque el HTML cambie, esta variable tendr´a un comportamiento distinto 5.2. Dise˜no basado en componentes Una arquitectura basada en componentes consiste en descomponer el dise˜no en elementos individuales llamados componentes. Estos componentes deben ser funcionales o l´ogicos, y deben exponer interfaces de comunicaci´on bien definidas para proporcionar un nivel de abstracci´on mayor [49]. Entre los principios que definen este tipo de dise˜no, se encuentran: Reusabilidad: los componentes deben ser conceptualizados para poder ser utilizados en distintos escenarios. No obstante, puede darse la creaci´on de componentes para un uso muy espec´ıfico. Sin contexto espec´ıfico: los componentes, como hemos visto antes, deben crearse para ser utilizados en distintos escenarios. Informaci´on determinante como puede ser el estado del componente, el nombre del componente o el comportamiento espec´ıfico, deben ser pasados al componente a trav´es de su interfaz en vez de permitir al componente acceder a ellos o modificarlos. Extensible: un componente puede ser extendido desde otro para definir un nuevo comportamiento. 49 5.2. DISE ˜ NO BASADO EN COMPONENTES Encapsulado: los componentes deben mostrar una interfaz para permitir al programa o a otros componentes utilizar su funcionalidad sin revelar detalles o implementaci´on interna. Independiente: se debe reducir al m´ınimo la interdependencia entre componente, para favorecer la reutilizaci´on. Una vez que hemos visto un poco de informaci´on sobre los principios de este tipo de dise˜no, podemos enumerar algunas de las ventajas de este tipo de dise˜no. La primera de ellas es que, al ser encapsulados, favorece mucho la independencia entre los propios componentes, lo que facilita a su vez la reutilizaci´on y reduce al m´ınimo la interdependencia entre ello. En segundo lugar, como consecuencia l´ogica de lo explicado, esta independencia hace que la fase de testing y de pruebas sea m´as sencilla, pues permite aislar a los componentes y, as´ı, aislar los errores que puedan existir. El conjunto de todo lo que hemos visto tambi´en se traduce en un mantenimiento del sistema m´as sencillo, pues si se necesita modificar una serie de componentes para que sean m´as escalables, modificar su comportamiento o, directamente, eliminarlos, estas caracter´ısticas har´an que el proceso sea mucho m´as sencillo. 5.2.1. Dise˜no basado en componentes en este proyecto En este proyecto, se ha empleado Atomic Web Design como dise˜no para el desarrollo de componentes. Atomic Web Design surge en 2013 para explicar el dise˜no de una interfaz web descomponiendo en entidades m´as peque˜nas (denominadas ´atomos) para reutilizarlos y combinarlos con el objetivo de generar entidades m´as grandes (composiciones) y potentes que den sentido a la funcionalidad del dise˜no [22]. Al utilizar el framework Vue.js en nuestro proyecto, lo que estamos haciendo es definir y dise˜nar componentes reutilizables con su propio estado y propiedades (denominadas props, como vimos en el Cap´ıtulo 4.2.5). Una vez dise˜nados estos componentes, se dise˜na la componetizaci´on para agregarlos y que generen una funcionalidad mostrada por la interfaz [62]. En Vue.js, como se explic´o en el Cap´ıtulo 4.2.5, se utiliza la filosof´ıa Single File Component (SFC), en la que un archivo de Vue est´a compuesto por el Template, el Style y, por ´ultimo, Script. De esta manera, un archivo SFC es una composici´on de estas tres entidades, manifest´andose as´ı en un componente. En el siguiente apartado vamos a ver el diagrama de componentes de nuestro proyecto y a comentar en qu´e consiste cada componente, adem´as de comentar aspectos relevantes del propio diagrama y decisiones que se han tomado para realizarlo. 5.2.2. Diagrama de componentes En la Figura 5.2 podemos ver el diagrama de componentes de este proyecto. 50 CAP´ ITULO 5. DISE ˜ NO Figura 5.2: Diagrama de componentes. 51 5.3. DISE ˜ NO DE LA INTERFAZ DE USUARIO (IU) Sprint 8 - Bocetos (ver tabla 7.8) En este sprint se comienza a desarrollar la implementaci´on de las acciones CRUD de dispositivos. De esta manera, en este sprint se crea un componente Dialog que, seg´un la opci´on seleccionada, muestre un formulario (vac´ıo en el caso de a˜nadir un dispositivo, con los par´ametros actuales si deseamos modificarlo) o una tabla con los datos que se van a eliminar en el caso de querer borrar un dispositivo de la base de datos. Las distintas vistas de este componente las podemos ver en las tablas 5.8 y 5.9. Figura 5.8: Boceto del componente Dialog en el caso de A˜nadir/Editar dispositivo En el caso de a˜nadir y editar un dispositivo 5.8, la vista es la misma, solo que los campos del formulario aparecer´an vac´ıos en el caso de a˜nadir, mientras que si editamos el dispositivo, los campos aparecer´an rellenos con los par´ametros actuales del dispositivo Por otro lado, aunque se utilice en numerosas vistas (pues es un componente de uso general), el Alert se genera tambi´en en este sprint. El Alert informa de un evento que sucede en la base de datos o al realizar una llamada a la API. De esta manera, cada vez que el usuario realiza una acci´on que implica una llamada, el commponente Alert informa al usuario de qu´e ha sucedido, ya sea para informar de que la acci´on se realiz´o con ´exito, que hubo un error o informar a modo de advertencia que los datos introducidos no son correctos. Podemos ver el boceto de este componente en la Figura 5.10. Aunque la vista de fondo se corresponde con la H.U. 05, este componente es el mismo para todas las vistas, por lo que el concepto puede entenderse de igual manera bajo esta vista. 58 CAP´ ITULO 5. DISE ˜ NO Figura 5.9: Boceto del componente Dialog en el caso de Eliminar dispositivo Figura 5.10: Boceto del componente Alert de prop´osito general 59 5.3. DISE ˜ NO DE LA INTERFAZ DE USUARIO (IU) Sprint 13 - Bocetos (ver tabla 7.13) Durante este sprint tienen lugar las H.U. 06: Aplicar configlets y H.U. 17: Validar configlet. En la H.U. 06 primero se selecciona un dispositivo y se muestran los configlets disponibles para aplicar y, en la segunda, se muestra la validaci´on de todos los configlets que se quieren validar. Esta validaci´on se muestra en un componente Dialog que mostrar´a un mensaje en verde por cada configlet v´alido y, en caso de una configuraci´on no v´alida, mostrar´a un mensaje en rojo en el mismo componente. En el caso de seleccionar varios confilets para validar, se podr´a pasar de uno a otro con flechas laterales. Podemos ver, en la Figura 5.11, c´omo se define esta vista. Lo primero que mostrar´a ser´a la IP y el nombre del dispositivo donde se van a aplicar los configlets seleccionados. Para cambiar entre configlets, se pueden ver unas pesta˜nas que tendr´an el ID del configlet y su correspondiente formulario, donde el usuario tendr´a que introducir los datos deseados. Una vez que el usuario haya introducido los datos necesarios, si hace click en el bot´on aplicar (Apply en la figura), podr´a validar todos estos configlets y, dependiendo de si el resultado ha sido correcto o no, aparecer´an las vistas que se pueden ver en las Figuras 5.12 y 5.13, respectivamente. Como se puede ver, ambas vistas son id´enticas solo que, en el caso del error, aparecer´a un c´odigo en rojo que indicar´a la causa del error. En ambas vistas, el bot´on de aceptar se habilitar´a s´ı y s´olo si todos y cada uno de los configlets han sido validados con ´exito. Como hemos mencionado, al pulsar sobre las flechas laterales se cambiar´a entre configlets y se podr´a ver el c´odigo que se va a inyectar en el dispositivo seleccionado. Figura 5.11: Aplicaci´on de configlets a un dispositivo 60 CAP´ ITULO 5. DISE ˜ NO Figura 5.12: Validaci´on de configlets correcta Figura 5.13: Validaci´on de configlets incorrecta 61 5.4. ARQUITECTURA L ´ OGICA DEL BACK-END Sprint 14 - Bocetos (ver tabla 7.14) En este sprint tiene lugar el bocetado de la ´ultima vista. En el sprint anterior vimos c´omo se generaba una vista (Figura 5.11 donde, seleccionado un dispositivo, se le pudieran aplicar los configlets necesarios. Pues bien, en la H.U. 11: Seleccionar configlets, se ha implementado la opci´on contraria: en la lista de configlets, al seleccionar uno para aplicar, podremos ver los dispositivos a los que lo podemos aplicar. De esta manera, si antes se aplicaba varios configlets en un dispositivo, ahora es el caso contrario: se aplica un solo configlet en uno o varios dispositivos. La vista para aplicar un configlet a varios dispositivos la podemos encontrar en la Figura 5.14. Figura 5.14: Aplicar un configlet a varios dispositivos Como se puede ver, ambas vistas son muy similares. Sin embargo, en estas pesta˜nas se cambia el dispositivo al que le aplicaremos los datos introducidos en el formulario correspondiente. El resto de la l´ogica se mantiene intacta: si hacemos click sobre el bot´on de aplicar, nos aparecer´a un dialog indicando si la validaci´on ha sido correcta o no, pues se utiliza el mismo componente para mostrar este paso (ya visto en las Figuras 5.12 y 5.13). 5.4. Arquitectura l´ogica del back-end El servidor back-end tambi´en necesita un dise˜no de clases agrupadas por paquetes. El diagrama mostrar´a en medida de lo posible la estructura de dicho servidor para poder ha62 CAP´ ITULO 5. DISE ˜ NO cernos una idea de la arquitectura dentro de este sistema. Se puede ver este diagrama en la Figura 5.15. Durante el dise˜no del back-end, adem´as se han tomado decisiones importantes a la hora de aplicar algunos patrones para mejorar el c´odigo y su reutilizaci´on. Entre ellos, el patr´on fachada ha resultado ´util en el m´odulo management del proyecto. Este patr´on fachada (facade) se suele utilizar para reducir acoplamiento entre clases en un proyecto [20]. En nuestro caso, como el paquete management se comunica con un gran n´umero de m´etodos y clases, se realiza una clase que act´ua como interfaz simple para reducir la dependencia entre las clases del proyecto. Figura 5.15: Diagrama de despliegue. 5.5. Dise˜no del despliegue El despliegue se realizar´a en una m´aquina virtual ofrecida por mi entorno de trabajo. Para conectarme a ella, es necesario tener credenciales de usuario, pues necesita estar en un entorno autorizado para realizar las peticiones tanto a los portales utilizados como a los propios dispositivos. Actualmente, el proyecto se encuentra desplegado en la misma m´aquina pero, posteriormente, su despliegue se realizar´a por contenedores, utilizando otra m´aquina para realizar las peticiones de Login. Una vez que la aplicaci´on entre en entorno de producci´on, posterior a la dockerizaci´on del Login, se podr´a acceder a ella desde cualquier ordenador dentro de la VPN de la empresa. As´ı, podremos comunicarnos con esta aplicaci´on, realizar las peticiones necesarias y aplicar los configlets deseados (ver Figura 5.16). 63 5.5. DISE ˜ NO DEL DESPLIEGUE Figura 5.16: Diagrama de despliegue. 64 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Cap´ıtulo 6 Implementaci´on y pruebas Tras haber visto el dise˜no de la aplicaci´on, el siguiente paso l´ogico es hablar de la implementaci´on. En este cap´ıtulo vamos a hablar de la estructura final del c´odigo en el servidor y en las vistas de la parte web. Adem´as, tambi´en vamos a comentar aspectos relevantes como cambios en el modelo del dominio o en el dise˜no de las vistas, aspectos a tener en cuenta a la hora de modificaciones en la funcionalidad. 6.1. Estructura del c´odigo de la web Aqu´ı se muestra la estructura y jerarqu´ıa final del c´odigo. Una vez listados estos archivos, se procede a hablar de los m´as importantes para la parte del front-end. Es importante comentar que no se van a listar todos los archivos o carpetas, pues algunos son implementaciones internas del editor de c´odigo, configuraciones internas, y otros componentes no relacionados con el c´odigo | .browserslistrc | .eslintrc.js | .gitignore | babel.config.js | cypress.json | jest.config.js | package.json | README.md | +---cypress (m´odulo para realizar test end-to-end) | +---node_modules (m´odulos de Node usados, comentados anteriormente) | +---public 65 6.1. ESTRUCTURA DEL C ´ ODIGO DE LA WEB | | index.html | | logo-junco.png | | logo-junco-dark.png | +---server (carpeta que contiene la parte del servidor back-end, se comentar´a en el siguiente apartado) | +---src | | App.vue | | main.js | | | +---api | | | arp.js | | | devices.js | | | junos.js | | | +---assets (se omite su contenido por brevedad) ||| | | +---configlets | | | | apply-cli-configlet.json | | | | validate-configlets.json | | | | +---images (im´agenes usadas en la app, se omite su contenido) | | | +---components ||| | | +---arptables | | | | ARPTablesComp.vue | | | | +---devices | | | | AllDeviceComp.vue | | | | DeviceComp.vue | | | | +---global | | | | HomeComp.vue | | | | MainHeader.vue | | | | MenuBar.vue | | | | +---utilityComponents | | | | alertComponent.vue | | | | DialogComp.vue | | | | PagesDialogComp.vue | | | | SelectTableComp.vue | | | | ShowConfigComponent.vue | | | +---lang ||| | | +---messages | | | | en.js | | | | es.js ||| 66 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS | | | i18n.js | | | +---plugins | | vuetify.js | | | +---router | | index.js | | | +---store | | | index.js ||| | | | +---utils | | | constants.js | | | functions.js | | | +---views | | | | +---arptables | | | | ARPTables.vue | | | | +---configlets | | | | ApplyConfiglet.vue | | | | +---devices | | | | AllDevices.vue | | | | JunosDevices.vue | | | | JunosDevicesConfiglets.vue | | | | +---global | | | | About.vue | | | | Home.vue | | | | Login.vue | | +---tests | | e2e | | unit Los primeros ficheros de la lista hacen referencia a ficheros de configuraci´on de Node, configuraci´on de test (tanto unitarios como end-to-end), el .gitignore (fichero en el cual podemos incluir qu´e archivos no queremos trackear, es decir, ficheros que si cambian, Git no tiene ning´un tipo de seguimiento sobre ellos y que no se a˜naden al repositorio) y, por ´ultimo, el README.md del proyecto. En .gitignore hemos a˜nadido, adem´as de carpetas como node modules, archivos con informaci´on sensible como, por ejemplo, la direcci´on IP de alg´un servidor con el que nos comunicamos, etc. De esta manera, si se sube el proyecto a alguna herramienta de Git (como Github), estos archivos no aparecer´an. Ahora vamos a comentar de qu´e est´an compuestas el resto de carpetas. 67 6.4. CAMBIOS IMPORTANTES EN EL DESARROLLO DEL PROYECTO protocolo AAA de Autenticaci´on, Autorizaci´on y Registro [3]. Para comunicarnos con esta plataforma, tuve que implementar finalmente Tacacs+ como protocolo final, por lo que la versi´on definitiva del proyecto incorpora este tipo de Login con protocolo Tacacs+ frente al protocolo LDAP que implement´e anterior a ´este. 6.4.3. Cambios en el algoritmo de b´usqueda ARP Aunque el algoritmo era funcional con el dise˜no inicial, la depuraci´on gracias a casos de uso y una bater´ıa de pruebas propuesta por algunos miembros de mi grupo de trabajo ha sido esencial para perfeccionar y pulir el algoritmo todo lo posible. Comenzamos con la primera implementaci´on, realizada en los primeros d´ıas de proyecto (Figura 6.1). Si nos fijamos bien, el dise˜no del modelo de dominio es muy simple: una clase Device que contiene atributos para representar a sus datos: nombre, IP, vendedor, tipo de dispositivo y conexi´on son los m´as importantes. De ´el salen dos clases con relaci´on uno a muchos, que son las tablas ARP y EthernetSwitching. De esta manera, primero se buscaba la relaci´on IP-MAC en routers y, posteriormente, se busca por qu´e interfaz se ve esta MAC en las tablas EthernetSwitching. Esta opci´on, aunque sencilla, mostraba la respuesta, pero hab´ıa un problema: mostraba todas las respuestas que se encontraban en las tablas EthernetSwitching, respuestas que no eran el dispositivo final, pues en ellas se indica que se est´a viendo esa direcci´on a trav´es de otro dispositivo que est´a conectado al dispositivo en cuesti´on. Para mejorar los resultados que se muestran, se incluy´o una nueva tabla llamada Interface. Antes, la interfaz era simplemente un atributo de cada tabla pero ahora hay una nueva tabla, que tambi´en incluye la descripci´on y el nombre de las interfaces de ese dispositivo, lo que significa que una vez encontrada la interfaz por la que se ve una MAC, tambi´en encontramos el nombre y la descripci´on de ´esta. Este hecho, adem´as de permitirnos obtener unos datos relevantes sobre la interfaz, nos permite ver si la interfaz es l´ogica (es decir, es un puerto del dispositivo) o es una interfaz virtual. Si el algoritmo detecta que no es una interfaz l´ogica (es decir, no es un puerto del dispositivo), no incluye este resultado en el array final que se mostrar´a por pantalla al usuario. Por ´ultimo, gracias a probar m´as ejemplos y casos, vimos que hay redes que, aunque no sean una interfaz f´ısica, pueden ser un resultado a mostrar. Estos resultados, aunque en vez de verse a trav´es de una interfaz l´ogica se vean a trav´es de una VLAN o de un agregado, tambi´en son necesarios, pues la informaci´on que muestran es cr´ıtica en caso de querer buscar su direcci´on IP o MAC. La pregunta era ¿c´omo sabemos que una interfaz que no sea un puerto est´a asociada con un dispositivo final? Aqu´ı entra en juego la tabla de Neighbors, que muestra los dispositivos que hay conectados a un dispositivo. Si tenemos un switch, consultar esta tabla de Neighbors nos mostrar´a qu´e hay conectado por cada interfaz del dispositivo. Es una tabla que ha sido realmente ´util, pues en la descripci´on est´a escrito (por los responsables que han configurado estas conexiones) informaci´on sobre el dispositivo al que est´a conectada cada interfaz. As´ı pues, si al otro lado vemos que el nombre es de un dispositivo de nuestra lista, sabemos que no es una direcci´on final, sino que simplemente est´a viendo esa MAC a trav´es de otro dispositivo al que est´a 74 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS conectado. El diagrama final de dominio lo vemos en la Figura 6.4, que es ya la versi´on que se documenta en el Cap´ıtulo de An´alisis (Figura 3.4). 6.4.4. Cambios en el modelo de dominio Los cambios en el modelo de dominio han sido motivados tanto por los cambios en el algoritmo de b´usqueda ARP como en mejoras para tener un modelo m´as consistente. Recordemos que el proyecto ha ido siguiendo un desarrollo ´agil, abordando las diferentes historias de usuario sprint a sprint. En primer lugar, como vemos en la Figura 6.1 podemos ver un modelo bastante simple. Al principio s´olo se pens´o en representar las clases necesarias para una b´usqueda preliminar de las tablas ARP. Aqu´ı tenemos s´olo la figura del dispositivo y sus tablas. Figura 6.1: Modelo de dominio inicial M´as adelante, se empezaron a detectar ciertos cambios que se pueden implementar. Entre ellos, que el dispositivo s´olo puede ser un tipo de dispositivo a la vez. Un router, aunque puede actuar con funciones de switch, no es un switch, por lo que tiene sentido a˜nadir en Device una modelado de especializaci´on/generalizaci´on. Tambi´en se incluye la tabla Interfaces que interact´ua con ambas tablas existentes. Estos cambios se recogen en el modelo de dominio de la Figura 6.2. 75 6.4. CAMBIOS IMPORTANTES EN EL DESARROLLO DEL PROYECTO Figura 6.2: Modelo de dominio versi´on 2 En el momento que detectamos algunos casos de uso que no mostraban las interfaces finales porque no las ve´ıan por una interfaz l´ogica, fue necesario a˜nadir Neighbors. De esta manera, en la tabla Neighbors se listan los dispositivos que est´an conectados al dispositivo seleccionado a trav´es de sus interfaces. Tambi´en, se utiliza la clase Interfaces para a˜nadir informaci´on extra muy ´util para el usuario, adem´as de poder hacer comprobaciones a la hora de filtrar resultados no deseados. Como tambi´en fue necesario a˜nadir los Firewalls para tener sus tablas ARP, se a˜naden a la generalizaci´on de los dispositivos. Para ver los cambios reflejados, consultar Figura 6.3. Por ´ultimo, aunque no se hab´ıa pensado en incluir los configlets y sus aplicaciones en el modelo de dominio al no ser parte del servidor back-end, he considerado incluirlos, al formar parte de toda la l´ogica del proyecto. As´ı pues, en el modelo de dominio final tambi´en aparece el objeto Configlet, relacionado con el dispositivo gracias a una clase de asociaci´on llamada ConfigurationJob, que incluir´a qu´e datos del configlet ha modificado el usuario para aplicarlo en uno o m´as dispositivos. Esta configuraci´on la har´a un usuario, por lo que la clase User tambi´en se incluye en el diagrama final (Figura 6.4). 76 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Figura 6.3: Modelo de dominio sin Configlets 77 6.4. CAMBIOS IMPORTANTES EN EL DESARROLLO DEL PROYECTO Figura 6.4: Modelo de dominio definitivo 78 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS 6.4.5. Cambios en el modelo relacional de la base de datos Al igual que sucedi´o con los modelos de dominio, cada cambio que se ha realizado en la web ha provocado que se actualizara el modelo relacional de la base de datos. En este subapartado vamos a ver c´omo ha ido evolucionando la base de datos de nuestro proyecto a trav´es de su modelo relacional y, a su vez, explicando qu´e cambios son los que han motivado estas modificaciones y el resultado de ´estas. El primer modelo relacional de la base de datos se puede observar en la Figura 6.5. En ella vemos la tabla devices, cuyas claves primarias son el ID del dispositivo y su direcci´on IP. A su vez, tenemos las tablas arp table yethernet switching table. Ambas tienen como clave for´anea (que a su vez tambi´en es primaria) el campo ip addres, que referencia al campo ip de la tabla devices. Figura 6.5: Modelo relacional de la base de datos (1) Bajo este primer modelo se comenz´o a desarrollar el algoritmo de b´usqueda ARP. No obstante, surgieron dos problemas derivados de este modelo relacional inicial: 1. Algunos campos de la tabla device necesitan ser consistentes. Entre ellos, el tipo de conexi´on, el tipo de dispositivo y, por ´ultimo, el fabricante. Estos campos son device type,connection type yvendor, respectivamente. 2. Para optimizar el algoritmo, necesitamos una tabla a˜nadida que muestre las interfaces y sus descripciones. 79 6.4. CAMBIOS IMPORTANTES EN EL DESARROLLO DEL PROYECTO Una vez analizadas las necesidades para desarrollar un nuevo modelo relacional, se cambia el modelo de la base de datos y la implementaci´on de este. As´ı, surge el siguiente modelo relacional (Figura 6.6). Figura 6.6: Modelo relacional de la base de datos (2) Aqu´ı podemos ver las correcciones sobre los dos problemas encontrados en la versi´on anterior del modelo relacional. Para garantizar consistencia, estos campos (que s´olo pueden tener unos valores predefinidos por el dominio de redes sobre el que trabajo) se cambia a enum. De esta manera, la tabla devices obtiene el valor de estos campos comprobando el ID de la tabla enum correspondiente. En cuanto a la tabla de interfaces de cada dispositivo, aqu´ı no se incluye, pues se encuentran problemas de compatibilidad en fabricantes a la hora de referenciar con claves for´aneas debido a distintas nomenclaturas, lo que puede generar violaciones de la consistencia de la base de datos. Estos cambios se ver´an en el siguiente modelo (Figura 6.7). 80 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Figura 6.7: Modelo relacional de la base de datos (3) En este modelo podemos ver c´omo se a˜nade la tabla interfaces table. Al igual que arp table yethernet switching table, tiene una referencia a la direcci´on IP de la tabla devices. La soluci´on que se ha encontrado es establecer esta tabla sin relaci´on a las dos tablas mencionadas antes. Esta decisi´on es debido a que el formato entre distintos vendedores tiene una nomenclatura distinta, incluso se ha dado el caso que en Cisco, seg´un el dispositivo y su versi´on, se nombran de manera distinta. Adem´as, se toma esta decisi´on debido a que hay interfaces virtuales que no salen reflejadas en alguna tabla, por lo que esa clave for´anea tendr´ıa que ponerse a null. As´ı pues, dejando esta tabla ´unicamente relacionada con devices, se evitan estos problemas. Por ´ultimo, como comentamos a la hora de modificar el modelo de dominio, hace falta ver los vecinos que tiene cada dispositivo para comprobar que el resultado no es un dispositivo dentro del dominio de mi grupo de trabajo. As´ı pues, en la Figura 6.8, podemos ver c´omo se a˜nade la tabla neighbors table que, al igual que las anteriores, hacen referencia a la IP de la tabla devices. De esta manera, el modelo relacional de la base de datos evoluciona hasta dar como resultado el dise˜no que muestra esta figura. 81 6.4. CAMBIOS IMPORTANTES EN EL DESARROLLO DEL PROYECTO Figura 6.8: Modelo relacional de la base de datos final 82 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS 6.5. Pruebas En las secciones anteriores se han explicado tanto la estructura de ficheros (ya sea en el front-end como en el back-end) como las decisiones tomadas a lo largo del proyecto, as´ı como cambios importantes que se han ido realizando durante desarrollo. Los cambios en la implementaci´on, en especial los relativos al algoritmo de b´usqueda ARP, se han dado gracias a seleccionar una bater´ıa de pruebas suficiente para detectar posibles fallos, sugerencias de implementaci´on, etc. Esta bater´ıa de pruebas, por lo general, se ha ido aumentando y ampliando a medida que lo hac´ıa la funcionalidad de la web y ha sido, en su mayor parte, confeccionada por el Product Owner del proyecto. El m´etodo escogido para realizar el apartado de pruebas se define como desarrollo guiado por pruebas de software, m´as conocido por Test-Driven Development (TDD). El desarrollo TDD es una pr´actica de ingenier´ıa que consiste en dise˜nar primero las pruebas que se van a hacer para, posteriormente, escribir el c´odigo fuente (o las modificaciones a incluir en el c´odigo fuente), desarrollar una implementaci´on que pasa las pruebas y hacer un refactoring para mejorar el c´odigo desarrollado [27]. El proceso de dise˜no de software, combinado con metodolog´ıas ´agiles en nuestro caso, se define as´ı: 1. El cliente elige una H.U.. 2. Se escriben junto al cliente los criterios de aceptaci´on de esta H.U. simplific´andolos lo m´aximo posible. 3. Se escoge el criterio de aceptaci´on m´as simple y se convierte a una prueba unitaria. 4. Se verifica que esa prueba falla. 5. Se escribe la implementaci´on del c´odigo fuente. 6. Se ejecutan las pruebas automatizadas. 7. Se refactoriza el c´odigo. 8. Se actualiza la lista de criterios de la H.U. y se vuelve al punto 3. El modelo de implementaci´on que se ha escogido es la t´ecnica triangular. Esta t´ecnica se basa en tres pasos de manera c´ıclica [24]: 1. Se escoge el caso m´as f´acil para resolver. 2. Se aplica el algoritmo del TDD. 3. Repetir los pasos 1 y 2 cubriendo nuevas casu´ısticas, esta vez m´as complejas. Si bien es cierto que, por lo general, realizar una bater´ıa de pruebas para la mayor´ıa de las historias de usuario ha sido una tarea bastante trivial, para la b´usqueda ARP ha sido bastante m´as complejo, tanto en extensi´on como a la hora de seleccionar qu´e casos iban a ser interesantes. Entre las razones de su dificultad, podemos encontrar las siguientes: 83 7.1. SEGUIMIENTO DE LOS SPRINTS 7.1.1. Sprint 1 H.U. Tarea Descripci´on Estimado Empleado Estado 01 T-1 Definir las tareas de backlog 2h 2h Completado 01 T-2 Estructurar puntos de la memoria 1.5h 1h Completado 01 T-3 Arquitectura y estructura del proyecto 5h 5h Completado 01 T-4 Comunicaci´on con las distintas APIs para obtener datos y realizar peticiones REST 8h 18h Completado 01 T-5 Documentaci´on del sprint 0.5h 1h Completado 01 T-6 Bocetado de las vistas para la H.U. 1 2h 3h Completado 01 T-7 Creaci´on de las vistas necesarias para la p´agina de dispositivos 1h 1h Completado 01 T-8 Creaci´on del componente para mostrar los dispositivos y poder aplicar filtros de b´usqueda 2h 1.5h Completado 01 T-9 Creaci´on del componente de cabecera de la aplicaci´on 1h 1.5h Completado 01 T-10 Creaci´on del componente barra lateral de la aplicaci´on 2h 1.5h Completado 01 T-11 Creaci´on de las vistas necesarias para la p´agina principal 2h 2.5h Completado 09 T-12 Creaci´on de ficheros necesarios para cambio de idioma 0.5h 0.5h Completado 09 T-13 A˜nadir cadenas de texto de cada idioma 0.5h 0.5h Completado 01 T-14 Revisi´on y documentaci´on del c´odigo 1h - No iniciado 01 T-15 Test unitarios Consultad de dispositivos 2h - No iniciado 01 T-16 Test end-to-end (e2e) Consultad de dispositivos 2h - No iniciado - T-17 Documentaci´on de la memoria 1h 1h Completado TOTAL 34 horas 40 horas 14/17 Tabla 7.1: Sprint 1: 08/02/2021 - 14/02/2021 90 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO En este sprint, tienen lugar las primeras tareas de bocetado, arquitectura y dise˜no del proyecto. Se ha elegido la primera Historia de Usuario (de ahora en adelante, H.U.), para intentar realizarla casi en su totalidad. De esta manera, se puede realizar un primer contacto con las tecnolog´ıas empleadas, ver cu´anto se tarda tanto en maquetar como en desarrollar el c´odigo, c´omo se comporta la API, etc. Por ello, se le ha asignado 7 Puntos de Historia (P.H.). Como vimos en la tabla 2.1, se corresponden unas 20 horas con esta puntuaci´on. Por otro lado, la H.U. 09 tiene 5 P.H. pues, aunque se realiza durante varios sprints, son tareas cortas de a˜nadir cadenas de texto. Al ser la primera tarea, hay mucho trabajo en cuanto a leer documentaci´on, atacar a una API para obtener datos y enviarlos, etc., por lo que una de las tareas cr´ıticas como la T-004 se estima que lleve bastantes horas. No obstante, una vez realizada, las siguientes tareas de comunicaci´on con la propia API se estima que lleven mucho menos tiempo al entender c´omo funciona y ver si ha habido problemas a la hora de realizar las peticiones. En este sprint se realizar´an las tareas que se describen en la Tabla 7.1. Como se puede ver, se han tenido que emplear m´as horas de las previstas debido a que algunas tareas han llevado m´as tiempo de lo estimado. Las 10 horas aproximadas adicionales que se han tenido que emplear son, en gran parte, consecuencia de la tarea T-004, debido a que tuve problemas a la hora de comunicarme con la API debido a un error de CORS. CORS (Cross-origin resource sharing) es un mecanismo que permite que se puedan solicitar recursos restringidos (como por ejemplo, las tipograf´ıas) en una p´agina web desde un dominio diferente del dominio que sirvi´o el primer recurso [14]. Al desplegar el proyecto desde una m´aquina virtual, las peticiones a la API (que es un servidor Apache) fueron denegadas. Para solucionarlo tuve que mirar documentaci´on en internet para ver qu´e significaba este error. La soluci´on fue incluir unas l´ıneas en un fichero del propio servidor para autorizar las peticiones de la IP donde se despliega el proyecto. De esta manera, todas las peticiones y el tr´afico que lleguen desde la IP del proyecto se permitir´an y podremos comunicarnos con la API a trav´es de peticiones REST. En cuanto al resto de tareas, no ha sido posible revisar y documentar el c´odigo, por lo que esa tarea se traslada al siguiente sprint. Tampoco se ha podido realizar los test. Requer´ıan instalar ciertas herramientas y no he podido, por lo que se ha decidido pasarlo a otro sprint. 7.1.2. Sprint 2 En este sprint se van a incluir las tareas de Login (H.U. 4), consulta de configlets (H.U. 2) y aplicaci´on de configlets (H.U. 3). He elegido continuar con la tarea de Login debido a que, para subir el c´odigo, necesito tener en funcionamiento la capacidad de loguearse para no subir datos o credenciales de usuarios, debido a las pol´ıticas de seguridad del entorno donde se va a usar esta aplicaci´on. De esta manera, una vez que el usuario se registra, se almacena un token que se incluir´a en la cabecera de las peticiones GET y POST. Los P.H. de las H.U. 2, 3 y 4 son 5, 8 y 9, respectivamente. La H.U. 5 tiene una menor puntuaci´on debido a que, al realizar la H.U. 1, he adquirido el conocimiento suficiente para trabajar con la API de Junos de manera m´as eficiente. 91 7.1. SEGUIMIENTO DE LOS SPRINTS Una vez realizado esto, el paso siguiente ser´a poder ejecutar un configlet en uno de los dispositivos de la lista, con lo cual se completan las H.U. 2 y 3. No obstante, como la tarea del Login es muy laboriosa al tratar temas de seguridad y comunicaci´on con API, est´a previsto que su finalizaci´on tenga lugar en el siguiente sprint. Por ello, se han a˜nadido las historias 2 y 3, bastante m´as cortas en duraci´on. Las tareas se pueden ver en la Tabla 7.2 H.U. Tarea Descripci´on Estimado Empleado Estado 04 T-18 Bocetado de vista Login 1h 1h Completado 03 T-19 Bocetado de Configlet y componentes de Configlet 1h 1h Completado 04 T-20 Bocetado de la aplicaci´on de configlet y sus componentes 1h 1h Completado 04 T-21 Maquetado de Login 4h 5h Completado 02 T-22 Maquetado de Configlets y componentes 5h 7h Completado 03 T-23 Maquetado de componentes de Configlets 3h 2.5h Completado 04 T-24 Lectura de documentaci´on de la API de ClearPass para autenticaci´on 5h 7h En progreso 02 T-25 Maquetado de Configlets 1.5h 1.5 Completado 04 T-26 L´ogica de Login y env´ıo de datos 1.5h 1.5 Completado 04 T-27 Securizaci´on y anonimizaci´on de credenciales 5h - No iniciado 02 T-28 Peticiones REST para mostrar lista de configlets 1h 0.5h Completada 03 T-29 Env´ıo de peticiones para aplicar un configlet en un dispositivo 1h 1h Completada 03 T-30 Mocks para la plantilla de modificaci´on de datos del configlet 0.5h 0.5h Completada 09 T-31 A˜nadir cadenas de texto de cada idioma 1.5h 1.5h Completada 02 T-32 Revisi´on y documentaci´on del c´odigo 1h 1h Completada 03 T-33 Revisi´on y documentaci´on del c´odigo 1h 1h Completada 04 T-34 Revisi´on y documentaci´on del c´odigo 1h 1h Completada - T-35 Documentaci´on de la memoria 1h 1h Completado TOTAL 36 h 35 h 16/18 Tabla 7.2: Sprint 2: 15/02/2021 - 21/02/2021 92 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Una vez comentada cu´al ha sido la previsi´on de tareas, podemos comprobar que en este sprint surgieron problemas problemas con el propio proyecto relacionado con su ´arbol de dependencias. Esto ha imposibilitado realizar los test a tiempo, debido a que no ha permitido instalar la herramienta Cypress para los test end-to-end y los unitarios. Como consecuencia, en el sprint siguiente ´unicamente tendr´a lugar la autenticaci´on del login y la realizaci´on de los test pendientes. La tarea de autenticarse a trav´es de ClearPass est´a en progreso. La API es algo m´as compleja de lo que pensaba, aunque s´ı que hab´ıa tenido en cuenta la complejidad de la tarea, pues es una de las que tienen m´as Puntos de Historia asociados. Por ´ultimo, al hablar de la H.U. 3, se hizo una peque˜na prueba piloto con una configuraci´on sencilla para ver que el dispositivo recibe la aplicaci´on de ese configlet. Sin embargo, se deja para m´as adelante debido a su complejidad. 7.1.3. Sprint 3 Como coment´e en la secci´on anterior, no pude realizar los test de las H.U. debido a un problema de dependencias. Al mover el proyecto y recompilarlo, el problema parece estar solucionado, por lo que se espera que, durante este sprint, se realicen todas estas tareas pendientes para as´ı, por fin, dar por concluidas varias de las H.U. ya realizadas. Se esperan finalizar completamente las H.U. 01, 02 y 03 y 10. Sin embargo, la 04 no se espera completar durante este sprint debido a su complejidad al tener que trabajar contra una herramienta externa. Para la tarea 10 se fija una cantidad de 3 P.H.. El desglose de las actividades se puede ver en la Tabla 7.3. Como podemos ver, en este sprint no se ha podido iniciar los test debido a un problema: el Product Owner necesita que, si el usuario no se loguea correctamente, no se puede acceder a ninguna otra vista. Tras tener una reuni´on con el equipo de desarrollo, se ha decidido implementar el mismo mecanismo de login (mediante un Active Directory) que en el resto de aplicaciones de desarrollo que tienen lugar dentro de la divisi´on donde me encuentro desarrollando este proyecto. Puesto que la reuni´on tiene lugar la semana que viene, de momento las actividades relacionadas con el Login quedan paralizadas, pues dependen de esta actividad. Se espera que en el siguiente sprint, una vez se tenga la reuni´on se complete la actividad y, por consiguiente, los test del resto de historias de usuario. En cuanto al resto del tiempo, me he dedicado a revisar documentaci´on sobre tablas ARP y tareas de dise˜no, por ejemplo, c´omo implementar las librer´ıas que permitan conectarse a los dispositivos para, entre otras cosas, manejar una base de datos de m´as vendedores (no s´olo Juniper) y, as´ı, poder realizar las siguientes H.U. de manera m´as fluida. 7.1.4. Sprint 4 Durante este sprint se prev´e finalizar la H.U. 4: Login. Durante esta semana tendr´an lugar reuniones sobre qu´e pol´ıtica se va a aplicar a la hora de realizar el Login, tratar la manera en la 93 7.1. SEGUIMIENTO DE LOS SPRINTS H.U. Tarea Descripci´on Estimado Empleado Estado 01 T-36 Test e2e de Consulta de dispositivos 4h 4h Completado 01 T-37 Test unitarios de Consulta de dispositivos 4h 1h En progreso 02 T-38 Test e2e de Consulta de configlets 3h - No iniciado 02 T-39 Test unitarios de Consulta de configlets 3h - No iniciado 03 T-40 Test e2e de Aplicaci´on de configlets 2h - No iniciado 03 T-41 Test unitarios de Aplicaci´on de configlets 2h - No iniciado 10 T-42 Creaci´on del componente para ver config. del dispositivo 2h 2h Completado 10 T-43 L´ogica para mostrar la configuraci´on del dispositivo 2h 2h Completado 04 T-44 Comunicarse con la API de ClearPass a trav´es de peticiones REST 8h 16h Completado 04 T-45 Revisi´on y documentaci´on del c´odigo 1h 2h Completado - T-46 Documentaci´on de la memoria 1h 1h Completado TOTAL 32 h 24 h 4/11 Tabla 7.3: Sprint 3: 22/02/2021 - 28/02/2021 que se van a gestionar las peticiones y ver el Active Directory contra el que se va a autenticar. No obstante, en el sprint anterior ya se realiz´o un proceso de autenticaci´on contra Junos Space en el que se introduc´ıan las credenciales y se guardaban en el sessionStorage de la propia aplicaci´on, por lo que se reutilizar´a parte de este c´odigo para realizar la autenticaci´on contra el nuevo servidor. A lo largo de esta semana se ha planificado finalizar esta tarea securizando y anonimizando las credenciales de usuario necesarias para el Login, adem´as de realizar los test de esta H.U. con la consiguiente modificaci´on del resto de tests. Esto es debido a que, si el usuario no se ha logeado, no se puede acceder al resto de vistas por motivos de seguridad. Las actividades planificadas para este sprint se encuentran en la Tabla 7.4. Como hemos visto en la tabla, se ha tenido que utilizar una mayor cantidad de horas debido a que en el anterior sprint no pude avanzar todo lo que me gustar´ıa debido a que tuve que esperar para que el equipo de desarrollo se pusiera en contacto conmigo. Durante este sprint, complet´e los test de las anteriores Historias de Usuario y, adem´as, implement´e la H.U. del Login. No obstante, durante los ´ultimos d´ıas se encontr´o un problema a la hora de autenticar contra los servidores, por lo que se paraliza la implementaci´on actual. Aunque 94 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO la tarea est´a acabada, es posible que se tenga que modificar en el futuro debido a cambios externos en el servidor de autenticaci´on (tarea sobre la que no tengo ninguna capacidad de operar). Debido a esto, se marcan con el estado ”En pausa“ aunque, como hemos visto, est´an ya finalizadas y son funcionales. H.U. Tarea Descripci´on Estimado Empleado Estado 04 T-47 Petici´on con ´exito contra el nuevo AD 5h 3h En pausa 04 T-48 Aplicaci´on del protocolo elegido en la nueva autenticaci´on 8h 5h En pausa 04 T-49 Integraci´on en la aplicaci´on de las nuevas pol´ıticas de autenticaci´on 8h 8h Completado 04 T-27 Securizaci´on y anonimizaci´on de credenciales 5h 4h En pausa 04 T-50 Test e2e de Login 2h 4h En pausa 04 T-51 Test unitarios de Login 2h 4h Completado 01 T-52 Modificaci´on test e2e Consulta de Dispositivos 1h 1h Completado 01 T-53 Modificaci´on test unitarios Consulta de Dispositivos 1h 1h Completado 02 T-38 Test e2e de Consulta de configlets 3h 1h Completado 02 T-39 Test unitarios de Consulta de configlets 3h 3h Completado 03 T-40 Test e2e de Aplicaci´on de configlets 2h 1h Completado 03 T-41 Test unitarios de Aplicaci´on de configlets 2h 4h Completado 10 T-54 Creaci´on del componente para ver config. del dispositivo 2h 2h Completado 10 T-55 L´ogica para mostrar la configuraci´on del dispositivo 2h 2h Completado - T-56 Documentaci´on de la memoria 1h 1h Completado TOTAL 47h 44h 11/15 Tabla 7.4: Sprint 4: 01/03/2021 - 07/03/2021 La conclusi´on es que, durante este sprint, se ha completado la tarea de testing de las anteriores H.U., adem´as de redefinir la funcionalidad que debe tener la aplicaci´on para la presentaci´on final. Se ha completado la tarea de Login con un peque˜no inconveniente debido a problemas externos, por lo que en el futuro quiz´a se tenga que volver a cambiar y, por ´ultimo, se ha pensado en c´omo desarrollar el resto del proyecto al haber un cambio en las H.U. del Product Backlog. 95 7.1. SEGUIMIENTO DE LOS SPRINTS 7.1.5. Sprint 5 Una vez acabada la H.U. del Login, podemos continuar con el resto de tareas que aportan una funcionalidad importante a la aplicaci´on. Para este sprint, se ha decidido comenzar la H.U. 7: A˜nadir dispositivo. Al contrario que en las anteriores historias, aqu´ı vamos a incluir tambi´en los dispositivos Cisco y de otros fabricantes, por lo que ser´a necesario desarrollar tambi´en una base de datos que almacene los datos importantes de ´estos y permita hacer b´usquedas entre ellos. Para ello tambi´en ser´a necesario estudiar qu´e lenguaje o qu´e tecnolog´ıas permiten conectarse a estos dispositivos y, una vez que esto se ha probado, desarrollar la BD e integrar todo en su conjunto con nuestra aplicaci´on. Es una tarea muy extensa, pues es la primera que necesita arrancar la base de datos y comenzar la comunicaci´on directa con los dispositivos. Para ello, adem´as, es necesario desarrollar un back-end a trav´es del cual podamos ejecutar consultas en la base de datos mediante una API. Debido a los factores comentados, se fija una puntuaci´on de 9 P.H. para esta tarea. Las tareas asociadas a este sprint son las que se describen en la Tabla 7.5. H.U. Tarea Descripci´on Estimado Empleado Estado 07 T-57 Integrar Flask en la aplicaci´on 8h 10h Completado 07 T-58 Conexi´on directa con los dispositivos a trav´es de SSH/- Telnet 14h 10h Completado 07 T-59 Dise˜no de las tablas de la BD con SQL 3h 2h Completado 07 T-60 Conexi´on con la BD para mostrar datos de los dispositivos 8h 2h En progreso 07 T-61 Conceptualizar cambios en el dise˜no y las vistas para implementar las nuevas funcionalidades 2h 2h Completado 04 T-62 Finalizaci´on del Login 8h 6h Completado 04 T-63 Volver a comprobar los test e2e del Login 1h 1h Completado - T-64 Documentaci´on de la memoria 1h 1h Completado TOTAL 45h 34h 7/8 Tabla 7.5: Sprint 5: 08/03/2021 - 14/03/2021 Seg´un se muestra en la tabla, se han completado casi todas las tareas a excepci´on de una (tarea 65) por falta de tiempo. Este imprevisto ha sido causado por la H.U. del Login, puesto que ya pude finalizarla al saber de qu´e manera ten´ıa que autenticar y contra qu´e servidor. Debido a ello, aunque no estaba previsto durante el Sprint Planning, se han a˜nadido estas dos ´ultimas tareas dentro del sprint y, con ellas, se finaliza del todo la H.U. 4. 96 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Como la H.U. 7 queda en curso, se prev´e que sea completada durante el siguiente sprint. ´ Unicamente queda por completar la creaci´on y conexi´on con la base de datos de los dispositivos y mostrarlos por pantalla a trav´es de consultas SQL. 7.1.6. Sprint 6 En este sprint se introduce la H.U. 5: tablas ARP y, adem´as, tambi´en se planifica finalizar la historia de usuario 7 que qued´o incompleta en el anterior sprint debido a cambios en la pol´ıtica de Login de la aplicaci´on. Al acordarse la pol´ıtica definitiva, esto va a permitir permite avanzar en otras historias de usuario. Tambi´en se a˜nade como posible tarea la H.U.8: Eliminar dispositivo en caso de que diese tiempo a realizarla. Como la tarea 5 es, con diferencia, la m´as larga y compleja del proyecto, no se espera finalizar durante este sprint y se le asignan 9 P.H. Sin embargo, como la H.U. 8 reutiliza mucho c´odigo y ya tiene la conexi´on con la base de datos realizada, sus P.H. asociados se situan en 4. Las tareas asociadas a este sprint las podemos ver en la Tabla 7.6. H.U. Tarea Descripci´on Estimado Empleado Estado 07 T-65 Recogida y tratamiento de datos de un fichero excel/csv para poblar las tablas de la BD 4h 5h Completado 07 T-60 Conexi´on con la BD para mostrar datos de los dispositivos 8h 11h Completado 07 T-66 Ajustar cambios en la l´ogica de las vistas para mostrar los nuevos dispositivos 3h 4h En progreso 08 T-67 Eliminar dispositivos 2.5h - No iniciado 07 T-68 Test e2e de A˜nadir dispositivo 1h - No iniciado 07 T-69 Test unitario de A˜nadir dispositivo 5h - No iniciado 08 T-70 Test e2e de Eliminar dispositivo 1h - No iniciado 08 T-71 Test unitario de Eliminar dispositivo 2h - No iniciado 05 T-72 Maquetaci´on de la vista de las tablas ARP 1h 1h Completado 05 T-73 Dise˜no de la l´ogica para las consultas ARP 4h 6h Completado - T-74 Desarrollo de la memoria 6h 6h Completado TOTAL 37.5h 33h 5/11 Tabla 7.6: Sprint 6: 15/03/2021 - 21/03/2021 97 7.1. SEGUIMIENTO DE LOS SPRINTS Durante la realizaci´on de este sprint ha surgido un problema que me ha impedido acceder a los dispositivos, por lo que se han podido desarrollar las H.U. 7 y 8. Sin embargo, como soluci´on para seguir avanzando, he mockeado de forma local los posibles datos de los dispositivos para probar la base de datos a la hora de inyectar dispositivos en ella. Gracias a ello, he podido comprobar que el dise˜no de ´esta es correcto y que los datos se introducen bien a trav´es de un fichero .csv en el cual se pueden ir actualizando por cualquier miembro del equipo de trabajo. Tambi´en hice pruebas para comprobar si las tablas de la base de datos son correctas y comprender mejor los m´odulos de Python con los que hac´ıa las llamadas, puesto que los utilizar´e para otras H.U. posteriores. El tiempo que no se ha podido emplear en realizar estas tareas, lo he utilizado para completar el documento de la memoria y ampliar algunas secciones. Las tareas que no se han llevado a cabo se trasladan al siguiente sprint. 7.1.7. Sprint 7 Aqu´ı, en el sprint 7, vamos a adaptar a nuestro c´odigo desarrollado localmente en el Sprint anterior a todas las tareas realizadas en otra m´aquina. Adem´as, una vez acabada esta H.U. 7 (A˜nadir dispositivo), se pretende finalizar la H.U. 8 (Eliminar dispositivo) para poder eliminar dispositivos y, si fuera posible, comenzar la H.U. 14 (Editar dispositivo), finalizando as´ı las acciones CRUD sobre los dispositivos. Adem´as, se ha creado una nueva H.U. para mostrar todos los dispositivos actualmente en uso, ya sean del fabricante que sean. Esta tarea es distinta respecto a la H.U. 1 (Consulta de dispositivos Juniper), pues esta ´ultima s´olo muestra los dispositivos Juniper y, adem´as, los muestra a trav´es de una llamada a la API frente a la H.U. 15., que los obtiene con una llamada al backend, obteni´endolos as´ı de una base de datos. Adem´as, la H.U. 1 permite, a trav´es de la interfaz correspondiente, aplicar los configlets disponibles seg´un el dispositivo, pero no permite realizar acciones CRUD sobre ellos. A la H.U. 15 se le asignan 8 P.H.. El seguimiento de este sprint se puede ver en la Tabla 7.7. Durante este sprint se han completado todas las tareas estimadas. No obstante, me he dado cuenta de que, muchas de ellas, se pueden mejorar. Por ejemplo, para el siguiente sprint, donde pienso realizar las H.U. 7 y 14 (A˜nadir y editar dispositivo, respectivamente), ser´ıa muy adecuado crear un componente “Dialog” para que muestre un mensaje al usuario preguntando si realmente desea eliminar esos dispositivos o, por otro lado, que muestre los datos del dispositivo que se desea modificar o una peque˜na tabla donde puedes a˜nadir los datos que va a tener un nuevo dispositivo. De esta manera, con el componente Dialog, el usuario podr´a ver, antes de eliminarlos definitivamente, los dispositivos que se van a eliminar en una lista que se mostrar´a a modo de confirmaci´on. Como hemos comentado, este componente se podr´a reutilizar para las opciones de a˜nadir y editar dispositivo, puesto que el Dialog se mostrar´a tambi´en al pulsar un bot´on, pero cambiar´a el contenido en funci´on del bot´on que se pulse. 98 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO H.U. Tarea Descripci´on Estimado Empleado Estado 15 T-75 Creaci´on de la BD en el backend de la aplicaci´on 2h 2h Completado 15 T-76 Conexi´on de la BD con el frontend 6h 8h Completado 15 T-77 Adaptar componentes existentes para mostrar los datos de todos los dispositivos 2h 2h Completado 15 T-78 Creaci´on de botones para acciones CRUD 2h 1h Completado 15 T-79 Cambio en la l´ogica de componentes para las siguientes HU 6h 5h Completado 15 T-80 Creaci´on de la acci´on de refrescar la lista 2h 1h Completado - T-81 Adaptaci´on de la l´ogica de backend para mejor escalabilidad 5h 5h Completado 08 T-82 Backend para query para borrar dispositivos 3h 2h Completado 08 T-83 Selecci´on de varios dispositivos para posterior borrado 1h 3h Completado 09 T-84 A˜nadir cadenas de texto para mostrar seg´un el idioma seleccionado 1h 1h Completado 08 T-85 Conexi´on frontend-backend para borrar dispositivos 3h 2h Completado - T-86 Documentaci´on de la memoria 1h 1h Completado TOTAL 34h 33h 12/12 Tabla 7.7: Sprint 7: 22/03/2021 - 28/03/2021 7.1.8. Sprint 8 Como comentamos anteriormente, se llevar´an a cabo las H.U. 7 y 14 (a˜nadir y editar un dispositivo, respectivamente), adem´as de a˜nadir una peque˜na modificaci´on a la H.U. 8 (eliminar un dispositivo). Como la H.U. 14 se basa en varios componentes ya creados para la H.U. 7, se le asigna una puntuaci´on de 7 P.H., puesto que aunque parte del c´odigo es muy similar, son necesarias muchas comprobaciones y cambios en la l´ogica de la vista. Tambi´en, se ha cre´ıdo oportuno mostrar un mensaje de alerta a trav´es de un Alert Component que permita informar al usuario si la operaci´on se ha llevado a cabo con ´exito o, si por el contrario, ha habido un error en la base de datos. Para ver lo que se ha llevado a cabo en este sprint, consultar la Tabla 7.8. 99 7.1. SEGUIMIENTO DE LOS SPRINTS de ´este a la nueva H.U. H.U. Tarea Descripci´on Estimado Empleado Estado 13 T-138 Borrar datos sessionStorage 2h - No iniciado 13 T-139 Borrar los datos al pulsar Logout en la interfaz 2h - No iniciado 13 T-140 Mostrar Logout siempre o redirigir a Login 1h - No iniciado - T-141 Cambio en la l´ogica del componente para mostrar tablas 6h 8h Completado 03 T-142 Cambio en la l´ogica para la reutilizaci´on del componente de mostrar configuraciones 3h 5h Completado 03 T-143 Llamada a la API de Junos Space para mostrar la configuraci´on del configlet 2h 1h Completado 03 T-144 Conectar l´ogica para mostrar la configuraci´on del configlet por pantalla 2h 2h Completado 06 T-145 Bocetado de la vistas tras seleccionar un configlet 2h 2h Completado 06 T-146 Conectar rutas din´amicas de Configlets a ApplyConfiglets 2h 2h Completado 06 T-147 Maquetado de la vistas tras seleccionar un configlet 6h 8h Completado 06 T-148 Aplicaci´on de configlets v´ıa API 6h - No iniciado 09 T-149 A˜nadir cadenas de texto para el lenguaje 0.5h 0.5h Completado 17 T-150 Bocetado de la vista para mostrar la validaci´on de configlets 1h 1h Compleatdo 17 T-151 Maquetado de la vista para mostrar la validaci´on de configlets 3h 5h Completado 17 T-152 L´ogicas para las llamadas a la API para validar configlet 2h 2h Completado 17 T-153 Conectar validaci´on del configlet para posterior aplicaci´on 2h 3h Completado - T-154 Completar apartados de la memoria 3h - No iniciado - T-155 Documentaci´on de la memoria 1h - No iniciado TOTAL 46.5h 39.5h 12/18 Tabla 7.13: Sprint 13: 03/05/2021 - 09/05/2021 106 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO H.U. Tarea Descripci´on Estimado Empleado Estado 06 T-156 A˜nadir la opci´on de que se pueda copiar los par´ametros a los otros dispositivos 7h - No iniciado 06 T-157 Cambiar scroll al componente 2h 1h Completado 06 T-158 Comprobar bug al cerrar tabs 4h 2h Completado 06 T-159 Mostrar alerts cuando se aplique (bien o mal) una config 2h 2h Completado 06 T-160 Deshabilitar bot´on si alg´un configlet no est´a bien validado 3h 2h Completado 06 T-161 Comprobar configlets que fallan al querer editarlos y convertirlos en editables 2h 2h Completado 13 T-138 Borrar datos sessionStorage 2h - No iniciado 13 T-139 Borrar los datos al pulsar Logout en la interfaz 2h - No iniciado 13 T-140 Mostrar Logout siempre o redirigir a Login 1h - No iniciado 11 T-162 Maquetado para la H.U. 11 3h 3h Completado 11 T-163 Adaptar componentes para la H.U. 11 3h 3h Completado 11 T-164 Debug a la hora de seleccionar y montar componentes y objetos 3h 5h Completado 11 T-165 Adaptar componentes para la H.U. 11 3h 3h Completado 11 T-166 Llamada para aplicar uno o m´as configlets distintos en un dispositivo 5h 4h Completado 01 T-167 Mostrar un bot´on verde o rojo seg´un el estado del dispositivo 1h 1h Completado 09 T-168 A˜nadir cadenas de texto para el lenguaje 0.5h 0.5h Completado - T-169 Completar apartados de la memoria 3h 3h Completado - T-170 Documentaci´on de la memoria 1h 3h Completado TOTAL 47.5h 34.5h 14/18 Tabla 7.14: Sprint 14: 10/05/2021 - 16/05/2021 107 7.1. SEGUIMIENTO DE LOS SPRINTS Para el siguiente sprint ´unicamente queda hacer la H.U. 13 (Logout) y tareas de refactoring, especialmente en el CSS para mostrar una interfaz de usuario mucho m´as adecuada. Adicionalmente, se intentar´a implementar la opci´on de copiar valor del formulario de uno a varios configlets, adem´as de otras peque˜nas mejoras en la funcionalidad. Tambi´en se completar´an diagramas para dejar documentadas las decisiones tomadas y otros apartados de la memoria, al estar hechas las historias de usuario. 7.1.15. Sprint 15 H.U. Tarea Descripci´on Estimado Empleado Estado 06 T-156 A˜nadir la opci´on de que se pueda copiar los par´ametros a los otros dispositivos 7h - No iniciado - T-171 A˜nadir la opci´on de “deseleccionar todo” en varias vistas 3h - No iniciado 13 T-138 Borrar datos sessionStorage 2h - No iniciado 13 T-139 Borrar los datos al pulsar Logout en la interfaz 2h - No iniciado 13 T-140 Mostrar Logout siempre o redirigir a Login 1h - No iniciado - T-172 Cambiar CSS de las tablas para dejar columnas fijas 3h - No iniciado - T-173 Cambiar CSS de todas las vistas 4h - No iniciado - T-174 Refactoring de la BD para poderlo automatizar 7h 9h Completado 05 T-175 Refactoring del input de las direcciones MAC para aceptar y convertir m´as formatos 2h 2h Completado 05 T-176 Refactoring para las nuevas tablas de Neighbors en la BD 2h 2h Completado 05 T-177 Poblar las tablas de Neighbors para los Juniper 2h 3h Completado 05 T-178 Poblar las tablas de Neighbors para los Cisco 7h 10h En progreso - T-179 Refactoring del c´odigo para hacerlo m´as reutilizable 7h 5h En progreso - T-180 Dise˜no del nuevo logo y cambio de nombre 3h - No iniciado - T-181 Desarrollo de la memoria 15h 15h En progreso TOTAL 67h 46h 4/15 Tabla 7.15: Sprint 15: 17/05/2021 - 23/05/2021 108 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Durante este sprint, se plantea simplemente finalizar la H.U. 13. Adem´as, se intentar´a a˜nadir algo de funcionalidad a la H.U. 06 para hacerla m´as c´omoda a la hora de rellenar varios dispositivos para el mismo configlet. Por ´ultimo, las tareas que se llevar´an a acabo ser´an de mejorar funcionalidad, depuraci´on y cambiar el CSS para mostrar las vistas de manera m´as clara o m´as est´etica. Tambi´en se limpiar´a algo de c´odigo y se probar´a distintos escenarios. Como podemos ver en la Tabla 7.15, se han dejado sin comenzar bastantes tareas relacionadas con CSS en pos de a˜nadir una nueva tabla de base de datos, que nos permitir´a todav´ıa afinar un poco m´as la b´usqueda ARP de los dispositivos. De esta manera, se pasan al siguiente sprint, que ser´a ´unicamente de aspectos visuales y depurar el c´odigo, adem´as de eliminar todo aquel que finalmente no se utilice para estructurarlo mejor. El resto del tiempo se emplear´a en seguir desarrollando el documento. Durante este sprint se realizan varios puntos de desarrollo de la memoria lo que permitir´a avanzar en paralelo la correcci´on de la tutora. 7.1.16. Sprint 16 Llegamos al que, seg´un lo acordado, ser´a el sprint final en cuanto a c´odigo. Debido a esto, se completar´an las tareas anteriores y se rematar´an otras nuevas, pero no se a˜nadir´a nueva funcionalidad a la aplicaci´on. Si bien es cierto que durante el Sprint Planning se acord´o que este es el ´ultimo sprint, siempre se puede a˜nadir otro a mayores. Podemos ver las tareas en la Tabla 7.16. No se han incluido algunas tareas (por ejemplo, la opci´on de “deseleccionar todo” o la de copiar par´ametros) por falta de tiempo y porque al consultarlo con el Product Owner indic´o que tampoco era una funcionalidad esencial, pues no se suele dar el caso en el que llegue a ser ´util. Al terminar este sprint, la aplicaci´on ya es totalmente funcional y s´olo queda acabar la memoria del proyecto, adem´as de subirlo a la instancia GitLab on premises de la que dispone la Escuela, cambiar el logo por defecto y completar informaci´on relevante en el About. 7.1.17. Sprint 17 Como comentamos antes, el c´odigo de la aplicaci´on est´a acabado. En este sprint, simplemente se llevar´an a cabo acciones sobre la memoria, la documentaci´on, cambiar el logotipo de la aplicaci´on, redactar el About y otras tareas que puedan surgir al comprobar la bater´ıa de pruebas y funcionalidad. Las tareas se han recogido en la Tabla 7.17. Como podemos ver, algunas tareas han llevado m´as tiempo del estimado. Por ejemplo, al cambiar el nombre del proyecto, hubo que recompilar todo el entorno virtual de Python. Por otro lado, se depur´o y se a˜nadieron restricciones al algoritmo que restringen todav´ıa m´as los resultados mostrado por pantalla. Tambi´en, se redact´o el About de la p´agina que muestra mis datos de contacto empresariales por si hubiese alg´un error, adem´as de reflejar algo de informaci´on sobre las tecnolog´ıas usadas en el desarrollo. 109 7.1. SEGUIMIENTO DE LOS SPRINTS Con esto, queda finalizado el proyecto incluida su documentaci´on. Se han realizado en total 17 sprints, distribuidos a lo largo de 17 semanas. H.U. Tarea Descripci´on Estimado Empleado Estado 06 T-156 A˜nadir la opci´on de que se pueda copiar los par´ametros a los otros dispositivos 7h - No realizado - T-171 A˜nadir la opci´on de “deseleccionar todo” en varias vistas 3h - No realizado 13 T-138 Borrar datos sessionStorage 2h 2h Completado 13 T-139 Borrar los datos al pulsar Logout en la interfaz 2h 0.5h Completado 13 T-140 Mostrar Logout siempre o redirigir a Login 1h 2h Completado - T-182 Cambiar CSS de las tablas para dejar columnas fijas 3h 1h Completado - T-183 Cambiar CSS de todas las vistas 4h 4h Completado - T-184 Cambiar CSS del caroussel 4h 2h Completado - T-185 Cambiar CSS del dialog de los dispositivos 4h 1h Completado - T-186 Cambiar CSS de los botones para hacerlos cuadrados 1h 2h Completado 05 T-178 Poblar las tablas de Neighbors para los Cisco 5h 3h Completado 05 T-187 Modificar algoritmo Calambuco para que muestre otros mensajes y tenga en cuenta los neighbors 5h 6h Completado - T-179 Refactoring del c´odigo para hacerlo m´as reutilizable 7h 5h Completado 05 T-188 Creaci´on de logs por cada tabla de la BD al poblar 5h 5h Completado - T-189 Dise˜no del nuevo logo y cambio de nombre 3h - No iniciado TOTAL 56h 33.5h 12 / 15 Tabla 7.16: Sprint 16: 24/05/2021 - 30/05/2021 110 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO H.U. Tarea Descripci´on Estimado Empleado Estado - T-190 Redactar informaci´on de la vista About 2h 1h Completado - T-191 Testing y detecci´on de errores 7h 12h Completado - T-192 Depuraci´on algoritmo b´usqueda ARP 7h 10h Completado - T-189 Dise˜no del nuevo logo y cambio de nombre 3h 5h Completado - T-193 Completar la memoria del proyecto 18h 18h Completado - T-194 Limpiar c´odigo y crear nuevo proyecto git para no a˜nadir datos sensibles 3h 5h Completado TOTAL 40h 51h 6/6 Tabla 7.17: Sprint 17: 31/05/2021 - 06/06/2021 111 7.2. RESUMEN DE EJECUCI ´ ON DEL PROYECTO 7.2. Resumen de ejecuci´on del proyecto Durante la realizaci´on del proyecto, se han realizado 17 sprints de una semana cada uno. En ellos, se han realizado en total 17 historias de usuario, cada una compuesta de sus tareas correspondientes. En este apartado, vamos a contrastar los n´umeros que reflejan las tablas del apartado anterior. En primer lugar, se puede ver a lo largo de estos 17 sprints se han realizado 194 tareas. En total, estas tareas han supuesto un total de 632 horas efectivas, frente a 729 horas estimadas. La diferencia de casi 100 horas reside en que, al realizar los sprints, hay tareas que no se han podido realizar hasta el siguiente y, de esta manera, las tareas ligadas a esas horas no se realizan. En cuanto al n´umero de tareas seg´un su estado, se han contabilizado: Tareas completadas: 165 tareas en total. Tareas en progreso: 12 tareas. Tareas en pausa: 4 tareas (todas se pueden encontrar en el sprint 4, Tabla 7.4). Tareas no iniciadas: 27 tareas que se han trasladado al sprint siguiente. Tareas no realizadas: 2 tareas finalmente no se aplicaron en el c´odigo de la aplicaci´on (se encuentran en el ´ultimo sprint, Tabla 7.17) Para poder hacer una estimaci´on visual sobre qu´e porcentaje de tareas a lo largo de todos los sprints quedaron en cada estado, podemos fijarnos en la Figura 7.1. Figura 7.1: Tareas seg´un su estado 112 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Tambi´en, creo que es interesante comentar cu´antas tareas han sido necesarias para cada Historia de Usuario. En la Tabla 7.18, podemos ver todas las H.U. y, a su lado, el n´umero de tareas que se han realizado asociadas a esa historia. Como se puede ver, la H.U. 5: Tablas ARP es la que m´as tareas ha necesitado. Esto es l´ogico pues, adem´as de ser una de las tareas con m´as Puntos de Historia, sin duda ha sido la que m´as tiempo ha llevado, pues ha necesitado muchas horas para depurar el algoritmo y filtrar los resultados. A su vez, la que menos tareas han necesitado son las H.U. 12: Eliminar configlet, 14: Editar dispositivo, y 16: Mostrar dispositivo. La H.U. 12 es simplemente una llamada a la API envi´andole en un formato espec´ıfico qu´e configlet se quiere eliminar. Como en muchas tareas anteriores ya se hab´ıa trabajado con la API, ya se ten´ıa el conocimiento necesario para realizar estas tareas de forma eficiente. En el segundo caso, esta H.U. se realiz´o despu´es de otras que abrieron camino a la hora de interactuar con la base de datos. De esta manera, el c´odigo y el conocimiento sobre c´omo enviar y recibir peticiones ya estaba hecho. Debido a esto, el c´odigo ya estaba escrito, s´olo hab´ıa que reutilizarlo para la nueva H.U., por lo que el n´umero de tareas es m´as corto. Por otro lado, en cuanto a la H.U. 16, es una historia de usuario muy concreta, por lo que el hecho de que tenga pocas tareas es una consecuencia l´ogica de sus caracter´ısticas. En esta tabla, se debe mencionar tambi´en el caso de la H.U. 13: Logout. En este caso, aunque aparezcan 12 tarea asociadas, en realidad s´olo tiene 2, pues la mayor´ıa de ellas tienen como estado “no inciado”, lo que significa que se pasaron a al siguiente sprint. Una vez hemos hablado del n´umero de tareas, pasemos a fijarnos en las horas empleadas y estimadas en cada Historia de Usuario. En la siguiente tabla (Tabla 7.19) podemos ver estos datos. Al igual que en la tabla anterior, podemos ver que las historias con un mayor n´umero de tareas, tambi´en son las que ocupan un mayor n´umero de horas. Esto tambi´en se aplica a las historias que menos horas ocupan, que se corresponden en general con las historias que menos tareas tienen asociadas. 113 7.2. RESUMEN DE EJECUCI ´ ON DEL PROYECTO H.U. Node tareas 1 22 2 8 3 12 4 17 5 33 6 12 7 13 8 8 9 7 10 4 11 5 12 3 13 12 14 3 15 6 16 3 17 4 Tabla 7.18: Tareas por cada Historia de Usuario H.U. Horas estimadas Horas empleadas 1 45 48 2 20,5 14 3 21,5 19 4 66,5 69,5 5 149,5 133,5 6 50 21 7 67 56 8 23,5 20 9 6 6 10 8 4 11 17 18 12 10 9 13 20 4,5 14 9 7 15 20 19 16 8 7 17 8 11 Tabla 7.19: Horas por cada Historia de Usuario 114 CAP´ ITULO 8. CONCLUSIONES Cap´ıtulo 8 Conclusiones 8.1. Conclusiones A lo largo de este proyecto hemos visto c´omo aplicar soluciones software a un dominio de redes. Al realizar el proyecto he podido comprobar c´omo se desarrollan las actividades de un Ingeniero de Software en un entorno real, con problemas y necesidades reales a trav´es de las herramientas disponibles gracias a los conocimientos adquiridos. Adem´as, creo que ha sido gratificante poder hacerlo de principio a fin, tomando decisiones a lo largo de todo el desarrollo del producto. Personalmente, ha supuesto un reto para m´ı en cuanto a adquirir muchos conocimientos de equipos de redes que no ten´ıa, sobre seguridad y, en especial, haber construido una aplicaci´on desde el dise˜no hasta el producto final por primera vez. Si nos centramos en los objetivos expuestos en el Cap´ıtulo 1.5.2, personalmente creo que he cumplido con el objetivo de aprender a utilizar entornos no conocidos anteriormente como Flask y Vue.js. En mis estudios como Ingeniero de Software nunca me hab´ıa encontrado en esta tesitura de tener que montar un proyecto completamente. Ahora, visto con perspectiva, creo que ha sido un reto bastante motivador y, verlo acabado y funcional, gratificante. Creo que Vue.js es un framework muy potente y que, con bastante seguridad, utilizar´e en el futuro para proyectos personales. Tambi´en he logrado comprender c´omo se gestionan los elementos web, problemas e inconvenientes que pueden surgir a la hora de cambiar la disposici´on de ´estos y qu´e decisiones tomar a la hora de hacer m´as amigable la aplicaci´on de cara al usuario. Aunque el conjunto de experiencia adquirida al realizar este proyecto ha sido claramente positiva, tambi´en he aprendido lo que son los errores dif´ıciles de responder. En especial, los errores CORS mencionados en el Sprint 7.1. Esto me ha ense˜nado que siempre, por muy f´acil que parezca una tarea, si implica comunicaci´on entre entornos, dispositivos o equipos, puede complicarse. A su vez, estos contratiempos tambi´en me han ense˜nado a prever mejor 115 A.1. MANUAL DE USUARIO A.1.2. Vistas de acciones sobre los dispositivos Supongamos que ahora, el usuario, quiere realizar acciones en los dispositivos. Por ejemplo, quiere ver la lista total de todos los dispositivos, sea cual sea el fabricante. Para ello, debe hacer click sobre la opci´on de Todos los dispositivos, en el men´u lateral izquierdo. Una vez realizada esta acci´on, el usuario puede ver una tabla de todos los dispositivos disponibles. En esta vista, representada en la Figura A.5, Figura A.5: Vista All devices, en la que se muestran todos los dispositivos En esta vista, se pueden realizar las siguientes acciones: Buscar un dispositivo en la tabla. Para ello, simplemente tenemos que escribir un dato en la barra de b´usqueda encima de la tabla y s´olo se mostrar´an los dispositivos que tengan alg´un par´ametro cuyo valor coincida con el texto introducido. Ver la configuraci´on de un solo dispositivo. A˜nadir un dispositivo (bot´on azul con un “+”). Borrar uno o varios dispositivos (bot´on con una papelera como icono). Refrescar lista de dispositivos. Editar un dispositivo. Para ello, debemos hacer click en el l´apiz a la derecha de la fila del dispositivo que queramos editar. Para ver la configuraci´on de un dispositivo, se tiene que cumplir la condici´on de haber seleccionado un solo dispositivo. Para eliminar uno o varios dispositivos, debe haber uno o varios dispositivos seleccionados. Como en la Figura A.5 no hay ning´un dispositivo seleccionado, no se pueden realizar estas acciones, pues los botones aparecen deshabilitados. Sin embargo, en la A.6 vemos c´omo hay un dispositivo seleccionado y, en consecuencia, los botones mencionados aparecen habilitados. Si el usuario, por ejemplo, quisiera ver la configuraci´on de uno de los dispositivos de la lista, debe hacer click en el bot´on Mostrar configuraci´on. A continuaci´on, tras un breve 122 AP´ ENDICE A. MANUALES Figura A.6: Vista All devices, con un dispositivo seleccionado tiempo de carga, aparecer´ıa un componente en la parte interior de la pantalla que mostrar´ıa una pesta˜na con una caja de texto donde aparece toda la configuraci´on interna del dispositivo seleccionado. Si el usuario quiere cerrar esta pesta˜na, ´unicamente debe hacer click en el bot´on con una equis negra de la pesta˜na con el nombre del dispositivo. Si quiere ver la configuraci´on de otro dispositivo, simplemente debe seleccionar otro en la tabla y repetir el patr´on. Como esta acci´on es com´un en varias vistas, se explicar´a m´as adelante c´omo mostrar una configuraci´on de un dispositivo o configlet, pues en ambos casos se procede de la misma manera. Supongamos ahora que el usuario quiere a˜nadir un dispositivo a la lista. Para ello, hace click en el bot´on azul con un “+”. Al realizar esta acci´on, sale un dialog pidiendo los datos del nuevo dispositivo a trav´es de un formulario. El formulario tiene varios campos y los botones de Cancelar (se cierra el formulario y se vuelve a la vista anterior), Limpiar (vac´ıa todos los campos del formulario en caso de que haya algo escrito en alguno de ellos) y Confirmar. Este Dialog aparece en la Figura A.7. Una vez que el usuario haya introducido los datos (y estos sean correctos pues, si no, aparecer´a un mensaje de error en el propio dialog indicando qu´e campo es incorrecto), pulsa Confirmar y el dispositivo se incluir´a en la base de datos (si no existe todav´ıa en ´esta). Imaginemos que, por el contrario, lo ´unico que quiere hacer es editar un dispositivo en vez de a˜nadirlo. Quiere, por ejemplo, cambiar el nombre o la IP de uno de ellos. Lo ´unico que debe hacer es click en el l´apiz situado a la derecha de la fila del dispositivo y aparecer´a el mismo Dialog que en el caso anterior pero, esta vez, los campos estar´an rellenos con los valores actuales del dispositivo (Figura A.8. Una vez que el usuario quiera confirmar los cambios de uno o m´as par´ametros, procede igual que en el caso anterior, haciendo click sobre Confirmar. 123 A.1. MANUAL DE USUARIO Figura A.7: Componente para a˜nadir un dispositivo Figura A.8: Componente para editar un dispositivo Por ´ultimo, imaginemos que el usuario quiere eliminar uno o varios dispositivos. Simplemente debe seleccionar los dispositivos deseados en la tabla y, cuando haya al menos uno seleccionado, se habilitar´a el bot´on rojo que tiene una papelera como imagen. Si pulsa sobre ´el, aparecer´a el mismo componente pero mostrando una tabla con los dispositivos a eliminar, 124 AP´ ENDICE A. MANUALES a modo de mensaje de confirmaci´on. Aqu´ı, el usuario puede cancelar la acci´on o confirmarla, elimin´andose as´ı los dispositivos seleccionados. Esta acci´on se muestra en la Figura A.9. Figura A.9: Componente para eliminar dispositivos Con esta ´ultima acci´on concluyen las acciones que puede realizar un usuario sobre los propios dispositivos. A.1.3. B´usqueda en tablas ARP Si el usuario quiere realizar b´usquedas en las tablas ARP, debe hacer click en el bot´on de B´usqueda ARP de la barra lateral. Una vez realice esta acci´on, el usuario ver´a lo que se muestra en la Figura A.10. En esta vista, debe introducir una direcci´on MAC o IP en la barra de b´usqueda, y pulsar el bot´on redondo azul con una lupa. Una vez realice esta acci´on, puede tener lugar uno de los siguientes resultados: Resultado encontrado: se muestra una tabla con los par´ametros del resultado. Resultado no encontrado pero el registro ARP existe: se muestra un mensaje indicando que, efectivamente, el registro ARP existe pero no se encuentra en ning´un dispositivo. Resultado no encontrado: si no se encuentra ning´un registro ARP, se indica al usuario con un mensaje de error. Formato incorrecto: ocurre cuando el usuario introduce una cadena de caracteres inv´alida que no representa ninguna IP o MAC. Se muestra un mensaje indicando de la cadena incorrecta. Si la b´usqueda ha tenido ´exito, la Figura A.11 representa c´omo ser´ıa la tabla donde se muestra el resultado de la b´usqueda. Si se quiere volver a realizar una b´usqueda, se pulsa sobre el bot´on verde y la barra de b´usqueda queda vac´ıa, a la espera de introducir una nueva IP o una nueva MAC. 125 A.1. MANUAL DE USUARIO Figura A.10: Vista para realizar b´usqueda ARP Figura A.11: Vista que muestra un resultado de una b´usqueda ARP A.1.4. Configlets Vamos ahora a hablar sobre las posibles acciones en lo referente a los configlets. Si un usuario quiere ver la lista de configlets disponibles y las acciones sobre ellos, debe hacer click sobre el bot´on Configlets, en el men´u lateral. Una vez en la vista correspondiente, ver´a una lista con los configlets disponibles, adem´as de los siguientes botones: Ver configuraci´on: muestra la configuraci´on del configlet. Aplicar configlets: permite aplicar la configuraci´on de ese configlet a uno o varios dispositivos. Borrar configlets: bot´on con una papelera como icono. Permite borrar los configlets seleccionados. Refrescar lista de configlets: refresca la tabla de configlets. 126 AP´ ENDICE A. MANUALES Figura A.12: Vista que muestra los configlets disponibles. Los botones Ver configuraci´on yAplicar configlets s´olo se mostrar´an activos si hay un solo configlet seleccionado, mientras que el bot´on para eliminar configlets se mostrar´a activo si hay por lo menos uno o m´as configlets seleccionados. Dicho esto, supongamos que el usuario quiere ver la configuraci´on de un configlet. Al pulsar sobre Ver configuraci´on, se mostrar´a bajo la tabla un componente que contiene el c´odigo que representa la configuraci´on del configlet. De esta manera, el usuario puede hacerse una idea de lo que se podr´ıa aplicar en un dispositivo si desea aplicar ese configlet en cuesti´on. La Figura A.13 muestra este componente. Este mecanismo es igual que el explicado anteriormente, por lo que no nos detendremos m´as en explicar c´omo funciona la acci´on de mostrar la configuraci´on. Figura A.13: Configuraci´on de un configlet Los botones de eliminar configlets y refrescar la lista de configlets tienen el mismo funcionamiento que en la vista de los dispositivos, comentada anteriormente. Tampoco nos detendremos en este punto. Una vez comentadas estas acciones, nos queda por ver qu´e pasar´ıa si el usuario quiere 127 A.1. MANUAL DE USUARIO aplicar uno de los configlets disponibles en la lista a los dispositivos que admitan dicha configuraci´on. Una vez seleccionado el configlet en cuesti´on, el usuario debe pulsar el bot´on Aplicar configlets, lo que le llevar´a a la vista representada en la Figura A.14. Figura A.14: Vista para aplicar un configlet a varios dispositivos En esta vista aparecer´a una tabla con los dispositivos que admiten la aplicaci´on de ese configlet y, adem´as, los botones Aplicar configlets yValidar configlets. El primero s´olo se activar´a cuando se haya seleccionado, como m´ınimo, un dispositivo de la lista. Una vez que el usuario identifica en qu´e dispositivos quiere aplicar esa configuraci´on, debe hacer click en dicho bot´on y, como muestra la Figura A.15, aparecer´a un formulario con tantas pesta˜nas como dispositivos seleccionados, cuyas pesta˜nas representan, cada una, a uno de los dispositivos dentro de la selecci´on. Las pesta˜nas se pueden cerrar pulsando el bot´on circular con una equis. Si se desea realizar otra selecci´on, se debe seleccionar las opciones deseadas en la tabla y volver a hacer click sobre Aplicar Configlets. De esta manera, en cada pesta˜na debe introducir los datos que quiera aplicar en la configuraci´on de ese dispositivo en cuesti´on. Como vemos, al desplegarse este formulario, tambi´en se activa el bot´on de Validar configlets. Una vez que el usuario haya introducido todos los datos deseados en cada uno de los dispositivos, debe pulsar en el bot´on Validar configlets para que la plataforma Junos compruebe si la informaci´on introducida puede ser aplicada correctamente en cada dispositivo. En este punto, se pueden dar dos casos: 1. Hay, al menos, una o m´as configuraciones incorrectas. 2. Las configuraciones seleccionadas para todos y cada uno de los dispositivos son correctas. En el primer caso, se muestra un componente con varias p´aginas. Las p´aginas vienen redondeadas con un c´ırculo azul, para ser m´as precisos, en la Figura A.16. Cada gui´on muestra un configlet que se ha validado y podemos hacer click encima de ellos para ir pasando de uno a otro. En la figura, se muestra c´omo se representar´ıa una validaci´on err´onea. En este caso, 128 AP´ ENDICE A. MANUALES Figura A.15: Vista para introducir los par´ametros en cada uno de los dispositivos seleccionados los datos que ha introducido el usuario son incorrectos, por lo que se muestra en rojo un mensaje de error indicando cu´al ha sido el fallo. Si pulsamos sobre otros configlets, podemos ver si ha habido errores o no. Como para aplicar los configlets su validaci´on debe ser correcta, en este caso el bot´on Confirmar se muestra deshabilitado. Si se da el caso en el que todos los configlets se han validado correctamente, el bot´on Confirmar se habilita y todos y cada uno de los resultados salen en verde como se ve en la Figura A.17, mostrando en este componente el c´odigo que se va a inyectar en cada dispositivo seleccionado. Al pulsar este bot´on, se muestra un mensaje al usuario indicando el resultado de la aplicaci´on del configlet a todos los dispositivos. De esta manera, queda explicada la secci´on sobre los configlets y las acciones que un usuario puede hacer sobre ellos. A continuaci´on, vamos a ver la ´ultima secci´on, en la que se explicar´a qu´e puede hacer un usuario sobre los dispositivos disponibles en la plataforma Junos Space. A.1.5. Dispositivos Juniper Supongamos que el usuario quiere realizar la acci´on opuesta a la comentada anteriormente: si se ha explicado los pasos para aplicar un solo configlet en uno o m´as dispositivos, a continuaci´on vamos a ver c´omo aplicar uno o m´as configlets en un solo dispositivo. Al hacer click sobre Configlets en la barra lateral, ir´ıa a una nueva vista. Como vemos en la Figura A.18, se muestran los dispositivos Juniper disponibles en la 129 A.1. MANUAL DE USUARIO Figura A.16: Validaci´on incorrecta de, al menos, un configlet. Figura A.17: Validaci´on correcta de configlets. plataforma Junos Space. Esta vista es muy similar a la descrita para todos los dispositivos, excepto por unas peculiaridades: 1. No se permiten realizar acciones (como a˜nadir, editar, borrar) sobre estos dispositivos. 2. Los campos de las tablas son ligeramente diferentes. 3. Se muestra una columna representando el estado de ese equipo. El c´ırculo verde muestra que el dispositivo est´a activado para operar sobre ´el, mientras que un c´ırculo rojo muestra que el dispositivo no est´a operativo para realizar operaciones sobre ´el. En esta vista, nos encontramos dos botones. El primero de ellos, Ver configuraci´on, nos permite ver la configuraci´on interna del dispositivo. Como lo hemos comentado tanto para las vistas de todos los dispositivos y configlets, vamos a continuar con el siguiente bot´on. Aplicar configuraci´on es el bot´on que nos mostrar´a una lista para ver qu´e configlets est´an disponibles para aplicarse en un dispositivo concreto. Si, por ejemplo, un usuario quisiera 130 AP´ ENDICE A. MANUALES Figura A.18: Dispositivos Juniper aplicar uno o m´as configlets en un dispositivo, tendr´ıa que venir a esta vista, seleccionar el dispositivo en cuesti´on (cuyo estado debe ser disponible, es decir, con el c´ırculo de color verde). Cuando haya seleccionado uno y s´olo uno de los dispositivos de la lista, se habilitar´an los botones y, a continuaci´on, debe pulsar el bot´on Aplicar configuraci´on, lo que nos lleva a la vista mostrada en la Figura A.19. La manera de proceder por parte del usuario, es casi id´entica al caso anterior. En este caso, en vez de mostrar una lista de dispositivos, se mostrar´a una lista de configlets susceptibles de ser aplicables al dispositivo seleccionado. Una vez que se seleccione uno o m´as configlets, si se pulsa Aplicar configlets se mostrar´a un formulario similar al visto anteriormente en la Figura A.15. Sin embargo, esta vez los campos del formulario cambiar´an entre pesta˜nas, pues antes las pesta˜nas simbolizaban la aplicaci´on del mismo configlet pero para distintos dispositivos, por lo que la configuraci´on no cambiaba; sin embargo ahora, cada pesta˜na es un configlet, por lo que la configuraci´on ser´a distinta. El resto del procedimiento es exactamente igual. Una vez que el usuario introduzca los datos deseados en cada pesta˜na, pulsar´a sobre Validar configlets y, seg´un si la validaci´on ha sido correcta o incorrecta, se mostrar´a un componente como el de la Figura A.17 o A.16, respectivamente. Una vez que los datos hayan sido validados correctamente, el usuario pulsar´a Confirmar y un mensaje mostrado por pantalla le informar´a si la aplicaci´on de configlets ha tenido ´exito. 131