Aplicación web para monitorizar la seguridad ciudadana en España

id191453   APLICACIÓN WEB PARA MONITORIZAR LA SEGURIDAD CIUDADANA EN ESPAÑA RUBÉN DABRIO RAMÍREZ Director/a MARÍAJOSÉCASAÑGUERRERO(DepartamentodeIngenieriadeServiciosySistemasde Información) Titulación GradoenIngenieríaInformática(IngenieríadelSoftware) Memoria del trabajo de fin de grado Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 20/01/2025  Resumen Actualmente, la situación referente a la seguridad ciudadana en Cataluña es precaria y ha evolucionado de forma negativa en los últimos años. Existen herramientas que permiten monitorizar los delitos que han ocurrido en Cataluña pero tienen los datos desactualizados y no permiten ver con claridad si existe una tendencia negativa o no, por lo tanto, este proyecto se basa en construir una aplicación web que monitorice de forma interactiva los delitos en Cataluña y también en todas las demás comunidades autónomas de España. Además, la aplicación cuenta con tres tipos de predicciones en tiempo real hechas con Inteligencia Artificial. Resum Actualment, la situació referent a la seguretat ciutadana a Catalunya és precària i ha evolucionat de manera negativa en els darrers anys. Hi ha eines que permeten monitoritzar els delictes que han passat a Catalunya però tenen les dades desactualitzades i no permeten veure amb claredat si hi ha una tendència negativa o no, per tant, aquest projecte es basa en construir una aplicació web que monitoritzi de forma interactiva els delictes a Catalunya i també en totes les altres comunitats autònomes d'Espanya. A més, l'aplicació té tres tipus de prediccions en temps real fetes amb Intel·ligència Artificial. Abstract Currently, the situation regarding citizen security in Catalonia is precarious and has evolved negatively in recent years. There are tools that allow us to monitor the crimes that have occurred in Catalonia, but their data is outdated and do not allow us to clearly see whether there is a negative trend or not. Therefore, this project is based on building a web application that interactively monitors the crimes that have occurred in Catalonia and also in all the other autonomous communities of Spain. In addition, the application has three types of real-time predictions made with Artificial Intelligence. Índice de contenidos 1. Contextualización 3 1.1. Contexto del proyecto 3 1.2. Descripción del problema 3 1.3. Stakeholders 5 2. Justificación 6 2.1. Estudio de mercado 6 2.1.1. Mapa de delincuencia 6 2.1.2. Epdata 7 2.1.3. Tabla comparativa y conclusiones 7 3. Alcance del proyecto 9 3.1. Objetivos y subobjetivos 9 3.2. Requisitos funcionales y no funcionales 9 3.2.1. Requisitos funcionales 9 3.2.2. Requisitos no funcionales 10 3.3. Riesgos 10 3.4. Metodología 11 4. Descripción de las tareas 12 4.1. Inception 12 4.2. Sprint 1 13 4.3. Sprint 2 14 4.4. Sprint 3 14 4.5. Documentación final 15 4.6. Diagrama de Gantt 17 5. Gestión del riesgo 18 6. Presupuesto 19 6.1. Costes de personal por actividad 19 6.2. Costes generales 21 6.3. Costes de contingencia 21 6.4. Costes de imprevistos 22 6.5. Presupuesto final 22 7. Sostenibilidad 23 7.1. Marco ambiental 23 7.2. Marco económico 23 7.3. Marco social 23 7.4. Conclusiones 24 8. Especificación de requisitos 25 8.1. Proceso de obtención 25 8.2. Clasificación de los requisitos 25 8.2.1. Requisitos funcionales 25 8.2.2. Requisitos no funcionales 27 9. Arquitectura del sistema 29 9.1. Visión general 29 1 9.2. Patrones arquitectónicos usados 30 9.2.1. API REST 30 9.3. Diseño del backend 30 9.3.1. Base de datos en Firebase 30 9.3.2. Modelos predictivos y API REST 30 9.4. Diseño del frontend 31 9.4.2. Patrones de diseño 31 9.4.2.1. Composición de Componentes 31 9.4.2.2. Presentación y Contenedor 32 9.4.2.3. Hooks 32 9.4.2.4. Serverless functions 32 9.4.2. Colores 32 9.4.3. Navegación 33 9.4.4. Pantallas de la aplicación 33 10. Desarrollo 40 10.1. Recursos utilizados 40 10.1.1. Next.js 40 10.1.2. Vercel 41 10.1.3. FastAPI 41 10.1.4. TensorFlow 41 10.1.5. Render 41 10.1.6. Firebase 41 10.2. Hosting y deployment 42 10.3. Implementación de las historias de usuario 42 10.3.1. Ver mapa 42 10.3.2. Iniciar sesión 44 10.3.3. Filtrar por fecha, región, cantidad y tipo de delito 45 10.3.4. Activar/Desactivar mapa de calor 45 10.3.5. Ver distrito policial/comunidad autónoma 46 10.3.6. Filtrar historial de delitos por fecha y tipo de delito 46 10.3.7. Previsión de delito en distrito policial/comunidad autónoma 46 11. Testing 49 12. Conclusiones 51 12.1. Objetivos iniciales 51 12.2. Competencias técnicas 51 13. Referencias 54 14. Anexo 59 2 1. Contextualización 1.1. Contexto del proyecto Este proyecto está basado en la metodología y mejores requisitos del trabajo final de grado (también conocido como TFG), que es una de las últimas asignaturas obligatorias del grado en Ingeniería Informática que ofrece la Universidad Politécnica de Cataluña (UPC). A través de este, se quiere poner en práctica todos los conocimientos adquiridos durante la carrera desarrollando un proyecto profesional. En este caso, se realiza un TFG en modalidad A con la ayuda de algunos docentes de la universidad, como la tutora María José Casany, y está relacionado con la especialidad de Ingeniería del Software. Así pues, el proyecto consiste en el desarrollo de una aplicación web que permita monitorear la seguridad ciudadana en toda España. 1.2. Descripción del problema Es bien sabido que la situación social en Barcelona es precaria en algunas zonas. El aumento de la inseguridad en las calles responde a un problema multifactorial y es menos seguro salir a ciertas horas o en ciertos barrios. Así lo muestran los siguientes gráficos, provenientes del Ayuntamiento de Barcelona, que pertenecen a la encuesta anual Encuesta de victimización de Barcelona [1]. Dicha encuesta es una de las analíticas más amplias sobre el estado de la seguridad urbana a escala local y analiza la objetividad de la seguridad recogiendo los principales fenómenos delictivos que afectan a la población barcelonesa aportando información tanto de las características de los hechos delictivos como de sus víctimas. Figura 1 - Evolución del índice de victimización de Barcelona. Fuente: [6] 3 Figura 2 - Evolución del índice de hechos delictivos en Barcelona. Fuente: [7] Como podemos observar, el primer gráfico representa la evolución del índice de victimización, que muestra el porcentaje de personas que han sufrido delitos y en qué distritos. Si es cierto que del 2019 al 2020 hubo una disminución considerada del mismo, pero hay que tener en cuenta que en 2020 toda España estuvo confinada por COVID y había toque de queda. Aun después de la finalización oficial del confinamiento, muchísimos ciudadanos y ciudadanas seguían sintiéndose inseguros y establecían el mínimo contacto con el exterior, por tanto, podemos concluir que toda esta situación condiciona esta disminución del índice. Sigue siendo preocupante que, una vez acabada la época COVID, el índice creciese hasta esos 26,7 puntos en el 2022. En el segundo gráfico se muestra la evolución del índice de hechos delictivos, en el que se ve un incremento del mismo basándonos en explicaciones anteriores. Estos datos son públicos y cualquier persona puede encontrarlos, pero se debe buscar precisamente algo relacionado con el contexto de esta situación, no es algo que los medios televisivos ni las redes sociales hagan conocido para concienciar a la población del peligro que supone tener estas estadísticas. Por tanto, la idea principal del proyecto era monitorizar los delitos de Cataluña, pero como el problema que tiene Barcelona es prácticamente extensible a las demás regiones y además se han encontrado datos abiertos de toda España, la mejor opción es diseñar e implementar una aplicación web para que los usuarios puedan monitorizar los delitos de toda España, integrando el mapa de Cataluña en él. 4 1.3. Stakeholders Una vez descrito el problema, es importante definir correctamente qué Stakeholders intervienen en el proyecto. Estos se tratan de personas o entidades que son afectadas positiva o negativamente por el sistema y es fundamental tenerlos en cuenta para poder tener una capacidad de reacción y de adaptación excelentes para así poder mejorar el propósito o los requisitos del proyecto. Ciudadanos Los principales usuarios afectados positivamente son los ciudadanos de España, ya que podrán ver el historial de delitos de su comunidad autónoma o área básica policial (esta última solo en caso de Cataluña) en diferentes años y ver detalles específicos sobre estos que no se suelen mostrar para poder sacar conclusiones. Entidades gubernamentales y cuerpos policiales Aunque el propósito y trabajo de estos dos conjuntos son diferentes, el impacto positivo que puede tener poder ver todo este tipo de información es el mismo para ambos, ya que podrían gestionar recursos de manera más eficiente gracias a la app. Dueños de negocios locales Los más beneficiados son los que tienen su negocio local en Cataluña, ya que pueden ver si la región en la que están es más peligrosa que segura y cuál es su tendencia. De esta manera, pueden tomar medidas de protección extra o incluso crear nuevos protocolos de seguridad personalizados a su situación. Delincuentes Estos usuarios son los únicos a los que el proyecto afecta negativamente. La idea es que los stakeholders anteriores tomen consciencia de la situación y actúen en consecuencia para mejorar la problemática, por lo cual idealmente los delincuentes saldrían perjudicados. Desarrollador Es el encargado de desarrollar toda la aplicación web y redactar la documentación del proyecto, además de preparar la presentación del mismo. Directora La directora del TFG supervisa y controla el estado del proyecto de una manera iterativa e incremental. 5 2. Justificación En este apartado se realiza un estudio de mercado para verificar la viabilidad del proyecto a través de la búsqueda de sistemas similares y una tabla comparativa. 2.1. Estudio de mercado La mejor manera de comprobar la viabilidad de una idea antes de desarrollarla es ver si hay algún sistema hecho que ya haga algo parecido. En este caso he encontrado dos utilizando términos de búsqueda en Google como “aplicación delincuencia cataluña” o “datos delincuencia cataluña”, se verá de qué tratan y posteriormente una comparativa y su respectiva conclusión. 2.1.1. Mapa de delincuencia Esta herramienta interactiva, desarrollada por el Instituto Cartográfico y Geológico de Cataluña, utiliza las Dades Obertes de los Mossos d’Esquadra como input para generar un visor en forma de mapa. En él podemos ver a Cataluña dividida por áreas básicas policiales, cada una pintada de un tono de color diferente según cuántos sean el número de casos del año y tipo de delito seleccionados. En el primer selector, empezando por arriba, se puede seleccionar el título del Código Penal que tiene el delito a escoger y en el siguiente más abajo se puede seleccionar el tipo de hecho. También se puede ver un selector horizontal, en el que se puede escoger sobre qué año se quiere mostrar la información y por último una leyenda de la escala de colores junto a un desglose por meses de la información mostrada en el mapa. Figura 3 - Mapa delincuencial de Cataluña. Fuente: [2] 6 2.1.2. Epdata Epdata es una página web con multitud de gráficos sobre distintos temas que se puede buscar en su interfaz de manera rápida y sencilla. En este caso se ha buscado criminalidad en Barcelona y se ha escogido el primer resultado de búsqueda, de manera que se puede ver una gráfica de datos (estos sacados del ministerio del interior) y una breve descripción debajo. También se puede descargar la gráfica como imagen, descargar los datos como archivo csv e incluso se puede insertar como elemento iframe en un HTML básico. Más abajo se encuentran otro tipo de gráficos de comparación, como por ejemplo con el resto de España o su evolución respecto a estos años. De hecho se pueden explorar estos datos de manera más específica, en este caso existen gráficos individualizados para cada tipo de delito. Figura 4 - Estadísticas del crimen en Barcelona (EPdata). Fuente [4] 2.1.3. Tabla comparativa y conclusiones Una vez encontrados los únicos dos sistemas similares a la idea principal del proyecto, en esta tabla, creada por el autor de este trabajo, se muestran diferentes características y una puntuación en cada uno de los dos según como se adecúe en su sistema. 0 es nulo y 5 es muy alto. Mapa de delincuencia Epdata Fiabilidad de las fuentes 5 5 Interactividad 5 2 Exportación de los datos 0 4 Filtrado específico de los datos (p. ej. fechas) 3 2 7 4.3. Sprint 2 A. Configurar el mapa e integrar los datos de España: Filtrar los datos usando parámetros dummy para poder configurar el cómo se muestran en el mapa. Creación de un algoritmo de cálculo de límites para poder pintar las regiones de un color más cálido o menos en función del número de delitos en el tipo y año dummies. Pintado de las regiones siguiendo el cálculo de límites y añadido al efecto de hover la información del número de delitos. H: 30. D: 4.2.F. R: Dev. M: Ordenador, VSCode B. Crear filtros del mapa: Creación de componentes que leen los datos para poder filtrar el mapa dinámicamente por año, comunidad autónoma, tipo de delito, cantidad de delitos y activación/desactivación del mapa de calor. Reemplazo de los dummy de 1.3.A por los valores de los filtros. H: 40. D: 4.3.A. R: Dev. M: Ordenador, VSCode C. Integrar el mapa de Cataluña: Adaptación de los filtros creados para poder replicar su comportamiento pero usando los datos de Cataluña, divididos en ABP. Añadir un evento para que cuando se haga click en Cataluña, se abra el mapa de delitos de Cataluña. H: 25. D: 4.3.B. R: Dev. M: Ordenador, VSCode D. Testing: Probar que todas las funcionalidades desarrolladas no tengan ningún bug y que la combinación de filtros tenga el comportamiento esperado. Solucionar errores derivados. H: 10. D: 4.3.C. R: Dev. M: Ordenador, VSCode E. Revisión del Sprint: Comprobar el cumplimiento de los requisitos definidos. H: 1. D: 4.3.D. R: Dev. M: Ordenador F. Documentación del Sprint: Redactar documentación de las funcionalidades del Sprint actual. H: 1. D: -. R: Dev. M: Ordenador 4.4. Sprint 3 A. Configurar llamadas a la base de datos: Mirar documentación de Firebase y usar su API para programar los handlers. H: 3. D: 4.2.D. R: Dev. M: Ordenador, VSCode B. Integrar la gestión del usuario: Usar los handlers para crear y guardar usuarios mediante el Auth de google. Adaptar código para el manejo de usuarios. H: 10. D: 4.4.A. R: Dev. M: Ordenador, VSCode C. Ver detalles de la CCAA/ABP: Para cada región del mapa se añade un evento de click que abre un modal, en el que se ve el listado de todos los delitos por año. H: 5. D: 4.3.C. R: Dev. M: Ordenador, VSCode D. Formación Tensor Flow: Aprender a usar Tensor Flow en Python para crear modelos de predicción. H: 30. D: 4.2.A. R: Dev. M: Ordenador, VSCode 14 E. Crear modelo de previsión larga tendencia: Creación y entrenamiento del modelo de cada tipo de región para poder cargarlo y predecir. H: 12. D: 4.4.D. R: Dev. M: Ordenador, VSCode F. Crear modelo de previsión frecuencia diaria: Creación y entrenamiento del modelo de cada tipo de región para poder cargarlo y predecir. H: 12. D: 4.4.D. R: Dev. M: Ordenador, VSCode G. Crear modelo de previsión número de delitos: Creación y entrenamiento del modelo de cada tipo de región para poder cargarlo y predecir. H: 12. D: 4.4.D. R: Dev. M: Ordenador, VSCode H. Crear API de previsiones e integrar a Security Monitoring: Creación de una API con FastAPI en Python, crear los handlers que devuelven el valor predecido y deployarla. Hacer peticiones desde la app y adjuntar el resultado a la información del modal de cada región H: 17. D: 4.4.E, 4.4.F, 4.4.G. R: Dev. M: Ordenador, VSCode I. Testing: Probar todas las funcionalidades desarrolladas en el Sprint y solucionar errores. H: 5. D: 4.4.B, 4.4.H. R: Dev. M: Ordenador, VSCode J. Revisión del Sprint: Comprobar el cumplimiento de los requisitos definidos. H: 1. D: 4.4.I. R: Dev. M: Ordenador K. Documentación del Sprint: Redactar documentación de las funcionalidades del Sprint actual. H: 1. D: -. R: Dev. M: Ordenador 4.5. Documentación final A. Redacción de la memoria del TFG: Redactar la memoria del TFG. H: 33. D: -. R: Man. M: Ordenador B. Preparación de la presentación para la lectura del TFG: Preparar diapositivas y guión para la presentación. H: 3. D: 4.5.A. R: Man. M: Ordenador Código Nombre de tarea Dependencias Horas 4.1.A Elaboración de documento 1 - 35 4.1.B Elaboración de documento 2 4.1.A 35 4.1.C Elaboración de documento 3 4.1.B 35 4.1.D Elaboración de documento 4 4.1.C 25 4.1.E Definición de historias de usuario 4.1.D 5 4.2.A Preparación del entorno de desarrollo - 3 15 4.2.B Formación en tecnologías usadas 4.2.A 50 4.2.C Obtención y transformación de los datos 4.2.B 25 4.2.D Desarrollo de la interfaz inicial 4.2.C 10 4.2.E Integración de la librería para el mapa 4.2.D 25 4.2.F Testing 4.2.E 2 4.2.G Revisión del Sprint 4.2.F 1 4.2.H Documentación del Sprint - 1 4.3.A Configurar e integrar datos de España 4.2.F 30 4.3.B Crear filtros del mapa 4.3.A 40 4.3.C Integrar el mapa de Cataluña 4.3.B 25 4.3.D Testing 4.3.C 10 4.3.E Revisión del Sprint 4.3.D 1 4.3.F Documentación del Sprint - 1 4.4.A Configurar llamadas a base de datos 4.2.D 3 4.4.B Integrar gestión del usuario 4.4.A 10 4.4.C Ver detalles de CCAA/ABP 4.3.C 5 4.4.D Formación en Tensor Flow 4.2.A 30 4.4.E Creación modelo de larga tendencia 4.4.D 12 4.4.F Creación modelo de frecuencia diaria 4.4.D 12 4.4.G Creación modelo de número de delitos 4.4.D 12 4.4.H Creación e integración de API 4.4.E, 4.4.F, 4.4.G 17 4.4.I Testing 4.4.B, 4.4.H 5 4.4.J Revisión del Sprint 4.4.I 1 4.4.K Documentación del Sprint - 1 4.5.A Redacción de la memoria del TFG - 33 4.5.B Preparación de la presentación 4.5.A 3 Figura 7. Tabla de resumen de las tareas. Elaboración propia 16 4.6. Diagrama de Gantt Figura 8. Diagrama de Gantt. Elaboración propia usando GanttProject v3.3. 17 5. Gestión del riesgo Pueden haber varios obstáculos que retrasen una parte del desarrollo del proyecto. Es por eso que se debe estar preparado para poder gestionarlos de la mejor manera posible. Los posibles riesgos que pueden surgir son: ● Estancamiento en las formaciones. La probabilidad de que esto ocurra es alta, ya que al tener que aprender una o varias tecnologías nuevas es posible que no se entienda algún concepto o surjan dificultades de estructura de datos y sintaxis. La mejor manera de mitigar este riesgo es estimar con excesividad de horas las tareas de formación. ● Surgimiento de bugs. La probabilidad de que esto ocurra es alta, ya que al llevar a cabo las fases de testing de todas las funcionalidades desarrolladas durante el Sprint es común encontrarse con comportamientos inesperados de las mismas en situaciones muy específicas. La mejor manera de mitigar este riesgo es estimar con excesividad de horas las tareas de testing. 18 6. Presupuesto Una vez hechas las estimaciones y la definición de las tareas, es importante calcular el presupuesto del proyecto. Para ello se determinarán los siguientes tipos de coste: costes de personal por actividad, costes generales, costes de contingencia y coste de imprevistos. 6.1. Costes de personal por actividad Para determinar los costes de personal por actividad, es necesario dividir las horas de cada tarea en todos los roles que comportan un equipo de desarrollo estándar y calcular el coste de cada una en función del salario y coste de cada uno. El salario por hora se ha obtenido basándose en la información proporcionada por glassdoor [8] [9] [10] [11] [12] y el coste por hora se obtiene multiplicando por 1.3 el salario por hora. Rol Salario por hora (€) Coste por hora (€) Manager/Product Owner (M) 24,48 31,83 Desarrollador frontend (UI) 19,27 25,05 Desarrollador backend (B) 14,58 18,95 Arquitecto de software (A) 27,08 35,2 Tester (T) 13,28 17,26 Figura 9. Tabla de resumen de salarios y costes por rol. Elaboración propia Código Horas por rol Horas totales de la tarea Coste total de la tarea M UI B A T 4.1.A 35 35 1114,05€ 4.1.B 35 35 1114,05€ 4.1.C 35 35 1114,05€ 4.1.D 25 25 795,75€ 4.1.E 5 5 159,15€ 4.2.A 3 3 105,6€ 19 4.2.B 20 20 5 5 50 1142,3€ 4.2.C 25 25 473,75€ 4.2.D 10 10 250,5€ 4.2.E 22 3 25 607,95€ 4.2.F 2 2 34,52€ 4.2.G 0,5 0,5 1 22€ 4.2.H 0,5 0,5 1 22€ 4.3.A 20 7 3 30 739,25€ 4.3.B 40 40 1002€ 4.3.C 25 25 626,25€ 4.3.D 10 10 176€ 4.3.E 0,5 0,5 1 22€ 4.3.F 0,5 0,5 1 22€ 4.4.A 3 3 56,85€ 4.4.B 8 2 10 238,3€ 4.4.C 5 5 125,25€ 4.4.D 25 5 30 649,75€ 4.4.E 10 2 12 259,9€ 4.4.F 10 2 12 259,9€ 4.4.G 10 2 12 259,9€ 4.4.H 5 10 2 17 259,9€ 4.4.I 5 5 88€ 4.4.J 0,5 0,5 1 22€ 4.4.K 0,5 0,5 1 22€ 4.5.A 33 33 1050,39€ 4.5.B 3 3 95,49€ TOTAL 171 158 128 24 22 503 13050,95€ Figura 10. Tabla de costes por tarea y totales. Elaboración propia 20 6.2. Costes generales Los costes generales son los relacionados a costes materiales, de desplazamiento, de espacios… En este caso se calculan los costes generales teniendo en cuenta que cada miembro del equipo necesita un portátil y un espacio en el que trabajar. Alquilar una oficina sale demasiado caro, así que la mejor opción es utilizar un servicio de coworking como Coworking Spain. Según su página y sus servicios [13], una mesa fija en Ágora Coworking, situada en el barrio de San Andrés de Barcelona, cuesta 165€ al mes. Respecto al portátil, cada miembro del equipo dispondrá de un HP ProBook 440 G11 que cuesta 997,32€. Recurso Coste Unidades Coste total Coworking 165€/mes = 825€/5 meses 5 4125€ HP ProBook 440 G11 997,32€ 5 4986,6€ TOTAL 9111,6€ Figura 11. Tabla de resumen de recursos materiales y sus costes. Elaboración propia 6.3. Costes de contingencia Los costes de contingencia son sobrecostes para cubrir obstáculos no previstos. En el sector informático suele estar entre un 10%-20%, por lo que se fijará en un 15%. De esta manera, la tabla de costes de contingencia es la siguiente: Recurso Coste total Sobrecoste Coste de contingencia Costes de personal 13050,95€ 15% 1957,64€ Coworking 4125€ 15% 618,75€ HP ProBook 440 G11 4986,6€ 15% 747,99€ TOTAL 3324,38€ Figura 12. Tabla de resumen de los costes de contingencia. Elaboración propia 21 6.4. Costes de imprevistos Los costes de imprevistos son aquellos relacionados a los riesgos que podrían surgir durante el desarrollo del proyecto. En la definición de los mismos, también se hizo la descripción de la solución, que consistía en sobreestimar las tareas de formación y de testing. En la tabla siguiente, se muestran los costes de imprevistos, calculados a partir de la probabilidad de que sucedan, las horas previstas de afectación y el coste por hora de los roles afectados. Riesgo Probabilidad Tiempo y roles Coste Estancamiento en formaciones 80% Frontend - 20h 400,8€ Backend - 20h 303,2€ Arquitecto - 3h 84,48€ Surgimiento de bugs 95% Tester - 10h 163,97€ TOTAL 952,45€ Figura 13. Tabla de resumen de los costes de imprevistos. Elaboración propia 6.5. Presupuesto final El presupuesto final está formado por la suma de todos los tipos de costes mencionados y calculados anteriormente. Tipo de coste Coste Costes de personal 13050,95€ Costes generales 9111,6€ Costes de contingencia 3324,38€ Costes de imprevistos 952,45€ TOTAL 26438,38€ Figura 14. Tabla de resumen del presupuesto final. Elaboración propia 22 7. Sostenibilidad La encuesta sobre sostenibilidad da al usuario una visión sobre su conocimiento actual en los distintos marcos de esta. Una vez respondida, es importante evaluar el nivel de conocimientos en los 3 pilares principales. 7.1. Marco ambiental Respecto al ambiental, tomo consciencia de todos los productos electrónicos que he consumido a lo largo de la carrera así como los desechos que se producen al fabricarlos. También estoy actualizado sobre la reducción, reutilización y reciclaje de los mismos, así que estoy comprometido con la mejora del medio ambiente. Al ser un producto no físico, el impacto ambiental que tendrá el desarrollo del proyecto será muy pequeño. El aspecto más relevante será la compra de portátiles para el equipo, pero el impacto se mitigará al final del proyecto, donde se regalarán a un instituto de secundaria para que 5 alumnos puedan disfrutar de ellos. Actualmente lo que se suele hacer es enviar las piezas a reutilización, cosa que también se hará al cabo de unos años de funcionamiento. 7.2. Marco económico En el marco económico ha sido fácil saber que soy capaz de calcular los costes para el desarrollo y mantenimiento de software, así como realizar un estudio de mercado para poder identificar las cosas en las que mi proyecto podría destacar respecto a la competición. Es cierto que el coste es elevado, pero la mayor parte del presupuesto va destinado al personal, que es lo que se paga actualmente en el mercado español. Cómo será un software de uso gratuito, el presupuesto será como una inversión para la sociedad, con el fin de mejorar los aspectos mencionados en la descripción del problema. 7.3. Marco social Por último, en el marco social me he dado cuenta del impacto que puede tener en la sociedad el desarrollo de software, que está estrechamente relacionado con los principios éticos de la informática (como la seguridad y confidencialidad de los datos privados). De esta manera soy capaz de producir un software que los respete. A nivel personal, este proyecto me provocará un sentimiento de filantropía grande, ya que lo único que busco es poder facilitar la visión de ciertos tipos de datos de una manera clara y concisa para poder poner en situación a entidades gubernamentales y a la población y así 23 9.2. Patrones arquitectónicos usados 9.2.1. API REST Como se ha visto en el apartado de visión general, el backend crea y entrena modelos predictivos y permite su uso a través de la implementación de una API. Bien, esta es una API REST [30], un patrón arquitectónico que se usa para diseñar APIs para que cumplan una serie de reglas y unos estándares de calidad. Algunas reglas pueden ser: el manejo de todos los códigos de estado [31] tanto en la petición como en la respuesta, el uso correcto de los métodos HTTP [32], separación de código cliente y servidor, uniformidad y que las respuestas sean cacheables [33]. En el siguiente apartado se explica detalladamente el diseño de la API 9.3. Diseño del backend 9.3.1. Base de datos en Firebase La base de datos alojada en Firebase solamente contiene una tabla, la de usuarios. Son los únicos datos que necesita guardar esta aplicación, ya que los correspondientes a los delitos solamente se leen, cuyo uso se explicará en el apartado de desarrollo. Como se usa NextAuth.js para usar el proveedor de Google, en la tabla solamente se guarda el nombre de usuario, esto es suficiente para dejar constancia de que ese usuario de Google está registrado en la aplicación. 9.3.2. Modelos predictivos y API REST La arquitectura de esta parte del backend está formada por la API y los modelos. Es importante recalcar que debido a la diferencia de la estructura de datos entre abp y comunidad autónoma, se han tenido que crear modelos específicos para cada uno de ellos. En el apartado 10 está explicado la estructura de carpetas de la API. Por último, se encuentra el archivo main.py que incluye la inicialización de la API y la definición de las rutas. 30 Endpoint * Descripción Método HTTP Parámetros query /api/ccaa/DF/predict Obtiene la predicción de frecuencia diaria de una comunidad en un año GET comunidad: string año: int /api/ccaa/LT/predict Obtiene la predicción de larga tendencia de una comunidad en un año GET comunidad: string año: int /api/ccaa/NC/predict Obtiene la predicción de número de delitos de una comunidad en un año GET comunidad: string año: int /api/abp/DF/predict Obtiene la predicción de frecuencia diaria de una abp en un año GET comunidad: string año: int /api/abp/LT/predict Obtiene la predicción de larga tendencia de una abp en un año GET comunidad: string año: int /api/abp/NC/predict Obtiene la predicción de número de delitos de una abp en un año GET comunidad: string año: int * La URL base es: https://security-monitoring-backend.onrender.com Figura 16. Tabla de resumen de los endpoints de la API. Elaboración propia 9.4. Diseño del frontend 9.4.2. Patrones de diseño 9.4.2.1. Composición de Componentes Conocido generalmente como Composite [24], es usado implícitamente por el desarrollador que trabaja con React o Next.js, ya que la propia existencia de React implica la componentización. Esta se basa en la creación de pequeños fragmentos de código con el objetivo de ser reutilizables, personalizables y más eficientes. Además, este patrón permite crear componentes en estructura de árbol de manera incremental. Por ejemplo, si el componente padre es la página principal, habrá un componente mapa que represente el contenedor del mapa de la aplicación. Este mapa contendrá un componente que contiene los filtros y otro componente que se encargará de renderizar el mapa, y así sucesivamente. 31 9.4.2.2. Presentación y Contenedor El patrón de Presentación y Contenedor [25] surge de la necesidad de desacoplar lógica y renderizado de UI en el frontend para evitar utilizar observables que estén constantemente preguntando sobre el estado del componente. La utilización del patrón cumple con esta necesidad simplemente creando componentes que se dediquen exclusivamente a manejar lógica o a renderizar UI y combina muy bien con el anterior. En el proyecto se ha decidido utilizar al componente con una jerarquía superior en el árbol para manejar la lógica, mientras que los demás consumen los datos proporcionados por el primero para renderizar la interfaz deseada. 9.4.2.3. Hooks Los hooks son funciones predefinidas en React que facilitan el manejo del estado de la aplicación [26]. Estos no son patrones en sí, pero con el paso del tiempo se ha popularizado el uso de cierta estructura en React usando los hooks de estado y de efecto [27] que dan mucha solidez a cualquier aplicación construida con el. En el proyecto se usa esta estructura popularizada a la que podríamos llamar patrón. Se usa el hook de efecto para hacer un fetching de los datos cuando se carga la aplicación y así asegurar tenerlos todos, sin ninguna asincronicidad presente, para que el usuario pueda usar el sistema sin interrupciones. Se usa el hook de estado para guardar estos datos en objetos mutables que gracias a la interacción del usuario con la interfaz gráfica pueden cambiar, por ejemplo cuando lo hace con los filtros. 9.4.2.4. Serverless functions Este tipo de funciones [28] es una forma que tiene Next.js de crear y ejecutar llamadas API [29] dentro del frontend. Son muy útiles para separar el código en dos capas, la de cliente (lo que se renderiza) y la de servidor (para manejar lógica de servidor). Es decir, en este caso separa la renderización de los componentes (tanto los que manejan lógica como los de UI) de las llamadas asíncronas a la base de datos. De esta manera, se crea un endpoint en el que se pueden ejecutar métodos servidor para la comunicación con la base de datos de Firebase que consume el componente que maneja la lógica, después este tratará los datos tal y como se explica en el patrón Presentación y Contenedor. 9.4.2. Colores Para el desarrollo de la interfaz de usuario, se pueden distinguir dos grupos de colores que dotan a la aplicación un contraste atractivo: el de la escala de grises y el del mapa de calor. 32 El de la escala de grises se usa en los filtros (aunque los selectores usan un azul pastel hex. #2684FF) y en el modal de información de la región; está formada por #222222, #F5F5F5, #666666, #DDDDDD, #000000, #FFFFFF. El del mapa de calor se usa en el mapa y en la información estilo leyenda de los límites calculados y está formado por un amarillo pastel hex. #FBE69F, un naranja pastel hex. #FFCC80, un naranja oscuro pastel hex. #EF6C00 y un rojo pastel hex. #FF0000. 9.4.3. Navegación Al ser una SPA o una Single Page Application [36], no hay ninguna navegación entre páginas pero sí una clara navegación interna con modals. Cuando se da click en una región del mapa, se abre un modal con la información adicional y la posibilidad de hacer una predicción. Además, si se trata de Cataluña, se abrirá un modal que hace escoger al usuario si quiere cargar el mapa de la comunidad o si prefiere ver su información. Además, cuando se presiona el botón de iniciar sesión, hay una navegación interna hacia el proveedor de Google que da a escoger al usuario la cuenta con la que quiere iniciar sesión en la aplicación. Haga la acción que haga, se le redirige a la aplicación de nuevo. 9.4.4. Pantallas de la aplicación a) Visión por defecto al acceder a la aplicación con el filtro de calor activado Es el estado inicial de la aplicación, se muestran los datos de todas las comunidades autónomas de todos los tipos de delito en el año 2022. Se pueden ver las dos comunidades con más de 61857 delitos pintadas de color rojo. 33 b) Filtro de heatmap desactivado Es el estado inicial de la aplicación pero sin los colores correspondientes al degradado de color en el mapa. c) Cambio de tipo de delito a filtrar Se muestran los datos de todas las comunidades del delito “Contra la libertad” del año 2022. Para este tipo de delito no hay tantas comunidades en estados críticos. 34 d) Cambio de región en los filtros Se muestra únicamente el color correspondiente a la comunidad seleccionada (Cataluña) del delito “Contra la libertad” en el 2022. e) Uso del filtro de cantidad Se muestran los colores correspondientes a las comunidades cuya cantidad de delitos para el delito “Contra la libertad” en el 2022 sea superior o igual al especificado (2000). 35 f) Uso del filtro de año Se muestran los datos de todas las comunidades del delito “Contra la libertad” pero del año 2018. En este año Cataluña no estaba tan crítica. g) Hover en región Al pasar el cursor por encima de una región, se marcan sus límites y se muestra un tooltip con su nombre y el número de delitos que le corresponde según el valor de los filtros. 36 h) Click en región sin haber iniciado sesión Se muestra un modal con el historial de todos los tipos de delitos para la comunidad en la que se ha hecho click y en el año seleccionado en el filtro. Las previsiones de IA no están disponibles, ya que el usuario no ha iniciado sesión en la aplicación. i) Click en Cataluña Al hacer click en la región de Cataluña, se abre un modal en el que se puede seleccionar si se quiere ver su mapa de delitos, la información de la región o cerrar el modal. 37 j) Vista del mapa de Cataluña Se muestra el mapa de Cataluña dividida en áreas básicas policiales. Su estado inicial se compone de los datos de todas las regiones, todos los tipos de delitos y el año 2024 (hasta Marzo). Tiene las mismas funcionalidades que el mapa de España. k) Sesión iniciada Cuando se inicia sesión, el botón de “Iniciar sesión” se reemplaza por la foto que tiene el usuario en su cuenta de Google. Si hace click en ella, se muestra su nombre de usuario y la opción de cerrar sesión. 38 l) Información de región con sesión iniciada Se muestra el modal de información de Cataluña con la parte de previsiones de IA disponibles para usar, ya que se ha iniciado sesión. m) Ejemplo de cálculo de previsión para una región Se muestra el resultado que la aplicación devuelve al calcular la previsión del número de delitos que tendrá Cataluña en 2023, que en este caso es de unos 86884. 39 10.3.5. Ver distrito policial/comunidad autónoma La implementación de esta funcionalidad está dividida en varias partes: ● Eventos. Se crean eventos, configurándolos con la librería usada para crear el mapa, para que al hacer click en cada región se abra un modal. ● Tabla de delitos. Se construye una tabla vacía con las columnas: “Tipo de delito”, “Año seleccionado” y “Número”. ● Previsiones. Se construye el frontend de la parte de previsiones, formado por tres opciones: Frecuencia diaria, Tendencia LP y Año posterior. Al hacer click en cada opción, aparece una breve descripción de qué calcula cada tipo de previsión, el botón de calcular y un espacio donde aparecerá el resultado. En este punto no ocurre nada al hacer click en los botones de “calcular”. ● Construcción del modal de Cataluña. En el caso de hacer click en Cataluña, se abre un modal intermediario con dos opciones: “Ver mapa de delitos de Cataluña” y “Ver información de Cataluña”. Al hacer click en la primera, se carga el mapa correspondiente a Cataluña y sus regiones. Al hacer click en la segunda, se carga el modal de información que contiene la tabla de delitos y las previsiones. 10.3.6. Filtrar historial de delitos por fecha y tipo de delito Se adapta el código para pasar por parámetro, al modal de información de región, los datos correspondientes al año seleccionado en los filtros del mapa y a la región que ha disparado el evento de click. Estos datos están formados por todos los tipos de delito existentes en la región y año, el año y el número de delitos correspondiente a la intersección entre región, año y tipo de delito. Además, se programa la tabla para construir filas dinámicamente, que tiene tantas filas como tipos de delito hay en los datos. 10.3.7. Previsión de delito en distrito policial/comunidad autónoma Igual que la primera historia de usuario, la implementación de esta también ha sido de las más complejas y que ha requerido más tiempo. Hay que tener en cuenta que, aunque el proceso de entrenamiento de los modelos sea el mismo, existen dos versiones de cada tipo de previsión por la misma razón que en la primera historia de usuario se hicieron dos scripts para procesar los datos. El proceso fue el siguiente: ● Definición de los modelos. Para cada uno de los tres tipos de previsión (frecuencia de delitos diaria, tendencia de delitos diaria a largo plazo y delitos en año posterior) se decidieron utilizar unos modelos de previsión u otros según la forma en la que deberían tratarse los datos para conseguir el resultado adecuado. 46 ○ Para la frecuencia de delitos diaria, se quiere hacer una previsión de los delitos exactos por día en los siguientes 10 días. Se usa una arquitectura híbrida que combina redes neuronales convolucionales unidimensionales (CNN 1D) [49] y redes neuronales de memoria a corto y largo plazo (LSTM) [50]. CNN 1D extrae características de los datos y detecta patrones en conjuntos pequeños de datos (como tendencias), mientras que LSTM procesa las características extraídas y captura las relaciones temporales y la dependencia a largo plazo en los datos. ○ Para la tendencia de delitos diaria a largo plazo, se quiere hacer una previsión de la media a largo plazo de los delitos por día durante el próximo año. Se usa una Unidad Recurrente Cerrada (GRU) [51], que es una variante simplificada del LSTM y permite capturar las relaciones y dependencias temporales entre los datos. ○ Para los delitos en año posterior, se quiere hacer una previsión aproximada del número de delitos que se cometerían durante el próximo año. Para éste también se usa el LSTM pero con la técnica Dropout [52], que permite hacer que el modelo generalice los datos en el entrenamiento, es decir, que se centre en converger en un número a largo plazo. ● Entrenamiento de los modelos. Se programa en Python, usando TensorFlow, el entrenamiento de los modelos descritos anteriormente. Los datos que se les da a los modelos como input para entrenarlos son todos los obtenidos de los script creados en la primera historia de usuario, o lo que es lo mismo, los que se usan para mostrar la información en la aplicación web. Cada modelo al ser entrenado genera un archivo. Por cada uno, se crea un programa en Python que lo carga y que permite hacer una predicción sobre el modelo entrenado que ha generado ese fichero, pasándole como parámetro la región y el año deseados. ● Creación de la API. Por cada modelo y tipo de región (comunidad autónoma, área básica policial) se crea un endpoint de tipo GET usando FastAPI, explicados en el apartado de arquitectura del backend. Cada uno de ellos, según el modelo del cual se quiera obtener la predicción, llama a la función de predecir del fichero correspondiente (que es uno de los últimos creados, los que cargan el archivo generado por el entrenamiento de cada modelo). Cuando obtienen el resultado de la predicción, envían una respuesta a la petición con el mismo. La documentación de los endpoints están disponibles en el apartado del diseño del backend, en la figura 16. ● Integración de la API. En el frontend se crea el evento de lanzar una petición a los diferentes endpoints al hacer click en el botón de “calcular” del modal de información 47 de región. Según si la región es un área básica policial o una comunidad autónoma y el tipo de predicción escogido, se hará la petición a un endpoint u otro. Cuando se recibe la respuesta, se mostrará en la caja correspondiente. 48 11. Testing Para realizar el testing del sistema se han seguido dos métodos: pruebas en la interfaz y pruebas que han realizado usuarios sin conocimientos previos de la aplicación. En el primero, se probaban de forma manual todas las funcionalidades desarrolladas en el Sprint (incluyendo los endpoints de la API) al final del mismo de la siguiente manera: ● Sprint 1. El objetivo era que el fetching de los datos fuese correcto, que no hubiese momentos en los que el mapa intentara leer datos que no existen y que los límites de las fronteras en el mapa estuviesen bien definidos. Se consiguió probar todo esto recargando la página varias veces con comentarios en el código para ver en qué orden se ejecutaban las cosas y utilizando las herramientas de desarrollador en Google Chrome para asignarle más o menos carga de red. ● Sprint 2. El objetivo era que la combinación de filtros tuviera el comportamiento esperado. Se consiguió probar haciendo algo parecido a un test de carga pero con los filtros de ambos mapas, es decir, cambiando sus valores rápidamente y sin descanso comprobando que los valores tuviesen sentido gracias a comentarios en el código que mostraban el conjunto de objetos filtrados. ● Sprint 3. El objetivo era que la llamada a la API de predicciones funcionase correctamente, que la tabla del modal cargara bien los datos y generalmente, que toda la aplicación no tuviese ningún error. Se consiguió probar haciendo también una especie de test de carga a la API, usando las herramientas de desarrollador en Google Chrome para asignarle más o menos carga de red, seleccionando las regiones una a una para ver si cargaba correctamente la tabla en el modal y comprobando que los datos de las predicciones tuviesen sentido según el número anual de delitos en la región seleccionada. Para realizar las pruebas con la ayuda de usuarios sin conocimientos previos en la aplicación, se reunieron a 5 personas del círculo cercano del realizador del proyecto y se les hizo una visita guiada por la aplicación en vivo, en la cual se les iba explicando las acciones que podían hacer y la finalidad de las mismas mientras ellos las reproducían. El feedback que dieron fue el siguiente: ● Usuario 1. El mapa tardaba un poco en cargar al principio ● Usuario 2. El filtro de cantidad era poco intuitivo. ● Usuario 3. Los límites en la leyenda no se veían mucho. ● Usuario 4. El Login es demasiado discreto. ● Usuario 5. La cruz para cerrar el modal era demasiado pequeña. 49 ● Feedback común. Los colores son armoniosos, la UI de los filtros y los botones es bonita, los tooltip dan buena información, la aplicación es rápida, que se pueda buscar en los selectores de delito y región es un buen punto, las interacciones con los mapas son buenas, la previsión con IA es interesante. A partir de los errores encontrados en el primer método se ha mejorado la calidad del código y de la lógica del mismo, mientras que a partir del segundo método se ha mejorado la usabilidad, la experiencia de usuario y la interfaz de usuario. 50 12. Conclusiones Después de realizar todo el proyecto, es importante concluir si se satisfacen todos los objetivos iniciales y las competencias técnicas y de qué manera. 12.1. Objetivos iniciales El primer objetivo principal era ofrecer a las partes interesadas una herramienta en forma de mapa interactivo para poder ver la evolución de los delitos en España. Dada la calidad de información que provee la herramienta y la forma tan gráfica y descriptiva que tiene de mostrar los datos, potencialmente podría servir de gran ayuda para estas entidades al analizar el crecimiento de delitos de alguna región o para ver la situación actual, así que se podría decir que el objetivo está cumplido. Un objetivo secundario o subobjetivo era desarrollar una aplicación web que permita consultar al usuario los tipos de delitos en cada una de las comunidades autónomas y áreas básicas policiales visualizados en un mapa usando filtros y previsiones con inteligencia artificial. Este objetivo se ha cumplido completamente, puesto que lo que se describe en él son funcionalidades desarrolladas durante los diferentes Sprints. Otro objetivo secundario o subobjetivo era ser capaz de construir un back-end y una API para unir todos los datos referentes a los delitos en un solo sitio y poder ser consultados de forma fácil. Aunque no se vea tan claro como el objetivo anterior, el back-end y la API existen y están desplegados en Render, además de que la consulta de las previsiones es un requerimiento también desarrollado durante los diferentes Sprints. Por tanto, se puede concluir que el proyecto ha satisfecho los 3 objetivos definidos en la Inception. Aunque el criterio de cumplimiento primer objetivo pueda ser de carácter subjetivo según quién use la herramienta, lo cierto es que los criterios de los otros dos objetivos son de carácter objetivo y se puede comprobar su cumplimiento utilizando la aplicación. 12.2. Competencias técnicas 12.2.1. CES1.1 Descripción: Desarrollar, mantener y evaluar sistemas y servicios software complejos y/o críticos. Nivel de satisfacción esperado: Bastante. Nivel de satisfacción real: Bastante. 51 Justificación: Se ha desarrollado y mantenido una aplicación formada por un frontend y por un backend, ambos separados y con total independencia. 12.2.2. CES1.3 Descripción: Identificar, evaluar y gestionar los riesgos potenciales asociados a la construcción de software que pudieran presentarse. Nivel de satisfacción esperado: Un poco. Nivel de satisfacción real: Un poco. Justificación: En la Inception se identificaron los posibles riesgos que podrían surgir durante el desarrollo del proyecto y se prepararon planes de mitigación. Estos se aplicaron y resultaron en éxito. 12.2.3. CES1.4 Descripción: Desarrollar, mantener y evaluar servicios y aplicaciones distribuidas con soporte de red. Nivel de satisfacción esperado: Bastante. Nivel de satisfacción real: Mucho. Justificación: Una aplicación web depende completamente de la red y como su gestión puede afectar al rendimiento de la misma. En este caso he desarrollado un frontend y un backend con soporte en web, aunque este último podría considerarse servicio también. 12.2.4. CES1.5 Descripción: Especificar, diseñar, implementar y evaluar bases de datos. Nivel de satisfacción esperado: Un poco. Nivel de satisfacción real: Un poco. Justificación: Se ha hecho uso de Firebase y de su SDK para especificar, diseñar y evaluar una base de datos para la gestión de usuarios. Aunque tenga una arquitectura pequeña, cumple con su objetivo dentro del proyecto. 12.2.5. CES1.6 Descripción: Administrar bases de datos (CIS4.3). Nivel de satisfacción esperado: Un poco. Nivel de satisfacción real: Un poco. Justificación: Por la misma razón que en la justificación de CES1.5, una vez diseñada e implementada, se ha tenido que mantener y administrar para su correcto funcionamiento en la aplicación. 52 12.2.6. CES1.7 Descripción: Controlar la calidad y diseñar pruebas en la producción de software. Nivel de satisfacción esperado: Un poco. Nivel de satisfacción real: Bastante. Justificación: Se ha dedicado bastante tiempo al testing y gracias a él se han detectado bastantes bugs y se han solucionado, aumentando mucho la calidad del código y de la experiencia de usuario. 12.2.7. CES2.1 Descripción: Definir y gestionar los requisitos de un sistema software. Nivel de satisfacción esperado: Bastante. Nivel de satisfacción real: Bastante. Justificación: El hecho de pasar de una idea a una definición de requisitos y crear con éxito un sistema que refleja todos ellos, hace que se cumpla satisfactoriamente esta competencia. 12.2.8. CES2.2 Descripción: Diseñar soluciones apropiadas en uno o más dominios de aplicación, utilizando métodos de ingeniería del software que integren aspectos éticos, sociales, legales y económicos. Nivel de satisfacción esperado: Bastante. Nivel de satisfacción real: Bastante. Justificación: Se ha diseñado una solución utilizando patrones de diseño, patrones arquitectónicos, metodología Agile, varias tecnologías y con un buen resultado. Además, en la Inception se definieron los aspectos éticos, sociales, legales y económicos que el sistema tendría en cuenta. 53 13. Referencias 1. Ajuntament de Barcelona, "Enquesta de victimització de Barcelona", Seguretat i Prevenció - Ajuntament de Barcelona. Disponible: https://ajuntament.barcelona.cat/seguretatiprevencio/ca/documentacio/enquesta-de-victimitz acio-de-barcelona (Accedido: 19-Sept-2024). 2. Institut Cartogràfic i Geològic de Catalunya, "Mapa Delinqüencial", Visors ICGC. Disponible: https://visors.icgc.cat/mapa-delinquencial/ (Accedido: 19-Sept-2024). 3. Mossos d'Esquadra, "Dades obertes", Generalitat de Catalunya - Mossos d'Esquadra. Disponible: https://mossos.gencat.cat/ca/els_mossos_desquadra/indicadors_i_qualitat/dades_obertes/in dex.html (Accedido: 19-Sept-2024). 4. EPDATA, "Crimen, asesinatos, robos, secuestros y otros delitos registrados en cada municipio: Barcelona", EPDATA. Disponible: https://www.epdata.es/datos/crimen-asesinatos-robos-secuestros-otros-delitos-registrados-c ada-municipio/6/barcelona/1325 (Accedido: 19-Sept-2024). 5. Gobierno de España, "Portal de datos abiertos", Datos.gob.es. Disponible: https://datos.gob.es/es/ (Accedido: 19-Sept-2024). 6. Ajuntament de Barcelona, "Evolució de l’índex de criminalització de Barcelona", Seguretat i Prevenció - Ajuntament de Barcelona. Disponible: https://ajuntament.barcelona.cat/seguretatiprevencio/sites/default/files/2023-08/Victimitzacio _BCN_Informe_2023.PDF pg.40 (Accedido: 19-Sept-2024). 7. Ajuntament de Barcelona, "Evolució de l’índex de fets delictius de Barcelona", Seguretat i Prevenció - Ajuntament de Barcelona. Disponible: https://ajuntament.barcelona.cat/seguretatiprevencio/sites/default/files/2023-08/Victimitzacio _BCN_Informe_2023.PDF pg.42 (Accedido: 19-Sept-2024). 8. Glassdoor, "Sueldos de Product Owner", Glassdoor España. Disponible: https://www.glassdoor.es/Sueldos/product-owner-sueldo-SRCH_KO0,13.htm (Accedido: 03-Oct-2024). 9. Glassdoor, "Sueldos de Front End Developer", Glassdoor España. Disponible: https://www.glassdoor.es/Sueldos/front-end-developer-sueldo-SRCH_KO0,19.htm (Accedido: 03-Oct-2024). 54 10. Glassdoor, "Sueldos de Backend Developer", Glassdoor España. Disponible: https://www.glassdoor.es/Sueldos/backend-developer-sueldo-SRCH_KO0,17.htm (Accedido: 03-Oct-2024). 11. Glassdoor, "Sueldos de Arquitecto de Software", Glassdoor España. Disponible: https://www.glassdoor.es/Sueldos/arquitecto-de-software-sueldo-SRCH_KO0,22.htm (Accedido: 03-Oct-2024). 12. Glassdoor, "Sueldos de QA Tester", Glassdoor España. Disponible: https://www.glassdoor.es/Sueldos/qa-tester-sueldo-SRCH_KO0,9.htm (Accedido: 03-Oct-2024). 13. Coworking Spain, "Coworking Sant Andreu", Coworking Spain. Disponible: https://coworkingspain.es/espacios/coworking/barcelona/coworking-sant-andreu (Accedido: 03-Oct-2024). 14. Diagrams.net, "Diagrams.net", Diagrams.net. Disponible: https://app.diagrams.net/ (Accedido: 08-Nov-2024). 15. Vercel, "Vercel", Vercel. Disponible: https://vercel.com/ (Accedido: 08-Nov-2024). 16. Next.js, "Next.js", Next.js. Disponible: https://nextjs.org/ (Accedido: 08-Nov-2024). 17. Tailwind.css, “Tailwind.css”, Tailwind.css. Disponible: https://tailwindcss.com/ (Accedido: 08-Nov-2024). 18. Firebase, “Firebase”, Firebase. Disponible: https://firebase.google.com/ (Accedido: 08-Nov-2024). 19. NextAuth.js, “NextAuth.js”, NextAuth.js. Disponible: https://next-auth.js.org/ (Accedido: 08-Nov-2024). 20. Tensorflow, “Tensorflow”, Tensorflow. Disponible: https://www.tensorflow.org/ (Accedido: 08-Nov-2024). 21. FastAPI, “FastAPI”, FastAPI. Disponible: https://fastapi.tiangolo.com/ (Accedido: 08-Nov-2024). 22. Atlassian, "Historias de usuario", Atlassian. Disponible: https://www.atlassian.com/es/agile/project-management/user-stories (Accedido: 11-Nov-2024). 23. Volere, "Plantillas", Volere. Disponible: https://www.volere.org/templates/ (Accedido: 11-Nov-2024). 24. Refactoring Guru, "Patrón de diseño Composite", Refactoring Guru. Disponible: https://refactoring.guru/es/design-patterns/composite (Accedido: 11-Nov-2024). 25. Paradigma Digital, "Patrón Contenedor/Presentadores aplicado al desarrollo en Angular", Paradigma Digital. Disponible: https://www.paradigmadigital.com/dev/patron-contenedor-presentadores-aplicado-desarrollo -angular/ (Accedido: 11-Nov-2024). 55 62