Silence/Noise en el ámbito educativo y profesional

TRABAJO FIN DE GRADO Silence/Noise en el ´ambito educativo y profesional Realizado por Fernando Luis Sola Espinosa Para la obtenci´on del t´ıtulo de Grado en Ingenier´ıa Inform´atica - Ingenier´ıa del Software Dirigido por Inmaculada Concepci´on Hern´andez Salmer´on Agust´ın Borrego D´ıaz Realizado en el departamento de Lenguajes y Sistemas Inform´aticos Convocatoria de junio, curso 2020/21 Agradecimientos Quiero agradecer a mis padres por estar ah´ı siempre y apoyarme en todo momento y en cualquier decisi´on. A mis abuelos, Enrique y Paulina que, sin duda, estar´ıan orgullosos de ver d´onde he llegado. A mis amigos y compa˜neros que me han acompa˜nado a lo largo del Grado, cuyo apoyo y amistad no tienen precio. Tambi´en quiero agradecer a Inma y Agust´ın, por su ayuda y comprensi´on; y al grupo de investigaci´on DEAL, por ofrecerme la oportunidad de trabajar con ellos y el fant´astico trato que me han dado desde el primer momento. Resumen Hoy en d´ıa, el desarrollo web es una de las vertientes m´as demandadas en la industria inform´atica a nivel nacional e internacional. Su ense˜nanza en el ´ambito universitario debe mirar por el equilibrio entre, el uso de tecnolog´ıas y frameworks actuales y perdurables, y la asimilaci´on de los conceptos fundamentales de este ´area. Frente a ello, el framework educativo Silence ofrece un entorno unificado para el desarrollo de bases de datos relacionales que den soporte a una aplicaci´on web mediante una API REST, con una filosof´ıa de desarrollo sencillo y ´agil, simplificando esta tarea y diferenciando claramente backend y frontend. En este contexto se enmarca tambi´en la herramienta Noise, que aprovecha la homogeneidad de los proyectos Silence desarrollados por alumnos para desplegarlos en un servidor y facilitar la labor de correcci´on y evaluaci´on por parte del profesorado. En este sentido, se ha trabajado en la implementaci´on de un frontend para este sistema, el cual cuenta con distintas herramientas, m´etricas e indicadores que sirven de ayuda al docente. Por otro lado, se ha realizado un estudio de la idoneidad del uso de Silence en un proyecto comercial real, fuera del ´ambito acad´emico, mediante el an´alisis, dise˜no e implementaci´on de un sistema de informaci´on para una empresa de revisi´on de sistemas contraincendios. Este an´alisis ha demostrado su facilidad de uso, que lo hace id´oneo de cara al alumnado; no obstante, se ha puesto en relieve que carece, a d´ıa de hoy, de ciertas funcionalidades ofrecidas por otros frameworks y, sobre todo, provee pocas herramientas y medios de automatizaci´on para el desarrollo frontend, lo cual lo aleja de ser conveniente para un uso de tipo profesional o comercial. Palabras clave: Desarrollo web, framework, frontend, backend, API REST, docencia. Abstract Nowadays, web development is one of the most demanded areas in Computer Science industry, both locally and internationally. Its teaching on the university sphere must look for the balance between, the use of contemporary and lasting frameworks and technologies, and the comprehension of the basics of the topic. For that reason, the academic framework Silence offers an unified environment for relational databases development which support a web application through an API REST, with a simple and quick development philosophy, simplifying this task and clearly distinguishing backend and frontend. The tool Noise also belongs to this context, as it takes advantage of the homogeneity of the Silence projects developed by students to deploy them on a server and make it easier for lecturers to correct and evaluate them. In that way, work has been done on the implementation of a frontend layer for this system, which has different helpful tools, metrics and indicators to lecturers. On the other hand, a study has been carried out on the suitability of using Silence in a real commercial project, outside the academic environment, through the analysis, design and implementation of an information system for a fire systems revision company. This analysis has demonstrated its ease of use, which makes it ideal for students; however, it has been highlighted that it lacks, for the time being, certain functionalities offered by other frameworks and, above all, it provides few tools and means of automation for frontend development, which makes it far from being suitable for a professional or commercial use. Keywords: Web development, framework, frontend, backend, API REST, teaching. ´ Indice general 1. Introducci´on 1 2. Estudio Previo 3 2.1. Introducci´on................................. 3 2.2. SuiteSilence/Noise............................. 3 2.3. Objetivos .................................. 8 2.4. Metodolog´ıa................................. 9 2.5. Planificaci´on................................. 10 2.6. Presupuesto................................. 11 2.7. Conclusiones................................. 12 3. FrontEnd de Noise 13 3.1. An´alisis y requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Introducci´on y alcance . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Descripci´on de la situaci´on actual . . . . . . . . . . . . . . . . . 14 3.1.2.1. Modelos de procesos actuales . . . . . . . . . . . . . . 14 3.1.3. Necesidades ............................. 21 3.1.3.1. Objetivos ......................... 21 3.1.3.2. Modelos de procesos a implantar . . . . . . . . . . . . 22 3.1.4. Cat´alogo de requisitos del sistema . . . . . . . . . . . . . . . . . 23 3.1.4.1. Requisitos generales . . . . . . . . . . . . . . . . . . . 23 3.1.4.2. Casos de uso del sistema . . . . . . . . . . . . . . . . . 24 3.1.4.3. Requisitos funcionales . . . . . . . . . . . . . . . . . . 29 3.1.4.4. Requisitos no funcionales . . . . . . . . . . . . . . . . 30 3.2. Dise˜no.................................... 31 3.2.1. Diagrama de clases del sistema . . . . . . . . . . . . . . . . . . 31 3.2.2. Diagrama de arquitectura del sistema . . . . . . . . . . . . . . . 32 3.2.3. Diagrama de directorios del sistema . . . . . . . . . . . . . . . . 34 3.2.4. Prototipos de interfaz de usuario del sistema . . . . . . . . . . . 35 3.3. Implementaci´on............................... 39 3.4. Pruebas ................................... 47 3.4.1. PruebasdeAPI........................... 47 3.4.1.1. Dise˜no........................... 47 3.4.1.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.2. Pruebas de navegaci´on . . . . . . . . . . . . . . . . . . . . . . . 49 3.4.2.1. Dise˜no........................... 49 3.4.2.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5. Conclusiones................................. 52 4. Proyecto SuXSur 53 4.1. An´alisis y requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1.1. Introducci´on y alcance . . . . . . . . . . . . . . . . . . . . . . . 53 4.1.2. Objetivos del subproyecto . . . . . . . . . . . . . . . . . . . . . 54 4.1.3. Informaci´on sobre el dominio del problema . . . . . . . . . . . . 55 4.1.3.1. Introducci´on al dominio del problema y marco legal . . 55 4.1.3.2. Glosario de t´erminos del dominio del problema . . . . 55 4.1.4. Descripci´on de la situaci´on actual . . . . . . . . . . . . . . . . . 57 4.1.4.1. “Pros” y “contras” de la situaci´on actual . . . . . . . . 57 4.1.4.2. Modelos de procesos de negocio actuales . . . . . . . . 58 4.1.4.3. Entorno tecnol´ogico actual . . . . . . . . . . . . . . . . 61 4.1.5. Necesidades de negocio . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.5.1. Objetivos ......................... 62 4.1.5.2. Modelos de procesos de negocio a implantar . . . . . . 64 4.1.6. Cat´alogo de requisitos del sistema . . . . . . . . . . . . . . . . . 65 4.1.6.1. Requisitos generales del sistema . . . . . . . . . . . . . 65 4.1.6.2. Casos de uso del sistema . . . . . . . . . . . . . . . . . 66 4.1.6.3. Diagramas de secuencia del sistema . . . . . . . . . . . 73 4.1.6.4. Requisitos funcionales del sistema . . . . . . . . . . . . 82 4.1.6.5. Requisitos no funcionales del sistema . . . . . . . . . . 93 4.1.6.6. Restricciones t´ecnicas del sistema . . . . . . . . . . . . 94 4.2. Dise˜no.................................... 95 4.2.1. Arquitectura l´ogica del sistema . . . . . . . . . . . . . . . . . . 95 4.2.1.1. Diagrama de la arquitectura del sistema . . . . . . . . 95 4.2.1.2. Diagrama de despliegue del sistema . . . . . . . . . . . 96 4.2.2. Modelo de clases del sistema . . . . . . . . . . . . . . . . . . . . 97 4.2.2.1. Diagrama de clases del sistema . . . . . . . . . . . . . 97 4.2.2.2. Diagrama de estado de las clases del sistema . . . . . . 99 4.2.3. Prototipos de interfaz de usuario del sistema . . . . . . . . . . . 100 4.2.4. Interfaz de servicios del sistema . . . . . . . . . . . . . . . . . . 113 4.3. Implementaci´on............................... 117 4.3.1. Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.3.2. Sprint 1 (18 de febrero - 3 de marzo) . . . . . . . . . . . . . . . 119 4.3.2.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 119 4.3.2.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 119 4.3.2.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 119 4.3.2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 121 4.3.3. Sprint 2 (4 de marzo – 17 de marzo) . . . . . . . . . . . . . . . 122 4.3.3.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 122 4.3.3.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 122 4.3.3.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 122 4.3.3.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 125 4.3.4. Sprint 3 (18 de marzo – 31 de marzo) . . . . . . . . . . . . . . . 127 4.3.4.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 127 4.3.4.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 127 4.3.4.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 127 4.3.4.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 130 4.3.5. Sprint 4 (1 de abril – 14 de abril) . . . . . . . . . . . . . . . . . 131 4.3.5.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 131 4.3.5.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 131 4.3.5.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 131 v 4.3.5.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 132 4.3.6. Sprint 5 (15 de abril – 28 de abril) . . . . . . . . . . . . . . . . 133 4.3.6.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 133 4.3.6.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 133 4.3.6.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 133 4.3.6.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 138 4.3.7. Sprint 6 (29 de abril – 12 de mayo) . . . . . . . . . . . . . . . . 139 4.3.7.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . 139 4.3.7.2. Sprint backlog . . . . . . . . . . . . . . . . . . . . . . 139 4.3.7.3. Detalle de la implementaci´on . . . . . . . . . . . . . . 139 4.3.7.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 144 4.4. Pruebas ................................... 145 4.4.1. PruebasdeAPI........................... 145 4.4.1.1. Dise˜no........................... 145 4.4.1.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . 147 4.4.2. Pruebas de navegaci´on . . . . . . . . . . . . . . . . . . . . . . . 148 4.4.2.1. Dise˜no........................... 148 4.4.2.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . 149 4.4.3. Pruebas de aceptaci´on . . . . . . . . . . . . . . . . . . . . . . . 150 4.5. Conclusiones................................. 152 5. Conclusiones y trabajo futuro 153 6. Bibliograf´ıa 154 7. Documentos anexos 155 7.1. Acta de la primera reuni´on con el cliente . . . . . . . . . . . . . . . . . 155 7.2. Acta de la segunda reuni´on con el cliente . . . . . . . . . . . . . . . . . 156 7.3. Acta de la tercera reuni´on con el cliente . . . . . . . . . . . . . . . . . 157 7.4. Acta de la cuarta reuni´on con el cliente . . . . . . . . . . . . . . . . . . 158 7.5. Ejemplo de informe de extintores autogenerado . . . . . . . . . . . . . 159 vi ´ Indice de figuras 2.1. Estructura del framework y proyectos Silence . . . . . . . . . . . . . . . 4 2.2. Modelo relacional de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Directorios de la propuesta frontend de Silence . . . . . . . . . . . . . . 6 2.4. ´ Arbol de directorios de un proyecto de ejemplo Silence . . . . . . . . . 7 2.5. Ejemplo de despliegue de un proyecto . . . . . . . . . . . . . . . . . . . 8 3.1. Ejemplo de despliegue de un proyecto . . . . . . . . . . . . . . . . . . . 15 3.2. Proceso de despliegue de un proyecto . . . . . . . . . . . . . . . . . . . 15 3.3. Ejemplo de detalles de un proyecto . . . . . . . . . . . . . . . . . . . . 16 3.4. Obtenci´on de detalles de un proyecto . . . . . . . . . . . . . . . . . . . 17 3.5. Ejemplo de eliminaci´on de un proyecto . . . . . . . . . . . . . . . . . . 17 3.6. Eliminaci´on de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7. Ejemplo de listado de proyectos . . . . . . . . . . . . . . . . . . . . . . 18 3.8. Listado de todos los proyectos . . . . . . . . . . . . . . . . . . . . . . . 19 3.9. Ejemplo de listado de proyectos activos . . . . . . . . . . . . . . . . . . 19 3.10. Listado de proyectos activos . . . . . . . . . . . . . . . . . . . . . . . . 20 3.11. Nuevo proceso de despliegue de un proyecto . . . . . . . . . . . . . . . 22 3.12. Diagrama de casos de uso del sistema . . . . . . . . . . . . . . . . . . . 24 3.13. Diagrama de clases del sistema . . . . . . . . . . . . . . . . . . . . . . 31 3.14. Diagrama de arquitectura del sistema . . . . . . . . . . . . . . . . . . . 33 3.15. Diagrama de directorios del sistema . . . . . . . . . . . . . . . . . . . . 34 3.16. Mockup de la vista del listado de proyectos . . . . . . . . . . . . . . . . 35 3.17. Mockup de la vista del listado de proyectos activos . . . . . . . . . . . 36 3.18. Mockup de la vista de detalles de un proyecto (1) . . . . . . . . . . . . 37 3.19. Mockup de la vista de detalles de un proyecto (2) . . . . . . . . . . . . 38 3.20. Captura de directorios y archivos implementados . . . . . . . . . . . . 39 3.21. Captura del cuadro de texto de comentarios de un proyecto . . . . . . . 43 3.22. Captura de resultados de los test de API . . . . . . . . . . . . . . . . . 49 3.23. Captura de resultados de los test de interfaz . . . . . . . . . . . . . . . 51 4.1. Proceso de negocio general (2) . . . . . . . . . . . . . . . . . . . . . . . 59 4.2. Proceso de negocio general (1) . . . . . . . . . . . . . . . . . . . . . . . 60 4.3. Proceso de registro de un nuevo administrador con su cliente asociado . 61 4.4. Diagrama de casos de uso del sistema . . . . . . . . . . . . . . . . . . . 66 4.5. Diagrama de secuencia de “Creaci´on de albaranes de revisi´on” . . . . . 73 4.6. Diagrama de secuencia de “Creaci´on de acta de revisi´on” . . . . . . . . 74 4.7. Diagrama de secuencia de “Subrayado de acta de revisi´on” . . . . . . . 75 4.8. Diagrama de secuencia de “Cambio del mes de revisi´on de un cliente” . 75 4.9. Diagrama de secuencia de “Dar de baja o alta a un cliente” . . . . . . . 76 4.10. Diagrama de secuencia de “Revisi´on el acta de revisi´on y generar certificado”.................................... 76 4.11. Diagrama de secuencia de “Generaci´on de presupuesto” . . . . . . . . . 77 4.12. Diagrama de secuencia de “Registro de evento” . . . . . . . . . . . . . 77 4.13. Diagrama de secuencia de “Registro de nuevo administrador” . . . . . . 78 4.14. Diagrama de secuencia de “Registro de nuevo cliente” . . . . . . . . . . 78 4.15. Diagrama de secuencia de “Generaci´on de nuevo contrato” . . . . . . . 79 4.16. Diagrama de secuencia de “Asignaci´on de otro administrador a un cliente” 80 4.17. Diagrama de secuencia de “Acceso a los documentos de los clientes” . . 81 4.18. Diagrama de la arquitectura del sistema a desarrollar . . . . . . . . . . 95 4.19. Diagrama de despliegue del sistema a desarrollar . . . . . . . . . . . . . 96 4.20. Diagrama de clases del sistema . . . . . . . . . . . . . . . . . . . . . . 98 4.21. Diagrama de estado de las clases del sistema a desarrollar . . . . . . . . 99 4.22. Mockup de la vista de login del sistema . . . . . . . . . . . . . . . . . . 100 4.23. Mockup de la vista de inicio . . . . . . . . . . . . . . . . . . . . . . . . 101 4.24. Mockup de la vista de listado de administradores . . . . . . . . . . . . 102 4.25. Mockup de la vista de detalles de un administrador . . . . . . . . . . . 103 4.26. Mockup de la vista de listado de clientes . . . . . . . . . . . . . . . . . 104 4.27. Mockup de la vista de detalles de un cliente . . . . . . . . . . . . . . . 105 4.28. Mockup de la vista de listado de revisiones . . . . . . . . . . . . . . . . 106 4.29. Mockup de la vista de detalles de una revisi´on . . . . . . . . . . . . . . 107 4.30. Mockup de la vista de listado de documentos . . . . . . . . . . . . . . . 108 4.31. Mockup de la vista de listado de documentos de un administrador . . . 109 4.32. Mockup de la vista de listado de revisiones del ingeniero . . . . . . . . 110 4.33. Mockup de la vista de listado de revisiones de un t´ecnico . . . . . . . . 111 4.34. Mockup de la vista de acta de revisi´on de un t´ecnico . . . . . . . . . . 112 4.35. Diagrama de interfaz de servicios del rol gerente . . . . . . . . . . . . . 114 4.36. Diagrama de interfaz de servicios del rol t´ecnico . . . . . . . . . . . . . 115 4.37. Diagrama de interfaz de servicios del rol ingeniero . . . . . . . . . . . . 116 4.38. Diagrama de interfaz de servicios del rol administrador . . . . . . . . . 116 4.39. Listado de clientes con DataTables . . . . . . . . . . . . . . . . . . . . 134 4.40. Modal de generaci´on de revisiones mensuales . . . . . . . . . . . . . . . 136 4.41. Listado de revisiones con asignaci´on de t´ecnicos . . . . . . . . . . . . . 142 4.42. Captura de resultados de los test de API . . . . . . . . . . . . . . . . . 147 4.43. Captura de resultados de los test de navegaci´on . . . . . . . . . . . . . 149 7.1. Anexo: primer acta de reuni´on con el cliente del proyecto SuXSur . . . 155 7.2. Anexo: segunda acta de reuni´on con el cliente del proyecto SuXSur . . 156 7.3. Anexo: tercer acta de reuni´on con el cliente del proyecto SuXSur . . . . 157 7.4. Anexo: cuarta acta de reuni´on con un t´ecnico del cliente del proyecto SuXSur ................................... 158 7.5. Anexo: informe de revisi´on de extintores autogenerado (1) . . . . . . . 159 7.6. Anexo: informe de revisi´on de extintores autogenerado (2) . . . . . . . 160 viii Cap´ıtulo 2. Estudio Previo —Archivos SQL: los proyectos Silence cuentan con una carpeta /sql donde se definen aquellos archivos necesarios para crear la base de datos y poblarla, en caso deseado. —Endpoints: se trata de la propuesta de backend de Silence, enfocada hacia la definici´on sencilla de las rutas de una API REST, mediante el uso de la anotaci´on endpoint que permite difinir la ruta del recurso, el m´etodo HTTP que debe emplearse y la consulta a base de datos asociada, todo ello, en archivos .py dentro del directorio /endpoints. Para la clase Empleado de un modelo relacional como el de la figura 2.2, se podr´ıan tener un par de endpoints para recuperar informaci´on como los de la figura 2.1. Figura 2.2: Modelo relacional de ejemplo @endpoint( route="/employees", method="GET", sql="SELECT *FROM Employees", ) def get_all(): pass @endpoint( route="/employees/$employeeId", method="GET", sql="SELECT *FROM Employees WHERE employeeId = $employeeId", ) def get_by_id(): pass Extracto de c´odigo 2.1: Ejemplos de endpoints definidos en Silence —Archivos web: La propuesta de frontend, no aporta ninguna herramienta de automatizaci´on, sino que se limita a sugerir el uso de una arquitectura web basada en componentes mediante el lenguaje JavaScript puro, sin ninguna otra adici´on m´as all´a de librer´ıas de estilo CSS. Esta arquitectura se basa en la distinci´on 5 Cap´ıtulo 2. Estudio Previo clara de componentes, traducidos en la pr´actica en archivos diferenciados, que cumplen distintas funcionalidades como puede ser el acceso a la API del proyec- to, renderizar en pantalla una entidad del modelo relacional o un formulario de registro o modificaci´on de alguna de ellas; o servir como controlador moderando el flujo de informaci´on y funcionamiento de la aplicaci´on web, figura 2.3. Figura 2.3: Directorios de la propuesta frontend de Silence Con todo ello, para el proyecto Silence de ejemplo de Departamentos y Empleados, resultar´ıa un ´arbol de directorios como el que se puede observar en la figura 2.4. 6 Cap´ıtulo 2. Estudio Previo Figura 2.4: ´ Arbol de directorios de un proyecto de ejemplo Silence Por otro lado, tenemos el proyecto Noise, que est´a enfocado al despliegue y administraci´on de proyectos Silence de los alumnos en un mismo servidor a trav´es de una API RESTful. Noise es, a su vez, un proyecto Silence y su finalidad es proveer un sistema centralizado donde los alumnos puedan desplegar sus proyectos acad´emicos a trav´es de la API que ofrece, de forma que los profesores puedan acceder a ellos para poder evaluarlos de una forma m´as sencilla y homog´enea, teniendo control sobre el despliegue de los proyectos y todos los datos de los mismos. Al comienzo de este proyecto, Noise s´olo era accesible de forma program´atica mediante la mencionada API, figura 2.5. Es por ello, que se abord´o el desarrollo de una capa web que facilite su uso al profesorado. 7 Cap´ıtulo 2. Estudio Previo Figura 2.5: Ejemplo de despliegue de un proyecto 2.3. Objetivos El objetivo principal de este proyecto es validar el uso de la suite Silence/Noise tanto en el ´ambito educativo como en uno profesional. Junto a este, podemos enumerar otros objetivos secundarios, de car´acter docente, t´ecnico o personal: — Proveer al profesorado una herramienta ´util que facilite la labor de correcci´on y evaluaci´on del trabajo realizado por los alumnos. — Ofrecer al alumno una herramienta software adaptada y enfocada a la asimilaci´on de los conceptos y fundamentos del desarrollo web de la forma m´as sencilla y fruct´ıfera posible. — Proveer una capa frontend al sistema Noise, que s´olo pod´ıa ser accedido de forma program´atica mediante la API REST; para facilitar la labor de correcci´on y evaluaci´on al profesorado. — Desarrollar un proyecto real de una envergadura considerable con la inclusi´on de distintas funcionalidades y tecnolog´ıas de exigencia t´ecnica alta. — Estudiar la adecuaci´on e idoneidad del framework Silence para la implementaci´on de proyectos software reales, fuera del ´ambito educativo para el que fue dise˜nado. — Contribuir de forma activa en el desarrollo de la suite Silence/Noise para convertirla en un referente para la docencia de las competencias b´asicas de la Ingenier´ıa del Software y los sistemas de informaci´on. — Ofrecer una soluci´on adaptada y ´util a la empresa SuXSur para mejorar y automatizar sus procesos de negocio. 8 Cap´ıtulo 2. Estudio Previo — Explorar mis l´ımites y estudiar mi desempe˜no y capacidades tras cuatro a˜nos de formaci´on universitaria. — Exponer aquellos conocimientos adquiridos a lo largo del Grado, tanto t´ecnicos como metodol´ogicos, de forma que se aprovechen de forma adecuada y se pongan en pr´actica en un proyecto realista. Como visi´on a alto nivel, se presentan, a continuaci´on, algunas asignaturas previas y los conocimientos impartidos que han sido de utilidad en este proyecto: Asignatura Curso Conocimientos relacionados Introducci´on a la Ingenier´ıa del Software y los Sistemas de Informaci´on Segundo Bases de datos relacionales Arquitectura e Integraci´on de Sistemas Software Segundo Integraci´on de sistemas mediante API REST Dise˜no y Pruebas Tercero Implementaci´on de requisitos y pruebas del software Ingenier´ıa de Requisitos Tercero An´alisis de requisitos y dise˜no de sistemas Proceso Software y Gesti´on Tercero Metodolog´ıas tradicionales y ´agiles Planificaci´on y Gesti´on de Proyectos Inform´aticos Cuarto Planificaci´on de proyectos, tiempos, costes, fases y tareas de proyectos 2.4. Metodolog´ıa En la ejecuci´on del presente proyecto, se opt´o por un enfoque h´ıbrido en cuan- to a las t´ecnicas y m´etodos de organizaci´on a emplear, dadas las caracter´ısticas del mismo: divisi´on en dos subproyectos a abordar por una ´unica persona y que, durante ciertos periodos, se sobrepon´ıan temporalmente. Todo esto ligado a las restricciones temporales e irregularidades en la dedicaci´on debidas al estudio de otras asignaturas de alta exigencia durante el desarrollo de este proyecto, motiva que se hayan realizado adaptaciones de las metodolog´ıas ´agiles y coexistencia con tradicionales en otros momentos. Por un lado, para el primer subproyecto, el frontend de Noise, se emple´o un acercamiento tradicional de ciclo de vida en cascada: an´alisis, dise˜no, implementaci´on y pruebas. Esto se debi´o, principalmente, a que se trataba de una problem´atica de menor envergadura, que resultaba m´as sencilla de abordar por una ´unica persona organizada en las distintas fases mencionadas y donde las ideas ´agiles habr´ıan supuesto un obst´aculo o molestia realmente. Por otro lado, para el proyecto SuXSur, de car´acter real y una envergadura mucho mayor, se opt´o por el uso de la metodolog´ıa ´agil Scrum, que aboga por un an´alisis previo de los requisitos, de forma que se prioricen y ordenen. Adem´as, como parte de esta fase previa se realiz´o el dise˜no del sistema a implementar, por lo que comenz´o a emplearse las indicaciones de Scrum en la etapa de implementaci´on, organizada en seis sprints 9 Cap´ıtulo 2. Estudio Previo en los que se trataron las tareas m´as prioritarias. Dentro de estos sprints se prescindi´o de los procesos de sprint review y sprint retrospective, que al tratarse de un proyecto individual adaptado, poco valor habr´ıan tenido, aunque s´ı se tom´o la idea de la revisi´on con el cliente del valor generado tras cada sprint, aunque esto s´olo pudo realizarse en algunos concretos por limitaciones de agenda. En cuanto a las figuras de Product Owner o Scrum master, carec´ıan de sentido por las circunstancias descritas. 2.5. Planificaci´on El esfuerzo temporal a realizar hasta completar las trescientas horas estipuladas para un Trabajo de Fin de Grado fue dividido entre las dos partes de las que este consta, siendo unas cien para la parte del frontend de Noise y las doscientas restantes para el proyecto SuXSur. Para la primera parte se estim´o una divisi´on temporal en fases como la que se propone en la tabla siguiente, junto a los tiempos que finalmente se dedicaron: Fase Dedicaci´on estimada Dedicaci´on real Estudio previo 10 horas 8,2 horas An´alisis 10 horas 4,6 horas Dise˜no 15 horas 7,9 horas Implementaci´on 50 horas 36,9 horas Pruebas 10 horas 7,6 horas Redacci´on de la memoria 5 horas 7,1 horas Total 100 horas 72,3 horas En cuanto a la segunda parte, presentamos las estimaciones iniciales por cada una de las fases a realizar, y el tiempo que se emple´o finalmente: Fase Dedicaci´on estimada Dedicaci´on real Estudio previo 5 horas 2 horas An´alisis 15 horas 15,6 horas Dise˜no 25 horas 25,8 horas Implementaci´on 120 horas 150,36 horas Pruebas 20 horas 14,83 horas Redacci´on de la memoria 15 horas 41,4 horas Total 200 horas 250 horas La fase de implementaci´on de esta segunda parte del proyecto se abord´o mediante el uso de la metodolog´ıa ´agil Scrum, de forma que se definen, a continuaci´on los seis sprints que se ejecutaron, todos ellos con una duraci´on de dos semanas y una estimaci´on de dedicaci´on de alrededor de veinte horas, de forma que se cubrieran las 120 horas de desarrollo estimadas: 10 Cap´ıtulo 2. Estudio Previo Iteraci´on D´ıa de inicio - D´ıa de fin Dedicaci´on real Sprint 1 18 de febrero - 3 de marzo 32,1 horas Sprint 2 4 de marzo - 17 de marzo 24,7 horas Sprint 3 18 de marzo - 31 de marzo 14,2 horas Sprint 4 1 de abril - 14 de abril 24,2 horas Sprint 5 15 de abril - 28 de abril 21,16 horas Sprint 6 29 de abril - 12 de mayo 34 horas Total 150,36 horas Como puede observarse, la planificaci´on temporal prevista se desv´ıa de la dedicaci´on real en cuanto a que se invirti´o finalmente menos tiempo en el subproyecto frontend de Noise, el cual se dedic´o al proyecto SuXSur, cuya implementaci´on super´o las previsiones iniciales debido, esencialmente, a la propuesta de desarrollo frontend de Silence, como se concluye en el cap´ıtulo cuarto [4.5]. Adem´as, se super´o de forma clara la estimaci´on del tiempo dedicado a la redacci´on de la memoria, que al desarrollarse en L A T EX, consumi´o m´as tiempo del previsto. Con todo ello, las 300 horas planificadas supusieron, finalmente, un total de 322,3 horas dedicadas. 2.6. Presupuesto El c´alculo de los costes del presente proyecto tendr´a en cuenta varias partidas cuyo importe depender´a en mayor o menor medida de la dedicaci´on empleada en ´el. En primer lugar, los costes de personal, para un desarrollador contratado a jornada completa con una retribuci´on anual de unos 30.000 euros, a lo que sumado los costes de IRPF y Seguridad Social, suponen un coste total mensual de 38.970 euros, es decir, 20,3 euros por hora trabajada. Por otro lado, dentro de los costes de equipos y suministros, se deben incluir los de amortizaci´on del equipo empleado, con un coste inicial de 680 euros con una vida ´util estimada de cuatro a˜nos, es decir, 48 meses, y ocho meses de uso para el proyecto; el suministro el´ectrico del equipo, con un consumo estimado de unos 220W/hora y un coste medio del kilovatio por hora de 0,20 c´entimos de euro; y el suministro de conexi´on a internet, con una tarifa mensual de 55 euros mensuales. Finalmente, se establece un coste de reservas de riesgo para solventar cualquier incidencia que hubiera acontecido durante el desarrollo del proyecto, de un diez por ciento del total de los costes. Con todo ello, los costes previstos ascienden a un total de 6863,38 euros: 11 Cap´ıtulo 2. Estudio Previo Partida C´alculo Total Coste de personal 20,3 e/h x 300 horas 6.090 e Amortizaci´on del equipo 680 e/48 meses x 8 meses de proyecto 113,33 e Suministro el´ectrico 0,220kWh x 0,20 ex 300 horas 13,2 e Conexi´on a internet 55 e/ 720horas/mes x 300 horas 22,91 e Total parcial 6.239,44 e Reservas (10 %) 693,95 e Total 6.863,38 e Los costes incurridos finalmente, tras la ejecuci´on del proyecto, fueron: Partida C´alculo Total Coste de personal 20,3 e/h x 322,3 horas 6.542,69 e Amortizaci´on del equipo 680 e/48 meses x 8 meses de proyecto 113,33 e Suministro el´ectrico 0,220kWh x 0,20 ex 322,3 horas 14,18 e Conexi´on a internet 55 e/ 720horas/mes x 322,3 horas 24,62 e Gastos finales 6.694,82 e Total previsto (con reservas) 6.863,38 e Super´avit en costes 168,56 e Se concluye, por tanto, se ha producido una desviaci´on positiva del 2,46 por ciento en cuanto a los costes incurridos frente a los previstos, la cual es posible gracias al fondo de reserva del diez por ciento previsto frente a contingencias. 2.7. Conclusiones En esta secci´on se han expuesto distintos aspectos que fueron contemplados de forma previa al inicio del presente proyecto, definiendo las metodolog´ıas y directrices b´asicas que se siguieron a lo largo del mismo. 12 3. FrontEnd de Noise 3.1. An´alisis y requisitos 3.1.1. Introducci´on y alcance En este subapartado del proyecto se trata el dise˜no e implementaci´on de una capa de interfaz web o frontend para el proyecto Noise, el cual se basa en el framework de fin educativo y docente Silence, y cuyo objetivo es el despliegue de otros proyectos desarrollados en base a dicho framework. En primer lugar, hay que se˜nalar que Noise funciona mediante una API REST que ofrece al usuario las funcionalidades que tiene. Nuestro objetivo es facilitar la interacci´on con dicha capa de acceso program´atico, en la parte de administraci´on de los proyectos, a trav´es de una aplicaci´on web desplegada en el mismo Noise. Los alumnos podr´an acceder al sistema Noise desplegado en un servidor de la escuela a trav´es de la API que les proporcionar´a las operaciones de: deploy, es decir, desplegar sus propios proyectos Silence indicando una URL con el alojamiento del mismo en GitHub; obtener la informaci´on de su proyecto con el identificador del mismo que se le indica al ser desplegado; y la operaci´on de delete en caso de que deseen eliminar el proyecto que previamente han desplegado, indicando su identificador ´unico. Por otro lado, el profesorado tiene otras operaciones disponibles, s´olo para usuarios registrados: listar todos los proyectos o ´unicamente aquellos que est´en activos. A estas dos operaciones, se les a˜nadir´a la de acceder a los detalles de los proyectos y la de eliminarlos. Es en este punto donde se sit´ua este proyecto, que se centrar´a en la confecci´on de esta capa web sobre la API para el profesorado de forma que sea m´as sencillo e intuitivo acceder a sus funcionalidades y facilitar su labor de evaluaci´on y correcci´on de los proyectos desarrollados por el alumnado. Quedar´a fuera del alcance de este subproyecto el desarrollo de la interfaz para los alumnos, puesto que se cree, es m´as pedag´ogico, utilicen Noise para desplegar sus proyectos Silence mediante la API REST en lugar de a trav´es de una capa web. Cap´ıtulo 3. FrontEnd de Noise 3.1.2. Descripci´on de la situaci´on actual 3.1.2.1. Modelos de procesos actuales Descripci´on de actores actuales —Alumnos: estudiantes de la escuela que hacen uso del sistema Noise para desplegar, a trav´es de la API REST que ofrece, los proyectos Silence que desarrollan en distintas asignaturas. —Profesores: docentes que ponen el sistema a disposici´on de los alumnos y que lo usan para poder evaluar su trabajo, accediendo, tambi´en, a trav´es de una API REST. —Sistema Noise: se trata del propio sistema en cuesti´on, que recibe peticiones HTTP y ofrece las funcionalidades de despliegue y almacenamiento de los proyectos de los alumnos. Descripci´on de procesos actuales —Despliegue de un proyecto El proceso de despliegue de un proyecto lo lleva a cabo un alumno, que debe tenerlo alojado en su repositorio de GitHub previamente. A continuaci´on, deber´a realizar una petici´on HTTP de tipo POST al endpoint /deploy del sistema Noise, indicando con una cabecera que el cuerpo del mensaje es formato JSON para, en ´el, incluir una cadena de este formato donde se indique el campo url, cuyo valor ser´a la direcci´on a GitHub donde se encuentra el proyecto, figura 3.1. Si la operaci´on no puede completarse porque la url proporcionada no es v´alida, se devolver´a una respuesta de error y el alumno deber´a revisar y reintentar la operaci´on. Sin embargo, si la direcci´on al repositorio es correcta, Noise desplegar´a el proyecto y devolver´a al alumno un mensaje de ´exito con el identificador del despliegue de este, figura 3.2. En el caso de que se desee volver a desplegar un proyecto que ya lo est´a, digamos, actualizarlo a la ´ultima versi´on existente en su repositorio de GitHub, no es necesario eliminarlo primero, sino que se sigue este mismo proceso y una versi´on sobrescribe a la otra. Debemos aclarar, que un profesor, tambi´en podr´a realizar este proceso en las mismas condiciones que lo hace un alumno. 14 Cap´ıtulo 3. FrontEnd de Noise 3.1.3. Necesidades 3.1.3.1. Objetivos HU-001: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder listar todos los proyectos almacenados en el sistema Noise en una interfaz web Para facilitar mi labor de revisi´on y evaluaci´on de proyectos. HU-002: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder listar todos los proyectos activos actualmente almacenados en el sistema Noise en una interfaz web Para poder ahorrar tiempo y tener una mejor experiencia de uso de Noise. HU-003: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder acceder a los datos concretos de cada uno de los proyectos almacenados en el sistema Noise a trav´es de una interfaz web Para poder ahorrar tiempo y tener una mejor experiencia de uso de Noise. HU-004: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder eliminar los proyectos de alumnos almacenados en el sistema Noise a trav´es de varios clics y un bot´on que me lo permita Para poder ahorrar tiempo y tener una mejor experiencia de uso de Noise. HU-005: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder ordenar la lista de los proyectos de mis alumnos por los distintos campos de estos Para poder ahorrar tiempo y facilitar mi tarea de revisi´on o correcci´on. HU-006: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder efectuar b´usquedas por los distintos campos de los proyectos de los alumnos Para poder ahorrar tiempo encontrando el proyecto de un alumno concreto f´acilmente. HU-007: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder tener informaci´on de la frecuencia con la que el alumno ha ido trabajando en su proyecto Para poder tener una mayor idea del esfuerzo real realizado por el alumno. 21 Cap´ıtulo 3. FrontEnd de Noise HU-008: Como profesor del departamento Lenguajes y Sistemas Inform´aticos Quiero poder realizar anotaciones durante mi revisi´on del proyecto del alumno Para facilitar mi labor de correcci´on y evaluaci´on. 3.1.3.2. Modelos de procesos a implantar Descripci´on de actores a implantar En principio, los actores que intervendr´an ser´an los mismos que los que hay en la situaci´on inicial. Descripci´on de procesos a implantar En primer lugar, el proceso de despliegue de un proyecto se ver´a ligeramente modificado, de forma que, durante el mismo, a la vez que se descarga del correspondiente repositorio de GitHub y se lanza en la m´aquina servidora, se acceder´a a la API REST que ofrece dicho servicio para obtener la informaci´on de los commit realizados por el alumno en su proyecto de curso, de forma que estos datos puedan ser de utilidad posteriormente, figura 3.11. Figura 3.11: Nuevo proceso de despliegue de un proyecto 22 Cap´ıtulo 3. FrontEnd de Noise En segundo lugar, el proceso de mostrar los detalles de un proyecto, por parte del profesor, a˜nadir´a a la informaci´on mostrada, alguna que muestre el esfuerzo y ritmo de trabajo del alumno, mediante una combinaci´on de los datos recogidos en el acceso a la API de GitHub durante el despliegue del proyecto. El resto de procesos ser´an esencialmente los mismos, s´olo que todos ellos, a excepci´on del despliegue de un nuevo proyecto en Noise, ser´an realizables por el profesorado a trav´es de una interfaz web, quedando, por tanto, sujetos a los mismos condicionantes que fueron descritos en ep´ıgrafes anteriores. 3.1.4. Cat´alogo de requisitos del sistema 3.1.4.1. Requisitos generales —RG-01: El sistema deber´a gestionar los proyectos de los alumnos almacenados. —RG-02: El sistema deber´a gestionar los proyectos actualmente activos almacenados. —RG-03: El sistema deber´a permitir acceder a los detalles de cada uno de los proyectos registrados. —RG-04: El sistema deber´a permitir detener y eliminar los proyectos registrados. —RG-05: El sistema deber´a permitir ordenar los proyectos listados por distintos criterios. —RG-06: El sistema deber´a permitir realizar b´usquedas por los distintos campos de los proyectos. —RG-07: El sistema deber´a restringir el acceso a alumnos a las funcionalidades de gesti´on de los proyectos reservadas para profesores. —RG-08: El sistema deber´a permitir la paginaci´on de la lista de proyectos. —RG-09: El sistema deber´a ofrecer informaci´on de commits y despliegues de los proyectos. —RG-10: El sistema deber´a ofrecer una secci´on de comentarios y anotaciones en la p´agina de detalles de cada proyecto. 23 Cap´ıtulo 3. FrontEnd de Noise 3.1.4.2. Casos de uso del sistema Diagramas de casos de uso Figura 3.12: Diagrama de casos de uso del sistema Especificaci´on de actores del sistema —ACT-01: Profesor: docente que pone el sistema a disposici´on de los alumnos y que lo usa para poder evaluar su trabajo. —ACT-02: Sistema Noise: se trata del propio sistema en cuesti´on, que recibe peticiones HTTP y ofrece las funcionalidades de despliegue y almacenamiento de los proyectos de los alumnos. 24 Cap´ıtulo 3. FrontEnd de Noise Especificaci´on de casos de uso del sistema CU-01 Listar todos los proyectos Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide listar los proyectos Silence desplegados por sus alumnos. Para ello, dicho actor accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Projects”. El Sistema Noise (ACT-02) cargar´a los proyectos registrados y los listar´a exitosamente. Postcondici´on Los proyectos existentes son visibles en forma de lista por el actor Profesor (ACT-01). Excepciones - CU-02 Listar proyectos activos Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide listar los proyectos Silence desplegados por sus alumnos y que actualmente se encuentren activos, esto es, tengan un “port” asignado. Para ello, dicho actor accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Active projects”. El Sistema Noise (ACT-02) cargar´a los proyectos activos y los listar´a exitosamente. Postcondici´on Los proyectos activos son visibles en forma de lista por el actor Profesor (ACT-01). Excepciones - 25 Cap´ıtulo 3. FrontEnd de Noise CU-03 Acceder a los detalles de un proyecto Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide acceder a los datos de un proyecto desplegado por un alumno. Para ello, el actor Profesor (ACT-01) accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y entra a la secci´on de “Active projects” o “Projects”. A continuaci´on, elegir´a en la lista el proyecto que desee, haciendo clic sobre su id. Ser´a redireccionado a la p´agina de detalles del mismo, donde el Sistema Noise (ACT-02) mostrar´a el resto de los datos que no son ofrecidos en la vista de lista. Postcondici´on Los datos de un proyecto concreto son visibles en forma de tabla por el actor Profesor (ACT-01). Excepciones - CU-04 Eliminar un proyecto Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide eliminar un proyecto Silence desplegado por un alumno. Para ello, el actor Profesor (ACT-01) accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Active projects” o “Projects”. A continuaci´on, elegir´a en la lista el proyecto que desee, haciendo clic sobre su id. Ser´a redireccionado a la p´agina de detalles del mismo, donde el Sistema Noise (ACT-02) mostrar´a un bot´on de “Delete”. Al clicar sobre ´el, se abrir´a una alerta donde se confirme la voluntad de realizar esta acci´on y pulsar´a “Confirmar”. Postcondici´on El proyecto deseado ha sido detenido y eliminado del sistema, haciendo que ya no aparezca en el listado de los proyectos. Excepciones - 26 Cap´ıtulo 3. FrontEnd de Noise CU-05 Ordenar el listado de proyectos Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide ordenar los proyectos Silence desplegados por los alumnos. Para ello, el actor Profesor (ACT-01) accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Active projects” o “Projects”. A continuaci´on, elegir´a el criterio mediante el cual quiere ordenar los proyectos listados entre “Port”, “Project Id”, “Repository”, “Uvus”, “Commits” o “Deployments”. Clicar´a sobre una de las dos flechas que se encuentran junto a cada una de las cabeceras de cada criterio, de forma que una ordene de forma ascendente y la otra descendente. El Sistema Noise (ACT-02) aplicar´a el criterio de ordenaci´on seleccionado. Postcondici´on El actor Profesor (ACT-01) visualiza el listado de los proyectos ordenados por el criterio que ha seleccionado. Excepciones - CU-06 Buscar un proyecto concreto Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide buscar un proyecto Silence desplegado por un alumno. Para ello, el actor Profesor (ACT-01) accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Active projects” o “Projects”. A continuaci´on, elegir´a el campo mediante el cual quiere realizar la b´usqueda, entre “Port”, “Project Id”, “Repository” y “Uvus”; a trav´es de un desplegable. Deber´a escribir en un campo de texto el valor del campo que desea buscar y pulsar “Enter”. El Sistema Noise (ACT-02) aplicar´a la b´usqueda solicitada. Postcondici´on El actor Profesor (ACT-01) visualiza el listado de los proyectos que cumplen el criterio que ha seleccionado y especificado. Excepciones - 27 Cap´ıtulo 3. FrontEnd de Noise CU-07 Tomar anotaciones de un proyecto Precondici´on Los alumnos han subido alg´un proyecto a Sistema Noise (ACT-02) y el actor Profesor (ACT-01) posee una cuenta de acceso. Descripci´on El Sistema Noise (ACT-02) deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Profesor (ACT-01) decide revisar un proyecto Silence desplegado por un alumno. Para ello, el actor Profesor (ACT-01) accede al Sistema Noise (ACT-02), inicia sesi´on en ´el y accede a la secci´on de “Active projects” o “Projects”. A continuaci´on, seleccionar´a un proyecto, acceder´a a su despliegue y a su p´agina de detalles. Dentro de esta ´ultima anotar´a las distintas ideas de inter´es que encuentre durante su revisi´on en un cuadro de texto habilitado para ello. El Sistema Noise (ACT-02) guardar´a autom´aticamente el texto introducido cuando deje de teclearse. Postcondici´on El actor Profesor (ACT-01) dispone de las anotaciones realizadas para poder evaluar al alumno o consultarlas durante la defensa del proyecto. Excepciones - 28 Cap´ıtulo 3. FrontEnd de Noise 3.1.4.3. Requisitos funcionales Requisitos de informaci´on —RI-01: Informaci´on de commits El sistema deber´a almacenar los datos de los commits de un proyecto: Id del commit. Autor. Fecha de creaci´on. Mensaje de commit. N´umero de l´ıneas a˜nadidas. N´umero de l´ıneas eliminadas. Proyecto al que pertenece. —RI-02: Informaci´on de alumnos de cada profesor El sistema deber´a almacenar los datos de los alumnos de cada profesor: Uvus del alumno. Requisitos de conducta RC-01: Mostrar proyectos El sistema deber´a mostrar, a petici´on del profesor, todos los proyectos desplegados en el sistema o ´unicamente aquellos que se encuentren activos. RC-02: Ordenar proyectos El sistema deber´a ordenar, a petici´on del profesor, los proyectos listados seg´un el criterio m´as conveniente en cada caso. RC-03: Buscar proyectos El sistema deber´a permitir, a petici´on del profesor, buscar mediante un criterio, los proyectos que se ajusten a ´el. RC-04: Detalles de un proyecto El sistema deber´a mostrar, a petici´on del profesor, los detalles espec´ıficos de cada proyecto, as´ı como indicadores de esfuerzo y trabajo dedicados por el alumno. 29 Cap´ıtulo 3. FrontEnd de Noise RC-05: Anotaciones sobre un proyecto El sistema deber´a permitir, a petici´on del profesor, tomar notas y apuntes sobre cada uno de los proyectos, de forma que se almacene esta informaci´on y sea consultable posteriormente. RC-06: Detener un proyecto El sistema deber´a detener y eliminar, a petici´on del profesor, el despliegue de cualquier proyecto subido por los alumnos. 3.1.4.4. Requisitos no funcionales Requisitos de seguridad del sistema RS-01: Seguridad ante accesos indebidos El sistema deber´a ser seguro ante accesos al mismo por parte de individuos que no deban hacerlo, especialmente alumnos. 30 Cap´ıtulo 3. FrontEnd de Noise Figura 3.18: Mockup de la vista de detalles de un proyecto (1) 37 Cap´ıtulo 3. FrontEnd de Noise Figura 3.19: Mockup de la vista de detalles de un proyecto (2) 38 Cap´ıtulo 3. FrontEnd de Noise 3.3. Implementaci´on La obtenci´on de la informaci´on de commits del repositorio del alumno se realiza gracias a la API que ofrece GitHub [7]. Estos datos recibidos en formato JSON se procesan y almacenan en la base de datos con la que Noise trabaja, MariaDB, en este caso. Este proceso consta de una adici´on sencilla de c´odigo a aquel ya existente en el sistema y que se corre cuando el alumno solicita el despliegue de su proyecto. En cuanto a la implementaci´on del frontend previsto, ha resultado en la estructura de archivos de la figura 3.20. Figura 3.20: Captura de directorios y archivos implementados De ellos, las funcionalidades de login,index,footer yheader ven´ıan provistas por el framework Silence, aunque han sido sujeto de modificaciones. El resto de los archivos principales, siguen la misma l´ınea que se defini´o en el apartado de la fase de dise˜no de la soluci´on, concretamente en el diagrama de directorios del sistema. 39 Cap´ıtulo 3. FrontEnd de Noise Comentamos brevemente la implementaci´on realizada, ´ıntegra en c´odigo JavaS- cript y HTML, del flujo de informaci´on que sucede cuando se muestra una de las tres vistas principales, la de detalles de un proyecto, por ser esta la de m´as f´acil compresi´on y tener las ideas esenciales aplicables a las otras dos. En primer lugar, tenemos el archivo project details.html que no es m´as que un archivo base con la estructura b´asica de la vista y donde tenemos importadas distintas librer´ıas como las de estilos y los archivos .js necesarios, as´ı como varios div donde, posteriormente se incluir´a la informaci´on obtenida de la API y formateada por los renderers, figura 3.1. <body> <div id="page-header"></div> <div class="container"> <div class="row" id="errors"></div> <div id="project"></div> </div> <div id="page-footer"></div> <script> include("header.html", "#page-header"); include("footer.html", "#page-footer"); </script> <script type="module" src="js/header.js"></script> <script type="module" src="js/project_details.js"></script> </body> Extracto de c´odigo 3.1: Extracto de project details.html Como hemos dicho, al acceder a este archivo, se cargar´a el script de project - details.js, cuya funcionalidad viene dada por las l´ıneas de la figura 3.2. projectsAPI.getById(projectId) .then(project => { let table = projectRenderer.asDetails(project); projectCont.appendChild(table); loadDeleteButton(); }) Extracto de c´odigo 3.2: Extracto de project details.js En ellas, se obtiene la informaci´on del proyecto de identificador “projectId” a trav´es del m´etodo getById del archivo projects.js de la carpeta api. Esta informaci´on se entrega al m´etodo asDetails del archivo projects.js de la carpeta 40 Cap´ıtulo 3. FrontEnd de Noise renderers, que devolver´a un c´odigo HTML que ser´a incluido en el div de identificador “projects” (identificado en este trozo de c´odigo con la variable projectCont) del archivo HTML base. En cuanto al acceso a la API REST mediante el archivo projects.js de la carpeta api, se realiza como se muestra en la figura 3.3. getById: function (projectId) { return new Promise(function (resolve, reject) { axios .get(‘${BASE_URL}/projects/${projectId}‘, requestOptions) .then(response => resolve(response.data.project)) .catch(error => reject(error.response.data)); }); }, Extracto de c´odigo 3.3: Extracto de project.js de la carpeta /api El m´etodo se basa en una “promise” de JavaScript para realizar una petici´on GET a la URL indicada entre par´entesis, y devolver´a el contenido del JSON de la respuesta correspondiente al proyecto solicitado. Una vez se tiene esta informaci´on, como se ha explicado se entrega al “renderer” que la tratar´a de la forma mostrada en la figura 3.4. 41 Cap´ıtulo 3. FrontEnd de Noise asDetails: function (project1) { let html = ‘<table class="table"> <tbody> <tr> <td class="success">Deployment date: </td> <td>${project1.date}</td> </tr> <tr> <td class="success">Project ID: </td> <td>${project1.projectId}</td> </tr> [...] <tr> <td class="success">UVUS: </td> <td>${project1.uvus}</td> </tr> <tr> <td> <div class="btn btn-danger"> <span id="project-delete-button" class=" clickable"> <i class="fa fa-trash"></i> Delete</ span> </div> </td> <td></td> </tr> </tbody> </table>‘; let table = parseHTML(html); return table; }, Extracto de c´odigo 3.4: Extracto de project.js de la carpeta /renderers Se encargar´a de generar un trozo de c´odigo HTML que contiene una tabla donde se muestran todos los detalles del proyecto, se entrega a un “parser” y se devuelve el resultado que este arroja. Todo este proceso de funcionamiento, como se ha comentado, es aplicable a las vistas de proyectos y proyectos activos, s´olo que a˜naden otros elementos como la paginaci´on de los resultados que se muestran que, no a˜naden valor a esta explicaci´on, y habr´ıa dificultado la compresi´on del proceso y extendido innecesariamente estos p´arrafos. Finalmente, se cree de inter´es mostrar la implementaci´on realizada para mostrar un ´area de texto donde los profesores puedan tomar notas sobre el proyecto del alumno, y estas se guarden de forma autom´atica al dejar de escribir, figura 3.21. 42 Cap´ıtulo 3. FrontEnd de Noise Figura 3.21: Captura del cuadro de texto de comentarios de un proyecto Para ello, es necesario, en primer lugar, renderizar un formulario con un “textarea” donde se carguen comentarios guardados de forma previa, figura 3.5. // Load project comments let promise = projectsAPI.getCommentsById(projectId).then(comments => { let commentsForm = projectRenderer.commentsArea(projectId, comments); commentsCont.appendChild(commentsForm); }).catch(error => messageRenderer.showErrorMessage(error)); Extracto de c´odigo 3.5: Renderizado del “textarea” y carga de comentarios previos La carga de comentarios previos se realiza mediante un m´etodo getComments- ById de JavaScript, basado en promesas, que accede a un endpoint de la API dise˜nado para acceder al sistema de archivos y obtener el contenido de un archivo .txt donde se almacenan los comentarios del proyecto en cuesti´on, figura 3.6. De esta forma, estas anotaciones no son almacenadas en base de datos, sino en archivos de texto plano como lenguaje tipado HTML, facilitando as´ı la tarea de reinicio del sistema Noise, en caso de que fuera necesario, sin perder anotaciones realizadas. 43 Cap´ıtulo 3. FrontEnd de Noise @endpoint( route="/comments/$projectId", method="GET", sql="select $projectId", # dummy SQL auth_required=True ) def get_comments(): projectId = request.url.split("/")[-1] project = dal.query("SELECT *FROM Deployments WHERE projectId = %s", (projectId,)) if not project: raise HTTPError(404, "Proyecto no encontrado") file_path = "teachers_comments/"+project[0]["uvus"]+".txt" comments_body = "" if os.path.exists(file_path): with open(file_path, "r") as fh: comments_body = fh.read() response = {"comments_body": comments_body} raise HTTPError(202, payload=response, message="Accepted") Extracto de c´odigo 3.6: Endpoint de recuperaci´on de anotaciones de un proyecto A continuaci´on, una vez se tiene renderizado el formulario con el contenido del “textarea”, se carga la funcionalidad del cuadro editor de texto mediante la librer´ıa CKEditor [6], definiendo un evento “change” que se encargar´a de guardar los datos de forma automatizada cuando el texto contenido en el editor cambie, adem´as de mostrar un mensaje que lo indica, figura 3.7. 44 Cap´ıtulo 3. FrontEnd de Noise // Auto save lecturer comments let commentsAutoSaveMessage = document.getElementById("auto-save- message"); var typingTimer; var doneTypingInterval = 3000; let editor; ClassicEditor .create( document.getElementById("comments_body")) .then( newEditor => { editor = newEditor; editor.model.document.on(’change’, () => { clearTimeout(typingTimer); typingTimer = setTimeout(doneTyping, doneTypingInterval); } ); }) .catch( error => { console.error( error ); } ); function doneTyping () { commentsAutoSaveMessage.innerHTML = "Saving changes..."; handleCommentsForm(editor.getData()); } Extracto de c´odigo 3.7: Carga del editor de texto Por otro lado, se tiene el m´etodo invocado por el evento de cambio en el texto, el que se encarga de realizar la llamada al endpoint correspondiente, en el cual se aprovecha para dar unos segundos antes de cambiar el mensaje de autoguardado a “Saved”, figura 3.8. El endpoint que modifica el archivo .txt correspondiente es muy similar al que permit´ıa recuperar su contenido, figura 3.9. function handleCommentsForm(body) { let formData = new FormData(); formData.append("comments_body",body); formData.append("projectId", projectId); projectsAPI.addOrModifyComments(projectId, formData) .then(() =>{ sleep(2000).then(() => { document.getElementById("auto-save -message").innerHTML = "Saved"; }); }).catch(error => messageRenderer.showErrorAsAlert(error)); } Extracto de c´odigo 3.8: Funci´on JavaScript de guardado de los comentarios 45 Cap´ıtulo 3. FrontEnd de Noise @endpoint( route="/comments/$projectId", method="POST", sql="insert Deployment", # dummy SQL auth_required=True ) def add_or_modify_comments(): projectId = request.form.get("projectId") comments_body = request.form.get("comments_body") project = dal.query("SELECT *FROM Deployments WHERE projectId = %s", (projectId,)) if not project: raise HTTPError(404, "Proyecto no encontrado") file_path = "teachers_comments/"+project[0]["uvus"]+".txt" if not os.path.exists("teachers_comments"): os.makedirs("teachers_comments") with open(file_path, "wb") as fh: fh.write(comments_body.encode()) raise HTTPError(204, "Added") Extracto de c´odigo 3.9: Endpoint de guardado de anotaciones de un proyecto 46 4. Proyecto SuXSur 4.1. An´alisis y requisitos 4.1.1. Introducci´on y alcance En este subproyecto nos disponemos a prestar servicio a Francisco Contreras Carrasco, gerente de la empresa sevillana SuXSur, dedicada al sector del suministro, instalaci´on y revisi´on de equipos contraincendios por m´as de veinte a˜nos. Dentro de esta organizaci´on, encontramos un equipo humano conformado por t´ecnicos e ingenieros, que, bajo la supervisi´on y control del gerente, posibilitan la actividad de la misma a trav´es de los distintos procesos de negocio que manejan. Hasta d´ıa de hoy, han mantenido un sistema de gesti´on y organizaci´on de la informaci´on documental totalmente f´ısico, sin aprovechar ning´un tipo de ventaja que los sistemas de informaci´on actuales ofrecen para este tipo de negocios, lo cual podr´ıa facilitar mucho toda la labor que realizan y permitirles un gran ahorro tanto en costes monetarios y temporales, como de espacio f´ısico de almacenamiento. Es por ello, que se pretende desarrollar un sistema de gesti´on adaptado a sus necesidades concretas, que permita almacenar toda la informaci´on que manejan y aumentar la productividad de la empresa. El alcance del presente proyecto engloba el desarrollo de un sistema de informaci´on acerca de la revisi´on de sistemas contraincendios y los procesos de negocio que ello conlleva. Dentro de este, se encontrar´an elementos como el almacenamiento de todos los datos que manejen, de revisiones y clientes, por ejemplo, as´ı como los documentos que se generan. Quedar´an fuera del alcance del sistema aquellos procesos de negocio y gestiones que requieran de alguna transacci´on bancaria o monetaria, las cuales se seguir´an realizando de forma personal a trav´es de la entidad bancaria correspondiente. Cap´ıtulo 4. Proyecto SuXSur 4.1.2. Objetivos del subproyecto Los objetivos que se marcan a cumplir mediante la ejecuci´on del presente subproyecto son: — Implementar un sistema que cumpla todos los requisitos especificados por el cliente y las expectativas que ha puesto en nosotros. — Facilitar la labor administrativa y de gesti´on de nuestro cliente, por tanto, los procesos de negocio. — Garantizar la protecci´on e integridad de los datos, documentos y archivos del sistema. — Brindar acceso al sistema a los distintos actores que deber´an interactuar con ´el, de forma que quede bien definido y acotado su margen de acci´on y de funcionalidades que tendr´a disponibles en funci´on de su rol. — Ofrecer, de forma directa e indirecta, un mejor servicio a los clientes de la empresa. 54 Cap´ıtulo 4. Proyecto SuXSur 4.1.3. Informaci´on sobre el dominio del problema 4.1.3.1. Introducci´on al dominio del problema y marco legal El sector de los sistemas contraincendios est´a poblado de distintas empresas y entidades que ofrecen a sus clientes diversas soluciones que les permitan mantenerse acorde a los requerimientos, normativos y t´ecnicos, dictados por las entidades competentes del Estado en cuanto a instalaciones de prevenci´on y extinci´on de incendios. Estas se orientan a prevenir, detectar y, en ´ultimo lugar, extinguir un posible incendio de la forma m´as eficaz y r´apida posible. Hoy en d´ıa, todas estas empresas deben trabajar bajo la normativa actual contraincendios, el llamado “Reglamento de Instalaciones de Protecci´on Contra Incendios”, aprobado por Real Decreto en 2017 [8]. Este dicta condiciones y requisitos exigibles al dise˜no e inspecci´on, en a˜nadido a los anteriores requisitos de instalaci´on, aplicaci´on y mantenimiento de dichas instalaciones. En consecuencia, se dict´o la obligaci´on del titular de las instalaciones de realizar mantenimientos y revisiones peri´odicas de los equipos a trav´es de una empresa autorizada y reflejarlos en forma de actas o certificados de inspecci´on que recojan la informaci´on pertinente [4]. 4.1.3.2. Glosario de t´erminos del dominio del problema —Acta de revisi´on: documento que refleja la ejecuci´on de una inspecci´on de los sistemas contraincendios de un cliente y todas las deficiencias que se pudieran haber encontrado en el proceso. —Administrador: persona f´ısica responsable de uno o varios “clientes”, es decir, fincas, comunidades de vecinos, residenciales, parkings o cualquier otra localizaci´on que requiera de sistemas contraincendios. —Albar´an de revisi´on: documento que representa una orden de revisi´on, ya sea peri´odica o no, de los dispositivos contraincendios de un cliente. —BIE: acr´onimo de “boca de incendios equipada”, se refiere a un equipo completo contraincendios que se encuentra anclado a la pared y conectado a la red de abastecimiento de agua. —Certificado contraincendios: documento oficial firmado por un ingeniero en el que se refleja el correcto cumplimiento de los distintos sistemas contraincendios de un cliente con la normativa vigente y el buen estado de mantenimiento de los mismos. —Cliente: lugar o localizaci´on gestionado por un administrador, que requiere de servicios de instalaci´on y/o revisi´on de sistemas contraincendios. —Gerente de la empresa: responsable ´ultimo de la empresa que se encarga de orquestar todo el proceso de negocio actual, velando por su correcto funciona- 55 Cap´ıtulo 4. Proyecto SuXSur miento y gestionando las relaciones entre el resto de los actores y el flujo de documentaci´on e informes que se genera. —Hidrante: tambi´en conocido como “boca de incendios”, es un artefacto conectado a una red de abastecimiento de agua para suministrarla en caso de incendio. No tiene mangueras, si no que permite que los bomberos o servicios de emergencia conecten las suyas. —Ingeniero: empleado cuya funci´on dentro de la empresa es verificar las actas y generar los certificados de revisi´on contraincendios, que son documentos oficiales y deben ser tratados debidamente. —Retimbrado: prueba de la presi´on de un extintor, tambi´en conocida como prueba hidrost´atica, que debe realizarse cada cinco a˜nos y mediante la cual se previenen posibles fallos provocados por corrosi´on interna, manipulaciones indebidas o montaje impreciso de v´alvulas o discos de seguridad derivados de la exposici´on a altas temperaturas. —Sistema contraincendios: conjunto de medidas, dispositivos o artefactos que se disponen en edificios y cualquier tipo de construcci´on para protegerlos contra el fuego. —T´ecnico: empleado de la empresa que se dedica a la revisi´on, instalaci´on o reparaci´on de equipos y sistemas contraincendios. 56 Cap´ıtulo 4. Proyecto SuXSur 4.1.4. Descripci´on de la situaci´on actual 4.1.4.1. “Pros” y “contras” de la situaci´on actual Ventajas de la situaci´on actual —VEN-001: Control total sobre el proceso de negocio, posesi´on f´ısica de todos los documentos relacionados y almacenamiento de los mismos en carpetas o archivadores f´ısicos que se tienen a mano. —VEN-002: Sensaci´on de seguridad generada por el tener toda la documentaci´on de forma f´ısica y no ser propenso a p´erdidas de informaci´on en caso de estar almacenados en un sistema inform´atico. —VEN-003: El gerente del negocio se encuentra familiarizado con la forma de trabajo actual, sin ning´un grado de digitalizaci´on m´as all´a de la comunicaci´on con clientes y proveedores a trav´es de correo electr´onico y la redacci´on de documentos en programas de ofim´atica. Desventajas de la situaci´on actual —DESV-001: Riesgos derivados del almacenamiento en papel de los documentos, sean incendios, sustracci´on, cat´astrofe en el ´ambito dom´estico... —DESV-002: El almacenar todos los archivos f´ısicamente, supone un gran gasto innecesario y no es un m´etodo fruct´ıfero de asegurar los datos. —DESV-003: Capacidad espacial de almacenamiento de documentos limitada. —DESV-004: Actualmente, el gerente se desplaza, suponiendo varias decenas de kil´ometros diarios, para la entrega de los documentos necesarios a los t´ecnicos, clientes y al ingeniero encargado de los certificados. —DESV-005: Lentitud y gran inversi´on temporal en la b´usqueda de cualquier documento almacenado que sea requerido nuevamente por un cliente. —DESV-006: El gerente debe producir manualmente los albaranes de revisi´on de cada mes, suponiendo la redacci´on de en torno a 200 documentos, los cuales son verdaderamente similares porque parten de una misma plantilla. Este es un gasto de tiempo muy costoso. —DESV-007: Problemas derivados de la manipulaci´on, por parte de los t´ecnicos, de las actas de revisi´on en papel durante el transcurso de las mismas. 57 Cap´ıtulo 4. Proyecto SuXSur 4.1.4.2. Modelos de procesos de negocio actuales Descripci´on de actores de negocio actuales Los actores que intervienen en la operativa de la empresa son el gerente, los administradores, los t´ecnicos y el ingeniero (v´ease el glosario de t´erminos, 4.1.3.2). Descripci´on de procesos de negocio actuales Se han diferenciado dos procesos de negocio, de los cuales, uno representar´a el proceso general que se sigue en la empresa, y el otro reflejar´a el procedimiento de registro de un nuevo administrador y un cliente asociado. —Modelo proceso general El proceso de negocio general actual, figuras 4.2 y4.1, comienza con el gerente de la empresa produciendo los albaranes de revisi´on para los clientes que tengan marcada revisi´on de sus sistemas en el mes pr´oximo. Cada uno de estos documentos es asignado a un t´ecnico. El albar´an de cada cliente es una especie de orden de revisi´on que es entregada a los t´ecnicos y con la que se dirigen al lugar indicado para el chequeo de los equipos. En ese mismo lugar, durante este proceso de verificaci´on, rellenan el acta de revisi´on con todos los datos que le son requeridos y una vez hecho esto, se env´ıa al gerente, que se encargar´a de revisarla y destacar las deficiencias, en el caso de que se hayan detectado; para a continuaci´on, remitir dicha acta al ingeniero. Este ingeniero t´ecnico se encargar´a de estudiar el acta que ha recibido, con los fallos detectados ya marcados para facilitar su labor, y producir, a partir de ´el, un certificado contraincendios para el cliente en cuesti´on. Este certificado es remitido al gerente, que se encargar´a, si se han detectado deficiencias corregibles, de construir un presupuesto para subsanarlas en caso de que el administrador del cliente lo crea conveniente. El certificado contraincendios se emite siempre, a pesar de la gravedad de las anomal´ıas detectadas. Es por ello, que el gerente env´ıa el certificado y el presupuesto, en caso de que hubiera este ´ultimo, al administrador, que decidir´a si aplicar´a las medidas correctivas propuestas por la empresa enviando de vuelta el presupuesto firmado, o no lo har´a. En caso afirmativo, el gerente se ocupar´a de realizar las gestiones necesarias para ejecutar las medidas correctivas reflejadas en dicho documento. Debemos destacar que todos los env´ıos de documentos entre los distintos actores se realizan, en su gran mayor´ıa, en persona, cara a cara, y en algunos casos, mediante correo electr´onico. 58 Cap´ıtulo 4. Proyecto SuXSur Figura 4.1: Proceso de negocio general (2) 59 Cap´ıtulo 4. Proyecto SuXSur Figura 4.2: Proceso de negocio general (1) —Modelo nuevo cliente En este segundo proceso de negocio, figura 4.3, muy similar al realizado en cualquier otro sector servicios, el gerente se encarga de registrar al nuevo administrador y al cliente que le corresponde con todos los datos necesarios. El aspecto a destacar aqu´ı es el m´ınimo nivel de automatizaci´on y digitalizaci´on de este proceso, que como se indica en el diagrama BPMN, se realiza pr´acticamente todo de forma manual. Otra idea de importancia en este proceso es el hecho de que el contrato de servicio que se genera, que es vinculante una vez formalizado, debe ser firmado primero siempre por el administrador y nunca antes por el gerente y, por tanto, la empresa, en vistas a evitar posibles problemas legales con el administrador en cuesti´on. 60 Cap´ıtulo 4. Proyecto SuXSur Figura 4.3: Proceso de registro de un nuevo administrador con su cliente asociado 4.1.4.3. Entorno tecnol´ogico actual La empresa, como hemos dicho, gira en torno a la acci´on del gerente, que se encarga de coordinar todo el proceso de negocio. Este actor dispone de un equipo inform´atico de sobremesa que usa para almacenar plantillas de documentos, generar nuevos documentos y recibir y enviarlos por medio de correo electr´onico. Adem´as, en ´el guarda algunos de estos archivos, adem´as de tenerlos f´ısicamente en papel. Por otro lado, tambi´en usa este equipo para el cobro en cuenta bancaria de los administradores de los distintos servicios que se les ofrece. Por otro lado, en cuesti´on de comunicaciones, podemos distinguir aquellas que se producen entre el gerente y los otros actores de la empresa, los t´ecnicos y el ingeniero, que, generalmente, se dan mediante llamada telef´onica, y en casos de menor importancia del asunto a tratar, mediante servicios de mensajer´ıa instant´anea; y el que se produce con los administradores, que puede ser tanto por v´ıa telef´onica, como por mensajer´ıa instant´anea o correo electr´onico, seg´un el que el interesado considere m´as oportuno en cada momento. 61 Cap´ıtulo 4. Proyecto SuXSur 4.1.5. Necesidades de negocio 4.1.5.1. Objetivos HU-001: Como gerente del negocio Quiero poder gestionar las revisiones de equipos contraincendios a trav´es de un sistema informatizado Para poder ahorrar tiempo y costes. HU-002: Como gerente del negocio Quiero poder generar y almacenar los albaranes de revisi´on de cada cliente Para ahorrar tiempo y papel. HU-003: Como t´ecnico de mantenimiento en protecci´on contraincendios Quiero poder acceder a los albaranes de los clientes Para poder disponer de la informaci´on de forma r´apida sin necesidad de usar papel al ir a realizar el reconocimiento de los equipos. HU-004: Como t´ecnico de mantenimiento en protecci´on contraincendios Quiero poder rellenar las actas de revisi´on de forma digital a trav´es de alg´un dispositivo m´ovil Para poder trabajar de forma m´as c´omoda y eficiente. HU-005: Como t´ecnico de mantenimiento en protecci´on contraincendios Quiero poder rellenar las actas de revisi´on en zonas donde la cobertura telef´onica sea baja o nula Para evitar p´erdidas de datos cuando accedo a revisar lugares sin cobertura. HU-006: Como gerente del negocio Quiero poder acceder a las actas de revisi´on y modificarlas para subrayar las deficiencias encontradas Para ahorrar tiempo y trabajo al ingeniero. HU-007: Como ingeniero de la empresa Quiero poder acceder a las actas de revisi´on con las deficiencias ya se˜naladas Para evitar desplazamientos f´ısicos y ahorrar tiempo. HU-008: Como ingeniero de la empresa Quiero poder almacenar y gestionar los certificados de revisi´on que genero Para facilitar mi trabajo y evitar desplazamientos innecesarios. 62 Cap´ıtulo 4. Proyecto SuXSur CU-04 Cambio del mes de revisi´on de un cliente Precondici´on El cliente debe estar registrado en el sistema y mostrar su voluntad de cambiar el mes en que se le realizan las revisiones cada a˜no. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor T´ecnico (ACT-02) se dispone a cambiar el mes en que se realizan las revisiones de un cliente. Para ello, acceder´a a la ficha del cliente y cambiar´a el mes que tiene asignado. A continuaci´on, guardar´a el cambio y el sistema le indicar´a que la operaci´on se realiz´o exitosamente. Postcondici´on El T´ecnico (ACT-02) y el Gerente (ACT-01) pueden ver en la ficha del cliente el nuevo valor del campo “Mes de revisi´on”. Excepciones - CU-05 Dar de baja o alta a un cliente Precondici´on El cliente debe estar registrado en el sistema y mostrar su voluntad de prescindir o volver a disponer de los servicios ofrecidos por la empresa. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a dar de baja o dar de alta nuevamente a un cliente. Para ello, acceder´a a la ficha del cliente y cambiar´a el campo “Est´a activo o de baja”. A continuaci´on, guardar´a el cambio y el sistema le indicar´a que la operaci´on se realiz´o exitosamente. Postcondici´on El Gerente (ACT-01) puede ver en la ficha del cliente el nuevo valor del campo y ya no se incluye a este cliente en el listado de activos (en caso de que se haya dado de baja). Excepciones - CU-06 Revisar el acta de revisi´on y generar certificado Precondici´on Existe el acta de revisi´on que debe ser examinada y est´a subrayada. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Ingeniero (ACT-03) se dispone a estudiar una nueva acta generada en la inspecci´on de un cliente. Para ello, acceder´a al acta y examinar´a todos los datos de la revisi´on, haciendo un estudio y finalmente, redactar´a un certificado que subir´a al sistema en alg´un formato de documento, asoci´andolo a dicha acta. El sistema le indicar´a que la subida del archivo se ha realizado correctamente. Postcondici´on El certificado contraincendios est´a correctamente almacenado en el sistema y es visible por los actores Gerente (ACT-01) e Ingeniero (ACT-03). Excepciones - 69 Cap´ıtulo 4. Proyecto SuXSur CU-07 Generar presupuesto Precondici´on Existe el acta de revisi´on con las deficiencias halladas remarcadas. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a realizar un presupuesto de correcci´on de las faltas que se vislumbraron en la revisi´on de los equipos. Para ello, el actor Gerente (ACT-01) accede al acta en cuesti´on e indica que desea generar un presupuesto en base a ella y las anomal´ıas que se han detectado. El sistema informar´a que esta operaci´on se realiz´o con ´exito. Postcondici´on El nuevo presupuesto est´a correctamente almacenado en el sistema. Excepciones - CU-08 Registrar evento Precondici´on El sistema almacena la informaci´on del cliente sobre el que se quiere registrar un comentario o evento. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a anotar alguna observaci´on sobre el cliente en cuesti´on. Para ello, acceder´a al apartado de eventos del cliente y registrar´a uno nuevo, indicando d´ıa y contenido del comentario. El sistema deber´a hacerle saber que se ha guardado correctamente. Postcondici´on El evento se ha almacenado correctamente y se puede ver junto a los dem´as. Excepciones - CU-09 Registrar nuevo administrador Precondici´on Disponer de los datos personales del nuevo administrador. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a inscribir a un nuevo administrador de clientes en el sistema. Para ello, acceder´a a la secci´on de administradores y seleccionar´a que quiere a˜nadir uno, para a continuaci´on, rellenar todos sus datos personales. Guardar´a los cambios y el sistema le indicar´a que la acci´on se ha realizado con ´exito. Postcondici´on El administrador se ha almacenado correctamente y se puede ver junto a los dem´as. Excepciones - 70 Cap´ıtulo 4. Proyecto SuXSur CU-10 Registrar nuevo cliente Precondici´on Disponer de los datos del nuevo cliente. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a inscribir a un nuevo cliente en el sistema. Para ello, acceder´a a la secci´on de clientes y seleccionar´a que quiere a˜nadir uno, para a continuaci´on, rellenar los datos que se le requieren. Tambi´en, podr´a seleccionar el administrador responsable del nuevo cliente de entre todos los administradores ya registrados en el sistema. Guardar´a los cambios y el sistema le indicar´a que la acci´on se ha realizado con ´exito. Postcondici´on El cliente se ha almacenado correctamente y se puede ver junto a los dem´as. Excepciones - CU-11 Generar nuevo contrato Precondici´on Disponer del cliente al que se le quiere generar el contrato y su correspondiente administrador. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a generar un nuevo contrato para un cliente. Para ello, se dirigir´a al cliente que se desea, se indicar´a que se va a generar un contrato y el sistema compondr´a una plantilla en base a los datos ya almacenados tanto del cliente como del administrador. A continuaci´on, el actor Gerente (ACT-01) a˜nadir´a algunos datos concretos al contrato de forma manual y, finalmente, pedir´a al sistema que guarde el contrato. Este, avisar´a de que la operaci´on se complet´o con ´exito. Postcondici´on El nuevo contrato se encuentra almacenado en el sistema y se puede visualizar dentro de la ficha del cliente. Excepciones - 71 Cap´ıtulo 4. Proyecto SuXSur CU-12 Asignar otro administrador a un cliente Precondici´on Disponer del cliente al que se quiere cambiar de administrador y el nuevo que se le pretende asignar. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Gerente (ACT-01) se dispone a asignar otro administrador a un cliente del sistema. Para ello, acceder´a al cliente y le eliminar´a el administrador que tiene actualmente. A continuaci´on, indicar´a que va a a˜nadirle un nuevo administrador y podr´a seleccionarlo en una lista con todos los que hay registrados en el sistema. Una vez seleccione al elegido, confirmar´a la acci´on y el sistema le informar´a de que se ha realizado con ´exito. Postcondici´on El cliente tiene un nuevo administrador y esto es visible dentro de su ficha. Excepciones - CU-13 Acceder a los documentos de los clientes Precondici´on Disponer de un usuario y contrase˜na para acceder al sistema. Descripci´on El sistema deber´a comportarse tal como se describe en el siguiente caso de uso cuando el actor Administrador (ACT-04) se dispone a chequear los documentos de los clientes que gestiona. Para ello, acceder´a a la direcci´on web del sistema e iniciar´a sesi´on con las credenciales aportados por la empresa. A continuaci´on, visionar´a una lista de los clientes a su cargo y dentro de cada uno, los archivos correspondientes, pudiendo verlos y descargarlos si deseara. Postcondici´on El Administrador (ACT-04) ha obtenido el documento o informaci´on que necesitaba. Excepciones - 72 Cap´ıtulo 4. Proyecto SuXSur 4.1.6.3. Diagramas de secuencia del sistema Crear albaranes de revisi´on En el proceso de crear nuevos albaranes de revisi´on para todos los clientes que deban ser atendidos el mes pr´oximo o el que se desee generar, figura 4.5, intervendr´a ´unicamente el gerente de la empresa, que trasladar´a su deseo de generar los albaranes a la interfaz de usuario, que obtendr´a del sistema una lista de meses que puedan generarse para, a continuaci´on, el gerente, seleccionar uno de ellos y generarlos finalmente. Por ´ultimo, el gerente podr´a, para cada albar´an generado, indicar una fecha de ejecuci´on y un t´ecnico al que se le asignar´a la revisi´on. Figura 4.5: Diagrama de secuencia de “Creaci´on de albaranes de revisi´on” Crear acta de revisi´on El proceso de creaci´on de un acta de revisi´on por parte de un t´ecnico, figura 4.6, comienza con este accediendo a sus revisiones asignadas, seleccionando la correspondiente y generando el acta de la misma. Una vez hecho esto, ir´a a˜nadiendo informes de revisi´on, seg´un los que convengan para el cliente, rellen´andolos y guard´andolos, a excepci´on de que deje alg´un campo obligatorio sin rellenar, ya que el sistema as´ı se lo notificar´a. Por ´ultimo, deber´a revisar todos los datos y guardar el acta, de forma que, si ha olvidado alg´un sistema contraincendios por revisar, el sistema se lo haga saber mediante un aviso. 73 Cap´ıtulo 4. Proyecto SuXSur Figura 4.6: Diagrama de secuencia de “Creaci´on de acta de revisi´on” Subrayar acta de revisi´on Para el subrayado o remarcado de las deficiencias encontradas en una revisi´on, el gerente acceder´a al acta que corresponda y la revisar´a se˜nalando aquellos campos que deban ser de la atenci´on del ingeniero cuando examine el documento, figura 4.7. 74 Cap´ıtulo 4. Proyecto SuXSur Figura 4.7: Diagrama de secuencia de “Subrayado de acta de revisi´on” Cambio del mes de revisi´on de un cliente El t´ecnico que realice la revisi´on de sistemas contraincendios tendr´a la capacidad, a petici´on del administrador o responsable del cliente, de cambiar el mes en que se realiza su inspecci´on, mediante el acceso a la ficha de dicho cliente y la indicaci´on al sistema de un nuevo mes en que realizarla, figura 4.8. Figura 4.8: Diagrama de secuencia de “Cambio del mes de revisi´on de un cliente” Dar de baja o alta a un cliente El gerente podr´a dar de baja o alta a alg´un cliente que as´ı lo solicite, para lo cual deber´a acceder a su ficha, y dentro de ella, seleccionar su baja o alta, guardando el sistema el cambio, figura 4.9. 75 Cap´ıtulo 4. Proyecto SuXSur Figura 4.9: Diagrama de secuencia de “Dar de baja o alta a un cliente” Revisar el acta de revisi´on y generar certificado El ingeniero se encargar´a de redactar los certificados contraincendios a partir de los datos de las revisiones, para lo cual deber´a a acceder al acta de cada una de ellas, de la que podr´a obtener los datos que necesita, redactar el documento y subirlo al sistema a trav´es de la interfaz web de usuario, figura 4.10. Figura 4.10: Diagrama de secuencia de “Revisi´on el acta de revisi´on y generar certificado” Generar presupuesto Para la generaci´on de un presupuesto para actuaciones que corrijan las faltas encontradas en alguna revisi´on, el gerente deber´a acceder a un acta de revisi´on con las deficiencias ya marcadas e indicar al sistema que desea generar un presupuesto a partir de ella. El sistema as´ı lo har´a, en base a los datos que posee y a una plantilla ya definida, figura 4.11. 76 Cap´ıtulo 4. Proyecto SuXSur Figura 4.11: Diagrama de secuencia de “Generaci´on de presupuesto” Registrar evento El sistema ofrecer´a la capacidad de almacenar eventos, comentarios o informaciones de los clientes, para lo que el gerente deber´a acceder a su ficha e indicar el comentario o evento que desee guardar en el sistema, figura 4.12. Figura 4.12: Diagrama de secuencia de “Registro de evento” 77 Cap´ıtulo 4. Proyecto SuXSur Registrar nuevo administrador El gerente ser´a el ´unico actor que pueda registrar a nuevos administradores de clientes en el sistema, para lo que deber´a indicar esta voluntad y rellenar los datos del administrador en el formulario de registro que la interfaz web le ofrece, figura 4.13. Figura 4.13: Diagrama de secuencia de “Registro de nuevo administrador” Registrar nuevo cliente El proceso de registrar a un nuevo cliente de la empresa lo ejecuta el gerente, indicando los datos del mismo en el formulario que la interfaz web del sistema le ofrece y guardando los cambios. Una vez hecho esto, el gerente tiene la opci´on de asignarle un administrador ya registrado en el sistema a ese nuevo cliente, figura 4.14. Figura 4.14: Diagrama de secuencia de “Registro de nuevo cliente” 78 Cap´ıtulo 4. Proyecto SuXSur - Modelo. - N´umero de placa o botella. - A˜no de fabricaci´on. - Mes y a˜no de la ´ultima revisi´on. - A˜no del ´ultimo retimbre. - Peso de la carga del extintor. - Presi´on de la carga del extintor. - Indicador de “Prueba hidr´aulica”. - Indicador de “Baja presi´on”. - Indicador de “Sin se˜nalizador”. - Indicador de “Cristal roto”. - Indicador de “Ok”. - Notas. Acta de revisi´on de conservaci´on de instalaciones de protecci´on contraincendios: - Central de se˜nalizaci´on y control: ◦Fabricante. ◦Modelo. ◦N´umero de zonas. ◦Marcaje de la central seg´un la norma UNE. ◦Marcaje de la fuente de alimentaci´on seg´un la norma UNE. ◦Medidas para evitar actuaciones o maniobras no deseadas durante las labores de inspecci´on. ◦Funcionamiento de los indicadores ´opticos de la central al accionar el interruptor de pruebas. ◦Funcionamiento del indicador ´optico de alarma de la central. ◦Existencia de un indicador ´optico general de aver´ıa. ◦Indicaci´on ´optica y ac´ustica de fallo de alimentaci´on de red. ◦Existencia de una fuente de alimentaci´on secundaria (bater´ıas) y capacidad de las mismas. ◦Existencia de cargador de las bater´ıas. ◦Estado correcto de las bater´ıas. 85 Cap´ıtulo 4. Proyecto SuXSur ◦Capacidad de alimentaci´on de las bater´ıas para alimentar la instalaci´on 72h en vigilancia y 0,5h en alarma (consumo en vigilancia y consumo en alarma). ◦Ajuste de la capacidad y autonom´ıa de las bater´ıas al fabricante o proyecto. ◦Conmutaci´on autom´atica a la alimentaci´on de las bater´ıas en caso de fallo de red. ◦Indicaci´on ac´ustica y ´optica del fallo de las bater´ıas. ◦Se˜nalizaci´on de la zona o elemento de la instalaci´on en la que se ha producido la alarma. ◦Se˜nalizaci´on de la zona o elemento de la instalaci´on en la que se ha producido la aver´ıa. ◦Indicaci´on de las zonas o elementos de la instalaci´on que est´en fuera de servicio. ◦Se˜nalizaci´on de las aver´ıas por l´ınea abierta. ◦Se˜nalizaci´on de las aver´ıas por cortocircuito en cada zona de la instalaci´on. ◦Existencia de se˜nalizaci´on ´optica y ac´ustica para aver´ıa. ◦Existencia de se˜nalizaci´on ´optica y ac´ustica para alarma. ◦Existencia en la instalaci´on de un manual de uso simplificado junto a la central. ◦Observaciones. - Pulsadores de alarma: ◦Clara visibilidad, f´acil identificaci´on y accesibilidad a los pulsadores de alarma. ◦Existencia de pulsadores en las rutas de salida de emergencias a aire libre. ◦Distancia desde cualquier punto de la planta al pulsador m´as cercano es inferior a 25 metros. ◦Instalaci´on de los pulsadores a una altura del suelo comprendida entre 1,2 y 1,5 metros. ◦Se˜nalizaci´on correcta con su correspondiente cartel de pulsador. ◦Pulsadores rearmables. ◦Estado de los pulsadores correcto (fijaci´on, limpieza, corrosi´on, aspecto exterior). ◦Realizaci´on de pruebas sobre el 75 % de los pulsadores instalados, con transmisi´on correcta a la central. 86 Cap´ıtulo 4. Proyecto SuXSur ◦Total de pulsadores. ◦Total de pulsadores probados. ◦Se˜nalizadores dentro de vida ´util (10 a˜nos). ◦Cumplimiento de los se˜nalizadores de la normativa vigente. ◦Observaciones. - Detectores: ◦Marcaje de los detectores conforme norma UNE. ◦Detectores dentro de los 10 a˜nos de vida ´util. ◦Estado de los detectores correcto (fijaci´on, limpieza, corrosi´on, aspecto exterior). ◦Mantenimiento de un espacio libre, por debajo del detector y en todas las direcciones de, al menos, 50 cent´ımetros. ◦Detectores colocados fuera de la influencia de corrientes de aire debidas a la climatizaci´on o ventilaci´on. ◦Colocaci´on de los detectores fuera de puntos donde la temperatura ambiente pudiera provocar falsas alarmas. ◦Existencia de se˜nalizaci´on ´optica de los detectores situados en espacios ocultos. ◦Cantidad de detectores i´onicos instalados. ◦Cantidad de detectores ´opticos instalados. ◦Cantidad de detectores t´ermicos instalados. ◦Cantidad de detectores termovelocim´etricos instalados. ◦Cantidad de detectores ´optico-t´ermicos instalados. ◦Correspondencia de los detectores existentes con la especificaci´on del proyecto. ◦Realizaci´on de pruebas sobre el 75 % de los detectores, con transmisi´on correcta a la central. ◦Fabricante. ◦Marca. ◦Modelo. ◦Total, de detectores o zonas probadas. ◦Observaciones. - Actuaciones y equipos auxiliares: ◦Correcto funcionamiento de la activaci´on de campanas y sirenas. 87 Cap´ıtulo 4. Proyecto SuXSur ◦Audibilidad de campanas y sirenas en todos los puntos de la instalaci´on. ◦Existencia en la central de una salida de alarma general. ◦Supervisi´on de la salida de alarma por rel´e. ◦Existencia en la instalaci´on de puertas cortafuego actuadas mediante electroimanes. ◦Correcto funcionamiento de electroimanes de las puertas. ◦Correcto cierre de todas las puertas cortafuego. ◦Funcionamiento de la extracci´on de humo al activarse la alarma. ◦Correcto estado de rejillas y tuber´ıas. ◦Existencia en la instalaci´on de un sistema de extinci´on. ◦Temporizaci´on previa al disparo de la extinci´on es de 30 a 60 segundos. ◦Existencia de la posibilidad de activar o desactivar manualmente el sistema de extinci´on. ◦Se˜nalizaci´on adecuada de la activaci´on o desactivaci´on manual. ◦Existencia en la instalaci´on de rociadores o cortinas de agua. ◦Sectorizaci´on del sistema de rociadores o cortina de agua. ◦Correcto funcionamiento de todas las electrov´alvulas. ◦Existencia en la instalaci´on de v´alvulas de corte manual. ◦Existencia en la instalaci´on de v´alvulas de prueba manual. ◦Existencia en la instalaci´on de fuente de alimentaci´on auxiliar. ◦Existencia en la instalaci´on de una fuente de alimentaci´on secundaria (bater´ıas) y su capacidad y cantidad. ◦Existencia de cargador de las bater´ıas. ◦Estado correcto de las bater´ıas. ◦Conmutaci´on autom´atica a la alimentaci´on de bater´ıa en caso de fallo de red. ◦Capacidad de alimentaci´on de las bater´ıas para alimentar la instalaci´on 72h en vigilancia y 0,5h en alarma (consumo en vigilancia y consumo en alarma). ◦Observaciones. - Cableado: ◦Cumplimiento de las especificaciones del fabricante de los equipos en cuanto al cableado. 88 Cap´ıtulo 4. Proyecto SuXSur ◦Exclusividad y diferenciabilidad del cableado para el sistema de incendio de otras instalaciones. ◦Alojamiento de las uniones del cableado en cajas de registro. ◦Seguridad adecuada en las conexiones en los equipos y en las cajas de registro. ◦Discurrimiento del cableado por tubos de acero, PVC o corrugado que no permitan su deterioro. ◦Discurrimiento del cableado por zonas protegidas o de bajo riesgo. ◦Existencia de planos que muestren la ubicaci´on de todos los dispositivos, cajas de registro y recorrido del cableado. ◦Observaciones. Acta de revisi´on de grupos contraincendios: - Inspecci´on ocular del buen estado de la pintura y accesorios. - Verificaci´on del estado de las v´alvulas y su funcionamiento, apertura de la v´alvula de llenado autom´atico del aljibe. - Verificaci´on del nivel del aljibe al 100 %. - Limpieza del circuito de llenado. - Correcto funcionamiento del sistema de llenado autom´atico. - Funcionamiento de la alarma de nivel m´ınimo. - Ausencia de elementos s´olidos en el agua en recipientes sin techo. - Correcto funcionamiento del carder´ın (hidrosfera). - Apertura de la v´alvula de entrada directa de agua. - Correcto funcionamiento de la v´alvula de retenci´on. - Inspecci´on del dep´osito de agua y carencia de fugas. - Observaciones. Acta de revisi´on de BIES e hidrantes (para cada BIES/Hidrante): - Fabricante. - Modelo. - N´umero de placa. - A˜no de fabricaci´on. - Mes y a˜no de ´ultima revisi´on. - A˜no de ´ultimo retimbre. - Presi´on de man´ometro. 89 Cap´ıtulo 4. Proyecto SuXSur - Indicador de “Prueba hidr´aulica”. - Indicador de “Man´ometro malo”. - Indicador de “Sin se˜nalizador”. - Indicador de “Cristal roto”. - Indicador de “Ok”. - Notas. —RI-06: Informaci´on de certificados de revisi´on El sistema deber´a almacenar la informaci´on correspondiente a los certificados de revi- si´on: Administrador. Cliente. Acta de revisi´on. Fecha de expedici´on del certificado. Presupuesto. Documento del certificado. —RI-07: Informaci´on de presupuestos El sistema deber´a almacenar la informaci´on correspondiente a los certificados de revi- si´on: Administrador. Cliente. Acta de revisi´on. Certificado de revisi´on. Importe. Fecha de proposici´on. Indicador de firma. Documento del presupuesto. 90 Cap´ıtulo 4. Proyecto SuXSur Requisitos de reglas de negocio del sistema RN-01: Campos obligatorios en actas de revisi´on El sistema no deber´a permitir que se almacene un acta de revisi´on si no se han rellenado todos los campos que se indiquen como obligatorios. Requisitos de conducta del sistema RC-01: Documentos por cliente (gerente) El sistema deber´a agrupar, a petici´on del gerente, los documentos de cada cliente, de forma que se les pueda mostrar de forma ordenada por sus distintos campos. RC-02: Clientes por administrador El sistema deber´a agrupar, a petici´on del gerente, los distintos clientes que gestione cada administrador, brindando acceso a cada uno de ellos y a sus respectivos documentos. RC-03: Clientes activos o de baja El sistema deber´a diferenciar, a petici´on del gerente, los clientes que se encuentren activos, es decir, cuenten con nuestros servicios, de aquellos que hayan causado baja, en todos los listados de clientes que el sistema proporcione. Adem´as, se ofrecer´a una secci´on exclusiva donde s´olo se muestren los clientes de baja. RC-04: Documentos por categor´ıa El sistema deber´a agrupar, a petici´on del gerente, los distintos documentos que se almacenan seg´un su tipo: acta, contrato. . . RC-05: Generaci´on de plantillas El sistema deber´a generar, a petici´on del gerente, plantillas para los nuevos documentos que se vayan a generar en base a los datos que ya tiene almacenados: albar´an de revisi´on, acta de revisi´on, contrato y presupuesto. RC-06: Documentos por cliente (administrador) El sistema deber´a agrupar, a petici´on del administrador, los documentos de los clientes que gestione, de forma que se les pueda mostrar de forma ordenada por sus distintos campos. RC-07: Albaranes por prioridad El sistema deber´a ordenar, a petici´on del gerente, los clientes y sus albaranes de revisi´on de cada mes seg´un el nivel de prioridad que tengan. 91 Cap´ıtulo 4. Proyecto SuXSur RC-08: Asignaci´on de albaranes El sistema deber´a permitir al gerente asignar un t´ecnico a cada uno de los albaranes generados. RC-09: Albaranes por t´ecnico El sistema deber´a permitir a los t´ecnicos visualizar aquellos albaranes de revisi´on que les han sido asignados. RC-10: Revisi´on incompleta El sistema deber´a contrastar los datos de n´umero de equipos y sistemas que cada cliente posee con los que se han introducido en el acta de revisi´on, de forma que, si faltara alguno por comprobar, se avise al t´ecnico en el propio instante. 92 Cap´ıtulo 4. Proyecto SuXSur 4.1.6.5. Requisitos no funcionales del sistema Requisitos de fiabilidad del sistema RF-01: Fiabilidad ante ca´ıdas del sistema El sistema deber´a ser fiable ante posibles apagones o ca´ıdas del mismo para no perder ning´un documento o informaci´on relevante, y ser capaz de auto regenerarse y volver a estar operativo. RF-02: Copias de seguridad El sistema deber´a generar, de forma peri´odica o bajo demanda, copias de seguridad de todos los datos almacenados, de forma que siempre se pueda tener una versi´on anterior de respaldo. Requisitos de usabilidad del sistema RU-01: Interfaz del sistema El sistema deber´a tener una interfaz intuitiva, simple y amigable, que contribuya a una mayor productividad y eficacia en las acciones que se realicen, reduciendo al m´aximo los tiempos de espera. RU-02: Flexibilidad del sistema El sistema deber´a ser muy flexible, es decir, debe permitir el acceso a los datos mediante distintos tipos de criterios y ordenaciones, seg´un convenga. RU-03: Interfaz para firmas El sistema deber´a ofrecer una interfaz donde se pueda escribir una firma sobre la pantalla del dispositivo en que se use, lo cual es necesario para las actas de revisi´on. Requisitos de mantenibilidad del sistema RM-01: Mantenimiento del sistema El sistema deber´a ser verificado temporalmente cada vez que la empresa lo solicite con el fin de actualizar o agregar las funcionalidades que puedan mejorarse, perfilarse, cambiar o aparecer en el ´ambito del negocio. Requisitos de seguridad del sistema 93 Cap´ıtulo 4. Proyecto SuXSur RS-01: Seguridad ante accesos indebidos El sistema deber´a ser seguro frente accesos indebidos con tal de evitar posibles robos de datos. RS-02: Restricciones de acceso seg´un rol El sistema deber´a prevenir el acceso de un usuario con un determinado rol a recursos sobre los cuales no tenga permisos. 4.1.6.6. Restricciones t´ecnicas del sistema RT-01: Compatibilidad con dispositivos m´oviles El sistema deber´a ser totalmente compatible con dispositivos m´oviles y sus correspondientes navegadores, de forma que la experiencia de usuario del mismo no se vea penalizada por la plataforma en que se use y todas las funcionalidades se encuentren disponibles. RT-02: Uso en zonas sin cobertura El sistema deber´a permitir la cumplimentaci´on de actas de revisi´on en zonas donde la cobertura sea baja o nula. 94 Cap´ıtulo 4. Proyecto SuXSur Figura 4.23: Mockup de la vista de inicio El primer conjunto de vistas a las que el gerente podr´a acceder es a las de administradores, en las que podr´a listar aquellos que se encuentran registrados en el sistema y a˜nadir uno nuevo, figura 4.24; y acceder a la ficha de cada uno de ellos, pudiendo consultar todos sus datos, editarlos y visualizar r´apidamente aquellos clientes que se encuentran a su cargo, figura 4.25. 101 Cap´ıtulo 4. Proyecto SuXSur Figura 4.24: Mockup de la vista de listado de administradores 102 Cap´ıtulo 4. Proyecto SuXSur Figura 4.25: Mockup de la vista de detalles de un administrador Adem´as de los administradores de fincas y propiedades, el gerente contar´a con un conjunto de vistas que le permitan gestionar los clientes de la empresa, pudi´endolos listar y registrar nuevos, figura 4.26; y acceder a los detalles de cada uno de ellos, donde contar´a con todos sus datos, comentarios de importancia, as´ı como los contratos de servicio y las revisiones realizadas al mismo, figura 4.27. 103 Cap´ıtulo 4. Proyecto SuXSur Figura 4.26: Mockup de la vista de listado de clientes 104 Cap´ıtulo 4. Proyecto SuXSur Figura 4.27: Mockup de la vista de detalles de un cliente En lo que respecta a las revisiones de los sistemas contraincendios, el gerente podr´a listarlas y ordenarlas por distintos criterios, adem´as de generar las revisiones y albaranes de un mes concreto de forma automatizada, figura 4.28. Tambi´en, podr´a acceder a todos los detalles e informaci´on de cada revisi´on, incluyendo los distintos documentos asociados a la misma, figura 4.29. 105 Cap´ıtulo 4. Proyecto SuXSur Figura 4.28: Mockup de la vista de listado de revisiones 106 Cap´ıtulo 4. Proyecto SuXSur Figura 4.29: Mockup de la vista de detalles de una revisi´on 107 Cap´ıtulo 4. Proyecto SuXSur Por ´ultimo, el gerente podr´a listar todos los documentos que se registren en el sistema, de forma que pueda acceder a ellos r´apidamente, filtrarlos, ordenarlos y realizar b´usquedas, figura 4.30. Figura 4.30: Mockup de la vista de listado de documentos Un administrador tendr´a disponible una ´unica vista donde se listen los documentos de sus clientes, de forma que pueda acceder a ellos y descargar los archivos PDF correspondientes a cada uno de ellos, figura 4.31. 108 Cap´ıtulo 4. Proyecto SuXSur Figura 4.31: Mockup de la vista de listado de documentos de un administrador El ingeniero, por su parte, podr´a disponer de un listado de las revisiones realizadas, pudiendo acceder a los archivos PDF de las actas para poder revisarlas y estudiarlas, de forma que pueda redactar el certificado correspondiente en formato PDF y subirlo al sistema, figura 4.32. 109 Cap´ıtulo 4. Proyecto SuXSur Figura 4.32: Mockup de la vista de listado de revisiones del ingeniero Finalmente, los t´ecnicos contar´an con una vista donde se listen las revisiones contraincendios que les han sido asignadas y desde las cuales podr´an acceder a los datos del cliente que se trate, as´ı como al albar´an de revisi´on correspondiente, figura 4.33. Desde esta vista, podr´an crear una nueva acta o modificar una ya existente si se diese el caso de necesidad de rectificar algo en el mismo lugar. Adem´as de esta vista, contar´an con una donde rellenar todos los datos del acta y a˜nadir y cumplimentar los distintos informes de revisi´on contraincendios que sean necesarios en cada caso, figura 4.34. 110 Cap´ıtulo 4. Proyecto SuXSur 4.3. Implementaci´on En esta secci´on se muestran, en primer lugar, el product backlog con las tareas priorizadas abordadas durante los sprints y, a continuaci´on, el detalle de cada uno de ellos: una breve introducci´on, el backlog del mismo, aspectos destacables de la implementaci´on y unas conclusiones. 4.3.1. Product backlog En base a los resultados de las fases de an´alisis y dise˜no previas y la envergadura del proyecto, se deciden implementar dentro del marco de este TFG, las funcionalidades “core” del sistema, suficientes para el estudio de la idoneidad de Silence fuera del ´ambito acad´emico. Por ello, se definen, a continuaci´on, las tareas priorizadas que fueron abordadas a lo largo de los distintos sprints: —Tarea-01: Creaci´on y modificaci´on de informes de extintores. —Tarea-02: Creaci´on y modificaci´on de informes de BIES/hidrantes. —Tarea-03: Creaci´on y modificaci´on de informes de conjunto de extintores, de conservaci´on de centrales contraincendios y de conservaci´on de grupos contraincendios. —Tarea-04: Aviso de campos sin rellenar antes de guardar alg´un informe de revi- si´on de alg´un acta. —Tarea-05: Hacer la interfaz de creaci´on de informes compatible y totalmente funcional con dispositivos m´oviles. —Tarea-06: Permitir la creaci´on de los informes de un acta en zonas sin cobertura. —Tarea-07: Permitir la introducci´on de la firma del responsable de la instalaci´on en el acta. —Tarea-08: Generar documentos PDF de cada informe de revisi´on en base a los datos recogidos. —Tarea-09: Creaci´on y modificaci´on de administradores. —Tarea-10: Creaci´on y modificaci´on de clientes. —Tarea-11: Generar revisi´on de un cliente. —Tarea-12: Generar revisiones correspondientes a un mes concreto. —Tarea-13: Mostrar, crear y modificar un acta de revisi´on. —Tarea-14: Aviso de campos sin rellenar antes de guardar un acta de revisi´on. —Tarea-15: Configurar un login para usuarios. —Tarea-16: Introducir roles en los usuarios. —Tarea-17: Configurar registro de t´ecnicos en el sistema. 117 Cap´ıtulo 4. Proyecto SuXSur —Tarea-18: Asignar revisi´on a un t´ecnico. —Tarea-19: Configurar vistas y acceso seg´un el rol. —Tarea-20: Configurar perfil del t´ecnico para a˜nadir su firma. —Tarea-21: Aviso en el informe de extintores/BIES del n´umero de ellos que hab´ıa el a˜no pasado y si falta alguno por revisar. —Tarea-22: Generaci´on de copias de seguridad. 118 Cap´ıtulo 4. Proyecto SuXSur 4.3.2. Sprint 1 (18 de febrero - 3 de marzo) 4.3.2.1. Introducci´on En este primer sprint de implementaci´on del sistema SuXSur, se han desarrollado aquellas funcionalidades que fueron el detonante del comienzo del proyecto: la cumplimentaci´on de actas de revisi´on mediante un sistema inform´atico. Es por ello, que todos los requisitos que se han cubierto en este primer sprint tienen que ver en gran parte con ellas, adem´as de que el proceso de negocio gira en torno a ellas y el resto de las funcionalidades se ven afectadas por las que se desarrollaron en este punto. 4.3.2.2. Sprint backlog Para el sprint backlog, se tomaron las primeras tareas del product backlog en orden de prioridad: —Tarea-01: Creaci´on y modificaci´on de informes de extintores. —Tarea-02: Creaci´on y modificaci´on de informes de BIES/hidrantes. —Tarea-03: Creaci´on y modificaci´on de informes de conjunto de extintores, de conservaci´on de centrales contraincendios y de conservaci´on de grupos contraincendios. —Tarea-04: Aviso de campos sin rellenar antes de guardar alg´un informe de revi- si´on de alg´un acta. —Tarea-05: Hacer la interfaz de creaci´on de informes compatible y totalmente funcional con dispositivos m´oviles. 4.3.2.3. Detalle de la implementaci´on En lo que respecta a la implementaci´on de la funcionalidad de creaci´on de informes, tenemos, en primer lugar, aquellos de conjunto de extintores, conservaci´on de instalaciones y grupos contraincendios, de los que podemos destacar la necesidad de utilizar la f´ormula Promise.all, que permite que la ejecuci´on del c´odigo JavaScript espere a que las promesas, que son as´ıncronas, del registro en la base de datos de los campos del informe, por ejemplo, finalicen para poder redirigir a la p´agina del acta de revisi´on a la que pertenece el informe que acabamos de registrar, figura 4.1. 119 Cap´ıtulo 4. Proyecto SuXSur informesAPI.add(informeFormData) .then(respuesta =>{ var informeId = respuesta["lastId"]; var promesas = crearCamposInforme(informeId,elements); Promise.all(promesas) .then(_ => window.location.href = "acta_detalles.html? actaId="+actaId); }) .catch(error => messageRenderer.showErrorMessage(error)); Extracto de c´odigo 4.1: Creaci´on de un informe en informe create.js Cabe destacar, tambi´en, la inclusi´on de dos peque˜nos scripts que indican al usuario los campos sin rellenar antes de enviar el informe, o le advierte que, en caso de querer retroceder de p´agina, perder´a los datos que no haya guardado, cumpliendo as´ı con la tarea n´umero cuatro del sprint backlog. Por otro lado, tenemos la creaci´on de los informes de extintores, con un dise˜no distinto al de los informes anteriores, ya que este permite, de forma din´amica, a petici´on del t´ecnico, a˜nadir o eliminar extintores a un listado de ellos, seg´un se vayan revisando, figura 4.2. function addExtintorToForm(event){ event.preventDefault(); var cuerpoTabla = document.getElementById("table-body"); var indice = parseInt(cuerpoTabla.lastChild.children[0]. children[0].value) + 1; cuerpoTabla.appendChild(informeExtintoresRenderer.extintorAsRow (indice)); } function deleteExtintorOfForm(event){ event.preventDefault(); var cuerpoTabla = document.getElementById("table-body"); if(cuerpoTabla.lastChild.children[0].children[0].value != "1"){ cuerpoTabla.lastChild.remove(); } } Extracto de c´odigo 4.2: C´odigo para a˜nadir o eliminar extintores del formulario del informe en informe extintores create.js Exceptuando esto, el registro de este tipo de informe es similar a lo anteriormente comentado, mediante una primera promesa que almacenar´a el informe, y varias promesas m´as que se ejecutar´an de forma as´ıncrona a continuaci´on, almacenando la informaci´on de todos los extintores revisados. En lo que respecta a la compatibilidad de la interfaz gr´afica del sistema con dispositivos m´oviles, el uso de la librer´ıa de estilos Bootstrap, propuesta tambi´en por el propio Silence, resuelve convenientemente este aspecto, ajustando en todo momento los men´us y formularios a la pantalla en que se visualiza. 120 Cap´ıtulo 4. Proyecto SuXSur 4.3.2.4. Conclusiones En este sprint se completaron la mayor´ıa de tareas que versaban sobre la implementaci´on de los informes de revisi´on, pero qued´o pendiente de finalizar la n´umero dos, aquella de informes de BIES/Hidrantes, muy asemejable a los de extintores. Esto pudo deberse a la complejidad de su implementaci´on y el tiempo que requer´ıan finalmente al ser desarrollados en su totalidad mediante la propuesta de frontend del framework Silence que no ofrece ninguna herramienta ni automatizaci´on, ´unicamente el uso de JavaScript puro, con su consecuente incremento temporal en la dedicaci´on requerida. 121 Cap´ıtulo 4. Proyecto SuXSur 4.3.3. Sprint 2 (4 de marzo – 17 de marzo) 4.3.3.1. Introducci´on En este segundo sprint fueron abordadas las tareas del anterior que no pudieron ser completadas, en vistas, tambi´en, a finalizar el ´area de informes de revisi´on antes de continuar con el resto de funcionalidades del sistema. 4.3.3.2. Sprint backlog Por ello, las tareas que se escogieron para este sprint, una de ellas, heredada del anterior, fueron: —Tarea-02: Creaci´on y modificaci´on de informes de BIES/hidrantes. —Tarea-06: Permitir la creaci´on de los informes de un acta en zonas sin cobertura. 4.3.3.3. Detalle de la implementaci´on La funcionalidad de creaci´on y modificaci´on de informes de revisi´on de BIES/hidrantes fue implementada de forma similar a la de los informes de extintores del sprint anterior, sin mayores problemas. En cuanto a la posibilidad de rellenar los informes de un acta sin tener conexi´on con el servidor, ha supuesto un reto tecnol´ogico mucho mayor y se ha compuesto por dos soluciones que deben trabajar juntas para ofrecer la funcionalidad completa. Por un lado, tenemos el uso de “service workers”, que consisten en una especie de cach´e que se crea en el navegador del cliente cuando se accede a un dominio web y donde se pueden guardar aquellas p´aginas del sistema que se indiquen, de forma que, puedan ser cargadas posteriormente desde dicha cach´e en caso de que nos encontremos sin conexi´on o cobertura. De esta forma, se tiene un archivo sw.js donde se defini´o el “service worker” que se crear´a y las p´aginas que se cachear´an al acceder al sistema, aquellas de creaci´on de informes, en nuestro caso, figura 4.3. 122 Cap´ıtulo 4. Proyecto SuXSur let cache_name = ’suxsur-v1’ let urls_to_cache = [ ’/’, ’/index.html’, [...] ’/informe_extintores_create.html’, ’/js/informe_extintores_create.js’, ’/js/renderers/informe_extintores.js’, ’/js/api/informe_extintores.js’, ’/js/api/extintores.js’, ’/informe_bies_create.html’, ’/js/informe_bies_create.js’, ’/js/renderers/informe_bies.js’, ’/js/api/informe_bies.js’, ’/js/api/bies.js’, ’/informe_create.html’, ’/js/informe_create.js’, ’/js/renderers/informes.js’, ’/js/api/informes.js’, ’/js/api/campo_informes.js’ ] Extracto de c´odigo 4.3: Archivos a cachear definidos en sw.js Es de importancia que en el evento de “fetch” que decidir´a si el navegador nos presenta la p´agina cacheada, o por el contrario puede acceder al servidor y la carga directamente, indiquemos la opci´on ignoreSearch: true, de forma que podamos acceder a las p´aginas cacheadas proveyendo par´ametros GET en la url, necesario para acceder a los formularios de creaci´on de informes indic´andoles el id del acta al que pertenece, figura 4.4. self.addEventListener(’fetch’, (e) => { e.respondWith(caches.match(e.request,{’ignoreSearch’: true}). then((response) => { if(response) return response; else return fetch(e.request); }) ); }); Extracto de c´odigo 4.4: Evento “fetch” en sw.js De otra forma, se tendr´ıan que cachear una a una todas las p´aginas con todas las combinaciones de par´ametros GET en lugar de ´unicamente la p´agina base, lo cual ser´ıa 123 Cap´ıtulo 4. Proyecto SuXSur totalmente inviable. Otro aspecto t´ecnico a destacar del uso de “service workers” es que, para permitir su instalaci´on, la p´agina debe servirse sobre protocolo HTTPS, el cual ofrece un certificado de confianza, o sobre HTTP pero hacer uso de una direcci´on localhost que se entiende se trata de labores de desarrollo. Frente a esta problem´atica se han encontrado dos opciones: la primera de ellas, no la mejor, pero sencilla y funcional, se trata de a˜nadir la direcci´on url del sistema a las p´aginas de confianza del navegador; la segunda opci´on consiste en, bien modificar el servidor Flask que utiliza el framework Silence para servir el servicio web de forma que utilice HTTPS, o bien, optar por un servidor de mayor envergadura como nginx o Apache. De cualquier forma, se requiere de un certificado que acredite el sistema, por lo que estas soluciones tendr´an sentido una vez el proyecto se vaya a poner en producci´on. Por tanto, se opta, por el momento, por la primera opci´on, durante el desarrollo, y se estudiar´an las posibilidades de la segunda una vez llegue el momento de desplegar el sistema. Por otro lado, y junto al “service worker”, se necesita hacer uso de “localStorage”, una propiedad que permite acceder al elemento “storage” del navegador cliente, cuya funci´on es permitir el almacenamiento de pares clave-valor, id´onea para guardar de forma temporal los formularios de los informes que se rellenen sin cobertura y poder recuperarlos posteriormente, una vez se vuelva a tener conexi´on, para ser procesados y registrados en la base de datos. El primer paso para ello es detectar si el navegador tiene conexi´on a internet o no, figura 4.5. A continuaci´on, se debe almacenar el objeto HTMLFormObject recibido de la vista en “localStorage” para poder ser recuperado posteriormente. En este momento se presenta la restricci´on de que s´olo pueden almacenarse cadenas de caracteres, y no existe ning´un procedimiento exitoso para serializar el objeto del formulario. En el caso de que este formulario tuviera unos campos definidos ser´ıa sencillo almacenar campo a campo, pero en nuestro caso, el formulario cambia dr´asticamente seg´un el tipo de informe de que se trate, haciendo muy necesario su almacenamiento en su totalidad. if(navigator.onLine){ handleSendList(informeForm); }else{ offlineSendList(informeForm); } Extracto de c´odigo 4.5: Detecci´on de conexi´on con el servidor en los formularios de creaci´on de informes Ante esto, se opt´o por obtener la cadena toString() del HTMLFormObject para lo cual se dispone de las propiedades innerHTML,outerHTML,textContent, de las cuales, las dos primeras devuelven ´unicamente c´odigo HTML sin los valores introducidos por el usuario en el formulario, y el ´ultimo devuelve ´unicamente los valores de los campos del formulario. No existe un m´etodo o propiedad que devuelva de forma sencilla la representaci´on en formato HTML del objeto junto a los valores de los campos. Para solventar esta problem´atica, se opt´o, en el caso de los informes de conjunto de extintores, conservaci´on de instalaciones y grupos contraincendios, por procesar los 124 Cap´ıtulo 4. Proyecto SuXSur valores del objeto formulario, y guardarlos en “localStorage” junto al nombre del campo, figura 4.6. var repeated_radios = []; let data = { ["Informe"+tipo+"?"+actaId]: {} }; for (const element of elements) { if (element.name.length > 0) { if(element.type === "radio" && !repeated_radios.includes( element.name)){ repeated_radios.push(element.name); data["Informe"+tipo+"?"+actaId][element.name] = elements[element.name].value; }else if(element.type != "radio"){ data["Informe"+tipo+"?"+actaId][element.name] = element .value; } } } // Almacenamos los valores del formulario en localStorage localStorage.setItem("Informe"+tipo+"?"+actaId, JSON.stringify(data ["Informe"+tipo+"?"+actaId])); Extracto de c´odigo 4.6: Procesamiento de los valores de los campos del formulario en informes create.js De esta forma, cuando el formulario fuera a ser enviado una vez se disponga de conexi´on se pueden incluir estos valores en el objeto HTMLFormObject seg´un el nombre de cada campo, y finalmente, procesar este objeto y almacenar el informe en la base de datos. En el caso de los informes de extintores o BIES/hidrantes, dado que siempre dispondr´an de los mismos campos para todos y cada uno de los extintores o BIES, se facilita la tarea pues se almacena, para cada campo, un array con los valores que toma para cada uno de los extintores o BIES, y una vez se recoja esta informaci´on desde “localStorage”, es sencillo recorrer estos arrays para registrar en la base de datos estas entidades. Finalmente, se ha determinado, en base al criterio del cliente, que sea en el momento en que se accede de nuevo al acta de revisi´on, una vez se dispone de cobertura, cuando se env´ıen de forma automatizada los informes guardados de forma offline, de forma que el t´ecnico no deba preocuparse por esta operaci´on. 4.3.3.4. Conclusiones Se abord´o en primer lugar la tarea n´umero dos, finalizando as´ı, la funcionalidad de creaci´on de todos y cada uno de los informes que puede contener un acta. Tambi´en se complet´o la tarea seis, de forma que dichos informes pudieran ser rellenados en 125 Cap´ıtulo 4. Proyecto SuXSur situaciones de cobertura o conexi´on nula. En cuanto a los problemas acaecidos fueron todos generados por la funcionalidad de funcionamiento sin cobertura, los cuales fueron todos resueltos a excepci´on de la necesidad de uso del protocolo “HTTPS” del “Service worker” que, como se ha comentado en el detalle de implementaci´on, se abordar´a una vez se vaya a desplegar el sistema en un entorno de producci´on. 126 Cap´ıtulo 4. Proyecto SuXSur 4.3.6. Sprint 5 (15 de abril – 28 de abril) 4.3.6.1. Introducci´on En este quinto sprint se abordaron, una vez finalizada el ´area de los informes de revisi´on y todas las problem´aticas que han supuesto, diversas funcionalidades que partan desde las operaciones CRUD de administradores, pasando por clientes y sus revisiones, hasta llegar a las actas de revisi´on donde se “conecta” con el ´area de informes; dando forma a la estructura central del sistema. 4.3.6.2. Sprint backlog Por ello, las tareas que se tomaron para este sprint, fueron: —Tarea-09: Creaci´on y modificaci´on de administradores. —Tarea-10: Creaci´on y modificaci´on de clientes. —Tarea-11: Generar revisi´on de un cliente. —Tarea-12: Generar revisiones correspondientes a un mes concreto. —Tarea-13: Mostrar, crear y modificar un acta de revisi´on. —Tarea-14: Aviso de campos sin rellenar antes de guardar un acta de revisi´on. 4.3.6.3. Detalle de la implementaci´on Las funcionalidades de mostrado, listado, creaci´on y modificaci´on de las entidades como administradores, clientes, revisiones y actas no supusieron mayor impedimento, pues la propuesta de Silence para ello, a´un siendo bastante manual y laboriosa, no supone ninguna dificultad. S´ı es de mayor inter´es la inclusi´on de la librer´ıa DataTables, de JavaScript, la cual se emple´o en las diferentes vistas de listado, como las de administrador, cliente o revisiones, permitiendo ordenarlas por sus distintos campos o realizar b´usquedas, adem´as de paginar los resultados, figura 4.39. 133 Cap´ıtulo 4. Proyecto SuXSur Figura 4.39: Listado de clientes con DataTables Esto se realiza a trav´es de una funci´on que recibe la tabla de clientes una vez ya se encuentre renderizada en la vista, y le aplica la librer´ıa, pudiendo definir diferentes aspectos de inter´es como el orden predeterminado de los datos, as´ı como las columnas que tendr´an la funcionalidad de poder ser filtrada por uno de sus valores, las n´umero dos, tres, cuatro, cinco y seis, en la figura 4.13. 134 Cap´ıtulo 4. Proyecto SuXSur function createDataTable() { $(’#clientes-list-table’).DataTable({ "order": [[1, "asc"]], "pageLength": 25, initComplete: function () { this.api().columns([2, 3, 4, 5, 6]).every(function () { var column = this; var select = $(’<select><option value=""></option ></select>’) .appendTo($(column.footer()).empty()) .on(’change’, function () { var val = $.fn.dataTable.util.escapeRegex( $(this).val() ); column .search(val ? ’ˆ’ + val + ’$’ : ’’, true, false) .draw(); }); column.data().unique().sort().each(function (d, j) { select.append(’<option value="’ + d + ’">’ + d + ’</option>’) }); }); }, }); } Extracto de c´odigo 4.13: Funci´on para aplicar la librer´ıa DataTables a la tabla de clientes en clientes list.js Por ´ultimo, se debe resaltar una de las funcionalidades implementadas, pues es una de las que m´as valor aporta al cliente por el sustancioso ahorro temporal y de recursos que supone: la generaci´on autom´atica de revisiones de los clientes de un mes concreto. Para ello, se presenta al usuario gerente un formulario de tipo modal, figura 4.40, en el listado de revisiones, donde puede seleccionar el mes que desea generar. 135 Cap´ıtulo 4. Proyecto SuXSur Figura 4.40: Modal de generaci´on de revisiones mensuales En aras de ejecutar este proceso, se deben realizar varias operaciones, comenzando por obtener los clientes que se revisan en el mes seleccionado; a continuaci´on, se itera sobre ellos para poder acceder a sus revisiones, verificar que no tienen una generada para el mes en cuesti´on, y en ese caso, crearla y almacenarla en la base de datos, figura 4.14. 136 Cap´ıtulo 4. Proyecto SuXSur // Traemos los clientes que se revisan el mes seleccionado clientesAPI.getByMes(mesAGenerar.split(" ")[0]) .then(clientes => { let i = 0; for (i = 0; i < clientes.length; i = i + 1) { let clienteId = clientes[i]["clienteId"]; // Accedemos a las revisiones del cliente let promiseCliente = clientesAPI.getRevisionesById( clienteId) .then(revisiones => { // Verificamos que no se genero una revision previa para ese cliente let nombresRevisiones = revisiones.map(( revision) => revision["titulo"]); let titulo = "Revision de " + mesAGenerar.split (" ")[0].toLowerCase() + " de " + mesAGenerar.split(" ")[1]; if (nombresRevisiones.indexOf(titulo) == -1) { // Creamos la revision para el cliente para el mes seleccionado let revisionForm = new FormData(); revisionForm.append("titulo", "Revision de " + mesAGenerar.split(" ")[0]. toLowerCase() + " de " + mesAGenerar. split(" ")[1]); revisionForm.append("finalizada", 0); revisionForm.append("clienteId", clienteId) ; let promiseRevision = revisionesAPI.add( revisionForm) .catch(error => messageRenderer. showErrorMessage(error)); promises.push(promiseRevision); } }).catch(error => messageRenderer.showErrorMessage( error)); promises.push(promiseCliente); } }) Extracto de c´odigo 4.14: Generaci´on de revisiones mensuales en revision list.js 137 Cap´ıtulo 4. Proyecto SuXSur 4.3.6.4. Conclusiones En este sprint se finalizaron funcionalidades vertebrales del sistema de gesti´on SuXSur como la creaci´on, listado y modificaci´on de revisiones, clientes, actas o administradores, adem´as de algunas funcionalidades adicionales como la librer´ıa DataTables, de gran utilidad, y la generaci´on de revisiones mensuales automatizada. En ello no se encontr´o mayor dificultad m´as all´a del poco nivel de automatizaci´on ofrecido por la propuesta del framework Silence, con su consecuente incremento en el tiempo dedicado frente a otros framework de desarrollo de frontend disponibles en el mercado. 138 Cap´ıtulo 4. Proyecto SuXSur 4.3.7. Sprint 6 (29 de abril – 12 de mayo) 4.3.7.1. Introducci´on En este sexto y ´ultimo sprint se abordaron las tareas de configuraci´on de los roles del sistema, as´ı como las restricciones de acceso de los mismos a las funcionalidades que no les correspondan, la asignaci´on de las revisiones a los t´ecnicos y otras funcionalidades accesorias como la generaci´on de copias de seguridad. 4.3.7.2. Sprint backlog Por ello, las tareas que se tomaron para este sprint, fueron: —Tarea-15: Configurar un login para usuarios. —Tarea-16: Introducir roles en los usuarios. —Tarea-17: Configurar registro de t´ecnicos en el sistema. —Tarea-18: Asignar revisi´on a un t´ecnico. —Tarea-19: Configurar vistas y acceso seg´un el rol. —Tarea-20: Configurar perfil del t´ecnico para a˜nadir su firma. —Tarea-21: Aviso en el informe de extintores/BIES del n´umero de ellos que hab´ıa el a˜no pasado y si falta alguno por revisar. —Tarea-22: Generaci´on de copias de seguridad. 4.3.7.3. Detalle de la implementaci´on En la tarea de implementar roles para permitir o denegar el acceso al usuario que est´e “logueado” en el sistema, se comenz´o por configurar el propio proyecto, explicitando qu´e campo de qu´e tabla de la base de datos determinar´a ese rol de cada usuario en el archivo settings.py, figura 4.15. Aparte de este peque˜no cambio, s´olo tuvo que explicitarse en cada endpoint del sistema, dentro de la anotaci´on @endpoint, cu´ales eran los roles que podr´ıan tener acceso al mismo, figura 4.16. USER_AUTH_DATA = { "table": "Usuario", "identifier": "username", "password": "password", "role": "role" } Extracto de c´odigo 4.15: Configuraci´on de roles en settings.py 139 Cap´ıtulo 4. Proyecto SuXSur @endpoint( route="/cliente/$clienteId", method="GET", sql="SELECT *FROM Cliente WHERE clienteId = $clienteId", auth_required=True, allowed_roles=["Gerente", "Tecnico"] ) def get_by_id(): pass Extracto de c´odigo 4.16: Ejemplo de endpoint de acceso restringido por rol en endpoints\clientes.py Como puede verse, la implementaci´on de la restricci´on de acceso a los endpoint propuesta por el framework Silence es verdaderamente sencilla y eficaz, pero supuso un reto en aquellos en los que, al mismo tiempo, deb´ıa verificarse el rol del usuario, y devolver un archivo, como pueden ser aquellos de generaci´on de documentos PDF de los informes. En el propio endpoint tuvo que recurrirse a otra anotaci´on para la definici´on de su ruta de acceso, adem´as de emplear una funci´on auxiliar del propio Silence que verifica la informaci´on de la sesi´on, figura 4.17. Por otro lado, tambi´en tuvieron que ser modificados los m´etodos JavaScript de acceso a la API, de forma que enviar´an la informaci´on de la sesi´on del usuario y, a la vez, indicaran el formato de la respuesta que reciben del endpoint al que acceden, figura 4.18. @manager.APP.route("/api/acta/<actaId>/pdfExtintores") def generate_pdf_Extintores(actaId): check_session(["Gerente"]) [...] Extracto de c´odigo 4.17: Endpoint de generaci´on de PDF de extintores en endpoints\actas.py getExtPDF: function (actaId) { return new Promise(function (resolve, reject) { axios({ url: ‘${BASE_URL}/acta/${actaId}/pdfExtintores‘, method: ’GET’, responseType: ’blob’, headers: {Token: sessionManager.getToken()} }) .then(response => resolve(response)) .catch(error => reject(error.response.data.message)); }); }, Extracto de c´odigo 4.18: M´etodo de API que accede al endpoint de generaci´on de PDF de extintores en api\actas.js 140 Cap´ıtulo 4. Proyecto SuXSur Por otra parte, fue necesario implementar un endpoint espec´ıfico para el registro de nuevos t´ecnicos en el sistema, puesto que aquel que propone Silence est´a orientado a que un usuario se registre por s´ı mismo, pero en el caso que nos concierne es el gerente el que realiza esta operaci´on. Afortunadamente, fue posible llevar a cabo esta tarea de forma sencilla con las propias herramientas que ofrece Silence, figura 4.19. Sin embargo, s´ı que fue necesario emplear librer´ıas de hashing en JavaScript para enviar la contrase˜na ya “hasheada” al endpoint y no viaje en claro en ning´un momento. La complicaci´on de esta tarea, fue encontrar el formato concreto de hash que usa la librer´ıa empleada por Silence, figura 4.20. @endpoint( route="/tecnico", method="POST", sql="INSERT INTO Usuario (username, password, nombre, apellidos , role) VALUES ($username, $password, $nombre, $apellidos, $role)", auth_required=True, allowed_roles=["Gerente"] ) def add(username, password, nombre, apellidos, role): pass Extracto de c´odigo 4.19: Endpoint de registro de t´ecnico en api\tecnicos.js function handleCreateTecnico(revisionForm) { let formData = new FormData(revisionForm); // Generamos el hash de la contrasena como lo haria el propio framework Silence, // que es el que se guardara en la base de datos let iterations = 150000; let salt = randomIdGenerator(7); let key512Bits = CryptoJS.PBKDF2(formData.get("password"), salt , { hasher:CryptoJS.algo.SHA256, keySize: 256 / 32, iterations: iterations }); let result = ‘pbkdf2:sha256:${iterations}$${salt}$${key512Bits. toString(CryptoJS.enc.Hex)}‘; formData.set("password", result); tecnicosAPI.add(formData) .then(_ =>window.location.href = "tecnico_list.html") .catch(error => messageRenderer.showErrorMessage(error)); } Extracto de c´odigo 4.20: M´etodo de creaci´on de t´ecnico en tecnico list.js Muy relacionado con este registro de t´ecnicos en el sistema est´a la asignaci´on de las revisiones a los mismos, que se ha permitido, para mayor comodidad, sea en el 141 Cap´ıtulo 4. Proyecto SuXSur listado de revisiones, mediante un men´u desplegable, figura 4.41. Esta funcionalidad no ha resultado compleja, pero su coexistencia con la librer´ıa DataTables, de forma que permitiera seguir filtrando por el nombre del t´ecnico seleccionado en el desplegable, s´ı que supuso ciertos retoques que tomaron su tiempo en ser ejecutados. Figura 4.41: Listado de revisiones con asignaci´on de t´ecnicos Por otro lado, la firma del t´ecnico es similar a la que se implement´o en el sprint tercero, figura 4.8, para el encargado del lugar de una revisi´on, pero en lugar de una cadena aleatoria, en este caso se usa el hash del nombre del t´ecnico como nombre del archivo de la firma, figura 4.21. Ello supuso recurrir a librer´ıas externas como sucedi´o con la propia contrase˜na del t´ecnico en su registro, pero en este caso, adem´as, sucede igual que con el “service worker”, que necesita que el navegador conf´ıe en el servidor para su correcto funcionamiento. 142