CERCLES: sistema de gestión de equipos para asignaturas de ingeniera de software

id193787   CERCLES: SISTEMA DE GESTIÓN DE EQUIPOS PARA ASIGNATURAS DE INGENIERA DE SOFTWARE VICTORIA PUSZYN MOSQUERA Director/a LIDIALÓPEZCUESTA(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 22/01/2025  Resumen El objetivo de este proyecto es diseñar e implementar CERCLES, una aplicación web para gestionar equipos y evaluar el rendimiento colaborativo en asignaturas de ingeniería de software. La herramienta permite a profesores y estudiantes organizar cursos, crear equipos, realizar evaluaciones entre compañeros y monitorizar métricas de contribución, mejorando la equidad y la eficiencia en proyectos grupales. Abstract The objective of this project is to design and implement CERCLES, a web application for managing teams and evaluating collaborative performance in software engineering courses. The tool allows professors and students to organize courses, create teams, conduct peer evaluations, and monitor contribution metrics, enhancing fairness and efficiency in group projects. Resum L’objectiu d’aquest projecte és dissenyar i implementar CERCLES, una aplicació web per gestionar equips i avaluar el rendiment col·laboratiu en assignatures d’enginyeria del programari. L’eina permet a professors i estudiants organitzar cursos, crear equips, realitzar avaluacions entre companys i monitoritzar mètriques de contribució, millorant l’equitat i l’eficiència en els projectes grupals. ÍNDICE 1.- Introducción 8 1.1 Contextualización 8 1.2 Motivación 8 1.3 Problema que resolver 8 1.4 Actores implicados 9 2.- Justificación 10 2.1 Proyectos similares 10 2.2 Conclusiones 10 3.- Alcance del proyecto 12 3.1 Objetivo principal 12 3.2 Sub-objetivos 12 4.- Metodología y rigor 13 4.1 Metodología de trabajo aplicada 13 4.2 Herramientas de gestión 14 4.3 Desviaciones reales en la metodología 16 5.- Planificación temporal 16 5.1 Introducción y fechas claves 16 5.2 Definición de las tareas 17 5.2.1 Tareas de Gestión del Proyecto 17 5.2.2 Tareas de Desarrollo 18 5.2.3 Tareas de Elaboración de la Memoria y de Comunicación 19 5.3 Recursos 20 5.3.1 Recursos tecnológicos 20 5.3.2 Recursos físicos 20 5.3.3 Recursos humanos 21 5.4 Resumen de las tareas 21 5.5 Diagrama de Gantt de la planificación 23 6.- Gestión del riesgo 25 6.1 Posibles riesgos 25 6.2 Planes alternativos y obstáculos 25 6.3 Desviaciones temporales 26 7.- Presupuesto 29 7.1 Identificación de los costes 29 7.1.1 Costes de recursos humanos 29 7.1.2 Costes generales 30 7.1.2.1 Hardware 30 7.1.2.2 Software 31 2 7.1.2.3 Otros 31 7.2 Estimación de los costes 31 7.2.1 Estimación final 32 7.3 Control de gestión 33 7.4 Desviaciones presupuestarias 33 8.- Análisis de requisitos 35 8.1 Requisitos funcionales 35 8.2 Requisitos no funcionales 39 9.- Diseño del software 44 9.1 Arquitectura del sistema 44 9.1.1 Arquitectura Cliente-Servidor 44 9.1.2 Patrón MVCS 45 9.1.3 Consideraciones sobre seguridad 46 9.2 Modelo conceptual de datos 47 9.3 Diseño de la base de datos 52 9.4 Diagramas de secuencia 55 9.5 Mock-ups 63 10.- Implementación 69 10.1 Implementación MVCS 69 10.2 Herramientas y tecnologías utilizadas 71 10.3 Dependencias del backend 73 10.4 Licencia de código abierto 74 10.5 Optimización llamadas GitHub 74 11.- Validación 76 11.1 Pruebas requisitos funcionales 76 11.2 Validación requisitos no funcionales 80 12.- Instalación y documentación 82 12.1 Requisitos e instalación de la aplicación web 82 12.2 Documentación de la RESTful API 83 12.3 Manual de usuario 86 13.- Informe de sostenibilidad 104 13.1 Autoevaluación 104 13.2 Dimensión económica 104 13.3 Dimensión ambiental 105 13.4 Dimensión social 105 14.- Conclusiones 107 14.1 Objetivos cumplidos 107 14.2 Futuras ampliaciones 108 3 14.3 Competencias logradas 108 14.4 Reflexiones finales 111 Glosario 112 Referencias 113 4 ÍNDICE DE TABLAS Y FIGURAS Figura 1. Gestión de proyectos Scrum. 13 Figura 2. Ejemplo de Kanban en Taiga. 14 Figura 3. Gitflow con diferentes ramas. 15 Figura 4. Tabla resumen de todas las tareas del proyecto. 21 Figura 5. Diagrama de Gantt. 24 Figura 6. Tabla de riesgos, probabilidad de aparición y horas de remedio. 26 Figura 7. Tabla de costes de cada uno de los roles en el proyecto. 29 Figura 8. Tabla de costes por tarea de los recursos humanos. 30 Figura 9. Tabla de costes del hardware empleado en el proyecto. 31 Figura 10. Tabla de costes del alquiler de un coworking. 31 Figura 11. Tabla de coste de las contingencias por apartado. 32 Figura 12. Tabla de costes de los imprevistos que puedan surgir en el proyecto. 32 Figura 13. Tabla de estimación de los costes totales del proyecto. 32 Figura 14. Tabla de estimación y coste real del proyecto. 34 Figura 15. Tablas de requisitos no funcionales. 40 Figura 16. Ejemplo de arquitectura cliente-servidor. 44 Figura 17. Ejemplo del patrón MVCS. 45 Figura 18. Esquema conceptual de datos. 48 Figura 19. Diseño de la base de datos. 53 Figura 20. Diagrama de secuencia de la funcionalidad para obtener detalles de un equipo. 56 Figura 21. Diagrama de secuencia de la funcionalidad para crear un curso. 58 Figura 22. Diagrama de secuencia de la funcionalidad para añadir profesores. 59 Figura 23. Diagrama de secuencia de la funcionalidad para añadir estudiantes. 60 Figura 24. Diagrama de secuencia de la funcionalidad para crear usuarios. 61 Figura 25. Diagrama de secuencia de la funcionalidad para crear evaluaciones. 62 Figura 26. Mock-up de la página de inicio de sesión. 63 Figura 27. Mock-up de la página principal. 64 5 Figura 28. Mock-up de la página de perfil. 64 Figura 29. Mock-up de la página de equipos. 65 Figura 30. Mock-up de la página de evaluaciones. 66 Figura 31. Mock-up de la página de un equipo. 67 Figura 32. Mock-up de la página de un equipo para el profesor. 68 Figura 33. Tabla de pruebas realizadas. 76 Figura 34. Ejemplo de application-properties. 83 Figura 35. Endpoints del código. 85 Figura 36. Captura de pantalla parcial del inicio de sesión. 86 Figura 37. Captura de pantalla parcial de la página de inicio. 87 Figura 38. Captura de pantalla parcial de la página de perfil sin conectar. 88 Figura 39. Captura de pantalla de la redirección de GitHub. 88 Figura 40. Captura de pantalla parcial de la página de perfil conectado. 89 Figura 41. Captura de pantalla de la página de cursos. 90 Figura 42. Captura de pantalla parcial de la página de crear curso. 91 Figura 43. Captura de pantalla parcial de la página de un curso. 92 Figura 44. Captura de pantalla parcial de la página de un equipo. 94 Figura 45. Captura de pantalla parcial de la página de un crear un equipo. 96 Figura 46. Captura de pantalla parcial de la página para evaluar como estudiante. 97 Figura 47. Captura de pantalla de la tabla resumen de evaluaciones. 98 Figura 48. Captura de pantalla de la tabla detalles de evaluaciones. 99 Figura 49. Captura de pantalla de la tabla métricas de GitHub. 100 Figura 50. Captura de pantalla de la tabla de detalles de HU y tareas. 101 Figura 51. Captura de pantalla de los gráficos de GitHub. 102 6 1.- Introducción 1.1 Contextualización Este Trabajo de Fin de Grado pertenece al Grado de Ingeniería Informática de la Facultad de Informática de Barcelona de la Universidad Politécnica de Cataluña [1], concretamente, forma parte de la especialización de Ingeniería del Software. Al ser un proyecto de Creación de un Sistema de Software, las asignaturas del Grado de las cuales se aplican más conceptos son: Ingeniería de Requisitos, Arquitectura del Software y, sobre todo, Gestión de Proyectos de Software [2]. Este proyecto tiene como objetivo crear un sistema de gestión y monitorización de equipos de trabajo para asignaturas de la propia universidad que se basan en el desarrollo de proyectos colaborativos, como las asignaturas de Ingeniería de Software. Dado que el trabajo en equipo es fundamental en este tipo de asignaturas, y los proyectos suelen implicar grupos grandes (de 6 a 8 miembros), surge la necesidad de un sistema que permita gestionar de manera eficiente la participación de cada miembro del equipo. Esto es esencial tanto para los estudiantes como para los profesores, ya que facilita la evaluación individual de los estudiantes en proyectos de larga duración. 1.2 Motivación A lo largo de mi carrera universitaria, he tenido la oportunidad de trabajar en varios proyectos en equipo. En diversas ocasiones, me di cuenta de que algunos miembros del equipo no estaban realizando una contribución suficiente al proyecto, mientras que, en otros casos, no estaba segura de si mi propia aportación era adecuada en comparación con la del resto del equipo. Esta falta de visibilidad sobre las contribuciones individuales generaba incertidumbre y, en algunos casos, una distribución desigual del trabajo. Cuando se presentó la oportunidad de realizar el TFG, vi en esta propuesta una solución práctica a este problema. El sistema propuesto no solo ayuda a clarificar las contribuciones de cada miembro del equipo, sino que también facilita la evaluación justa y objetiva, tanto para el equipo como para el profesorado. 1.3 Problema que resolver En algunas de las asignaturas de Ingeniería de Software, los estudiantes trabajan en equipos para desarrollar proyectos a lo largo del curso. Estos proyectos, que utilizan herramientas colaborativas como GitHub para el control de versiones y Taiga para la gestión de tareas, son monitorizados a través del Learning Dashboard (LD), un plug-in de Taiga que centraliza parte de la visualización del trabajo tanto a nivel de 7 equipo como individual. Sin embargo, el proceso de configuración del LD es manual, con el profesorado actuando como intermediario entre los estudiantes y el equipo encargado de configurar el sistema, lo que puede generar retrasos y pérdidas de datos. El problema principal es que el LD está más orientado a la monitorización de la participación, pero no está diseñado para facilitar una evaluación directa de las contribuciones individuales. Esto obliga al profesorado a realizar un esfuerzo adicional para completar la evaluación, ya que parte del proceso sigue siendo manual (introduciendo datos en hojas de Excel, por ejemplo). Esta implicación del profesorado en la configuración ralentiza el proceso y aumenta el riesgo de errores o 114información incompleta. Desde la perspectiva de los estudiantes, aunque el LD ya les permite visualizar métricas sobre su participación, el reto radica en que no tienen control directo sobre la configuración del sistema, lo que les limita en su capacidad de asegurar que la información registrada refleja adecuadamente su trabajo. La herramienta propuesta busca que los estudiantes asuman esta responsabilidad, facilitando la correcta configuración del LD. 1.4 Actores implicados Los actores principales implicados en este sistema son: Estudiantes: Usuarios que forman parte de los equipos de trabajo. Necesitan registrarse en el sistema y gestionar su participación en el proyecto, añadiendo su información de GitHub y Taiga, creando y gestionando equipos, y visualizando sus propios progresos en comparación con el equipo. Profesores: Usuarios que supervisan los proyectos. Su rol principal es crear y gestionar los cursos, cargar los datos de los estudiantes y monitorizar el progreso de cada equipo y estudiante. Necesitan una visión clara de las contribuciones individuales y grupales para poder evaluar el rendimiento de forma objetiva. Directora del TFG: Aunque también es profesora, actúa como un actor separado. Supervisará el proyecto y mantendrá reuniones de seguimiento para evaluar el progreso y los objetivos alcanzados. Desarrolladora: Yo, como única desarrolladora del proyecto, seré responsable de implementar todas las funcionalidades del sistema, gestionar el código, y asegurarme de cumplir con los objetivos definidos. 8 Google Meet Por último, las reuniones de seguimiento con mi tutora del TFG se realizarán a través de Google Meet [8]. En estas reuniones, se revisará el progreso del proyecto, se discutirán posibles bloqueos o mejoras y se ajustarán las prioridades según sea necesario para asegurar el cumplimiento de los plazos y objetivos establecidos. 4.3 Desviaciones reales en la metodología Desde el inicio del proyecto, se estableció la metodología Agile como marco de trabajo, y esta se ha mantenido a lo largo del desarrollo. Las herramientas iniciales previstas para apoyar esta metodología incluían GitHub para el control de versiones, Google Meet para reuniones de seguimiento, y Taiga para la gestión y planificación de las tareas. Sin embargo, debido a que el desarrollo del sistema ha sido realizado por una única persona, Taiga no resultó necesario. En su lugar, se optó por un enfoque más sencillo para la planificación y seguimiento de las tareas. Durante el proyecto, he mantenido un registro estructurado en un documento de texto donde se han detallado las historias de usuario, requisitos y las tareas asociadas, lo que ha permitido mantener claridad sobre las actividades pendientes y las completadas. Antes de cada sprint, se ha revisado este documento para seleccionar las historias de usuario que, según la planificación inicial, correspondían a esa etapa. Este enfoque ha permitido una organización eficiente y flexible del trabajo, adaptándose a las necesidades del proyecto sin introducir herramientas adicionales que no fueran estrictamente necesarias. 5.- Planificación temporal 5.1 Introducción y fechas claves El inicio del proyecto se establece el 18 de septiembre de 2024, coincidiendo con el comienzo de la asignatura de Gestión de Proyectos (GEP) [9]. La lectura del proyecto se prevé que se realice entre el lunes 20 de enero de 2025 y el viernes 24 de enero de 2025. Debido a que la memoria deberá ser entregada al menos una semana antes de la fecha asignada para la presentación [10], la entrega final del documento se fijará para el viernes 10 de enero de 2025 aproximadamente. Tomando en cuenta estas fechas, el tiempo total disponible para el desarrollo del proyecto es de 17 semanas. Si excluimos los fines de semana y festivos, nos quedan aproximadamente 83 días efectivos de trabajo. Durante las primeras 4 semanas del 15 proyecto, se dedicará tiempo a GEP, donde se estima que la carga de trabajo sea de 75 horas, dedicadas principalmente a la documentación inicial del proyecto. En cuanto a la distribución del tiempo, se reservarán los últimos 10 días de trabajo, es decir, dos semanas (del lunes 6 de enero al viernes 10 de enero), para finalizar la memoria y preparar la presentación. Por lo tanto, de los 79 días disponibles, restando los 10 últimos días de finalización y los 19 de GEP, quedan 50 días efectivos de desarrollo. Si consideramos una jornada laboral de 8 horas al día, tendremos un total de 400 horas destinadas al desarrollo del sistema. Sumando las 75 horas dedicadas a GEP y las 80 horas previstas para la memoria final, el tiempo total invertido en el Trabajo de Fin de Grado será de 555 horas. 5.2 Definición de las tareas Las tareas de este proyecto se han estructurado en tres categorías principales: gestión del proyecto, desarrollo técnico y elaboración de la memoria junto con tareas de comunicación. Las tareas relacionadas con el desarrollo técnico se han organizado en bloques según la funcionalidad específica a la que pertenecen. Cada una de ellas cuenta con una descripción breve que aclara su objetivo, además de una estimación del tiempo necesario para completarla y las dependencias de otras tareas que deben haberse finalizado previamente. 5.2.1 Tareas de Gestión del Proyecto ● GP1: Estudio de herramientas de apoyo para el proyecto (10 horas) o Análisis y selección de las herramientas TIC necesarias para la gestión y desarrollo del proyecto. o Dependencias: Ninguna ● GP2: Contextualización y alcance del proyecto (20 horas) o Definición del marco teórico y el ámbito del proyecto, así como los objetivos a alcanzar. o Dependencias: GP1 ● GP3: Planificación temporal (15 horas) o Establecimiento de la planificación temporal, describiendo las tareas y creando un diagrama de Gantt. o Dependencias: GP2 ● GP4: Presupuesto y sostenibilidad (15 horas) o Realización de una estimación de los recursos necesarios y elaboración de un informe de sostenibilidad. o Dependencias: GP3 ● GP5: Integración del documento final (15 horas) o Elaboración de la memoria final, integrando todas las entregas previas. 16 o Dependencias: GP4 5.2.2 Tareas de Desarrollo Inception ● I1: Preparación del entorno de desarrollo (16 horas) o Instalación y configuración de las herramientas y plataformas necesarias para el desarrollo del sistema. o Dependencias: Ninguna ● I2: Creación de mock-ups y prototipos (20 horas) o Diseño de maquetas y prototipos de la interfaz de usuario para validar la experiencia del usuario. o Dependencias: I1 ● I3: Estudio de conexión con APIs y de tecnologías seleccionadas (20 horas) o Investigación de la documentación de las APIs de GitHub y Taiga, y de los frameworks y lenguajes seleccionados. o Dependencias: Ninguna Conexión con las APIs ● C1: Conexión con la API de GitHub (40 horas) o Desarrollo de la funcionalidad para establecer la conexión con la API de GitHub y obtener datos relevantes. o Dependencias: Inception ● C2: Conexión con la API de Taiga (40 horas) o Implementación de la conexión con la API de Taiga para monitorizar la actividad del proyecto. o Dependencias: Inception Gestión de Usuarios ● U1: Creación de diferentes tipos de usuarios (22 horas) o Implementación de la funcionalidad para crear y gestionar usuarios, diferenciando entre estudiantes y profesores. o Dependencias: Conexión con las APIs Gestión de Profesores ● P1: Alta de curso y gestión de estudiantes (45 horas) o Desarrollo de la funcionalidad que permite a los profesores crear cursos y gestionar a los estudiantes inscritos. 17 o Dependencias: Gestión de Usuarios Gestión de Alumnos ● A1: Registro y conexión de estudiantes (25 horas) o Desarrollo del módulo de registro para que los estudiantes puedan proporcionar su información de usuario de GitHub y Taiga. o Dependencias: Gestión de Profesores ● A2: Gestión de equipos y proyectos (25 horas) o Implementación de la funcionalidad que permite a los estudiantes crear y gestionar equipos y proyectos, vinculándolos con GitHub y Taiga. o Dependencias: A1 ● A3: Comprobación de herramientas (12 horas) o Desarrollo de una función para verificar la conexión con GitHub y Taiga, mostrando datos clave (commits, ramas, tareas, etc.). o Dependencias: A2 Gestión de Fichas ● F1: Ficha individual y de equipo (55 horas) o Creación de funcionalidades para que los estudiantes consulten métricas personales y el resumen del rendimiento del equipo. o Dependencias: Gestión de alumnos ● F2: Monitorización del rendimiento (60 horas) o Desarrollo de herramientas para que los profesores analicen el rendimiento de los estudiantes según las fichas o Dependencias: F1 5.2.3 Tareas de Elaboración de la Memoria y de Comunicación ● EMC1: Repaso del proyecto (10 horas) o Revisión del proyecto, sobre todo la parte tecnológica. o Dependencias: Desarrollo ● EMC2: Redacción de la memoria (75 horas) o Elaboración de la versión definitiva de la memoria, integrando la información revisada y asegurándose de la coherencia entre las secciones. o Dependencias: EMC1 ● EMC3: Comunicación (15 horas) 18 o Reuniones periódicas con la tutora para discutir el progreso, resolver dudas y ajustar el desarrollo del proyecto según las recomendaciones. o Dependencias: Ninguna 5.3 Recursos En este apartado, vamos a destacar todos los recursos que van a ser necesarios para la elaboración de este proyecto. Los recursos necesarios se pueden dividir en tres categorías: 5.3.1 Recursos tecnológicos En este apartado se detallan todos los programas y herramientas del software utilizados durante el desarrollo del proyecto: ● [WIN10] Windows 10 ● [LINUX] Linux Ubuntu ● [VSC] Visual Studio Code: Entorno de desarrollo principal para la escritura del código [11]. ● [GIT] Git: Herramienta de control de versiones para gestionar y rastrear los cambios en el código. ● [GITHUB] GitHub: Plataforma para el alojamiento de repositorios. ● [TAI] Taiga: Herramienta de seguimiento ágil para gestionar tareas y asignar recursos. ● [SPRING] Spring Boot: Framework para el desarrollo del backend [12]. ● [REACT] React: Biblioteca de JavaScript para la construcción de interfaces de usuario en el frontend [13]. ● [SQL] SQLite: Sistema de gestión de bases de datos utilizado para almacenar la información del proyecto [14]. ● [FG] Figma: Herramienta colaborativa para la creación de prototipos y mockups [15]. ● [DW] Draw.io: Herramienta para la elaboración de diagramas y esquemas arquitectónicos [16]. ● [AT] Atenea: Plataforma de la universidad utilizada para acceder a recursos y enviar entregas. ● [GGS] Google Suite: Conjunto de herramientas que incluyen Google Drive, Docs, Sheets, Slides, Meet y Gmail. ● [IG] Instagantt: Plataforma para la elaboración del diagrama de Gantt [17]. 5.3.2 Recursos físicos Para poder realizar este proyecto, hará falta utilizar un ordenador portátil que cuente con las características adecuadas para el desarrollo de software y la ejecución de herramientas de desarrollo, además de una conexión estable y de alta velocidad a internet para gestionar repositorios y realizar las reuniones de seguimiento. 19 5.3.3 Recursos humanos Al ser un proyecto individual, deberé asumir estos diferentes roles a lo largo del proyecto: ● [GP] Gestora de proyecto: Responsable de la planificación y control del cronograma del proyecto, estimando las tareas necesarias y monitorizando el progreso. También se encarga de coordinar la comunicación con la directora y el tutor de GEP y redactar la memoria del proyecto. ● [DS] Desarrolladora del software: Encargada del desarrollo del código, integración con APIs y creación de funcionalidades. ● [ADMIN] Administradora de sistemas: Configuración del entorno de desarrollo y gestión de servidores locales. ● [DU] Diseñadora de UI/UX: Creación de mockups y diseño de la experiencia del usuario. ● [AS] Arquitecta de software: Encargada de determinar los requisitos de cada tarea y realizar el diseño arquitectónico del proyecto. ● [T] Tester: Realización de pruebas de funcionalidades y verificación de la calidad del software. Por descontado, este proyecto cuenta con la colaboración de la directora del TFG, [LL] Lidia López. Además, para la elaboración de la asignatura de GEP, cuenta con la asistencia del tutor de GEP [TGEP]. 5.4 Resumen de las tareas Figura 4. Tabla resumen de todas las tareas del proyecto. Fuente: Elaboración propia CÓDIGO TAREA DEP HORAS RECURSOS GP Gestión del proyecto 75 HUMANOS MATERIALES GP1 Estudio de herramientas de apoyo para el proyecto 10 GP GGS, SQL, SPRING, REACT GP2 Contextualización y alcance del proyecto GP1 20 GP, TGEP GGS, AT GP3 Planificación temporal GP2 15 GP, TGEP GGS, AT, IG GP4 Presupuesto y sostenibilidad GP3 15 GP, TGEP GGS, AT GP5 Integración del documento final GP4 15 GP, TGEP GGS, AT 20 D Desarrollo 380 I Inception 56 I1 Preparación del entorno de desarrollo 16 ADMIN, T WIN10, LINUX, VSC, GIT, GITHUB, SPRING, REACT, SQL I2 Creación de mock-ups y prototipos I1 20 DU GGS, FG, DW I3 Estudio de conexión con APIs y de tecnologías seleccionadas 20 ADMIN, DS GITHUB, TAI, SPRING, REACT, SQL C Conexión con las APIs 80 C1 Conexión con la API de GitHub I 40 ADMIN, DS, AS, T VSC, GIT, GITHUB, TAI, GGS, SPRING C2 Conexión con la API de Taiga I 40 ADMIN, DS, AS, T VSC, GIT, GITHUB, TAI, GGS, SPRING U Gestión de Usuarios 22 U1 Creación de diferentes tipos de usuarios C 22 AS, DS, T VSC, GIT, GITHUB, TAI, SQL P Gestión de Profesores 45 P1 Alta de curso y gestión de estudiantes U 45 AS, DS, T VSC, GIT, GITHUB, TAI, SPRING, REACT A Gestión de Alumnos 62 A1 Registro y conexión de estudiantes P 25 AS, DS, T VSC, GIT, GITHUB, TAI, 21 SPRING, REACT A2 Gestión de equipos y proyectos A1 25 AS, DS, T VSC, GIT, GITHUB, TAI, SPRING, REACT A3 Comprobación de herramientas A2 12 AS, DS, T VSC, GIT, GITHUB, TAI, SPRING, REACT F Gestión de Fichas 115 F1 Ficha individual y de equipo A 55 AS, DS, T VSC, GIT, GITHUB, TAI, SPRING, REACT F2 Monitorización del rendimiento F1 60 AS, DS, T VSC, GIT, GITHUB, TAI, SPRING, REACT EMC Elaboración de Memoria Comunicación 100 EMC1 Repaso del proyecto D 10 GP GS, TAI EMC2 Redacción de la memoria 75 GP GS, AT EMC3 Comunicación 15 GP, LL, TGEP GS TOTAL 555 5.5 Diagrama de Gantt de la planificación El siguiente diagrama de Gantt se ha elaborado mediante una priorización de las tareas a realizar. Sin embargo, dado que se seguirá un método Scrum, el diagrama es susceptible de ser modificado, ya que al inicio de cada sprint se seleccionarán las tareas a abordar 22 Figura 5. Diagrama de Gantt. Font: Elaboración propia mediante instagant 23 6.- Gestión del riesgo 6.1 Posibles riesgos Uno de los principales riesgos que enfrenta el sistema es la integración con herramientas externas como GitHub y Taiga. Estas plataformas son claves para el seguimiento de las contribuciones de los estudiantes, pero dependen de APIs que pueden sufrir cambios inesperados, caídas o limitaciones en su uso, lo cual puede afectar la capacidad del sistema para obtener los datos necesarios en tiempo real. También es importante considerar que la inexperiencia en las tecnologías seleccionadas para el desarrollo del sistema puede llevar a retrasos en la implementación o a problemas técnicos inesperados durante el desarrollo. Si bien estas herramientas han sido elegidas por su capacidad de adaptación a proyectos complejos, la falta de un conocimiento profundo en su uso puede llevar a problemas en la implementación de funcionalidades críticas, y consecuentemente provocar retrasos en el desarrollo o errores técnicos que afecten la calidad final del sistema. Esto incluye tanto la programación de las funcionalidades internas del sistema como la integración efectiva con las APIs de GitHub y Taiga. El último riesgo importante que considerar es la sobrecarga de trabajo por subestimación de tareas. Dada la complejidad del proyecto y el número de funcionalidades que deben desarrollarse, es posible que algunas tareas requieran más tiempo del estimado inicialmente. La subestimación puede generar una acumulación de trabajo hacia el final del proyecto, afectando el cronograma de entrega y comprometiendo la calidad del producto final. Este riesgo es especialmente preocupante debido a la naturaleza individual del proyecto, donde cualquier retraso tendrá un impacto directo en la capacidad de finalizarlo a tiempo. 6.2 Planes alternativos y obstáculos Este proyecto presenta una serie de riesgos que podrían impactar su desarrollo. En la tabla a continuación se detallan cada uno de estos riesgos, indicando la probabilidad de que ocurran y el tiempo estimado en horas necesario para remediarlos. 24 Figura 11. Tabla de coste de las contingencias por apartado. Fuente: Elaboración propia. Recurso Coste [en €] Contingencia [en €] Humanos 16.595,56 2.489,33 Hardware 119,28 17,89 Software 0,0 0,0 Otros 2.380,0 357,0 TOTAL 2.864,22 A continuación, veremos los costes añadidos según los imprevistos que puedan surgir a lo largo del proyecto, especificados en anteriores entregas. Figura 12. Tabla de costes de los imprevistos que puedan surgir en el proyecto. Fuente: Elaboración propia. Imprevistos Horas invertidas según rol [en h] Coste estimado [en €] Probabilida d [en %] Coste [en €] Integración con herramientas externas como GitHub y Taiga [ADMIN] 10 301,7 0,8 241,36 Inexperiencia en las tecnologías seleccionadas [DS] 15 490,95 0,66 324,03 Sobrecarga de trabajo por subestimación de tareas [GP] 10 255,3 0,5 127,65 TOTAL 693,04 7.2.1 Estimación final Para acabar, en la siguiente tabla podemos ver la estimación final aproximada del presupuesto que hace falta para llevar a cabo este proyecto. Figura 13. Tabla de estimación de los costes totales del proyecto. Fuente: Elaboración propia. Coste Precio CPA (Costes de personal por actividad) 16.595,56 CG (Costes imputados genéricamente) 2.499,28 Contingencias 2.864,22 Imprevistos 693,04 TOTAL 22.652,1 31 7.3 Control de gestión Para llevar un control adecuado del coste total del proyecto, se registrarán las horas empleadas en cada tarea. De esta forma, al finalizar el proyecto, se podrán realizar los cálculos necesarios para verificar si ha sido necesario utilizar el fondo de contingencia o no. A continuación se incluyen las fórmulas utilizadas para hacer las comprobaciones necesarias: 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝑐𝑜𝑠𝑡𝑒𝑠=𝐶𝑜𝑠𝑡𝑒 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜−𝐶𝑜𝑠𝑡𝑒 𝑟𝑒𝑎𝑙 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠=𝐻𝑜𝑟𝑎𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑎𝑠−𝐻𝑜𝑟𝑎𝑠 𝑟𝑒𝑎𝑙𝑒𝑠 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑐𝑜𝑛𝑠𝑢𝑚𝑖𝑑𝑎𝑠 𝑝𝑜𝑟 𝑡𝑎𝑟𝑒𝑎 = 𝐻𝑜𝑟𝑎𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑎𝑠−𝐻𝑜𝑟𝑎𝑠 𝑟𝑒𝑎𝑙𝑒𝑠( )*𝐶𝑜𝑠𝑡𝑒 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝑐𝑜𝑠𝑡𝑒 𝑠𝑒𝑔ú𝑛 𝑙𝑎𝑠 ℎ𝑜𝑟𝑎𝑠 𝑝𝑜𝑟 𝑡𝑎𝑟𝑒𝑎 = 𝐻𝑜𝑟𝑎𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑎𝑠−𝐻𝑜𝑟𝑎𝑠 𝑟𝑒𝑎𝑙𝑒𝑠( )*𝐶𝑜𝑠𝑡𝑒 𝑟𝑒𝑎𝑙 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒𝑙 𝑐𝑜𝑠𝑡𝑒 𝑠𝑒𝑔ú𝑛 𝑡𝑎𝑟𝑒𝑎= 𝐶𝑜𝑠𝑡𝑒 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜−𝐶𝑜𝑠𝑡𝑒 𝑟𝑒𝑎𝑙( )*𝐻𝑜𝑟𝑎𝑠 𝑟𝑒𝑎𝑙𝑒𝑠 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑖𝑚𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠 =𝑐𝑜𝑠𝑡𝑒 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 𝑑𝑒 𝑖𝑚𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠−𝑐𝑜𝑠𝑡𝑒 𝑟𝑒𝑎𝑙 𝑑𝑒 𝑖𝑚𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠 7.4 Desviaciones presupuestarias Durante el desarrollo del proyecto, se han identificado desviaciones presupuestarias debido al incremento de horas invertidas en ciertas tareas no previstas inicialmente. Estas desviaciones están relacionadas principalmente con las dificultades técnicas encontradas y la necesidad de dedicar más tiempo al desarrollo, específicamente desde el rol de Desarrolladora de Software (DS), cuyo coste por hora es de 32,73 €. En la tabla de imprevistos definida al inicio del proyecto, se estimaron horas adicionales para gestionar posibles riesgos. Sin embargo, debido a los múltiples retos encontrados, ha sido necesario añadir horas adicionales de trabajo desde el rol de Desarrolladora de Software en dos de las categorías de riesgos identificadas: 32 1. Integración con herramientas externas como GitHub y Taiga: Además, aunque inicialmente se estimaron 10 horas para posibles problemas de integración, finalmente se necesitaron otras 50 horas adicionales gestionando el intento de conectarse a la API de Taiga, así como explorando alternativas para suplir su funcionalidad. Este esfuerzo incluyó una revisión exhaustiva de la documentación, pruebas repetidas de conexión y análisis de opciones para reemplazar los datos que se esperaban obtener de Taiga. La combinación de estos factores consumió un tiempo significativo, excediendo las previsiones iniciales y requiriendo ajustes en el cronograma para priorizar otras tareas críticas del proyecto. 2. Sobrecarga de trabajo por subestimación de tareas: Algunas funcionalidades, como la autenticación con JWT y la configuración del backend, requirieron más tiempo del planeado. Por ello, se añadieron 10 horas adicionales para cubrir este retraso. Por lo tanto, las 60 horas adicionales que han hecho falta para mitigar esos errores e imprevistos, han supuesto un coste adicional de 1.963,8€. Figura 14. Tabla de estimación y coste real del proyecto. Fuente: Elaboración propia. Coste Presupuesto Coste real CPA (Costes de personal por actividad) 16.595,56 16.595,56 CG (Costes imputados genéricamente) 2.499,28 2.499,28 Contingencias 2.864,22 0,0 Imprevistos 693,04 2.656,84 TOTAL 22.652,1 21.751,68 Como podemos ver en la tabla, tanto los CPA como CG se mantienen tal y como se presupuestaron. Sin embargo, debido a más imprevistos de los previstos, se han tenido que añadir los 1.963,8€ a los 693,04 ya presupuestados. Aun así, como podemos ver el coste real es casi 1000€ menor al coste total estimado, ya que, no ha habido ningún coste por contingencias. 33 8.- Análisis de requisitos 8.1 Requisitos funcionales En este apartado se presentan todas las funcionalidades planteadas desde el inicio del proyecto en forma de historias de usuario, junto con los criterios de aceptación asociados a cada una. Estos criterios son esenciales para definir cómo se verificará que cada funcionalidad ha sido correctamente implementada. HU01a. Configuración de equipos Como estudiante, quiero crear un equipo seleccionando un curso, asignándole un nombre y añadiendo miembros del mismo curso, para organizar el trabajo en equipo de manera estructurada. Criterios de aceptación: 1. El sistema debe mostrar una lista de los cursos disponibles, permitiendo al estudiante seleccionar el curso en el que desea crear el equipo. 2. Al crear un equipo, el sistema debe proporcionar un formulario donde el estudiante pueda: a. Introducir un nombre único para el equipo dentro del curso seleccionado. b. Añadir miembros al equipo seleccionándolos de una lista de estudiantes del mismo curso que no pertenezcan a otro equipo. c. Seleccionar el profesor evaluador dentro de la lista de profesores de ese curso 3. El sistema debe validar que el nombre del equipo sea único dentro del curso antes de permitir guardar. 4. Tras guardar, el sistema debe mostrar un mensaje de confirmación. HU01b. Configuración de equipos (herramientas) Como estudiante, quiero vincular la organización de GitHub y el proyecto de Taiga a uno de mis equipos, para garantizar que todas las herramientas necesarias estén correctamente configuradas. Criterios de aceptación: 1. El sistema debe mostrar dentor de la página del equipo dos campos: a. Un formulario para asociar una organización de GitHub al equipo. b. Un formulario para asociar un proyecto de Taiga al equipo. 2. Cada formulario debe incluir un botón para verificar la conexión con las herramientas externas (GitHub y Taiga). 34 3. El sistema debe validar que: a. Todos los miembros del equipo están registrados en la organización de GitHub y el proyecto de Taiga. b. El profesor/a evaluador/a está incluidos en la organización de GitHub y el proyecto de Taiga. c. La cuenta de Github del profesorado está incluida en la organización de GitHub. d. El usuario servei-cercles-taiga está incluido en el proyecto de Taiga. 4. En caso de errores, el sistema debe mostrar mensajes claros indicando los problemas encontrados y cómo resolverlos. 5. Una vez configuradas correctamente ambas herramientas, el sistema debe mostrar un mensaje de éxito. 6. El estudiante tiene que poder desvincular la organización de Github. 7. El estudiante tiene que poder desvincular el proyecto de Taiga. HU02. Gestión de miembros de un equipo Como estudiante, quiero añadir o eliminar miembros de mi equipo, para mantenerlo actualizado según las necesidades del proyecto. Criterios de aceptación: 1. Solo se pueden añadir estudiantes que pertenezcan al mismo curso y no estén ya asignados a otro equipo. 2. En caso de eliminar a todos los miembros del equipo, este se deberá eliminar. HU03. Verificación de herramientas de soporte Como estudiante, quiero comprobar la conexión con mis herramientas de soporte (GitHub y Taiga), para asegurarme de que están correctamente vinculadas al sistema. Criterios de aceptación: 1. El sistema debe mostrar información privada de la cuenta de GitHub para asegurar su correcta conexión: a. Nombre de la cuenta b. Número de repositorios públicos y privados c. Número de organizaciones 2. El sistema debe permitir desvincularse de la cuenta de GitHub 35 HU04. Evaluar a compañeros de equipo Como profesor, quiero que los alumnos puedan evaluar a sus compañeros de equipo en varios momentos del curso, para proporcionar feedback sobre su contribución al proyecto. Criterios de aceptación: 1. El sistema debe permitir a los estudiantes realizar evaluaciones de sus compañeros en fechas configuradas por el profesor. 2. Los estudiantes, en cada evaluación, deberán asignar una puntuación tanto a sus compañeros de equipo como a sí mismos. La suma total de todas las puntuaciones asignadas debe ser igual al número de miembros del equipo multiplicado por 10. 3. Los resultados deben ser accesibles sólo para el profesorado. 4. El profesor debe poder visualizar una tabla por cada evaluación, en la que se muestren las puntuaciones otorgadas por cada estudiante a todos sus compañeros. Cada tabla incluirá también la media de las puntuaciones otorgadas por los compañeros para cada estudiante. 5. El profesor debe tener acceso a una tabla general que resuma todas las evaluaciones. Esta tabla debe mostrar las medias de las puntuaciones de los compañeros acumuladas a lo largo de todas las evaluaciones, así como la media de las autoevaluaciones de cada estudiante. HU05. Creación y configuración de un nuevo curso Como profesor, quiero crear y configurar un nuevo curso estableciendo sus datos básicos y dando de alta a los estudiantes mediante un archivo, para gestionar de manera organizada el curso y los equipos de trabajo. Criterios de aceptación: 1. El sistema debe permitir al profesor establecer los datos del curso, incluyendo: a. Nombre del curso. b. Año de inicio. c. Cuatrimestre. d. Profesores del curso e. Periodos de evaluación. f. Cuenta de profesorado de Github, junto con el token de acceso. 2. El sistema debe permitir la carga de un archivo en formato .xlsx con los datos de los estudiantes (grupo, nombre y apellidos, correo electrónico). 3. Los datos del archivo deben validarse antes de ser registrados: 36 a. Detectar estudiantes duplicados o con datos incompletos y generar un mensaje de error para corregirlos. b. Validar que las direcciones de correo electrónico tienen un formato correcto. 4. Los estudiantes cargados correctamente que aún no pertenezcan al sistema deben ser registrados automáticamente y asociados al curso correspondiente. HU06a. Consultar ficha de equipo (GitHub) Como profesor, quiero consultar las contribuciones y métricas individuales de cada estudiante dentro de su equipo utilizando datos de la organización de GitHub, para evaluar su rendimiento en el curso en comparación con sus compañeros de equipo. Criterios de aceptación: 1. El sistema debe mostrar métricas detalladas individuales como: ○ Número de commits. ○ Líneas de código añadidas (+). ○ Líneas de código eliminadas (-). ○ Número de pull requests (PRs). 2. El sistema debe presentar estos datos en una tabla que muestre las métricas individuales para todos los miembros del equipo. 3. Debe incluir un gráfico circular que visualice la proporción de commits realizados por cada miembro del equipo. 4. También debe incluir un gráfico de barras que compare las líneas de código añadidas y eliminadas entre los miembros del equipo. 5. Estos datos serán accesibles únicamente si los estudiantes han configurado correctamente su organización de GitHub asociada al equipo. HU06b. Consultar ficha de equipo (Taiga) Como profesor, quiero consultar las métricas individuales y del equipo utilizando datos del proyecto de Taiga, para evaluar el progreso y la colaboración en el curso. 37 Criterios de aceptación: 1. El sistema debe mostrar métricas detalladas individuales y del equipo como: a. Total de tareas. b. Total de HUs. c. Total de Power. d. HUs cerradas. e. Número de interacciones. 2. El sistema debe presentar estos datos en una tabla que muestre las métricas individuales y globales del equipo. 3. Debe incluir gráficos visuales para representar: a. El progreso en las HUs cerradas. b. El número de tareas completadas en comparación con las pendientes. 4. Estos datos serán accesibles únicamente si los estudiantes han configurado correctamente su proyecto de Taiga asociado al equipo. 8.2 Requisitos no funcionales En este apartado se especifican los requisitos no funcionales del sistema, los cuales definen las características cualitativas que debe cumplir la aplicación final. Estos requisitos son más difíciles de evaluar en comparación con los funcionales, ya que no siempre tienen una implementación directa, sino que representan propiedades generales del sistema, como la escalabilidad, la usabilidad o la seguridad. Para realizar una especificación más detallada y precisa, se ha adaptado el modelo de requisitos de Volere [21], estructurando cada requisito en una tabla que incluye su descripción, justificación y las condiciones de satisfacción que permiten verificar su cumplimiento. Podemos ver además como cada requisito incluye una cifra y una letra antes de su nombre. Esto indica, dentro de la Plantilla de Especificación de Requisitos de Volere, cuál es el requisito especificado. 38 Escalabilidad: El sistema debe ser capaz de soportar múltiples cursos y varios equipos por curso, sin degradar su rendimiento. Figura 15. Tablas de requisitos no funcionales. Fuente: Elaboración propia 12f. Requisitos de Capacidad Descripción El sistema debe ser capaz de gestionar múltiples cursos con hasta 500 estudiantes cada uno y varios equipos por curso, garantizando un rendimiento óptimo. Justificación Es crucial que la aplicación soporte un número creciente de usuarios y datos para ser viable en un entorno académico. Condición de satisfacción El tiempo de respuesta del sistema debe ser reducido para operaciones estándar, incluso con grandes volúmenes de datos. Disponibilidad y fiabilidad: El sistema debe garantizar un uptime elevado, asegurando que estudiantes y profesores puedan acceder a él en cualquier momento. Además, los datos de los usuarios y equipos deben estar seguros y disponibles en todo momento. 12d. Requisitos de Confiabilidad y Disponibilidad Descripción El sistema debe garantizar una alta disponibilidad y confiabilidad, asegurando que estudiantes y profesores puedan acceder en cualquier momento sin interrupciones. Justificación La continuidad en el acceso es esencial para evitar retrasos en la gestión de cursos y equipos, así como para prevenir la pérdida de datos críticos. Condición de satisfacción El sistema debe garantizar alta disponibilidad y fiabilidad, lo cual se logra mediante su despliegue en un servidor de la UPC, asegurando un uptime elevado gracias a la infraestructura establecida por la universidad. 39 Seguridad: Cifrado de contraseñas y autenticación segura para el acceso de los usuarios. Acceso restringido a los datos de estudiantes y equipos solo por usuarios autorizados. 15a. Requisitos de Acceso Descripción El sistema debe asegurar que solo los usuarios autorizados puedan acceder a las funcionalidades y datos específicos según su rol (profesor o estudiante). Justificación La confidencialidad y la integridad de los datos son críticas, especialmente para proteger la privacidad de estudiantes y profesores. Condición de satisfacción El sistema debe implementar JWT para autenticar a los usuarios y verificar que cada acción sea realizada solo por usuarios con los permisos adecuados. 15c. Requisitos de Privacidad Descripción Los datos almacenados deben cumplir con regulaciones de privacidad y anonimato, asegurando que métricas individuales solo sean visibles para el estudiante en cuestión o su profesor. Justificación La aplicación maneja datos sensibles, como evaluaciones de estudiantes y métricas personales, que deben ser presentados de forma anónima para proteger la privacidad. Condición de satisfacción Las fichas de equipo deben mostrar solo métricas agregadas, y las evaluaciones entre compañeros deben mantenerse anónimas en todo momento. 40 Figura 18. Esquema conceptual de datos. Fuente: Elaboración propia con Draw.io Este modelo conceptual detalla todos los elementos principales del sistema, así como las relaciones entre ellos. A continuación voy a detallar las entidades, sus claves primarias y externas, atributos y relaciones principales: 47 1. Usuario: ● Representa a cualquier persona que utiliza el sistema, ya sea como estudiante o profesor. ● Atributos principales: ○ Correo: Identificador único del usuario (clave primaria). ○ Nombre: Nombre completo del usuario. ○ GitUsername y TaigaUsername: Identificadores opcionales para integrar las herramientas externas (GitHub y Taiga). 2. Estudiante: ● Subclase de Usuario que representa a los alumnos. ● Relaciones: ○ Es miembro de equipos. ○ Está asociado a uno o varios cursos mediante la entidad intermedia Estudiante-Curso. 3. Profesor: ● Subclase de Usuario que representa al profesorado. ● Relaciones: ○ Es profesor de uno o varios cursos. ○ Es el profesor responsable (evaluador) de multiples grupos. 4. Curso: ● Representa un curso académico y agrupa a estudiantes y equipos. ● Atributos principales: ○ AñoInicio: Año en que se ofrece el curso (parte de la clave primaria). ○ NombreAsig: Nombre de la asignatura (parte de la clave primaria). ○ Cuatrimestre: Cuatrimestre en el que se imparte el curso (parte de la clave primaria). ○ Activo: Estado actual del curso (activo/inactivo). ○ GithubAsignatura: Se guarda la cuenta de GitHub del profesorado relativa al curso. ● Relaciones: ○ Contiene a varios equipos. ○ Tiene asociado a un profesor. 48 5. Equipo: ● Representa a un grupo de estudiantes trabajando juntos en un proyecto. ● Atributos principales: ○ Nombre: Identificador del equipo dentro de un curso (clave primaria compuesta junto con el curso al que pertenece). ○ GitOrganización: Organización de GitHub asociada (opcional). ○ TaigaProyecto: Proyecto de Taiga asociado (opcional). ● Relaciones: ○ Está asociado a un curso. ○ Tiene uno o varios estudiantes como miembros. 6. Evaluación: ● Representa las evaluaciones individuales que un estudiante realiza sobre sus compañeros. ● Atributos principales: ○ Puntuación: Nota asignada a un compañero durante una evaluación específica. ● Relaciones: ○ Cada evaluación está vinculada a una iteración y a estudiantes. 7. Iteración: ● Define un periodo de evaluación dentro del curso. ● Atributos principales: ○ FechaInicio y FechaFin: Delimitan el periodo de evaluación. 8. Estudiante-Curso: ● Relación intermedia que conecta a los estudiantes con los cursos. ● Atributos principales: ○ Grupo: Representa el grupo al que pertenece el estudiante dentro del curso. 49 Restricciones textuales (RTs): RT1: Un Usuario debe ser exactamente un Estudiante o un Profesor (generalización disjunta y completa). RT2: Un estudiante solo puede pertenecer a un equipo dentro de un curso donde sea estudiante. RT3: Un equipo debe pertenecer a un único curso. RT4: El nombre de un equipo debe ser único dentro del curso al que pertenece. RT5: Un profesor solo puede ser el evaluador de un equipo que pertenezca a un curso del cual este sea profesor. RT6: Un estudiante solo puede evaluar a otro estudiante que pertenezca a su mismo equipo. RT7: Un profesor, al crear un curso, debe especificar el número de periodos de evaluación, el cual debe estar entre 0 y 5. RT8: Cada iteración (periodo de evaluación) debe cumplir las siguientes condiciones: ● Tener una fecha de inicio anterior a la de fin. ● La fecha de inicio debe ser posterior a la fecha de fin del periodo anterior (si existe). ● La fecha de fin debe ser anterior a la fecha de inicio del siguiente periodo (si existe). RT9: Cada evaluación debe tener una puntuación mínima de 0. RT10: La suma total de las puntuaciones asignadas por un estudiante en una evaluación debe ser igual al número de miembros del equipo multiplicado por 10. RT11: Los datos de GitOrganización y TaigaProyecto en un equipo son opcionales, pero si están presentes, deben validarse correctamente para que el equipo sea considerado válido. Con estas restricciones, me aseguro de que el sistema es íntegro y está correctamente delimitado. Justificación de las relaciones binarias en lugar de asociaciones ternarias/cuaternarias: En este modelo conceptual, he optado por utilizar relaciones binarias en lugar de asociaciones ternarias o cuaternarias, las cuales habrían evitado el uso de múltiples asociaciones individuales entre las cuatro clases principales (estudiante-profesor-curso-equipo). La razón principal por la cual opté por hacerlo de esta manera es que un equipo no tiene sentido fuera del contexto de un 50 curso. Su existencia depende completamente de estar asociado a un curso específico. Por ello, la relación entre Equipo y Curso es fundamental y directa. Además, utilizar relaciones binarias asegura que el modelo sea más claro y fácil de interpretar, evitando la complejidad innecesaria que supondría gestionar una asociación ternaria o cuaternaria. Esto permite que cada relación binaria refleje un vínculo lógico y bien definido entre las entidades, manteniendo la coherencia y la simplicidad del diseño. 9.3 Diseño de la base de datos Para la persistencia de datos, se evaluaron varias opciones de sistemas de gestión de bases de datos relacionales. Las ventajas de las alternativas consideradas son: 1. SQLite ● Muy ligero y sencillo de configurar. ● Ideal para aplicaciones pequeñas con datos moderados. 2. PostgreSQL ● Avanzadas capacidades para operaciones complejas y tipos de datos personalizados. ● Altamente escalable y confiable. 3. MariaDB ● Total compatibilidad con MySQL, ampliamente utilizado en el entorno académico de la universidad. ● Desempeño robusto y soporte para operaciones concurrentes. Teniendo muy presentes estas opciones, acabé optando por MariaDB principalmente debido a su compatibilidad con los servidores de la UPC y su integración con herramientas utilizadas en el entorno académico. A pesar de que SQLite habría sido suficiente en términos de manejo de datos, las capacidades avanzadas de MariaDB ofrecen una mayor flexibilidad para futuros despliegues o expansiones del sistema. Por otra parte, se presenta el modelo de la base de datos. En la siguiente figura se puede observar el diseño propuesto para la gestión de las entidades y sus relaciones. 51 Figura 19. Diseño de la base de datos. Fuente: Elaboración propia En este apartado se presenta el diseño físico de la base de datos utilizado para la implementación del sistema, comparándolo con el modelo conceptual descrito anteriormente. La imagen adjunta muestra el esquema generado por DataGrip de JetBrains, representando todas las tablas y sus relaciones. Diferencias respecto al modelo conceptual 1. Incorporación de IDs autogenerados: ○ En todas las tablas principales, como usuario, curso, equipo, evaluacion, y sus relaciones intermedias, se utilizan identificadores únicos (id) autogenerados para simplificar la gestión de claves primarias y foráneas. Esto difiere del modelo conceptual, donde algunas claves se definían como compuestas (por ejemplo, curso y equipo). 52 2. Tokens y autenticación: ○ En la tabla usuario se incluye esta columna adicional para almacenar tokens de acceso, como: ■ github_token: Para gestionar la conexión y acceso seguro con GitHub de un usuario. ○ En la tabla equipo, se incluye estas columnas para gestionar el acceso a Taiga: ■ taiga_project_id: En la API de Taiga, se recomienda usar los ids de proyectos para hacer búsquedas. ■ taiga_refresh_token:En la API de Taiga, se recomienda usar refresh tokens ya que estos pierden validez con el teimpo. (aunque no fue posible realizar la integración final con Taiga, se planteó su inclusión para la autenticación segura). ○ En la tabla curso, se guarda el siguiente token: ■ github_asignatura_token: Se almacena el token de la cuenta de GitHub de la asignatura. 3. Tablas de relaciones intermedias: ○ Se añadieron tablas intermedias explícitas para gestionar relaciones de muchos a muchos: ■ estudiante_curso: Conecta a los estudiantes con los cursos en los que están matriculados, añadiendo información adicional como el grupo al que pertenece cada estudiante. ■ estudiante_equipo: Gestiona la relación de muchos a muchos entre estudiantes y equipos. ■ profesor_curso: Permite asignar a un profesor como responsable de uno o varios cursos. 4. Gestión de evaluaciones: ○ La tabla evaluacion en el diseño físico almacena información detallada de las puntuaciones asignadas por un estudiante a sus compañeros, mientras que evaluacion_detalle organiza la relación entre evaluadores y evaluados, indicando los puntos asignados. 5. Estructura más detallada para iteraciones: ○ La tabla evaluacion está vinculada directamente con los periodos definidos para cada curso, indicando las fechas de inicio y fin del periodo de evaluación. Todo aquello de tanto el esquema conceptual como la base de datos relacionado con Taiga se mantiene para una posible futura ampliación. 53 9.4 Diagramas de secuencia En este apartado se presentan dos diagramas de secuencia que ilustran ejemplos concretos del funcionamiento del sistema: uno para una consulta GET y otro para una operación de creación POST. Junto a cada diagrama, se incluyen los contratos relevantes que intervienen en la acción para proporcionar una visión completa del proceso. El primer diagrama corresponde a una consulta GET para obtener los detalles de un equipo. Dado que se trata de una acción simple, el diagrama incluye tanto el frontend como el backend, claramente separados por una doble línea en el centro de la imagen. Esto permite visualizar la interacción entre ambas partes y cómo se gestionan las solicitudes y las respuestas dentro del sistema. operación EquiposAPI::obtenerEquipoDetalle(id: int): EquipoDetalleDTO exc EquipoNoExiste: No existe un equipo con ese id retorna la información del equipo y los estudiantes que pertenecen al equipo 54 Figura 20. Diagrama de secuencia de la funcionalidad para obtener detalles de un equipo. Fuente: Elaboración propia con Draw.io 55 operación EquipoController::obtenerEquipoDetalle(id: int): <estado, EquipoDetalleDTO> exc EquipoNoExiste: No existe un equipo con ese id retorna en caso de que exista un equipo con ese id un DTO con la información del equipo y de los estudiantes que pertenecen al equipo y un mensaje 200 OK. En caso de que no exista, se devuelve un mensaje de error. operación EquipoService::obtenerDetallePorId(id: int): EquipoDetalleDTO exc EquipoNoExiste: No existe un equipo con ese id retorna la información del equipo y los estudiantes que pertenecen al equipo con ese id operación EquipoRepository::findById(id: int): Equipo exc EquipoNoExiste: No existe un equipo con ese id retorna la información del equipo con ese id operación EstudianteEquipoRepository::findByEquipoId(id: int): Lista <Estudiante> pre EquipoNoExiste: No existe un equipo con ese id retorna los estudiantes que pertenecen al equipo con ese id. El segundo diagrama de secuencia corresponde a una operación POST utilizada para la creación de un curso. A diferencia del primer ejemplo, este diagrama se centra exclusivamente en la interacción dentro del backend, omitiendo la parte del frontend. Esto se debe a que la interacción del frontend es similar a la mostrada en el primer diagrama y no aporta nuevos elementos relevantes. Este diagrama destaca por incluir múltiples subprocesos o subdiagramas que manejan aspectos específicos de la creación del curso 56 Figura 27. Mock-up de la página principal. Fuente: Elaboración propia con Figma [15] Evolución: La página final mantiene una estructura similar pero con un diseño visual mejorado, más moderno y responsivo. Además, ahora incluye un aviso destacado en caso de que el usuario no haya vinculado su cuenta de GitHub, alertándole sobre esta acción pendiente para poder acceder a ciertas funcionalidades del sistema. Página de perfil En el mockup inicial, esta página incluye una sección con herramientas de soporte (GitHub y Taiga) y un formulario para cambiar la contraseña. Figura 28. Mock-up de la página de perfil. Fuente: Elaboración propia con Figma [15] 63 Evolución: En la versión final, la página ha sido simplificada considerablemente. Debido a problemas técnicos, se descartó la integración con Taiga, y como el inicio de sesión se realiza mediante autenticación de Google, ya no es posible gestionar el cambio de contraseña desde la aplicación. La página final se centra únicamente en la conexión del usuario con su cuenta de GitHub, mostrando el estado de la vinculación y permitiendo gestionarla según sea necesario. Página de equipos En el mockup inicial, esta página permite al usuario crear un nuevo proyecto o unirse a uno existente, además de listar los proyectos actuales. Figura 29. Mock-up de la página de equipos. Fuente: Elaboración propia con Figma [15] Evolución: La versión final mantiene una funcionalidad muy similar pero con un diseño más atractivo y refinado. Sin embargo, se eliminó la opción de unirse a un equipo por decisión funcional: ahora, los usuarios no pueden solicitar unirse a un equipo por sí mismos, sino que deben ser añadidos por los responsables del equipo. Esto simplifica la gestión y asegura que solo los usuarios autorizados formen parte de un equipo. 64 Página de evaluaciones En el mockup inicial, se planteó un sistema de evaluación por estrellas, con valoraciones del 1 al 5, dividido en diferentes aspectos para que cada miembro del equipo pudiera evaluar a sus compañeros individualmente. Figura 30. Mock-up de la página de evaluaciones. Fuente: Elaboración propia con Figma [15] Evolución: En la versión final, tras discutir con la tutora, se simplificó el sistema de evaluación. Ahora, se utiliza un sistema de valoración numérica general, donde un estudiante califica el rendimiento global de sus compañeros como grupo, sin desglosarlo por categorías ni evaluar a cada miembro de forma individual. 65 Página equipo (estudiante) En el mockup inicial, los estudiantes podían configurar tanto el proyecto de GitHub como el de Taiga desde esta página. Se incluían opciones para verificar la existencia del proyecto y comprobar si los usuarios requeridos (como el profesor y el estudiante) estaban correctamente vinculados. Figura 31. Mock-up de la página de un equipo. Fuente: Elaboración propia con Figma [15] Evolución: En la versión final, esta página se fusionó con la vista del equipo que también utiliza el profesorado. Aunque mantiene la funcionalidad de configuración para los estudiantes, las métricas y la información avanzada del equipo no están disponibles para ellos. Ahora, los estudiantes solo pueden gestionar la conexión de GitHub, ya que la integración con Taiga fue descartada debido a problemas técnicos. 66 Página equipo (profesor) El mockup inicial para la vista del profesor muestra estadísticas sobre el rendimiento del equipo, incluyendo métricas individuales (como commits realizados, tareas asignadas) y métricas generales del equipo, además de la lista de miembros. Figura 32. Mock-up de la página de un equipo para el profesor. Fuente: Elaboración propia con Figma [15] Evolución: En el diseño final, esta página es similar, solo que hay subpáginas para acceder a los datos de GitHub y a los de las evaluaciones. Cómo he mencionado anteriormente, los mockups iniciales cumplieron un papel clave a lo largo del desarrollo del sistema como referencia para estructurar y visualizar las funcionalidades de cada página. Sin embargo, el diseño y las funcionalidades evolucionaron significativamente para adaptarse a los retos técnicos y a las necesidades reales de los usuarios. Esto resultó en decisiones como la simplificación de interfaces, la unificación de vistas para estudiantes y profesorado, y la eliminación de elementos no implementables. Aunque el diseño final difiere en varios aspectos, los mockups proporcionaron una base sólida sobre la que construir una solución funcional y coherente con los objetivos del proyecto. 67 10.- Implementación En este apartado se detalla el proceso de desarrollo del sistema, incluyendo la implementación de la arquitectura escogida, las herramientas y tecnologías seleccionadas, los lenguajes de programación utilizados, las aplicaciones para la gestión de la base de datos y las dependencias esenciales del proyecto. 10.1 Implementación MVCS Como he mencionado, el patrón utilizado es el MVCS, también llamado Controller-Service-Repository Architecture. Para poder implementarlo correctamente, he distribuido los componentes de la siguiente manera: Organización del Frontend El frontend está desarrollado en React, una biblioteca de JavaScript ampliamente utilizada para construir interfaces de usuario dinámicas y reactivas. Es el encargado de implementar la Vista dentro del patrón MVCS, y está estructurado de la siguiente manera: ● src/components/: Contiene todos los componentes reutilizables de la interfaz, como botones y barras, incluyendo elementos como la barra lateral. Los componentes están separados en /auth y /common para una mejor organización. ● src/pages/: Aquí se ubican las diferentes páginas de la aplicación organizadas en múltiples carpetas: /home, /usuarios, /cursos y /equipos. Cada página importa y combina los componentes necesarios para construir la vista completa. En estas páginas se gestionan los eventos del usuario (ver Figura 20). ● src/utils/: Define las rutas privadas de navegación de la aplicación, asociando cada ruta a un componente de página específico. ● src/services/: Contiene los servicios de comunicación con el backend, implementados para realizar peticiones HTTP. Se centralizan aquí para mantener un código limpio y facilitar el manejo de errores y tokens de autenticación. En el ejemplo de la operación de consultar los detalles de un equipo (Figura 20), el código de la clase EquipoAPI estaria aquí. ● src/assets/: Almacena recursos estáticos como imágenes e iconos. Escogí esta organización para mantener un código limpio, modular y fácil de escalar. Aunque React no sigue estrictamente el patrón MVCS, su capacidad para manejar componentes de forma modular y su gestión del estado permite mantener una estructura organizada y coherente con los principios de separación de responsabilidades. 68 Organización del Backend El backend está desarrollado en Spring Boot, un framework de Java que simplifica la creación de aplicaciones robustas y escalables. La estructura del proyecto sigue las convenciones estándar de Spring: ● src/main/java/tfg/backend_tfg/: Es la raíz del código fuente, donde se ubican los paquetes principales. ○ controller/: Contiene las clases controladoras que manejan las peticiones HTTP entrantes. Cada controlador se encarga de un conjunto específico de endpoints relacionados con funcionalidades como gestión de usuarios, cursos o equipos. ○ service/: Incluye las clases de servicio que encapsulan la lógica del negocio. Los controladores delegan en los servicios las operaciones más complejas, lo que permite mantener los controladores ligeros y enfocados en la interacción con el cliente. ○ repository/: Almacena las interfaces que interactúan con la base de datos, extendiendo las funcionalidades de JPA Repository. Esta capa permite realizar operaciones CRUD sin necesidad de implementar consultas SQL manualmente. ○ model/: Define las entidades del sistema que se mapean a tablas en la base de datos, utilizando anotaciones de JPA para establecer relaciones y restricciones. ○ auth/: Define todas las funcionalidades específicamente relacionadas con la autenticación del usuario en la aplicación. ○ config/: Gestiona la configuración general de la aplicación, así como la de seguridad. ○ dto/: Almacena los archivos que definen todos los Data Transfer Objects (DTOs), los cuales se utilizan para devolver conjuntos de datos específicos. ○ security/: Gestiona la configuración de seguridad, incluyendo la autenticación y autorización mediante JWT. Aquí se definen los filtros de seguridad y las políticas de acceso a los distintos endpoints según el rol del usuario. ● src/main/resources/: Contiene archivos de configuración, como application.properties, además de un application-secret.properties (propiedades privadas), donde se especifican detalles de la conexión a la base de datos y otras propiedades del sistema. Esta organización permite seguir el patrón MVCS de manera efectiva, separando la lógica de presentación (controladores), la lógica del negocio (servicios) y el acceso a datos (repositorios). Además, facilita la implementación de medidas de seguridad y la gestión de transacciones. Al incluir una capa de servicios, los controladores permanecen ligeros y enfocados exclusivamente en manejar las 69 solicitudes del usuario, mientras que los servicios gestionan las validaciones y la lógica empresarial, delegando el acceso a datos a los repositorios. Al combinar tecnologías modernas y muy utilizadas como React y Spring Boot, y al seguir patrones de diseño reconocidos como MVCS, se establece una base muy sólida para el desarrollo de esta aplicación. 10.2 Herramientas y tecnologías utilizadas El desarrollo del sistema se ha llevado a cabo utilizando un conjunto de herramientas y tecnologías modernas que garantizan la robustez, escalabilidad y mantenibilidad del proyecto: Backend ● Java: Lenguaje de programación orientado a objetos. ● Spring Boot: Framework de Java que facilita el desarrollo de aplicaciones robustas y escalables. Proporciona una configuración automatizada y un ecosistema integrado para gestionar dependencias, seguridad y acceso a datos. ● MariaDB: Sistema de gestión de bases de datos relacional, seleccionado por su compatibilidad con el entorno académico y su desempeño en operaciones concurrentes. ● JWT (JSON Web Token): Implementado para autenticar y autorizar las solicitudes de los usuarios de forma segura, eliminando la necesidad de sesiones persistentes en el servidor. ● Maven: Herramienta de gestión de dependencias y construcción del proyecto, utilizada para asegurar la integración fluida de bibliotecas y frameworks en el backend. ● Lombok: Biblioteca para reducir la escritura de código repetitivo en las clases de modelo, generando automáticamente getters, setters, constructores y otros métodos comunes. 70 Frontend ● JavaScript: Lenguaje de programación dinámico utilizado para crear interfaces interactivas y gestionar la lógica del frontend. ● HTML: Lenguaje de marcado que estructura el contenido visible de la aplicación web. ● CSS: Lenguaje de estilos que define la apariencia y diseño visual de los elementos HTML. ● React: Biblioteca de JavaScript utilizada para construir una interfaz de usuario dinámica y modular, que interactúa con el backend a través de APIs RESTful. ● React Router: Para gestionar la navegación entre páginas de la aplicación. ● Context API: Para la gestión global del estado, incluyendo la autenticación del usuario y las preferencias del sistema. Integración con APIs externas ● GitHub API: Para obtener datos en tiempo real sobre las contribuciones de los estudiantes en los repositorios vinculados. ● GitHub GrapQL API: Utilizada para realizar consultas eficientes que consolidan múltiples datos en una sola llamada, optimizando el rendimiento en la obtención de métricas avanzadas. ● Taiga API: Para recopilar información sobre el progreso y la organización de los equipos. Gestión de la base de datos Inicialmente, se utilizó DBeaver para la gestión de la base de datos. Sin embargo, al finalizar su período de licencia gratuita, se migró a Datagrip de JetBrains, una herramienta de código abierto que ofrece funcionalidades similares y se adapta a las necesidades del proyecto. Otras herramientas ● Postman: Utilizado para probar y depurar los endpoints del backend. ● Visual Studio Code: Editor principal para el desarrollo del código. ● Git: Sistema de control de versiones para gestionar el código fuente. 71 10.3 Dependencias del backend El archivo pom.xml de Maven define todas las dependencias necesarias para el correcto funcionamiento del backend. A continuación, se enumeran las dependencias principales y su propósito: Spring Boot Starters ● spring-boot-starter-web: Proporciona las herramientas necesarias para desarrollar APIs RESTful, incluyendo soporte para JSON y un servidor embebido (Tomcat). ● spring-boot-starter-data-jpa: Facilita la interacción con bases de datos relacionales utilizando JPA (Java Persistence API) y herramientas como Hibernate. ● spring-boot-starter-security: Implementa seguridad en el backend, manejando la autenticación y autorización de usuarios. JWT (JSON Web Token) ● jjwt-api: Proporciona las clases principales para crear, firmar y validar tokens JWT. ● jjwt-impl y jjwt-jackson: Extienden las capacidades de jjwt-api, proporcionando implementación para el manejo de JWT en tiempo de ejecución, con soporte para JSON utilizando Jackson. ● java-jwt: Biblioteca adicional para manejar la creación y verificación de tokens JWT con más flexibilidad. MariaDB ● mariadb-java-client: Driver JDBC que permite la conexión entre Spring Boot y la base de datos MariaDB. Gson ● gson: Biblioteca para serializar y deserializar objetos JSON, utilizada en algunas operaciones donde se requiere manipulación avanzada de datos JSON. Google API Client ● google-api-client: Proporciona herramientas para interactuar con servicios de Google, como la validación de tokens de inicio de sesión. ● google-oauth-client: Biblioteca para manejar flujos de autenticación OAuth 2.0, especialmente útil para validar tokens generados por Google. 72 Mostrar gráficas de datos de Github Pasado Como profesor, cuando entramos en la página de datos de GitHub nos muestra los gráficos que se generan con las métricas de los estudiantes. Por razones ya explicadas, se ha excluido todo test relacionado con Taiga (HU06b). Las funcionalidades que le correspondían han sido sustituidas con otras de GitHub, por eso se han hecho las pruebas respectivas. 11.2 Validación requisitos no funcionales En este siguiente apartado voy a describir cómo se han cumplido los requisitos no funcionales definidos al inicio del proyecto, especificados en el apartado 8.2. Para cada requisito, se detalla qué decisiones de diseño, herramientas o metodologías se han empleado para garantizar su cumplimiento. Escalabilidad Este requisito se ha cumplido mediante la selección de una base de datos relacional robusta, como MariaDB, capaz de gestionar grandes volúmenes de datos de manera eficiente. La estructura del sistema se diseñó específicamente para soportar múltiples cursos y varios equipos por curso. Gracias a la optimización de consultas y la utilización de índices en las tablas más relevantes (como estudiantes, equipos y cursos), se garantiza que el rendimiento del sistema no se degrade, incluso en escenarios de alta carga de usuarios y datos. Esto asegura tiempos de respuesta reducidos para operaciones estándar, cumpliendo con las condiciones de satisfacción establecidas. Disponibilidad y fiabilidad Este requisito se ha cumplido al desplegar la aplicación en un servidor proporcionado por la UPC, una infraestructura que garantiza un uptime elevado gracias a su estabilidad y soporte técnico. Esto asegura que los estudiantes y profesores puedan acceder al sistema en cualquier momento sin interrupciones, y que los datos críticos de usuarios y equipos estén disponibles y protegidos frente a posibles fallos o errores. Seguridad Este requisito se ha cumplido mediante la implementación de OAuth para la autenticación de usuarios, lo que elimina la necesidad de almacenar y cifrar contraseñas, ya que se delega la autenticación a un proveedor externo como Google. Además, se utiliza JWT (JSON Web Tokens) para garantizar la seguridad en cada sesión, verificando que solo los usuarios autorizados puedan acceder a las funcionalidades y datos según su rol. El sistema verifica cada solicitud utilizando 79 estos tokens, asegurando que las acciones sean realizadas únicamente por usuarios con los permisos adecuados. De esta manera, se protege la confidencialidad e integridad de los datos de estudiantes y equipos. Por otro lado, este requisito tiene otra condición que se cumple gracias a decisiones clave tomadas durante el desarrollo del proyecto. Solo los profesores tienen acceso a las métricas individuales de los estudiantes y a los resultados detallados de las evaluaciones, restringiendo así la información sensible que ven los estudiantes. Esta decisión garantiza el cumplimiento de regulaciones de privacidad y protegen la integridad de la información personal. Rendimiento Aunque el sistema fue diseñado para garantizar tiempos de respuesta rápidos, este objetivo no se ha cumplido completamente debido a limitaciones inherentes en la interacción con la API de GitHub. Para obtener métricas de un repositorio o una organización, es necesario realizar múltiples llamadas a la API, ya que no existe una única llamada global que proporcione toda la información requerida. Esto genera un pequeño tiempo de espera, de aproximadamente 15 segundos, para procesar y consolidar los datos necesarios. Aunque se ha implementado GraphQL en ciertas llamadas para optimizar el rendimiento, todavía persiste este periodo de espera en otras áreas, ya que no se ha contado con el tiempo suficiente para aplicar GraphQL en todas las solicitudes necesarias. Usabilidad El requisito de usabilidad se ha abordado mediante el diseño de una interfaz intuitiva y clara, que permite a los usuarios completar tareas clave en menos de tres clics. Para garantizar este objetivo, se realizó una demo del sistema con la tutora responsable del TFG, que será usuaria de la aplicación, quien proporcionó valioso feedback sobre posibles errores y mejoras en el diseño de la interfaz. Gracias a estas sugerencias, se realizaron ajustes que maximizan la facilidad de uso, optimizando la disposición de las vistas y paneles. Esta colaboración permitió alcanzar una experiencia de usuario más fluida y efectiva tanto para estudiantes como para profesores. Mantenimiento El requisito de mantenimiento se ha cumplido gracias a la elección de una arquitectura basada en el modelo MVC (Model-View-Controller). Esta estructura modular permite una clara separación de responsabilidades, lo que facilita la edición o adición de nuevas funcionalidades sin interferir con el resto del código existente. Gracias a esta arquitectura, las modificaciones en la lógica de negocio, las vistas o los controladores pueden realizarse de manera independiente, reduciendo significativamente los riesgos de errores, y por lo tanto, garantizando la sostenibilidad y evolución del sistema a largo plazo. 80 12.- Instalación y documentación 12.1 Requisitos e instalación de la aplicación web En este siguiente apartado, voy a explicar todo lo necesario para poder realizar la instalación de CERCLES. Antes de proceder a la instalación, hay que asegurarse de cumplir con los siguientes requisitos: 1. IDE (Entorno de desarrollo integrado): Visual Studio Code (VSC) o cualquier otro IDE para trabajar con proyectos backend y frontend, como IntelliJ, Eclipse, etc. 2. Java Development Kit (JDK): Descargar e instalar la versión 23 del JDK desde Oracle [24]. 3. Apache Maven: Instalar Maven para gestionar las dependencias y construir el archivo .war. Para instalarlo: a. En Linux/Ubuntu: sudo apt install maven b. En Windows: Descargar desde Maven [25] e incluirlo en las variables de entorno. 4. Node.js y npm: Descargar e instalar la versión 16+ de Node.js, que incluye npm [26]. 5. Servidor web Apache Tomcat: Descargar la versión 10.x desde Tomcat Downloads [27]. Posteriormente, instalar y configurar el servidor Tomcat. También cabe la posibilidad de descargar cualquier otro servidor web. 6. Base de datos MariaDB: Descargar e instalar MariaDB desde MariaDB Official Downloads [28]. Una vez contamos con todos los elementos necesarios, los pasos a seguir son los siguientes: 1. Generar el archivo .war desde el IDE 2. Desplegar el archivo .war en el servidor web (Apache Tomcat). Al desplegar este archivo, se creará un directorio en el que estarán los archivos necesarios para la ejecución de la aplicación. 3. Crear una nueva base de datos en MariaDB o MySQL, asegurándose de guardar la información de conexión (URL, puerto, usuario y contraseña). No es necesario añadir tablas ni datos manualmente, ya que la aplicación se encargará de crear las estructuras necesarias al ejecutarse por primera vez. 4. Ajustar los parámetros de conexión a la base de datos en la aplicación: Modificar el archivo application.properties (ubicado en la carpeta src/main/resources) en el directorio que se ha creado al desplegar la aplicación (punto 2), para incluir los datos de acceso a la base de datos que se han guardado en el punto 3. Este archivo debe contener la URL, usuario y contraseña que se han definido al crear la base de datos. 81 [Figura 34] Ejemplo de application-properties. Fuente: Elaboración propia 5. Iniciar el servidor: Una vez configurados los pasos anteriores, iniciar Apache Tomcat. La aplicación estará accesible desde el navegador en el puerto configurado, generalmente http://localhost:8080. Siguiendo estas instrucciones, la aplicación estará lista para su uso en el servidor correspondiente. El código de la aplicación se puede encontrar en la organización de GitHub: cercles-tfg. 12.2 Documentación de la RESTful API CERCLES, como aplicación web diseñada con una arquitectura MVCS, utiliza un servicio de API REST para gestionar la comunicación entre el frontend y el backend, es decir, entre las vistas y los controladores. Este diseño permite que las diferentes funcionalidades de la aplicación se integren de manera eficiente mediante llamadas a endpoints que proporcionan y reciben datos en formato JSON, un formato ampliamente usado debido a su facilidad de procesamiento y representación en las interfaces de usuario. El diseño de esta API se ha desarrollado conforme a las mejores prácticas para garantizar su funcionamiento como una RESTful API eficiente. En este proyecto, resultó fundamental diseñar nuevos métodos y endpoints que cumplieran con estos estándares. Por ejemplo, las URLs de los endpoints están estructuradas para representar claramente los recursos principales del sistema, como estudiantes, equipos y cursos. Esto permite que cada recurso sea gestionado de manera clara y coherente a través de operaciones bien definidas. En este apartado se presentan los endpoints de la API REST de forma general, mostrando todas las llamadas disponibles en el sistema. Cada endpoint está documentado con su propósito, parámetros esperados y las respuestas correspondientes, utilizando un formato estandarizado como el proporcionado por Swagger. Esto facilita la visualización y comprensión de las operaciones CRUD (Crear, Leer, Actualizar y Eliminar) que la API soporta sobre los recursos principales del sistema. 82 A continuación podemos ver la lista de todos los endpoints implementados agrupados por autorización; gestión de usuarios, cursos, equipos y evaluaciones; y las consultas sobre los datos del GitHub. 83 Figura 35. Endpoints del código. Fuente: Elaboración propia con swagger [29]. 84 El texto necesario para visualizar la documentación de la RESTful API se encuentra en el documento openapi.yaml de la carpeta docs dentro del código proporcionado, específicamente en el repositorio del backend. Para visualizarlo, se debe utilizar el editor Swagger [29]. 12.3 Manual de usuario Este apartado de la memoria está destinado a guiar tanto a profesores como a estudiantes en el uso de la aplicación, ofreciendo instrucciones detalladas sobre cómo realizar las tareas clave dentro del sistema. Inicio de Sesión En primer paso, tenemos el inicio de sesión. Para poder acceder a CERCLES, se debe iniciar sesión utilizando la cuenta de correo electrónico proporcionada por la universidad. Este proceso de autenticación se realiza mediante Google, garantizando seguridad y facilidad de acceso. Figura 36. Captura de pantalla parcial del inicio de sesión. Fuente: Elaboración propia Pasos: 1. En la pantalla de inicio, encontrarás el botón "Inicia la sessió amb Google". 2. Haz clic en el botón e inicia sesión con tu cuenta de la universidad. 3. Una vez autenticado, el sistema identificará automáticamente si eres un profesor o un estudiante. A partir de aquí, se diferenciaránlas pantallas o funcionalidades dentro de una misma pantalla según las que ve un estudiante o un profesor. 85 Página de inicio (Home) La página de inicio es la primera pantalla que aparece tras iniciar sesión en CERCLES y es prácticamente idéntica tanto para estudiantes como para profesores, con una única pequeña diferencia. Figura 37. Captura de pantalla parcial de la página de inicio. Fuente: Elaboración propia Pasos: 1. Accedir al Perfil: Este botón está disponible tanto para estudiantes como para profesores y permite acceder a la página de configuración del perfil. 2. Veure cursos/Veure equips: ○ Para profesores, este botón permite ver los cursos que gestionan. ○ Para estudiantes, este botón permite ver los equipos en los que participan. En caso que el usuario no haya configurado su cuenta de GitHub en su perfil, aparecerá un aviso destacado justo encima de los botones principales. Este aviso sirve para recordar al usuario que debe completar la configuración de su cuenta de GitHub, ya que es necesaria para el correcto funcionamiento de la aplicación. Página de perfil La página de perfil es común tanto para profesores como para estudiantes y permite gestionar la conexión del usuario con su cuenta de GitHub. Se presentan dos estados principales en esta pantalla. 86 Estado inicial (sin conectar) Figura 38. Captura de pantalla parcial de la página de perfil sin conectar. Fuente: Elaboración propia En este caso, el sistema muestra un botón "Connecta amb GitHub", que redirige a la página oficial de GitHub para realizar la conexión. Figura 39. Captura de pantalla de la redirección de GitHub. Fuente: Elaboración propia 87 Es importante prestar atención al mensaje destacado en negrita. Este indica que, si ya existe una sesión activa en GitHub, CERCLES asociará automáticamente la cuenta que está activa. Para conectar otra cuenta, será necesario cerrar previamente la sesión en GitHub. Este mensaje es relevante para evitar errores o confusiones al vincular una cuenta. Estado conectado Figura 40. Captura de pantalla parcial de la página de perfil conectado. Fuente: Elaboración propia Una vez que se ha establecido la conexión, y para poder verificar que la cuenta conectada es la correcta, la página muestra los siguientes datos relacionados con el usuario de GitHub: ● Nombre de usuario en GitHub. ● Número de repositorios públicos y privados. ● Número de organizaciones en las que participa el usuario. Se puede desconectar de esa cuenta simplemetne clicando en el botón de “Desconnecta el compte de GitHub” 88 Crear un equipo La pantalla de creación de equipos está diseñada para que tanto profesores como estudiantes puedan formar nuevos equipos dentro de los cursos en los que están involucrados. Figura 45. Captura de pantalla parcial de la página de un crear un equipo. Fuente: Elaboración propia Aunque la pantalla es similar para ambos roles, hay ligeras diferencias en su funcionamiento: Información general: 1. Nombre del equipo: Es un campo obligatorio donde se debe escribir un nombre para identificar al equipo. 2. Selección del curso: ○ Estudiantes: Se muestra un selector desplegable con los cursos en los que el estudiante está matriculado y donde aún no forma parte de un equipo. ○ Profesores: El curso ya está preseleccionado, ya que esta página sólo es accesible desde la página de detalles de un curso. 3. Profesor evaluador: Se debe seleccionar un profesor del curso que será responsable de evaluar al equipo. Es importante que los estudiantes se informen previamente sobre quién será su evaluador. 95 Selección de miembros: ● Una vez seleccionado el curso (o directamente para el profesor), se muestra una lista de estudiantes que pertenecen al curso pero que aún no forman parte de ningún equipo. ● Los usuarios pueden buscar estudiantes por nombre utilizando la barra de búsqueda disponible. ● Es obligatorio seleccionar al menos un miembro para crear el equipo. Proceso de creación: 1. Después de completar todos los campos y seleccionar los miembros, se debe pulsar el botón "Crear Equip", el cual mostrará al usuario un pop up con los datos para que confirme la crreación del equipo. 2. Si los datos ingresados son correctos, el equipo se crea y pasa a ser visible en la página de equipos del curso correspondiente (para el profesor) o en la página de equipos (para el estudiante). Página para evaluar La página de evaluación está disponible exclusivamente para los estudiantes. En esta vista, se muestran todos los compañeros del equipo, incluyendo al propio estudiante. Cada miembro debe recibir una puntuación según la evaluación del estudiante. Figura 46. Captura de pantalla parcial de la página para evaluar como estudiante. Fuente: Elaboración propia 96 La suma total de todas las puntuaciones asignadas debe ser equivalente al número de miembros del equipo multiplicado por 10. Esto incluye la autoevaluación, que también debe realizarse. Una vez completadas las puntuaciones, se puede enviar la evaluación utilizando el botón Enviar al final de la página. Esta página sólo estará disponible en los periodos seleccionados por el prfoesro al crear el curso. Página de evaluaciones La página de evaluaciones está disponible únicamente para los profesores y proporciona un desglose detallado de las evaluaciones realizadas por los estudiantes dentro de un equipo. Esta página incluye las siguientes secciones: Figura 47. Captura de pantalla de la tabla resumen de evaluaciones. Fuente: Elaboración propia En la parte superior, se presenta una tabla resumen que contiene: ● Columnas por estudiante: Cada columna representa a un estudiante del equipo. ● Media de compañeros: Muestra la media de las evaluaciones recibidas por cada estudiante de parte de sus compañeros en todos los períodos de evaluación. ● Media de autoevaluaciones: Indica la media de las autoevaluaciones realizadas por cada estudiante en los distintos períodos de evaluación. Debajo de la tabla resumen, se presenta una tabla por cada período de evaluación, con los siguientes elementos: 97 Figura 48. Captura de pantalla de la tabla detalles de evaluaciones. Fuente: Elaboración propia ● Filas y columnas: Cada fila y columna corresponde a un estudiante. Las intersecciones muestran las evaluaciones que un estudiante ha dado a otro (o a sí mismo en el caso de la diagonal). ● Última fila: Indica la media de las evaluaciones que cada estudiante ha recibido de sus compañeros durante ese período. Sistema de colores ● Verde: Representa valores superiores a 11, indicando evaluaciones altas. ● Rojo: Representa valores inferiores a 9, destacando evaluaciones bajas. ● Azul: Aparece únicamente en la diagonal de las tablas de evaluaciones, indicando las autoevaluaciones realizadas por los estudiantes. 98 Página de detalles de los datos de GitHub La pantalla de detalles de los datos de GitHub, exclusiva para los profesores, permite realizar un análisis exhaustivo de las métricas de cada equipo a través de varias tablas y gráficos. Tablas de métricas de contribuciones de usuarios. Figura 49. Captura de pantalla de la tabla métricas de GitHub. Fuente: Elaboración propia 1. “Métriques de les contribucions dels usuaris”: ○ “#Commits”: Cantidad de commits realizados por cada miembro del equipo. ○ “#Línies ++”: Número total de líneas de código añadidas por cada miembro. ○ “#Línies –”: Número total de líneas de código eliminadas por cada miembro. ○ “#PRs creats”: Cantidad de pull requests creadas por cada miembro. ○ “#PRs fusionats”: Cantidad de pull requests creadas por cada miembro. ○ En la última columna, se muestra una media general para cada métrica considerando todos los miembros. 2. “Métriques d'històries d'usuari i tasques”: ○ “Històries d'usuari”: Cantidad de historias de usuario asignadas a cada miembro. ○ “Històries d'usuari tancades”: Cantidad de historias de usuario asignadas y cerradas por cada miembro. 99 ○ “Tasques”: Cantidad de tareas asignadas a cada miembro. ○ “Tasques tancades”: Cantidad de tareas asignadas y cerradas por cada miembro. ○ En la última columna, se encuentra la media de las métricas en cada fila. Tablas de detalles de historias de usuario y tareas Figura 50. Captura de pantalla de la tabla de detalles de HU y tareas. Fuente: Elaboración propia ● Detalles de historias de usuario: ○ Se listan todas las historias de usuario creadas como issues en GitHub con un label asociado. ○ Labels válidos para historias de usuario: "user story", "historia de usuario", "història d'usuari". ○ Se indica el miembro al que está asignada la historia. Si no está asignada a nadie, se marca la última columna como "No assignat". ● Detalles de tareas: ○ Similar a las historias de usuario, pero con el label correspondiente a tareas. ○ Labels válidos para tareas: "task", "tarea", "tasca". 100 Gráficos de métricas Figura 51. Captura de pantalla de los gráficos de GitHub. Fuente: Elaboración propia 1. Distribució de commits: ○ Un gráfico circular que muestra la proporción de commits realizados por cada miembro del equipo. 2. Línies afegides i eliminades: ○ Un gráfico de barras que compara las líneas de código añadidas y eliminadas por cada miembro. 3. Històries d'usuari i tasques tancades: ○ Un gráfico de barras que muestra cuántas historias de usuario y tareas ha cerrado cada miembro. 4. Distribució d'històries d'usuari totals: ○ Un gráfico circular que muestra la proporción de historias de usuario asignadas a cada miembro. 101 Página de resumen de métricas de un equipo En la página de resumen de un equipo, los profesores pueden visualizar de forma conjunta las tablas de Métriques de les contribucions dels usuaris y Métriques d'històries d'usuari i tasques relacionadas con GitHub, así como la tabla de resumen de evaluaciones. Esta vista tiene como objetivo proporcionar una visión general de toda la información relevante del equipo en un único lugar. Si se requiere mayor detalle, el profesor puede acceder a cualquiera de las subpáginas específicas para profundizar en los datos de GitHub o de las evaluaciones. 102 13.- Informe de sostenibilidad 13.1 Autoevaluación Al realizar el cuestionario sobre sostenibilidad del Proyecto EDINSOST2-ODS [30], me he dado cuenta de que, aunque no poseo un conocimiento profundo sobre muchos de los conceptos y estrategias mencionados, tengo la capacidad de identificar cómo podría llevar a cabo un proyecto considerando las tres dimensiones: social, ambiental y económica. A lo largo de mi carrera, he aprendido que es fundamental integrar estos aspectos, incluso si no se tienen todos los conocimientos técnicos. En la universidad, el componente social ha sido el que más he desarrollado y aplicado. Un claro ejemplo de esto fue en la asignatura de Enginyeria dels Requisits (ER), donde nos pidieron crear un proyecto que usara las TIC con un impacto positivo en la sociedad. Propuse a mi grupo trabajar en un proyecto de residencias inteligentes para personas de la tercera edad, con el objetivo de proporcionar un entorno más seguro y eficaz a la hora de tratar a este colectivo. Por otro lado, también he tenido experiencias relacionadas con la sostenibilidad ambiental y económica. Por ejemplo, se nos inculcó la importancia de reutilizar los recursos, evitando la compra innecesaria de nuevas máquinas y promoviendo el aprovechamiento de componentes ya existentes, lo que nos hizo ser conscientes de cómo hacer una gestión responsable de materiales. En cuanto a la sostenibilidad económica, en casi todos los proyectos que hemos desarrollado, nos han insistido en realizar una evaluación económica responsable, asegurándonos de no exceder el presupuesto y de buscar siempre la eficiencia en los costes. En conclusión, he aprendido que no se puede trabajar en un proyecto ignorando cualquiera de las tres dimensiones de la sostenibilidad. Es fundamental tener siempre en mente el equilibrio entre lo social, ambiental y económico para asegurar que cualquier iniciativa tenga un impacto verdaderamente positivo y duradero. 13.2 Dimensión económica Respecto al Proyecto puesto en producción (PPP): ● ¿Reflexión sobre el coste que has estimado para la realización del proyecto? El coste estimado del proyecto se ha calculado teniendo en cuenta los salarios de los diferentes roles necesarios, así como los recursos físicos y tecnológicos. Al ser el único participante, los costes asociados se han reducido, pero aún así se ha hecho una estimación realista de lo que implicaría si participaran otros profesionales. Además, el uso de herramientas de software gratuitas y la amortización del hardware han permitido ajustar el presupuesto total, mostrando que es posible llevar a cabo el proyecto de manera eficiente y económica. 103 Respecto a la Vida Útil: ● ¿Cómo se resuelven actualmente los aspectos de costes del problema que quieres abordar (estado del arte)? Actualmente, se usan procesos manuales en Excel para la gestión y evaluación de estudiantes en proyectos en equipo, lo que hace que el profesorado tarde más tiempo en evaluar, aumentando así el coste en términos de horas dedicadas. ● ¿En qué mejorará económicamente (costes...) tu solución respecto a las existentes? Mi solución reducirá costes al usar un sistema gratuito, centralizado y automatizado, eliminando la necesidad de licencias y optimizando el uso de recursos humanos. 13.3 Dimensión ambiental Respecto al Proyecto puesto en producción (PPP): ● ¿Has estimado el impacto ambiental que tendrá la realización del proyecto? El impacto ambiental del proyecto es mínimo, ya que se desarrollará usando recursos ya disponibles, como un portátil propio que tiene ya unos años y software gratuito. ● ¿Te has planteado minimizar su impacto, por ejemplo, reutilizando recursos? Sí, el proyecto se llevará a cabo utilizando hardware existente y software en la nube para evitar la compra de nuevos equipos. Respecto a la Vida Útil: ● ¿Cómo se resuelve actualmente el problema que quieres abordar (estado del arte)?, y. ¿En qué mejorará ambientalmente tu solución respecto a las existentes? El sistema actual se basa en herramientas como Excel que pueden requerir más impresiones y uso de papel. Mi solución, al digitalizar y automatizar procesos, reduce este consumo, contribuyendo a la sostenibilidad ambiental. 13.4 Dimensión social Respecto al Proyecto puesto en producción (PPP): ● ¿Qué crees que te aportará a nivel personal la realización de este proyecto? La realización de este proyecto me permitirá desarrollar una serie de habilidades técnicas y personales que considero fundamentales para mi futuro profesional. Al abordar el diseño y la implementación de un sistema de gestión de equipos, tendré 104 Glosario GitHub: Plataforma en línea que permite alojar repositorios Git y colaborar en el desarrollo de proyectos de software de manera distribuida [3]. Taiga: Herramienta de gestión de proyectos ágil que facilita la organización, seguimiento y planificación de tareas en equipos colaborativos [4]. Commit: Acción en Git que guarda los cambios realizados en el código, creando un punto de control en el historial del proyecto. Pull Request: Propuesta para fusionar cambios en el código desde una rama hacia otra, permitiendo revisión y discusión antes de su integración. API: Conjunto de reglas y definiciones que permiten que diferentes aplicaciones o servicios se comuniquen entre sí mediante solicitudes y respuestas. Framework: Conjunto de herramientas y bibliotecas que proporcionan una estructura predefinida para desarrollar software de manera más eficiente y organizada. Plugin: Módulo o extensión de software que añade funcionalidades adicionales a una aplicación principal sin modificar su estructura base. Sprint: Ciclos cortos de trabajo en la metodología Agile, donde se desarrollan y entregan funcionalidades específicas del proyecto en un periodo de tiempo definido, generalmente de 1 a 4 semanas. CRUD: Acrónimo (en inglés) para las posibles operaciones sobre los datos (Create, Read, Update, Delete). 111 Referencias [1] Facultat d'Informàtica de Barcelona (FIB) — Universitat Politècnica de Catalunya, [Online]. Disponible en: https://www.fib.upc.edu/ [Último acceso: 18-sep-2024]. [2] Assignatures del Grau en Enginyeria Informàtica — Facultat d'Informàtica de Barcelona (FIB), [Online]. Disponible en: https://www.fib.upc.edu/ca/estudis/graus/grau-en-enginyeria-informatica/pla-destu dis/assignatures [Último acceso: 18-sep-2024]. [3] GitHub — Git, [Online]. Disponible en: https://github.com/ [Último acceso: 21-sep-2024]. [4] Taiga — Tree Taiga, [Online]. Disponible en: https://tree.taiga.io/login?unauthorized=true&next=%2F [Último acceso: 21-sep-2024]. [5] Git Insights — Git Insights, [Online]. Disponible en: https://github.com/git-insights/git-insights [Último acceso: 20-sep-2024]. [6] Ausum Cloud — Scrum: Metodología Ágil Más Popular en Empresas, [Online]. Disponible en: https://ausum.cloud/scrum-metodologia-agil-mas-popular-en-empresas/ [Último acceso: 20-sep-2024]. [7] Atlassian — Gitflow Workflow, [Online]. Disponible en: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow [Último acceso: 20-sep-2024]. [8] Google, "Meet", [Online]. Disponible en: https://meet.google.com/landing [Último acceso: 24-sep-2024]. [9] Facultat d’Informàtica de Barcelona, “Guia per a la Gestió de Projectes”, FIB UPC, [Online]. Disponible en: https://www.fib.upc.edu/sites/fib/files/documents/estudis/guia-gep-raco-fib.pdf [Último acceso: 1-oct-2024]. [10] Facultat d’Informàtica de Barcelona, “Trabajo de Fin de Grado”, FIB UPC, [Online]. Disponible en: https://www.fib.upc.edu/es/estudios/grados/grado-en-ingenieria-informatica/trabaj o-de-fin-de-grado [Último acceso: 1-oct-2024]. [11] Microsoft, “Visual Studio Code”, Code Visual Studio, [Online]. Disponible en: https://code.visualstudio.com [Último acceso: 1-oct-2024]. [12] Spring, “Spring Boot Framework”, Spring.io, [Online]. Disponible en: https://spring.io/projects/spring-boot [Último acceso: 1-oct-2024]. 112 [13] React, “React: A JavaScript Library for Building User Interfaces”, React Dev, [Online]. Disponible en: https://es.react.dev/ [Último acceso: 1-oct-2024]. [14] SQLite, “SQLite Home Page”, SQLite, [Online]. Disponible en: https://www.sqlite.org/index.html [Último acceso: 1-oct-2024]. [15] Figma, “Figma Design Tool”, Figma, [Online]. Disponible en: https://www.figma.com/ [Último acceso: 1-oct-2024]. [16] Diagrams.net, “diagrams.net Online Diagramming Tool”, diagrams.net, [Online]. Disponible en: https://app.diagrams.net/ [Último acceso: 1-oct-2024]. [17] Instagantt, “Instagantt: Project Management Tool”, Instagantt, [Online]. Disponible en: https://www.instagantt.com/ [Último acceso: 1-oct-2024]. [18] InfoJobs, “Buscador de Salarios”, [Online]. Disponible en: https://salarios.infojobs.net/ [Último acceso: 5-oct-2024]. [19] Amazon, “Dell XPS 15 9500 (Latest Model)”, [Online]. Disponible en: https://www.amazon.com/Dell-XPS-15-9500-i7-10750H/dp/B08LDZNRPC#:~:te xt=About%20this%20item.%20del%20XPS%2015%209500%20 [Último acceso: 5-oct-2024]. [20] Mitre Workspace, "Alquiler de despachos privados en Sarriá-Sant Gervasi", [Online]. Disponible en: https://mitreworkspace.com/alquiler-despachos-privados-sarria-santgervasi-barcel ona/ [Último acceso: 14-oct-2024]. [21] Volere, "Plantilla de requisitos Volere", [Online]. Disponible en: https://www.volere.org/wp-content/uploads/2018/12/template_es.pdf [Último acceso: 15-oct-2024]. [22] RandiKatech Blog, "Get your hands dirty with Micro-Services (MVCS)", [Online]. Disponible en: http://randikatech.blogspot.com/2019/09/get-your-hands-dirty-with-micro-services .html [Último acceso: 17-dic-2024]. [23] Lope González, "Tema 9: Internet - TIC I (1º Bachillerato)", [Online]. Disponible en: https://lopegonzalez.es/eso-y-bachillerato/tic-i-1o-bachillerato/tema-9-internet/ [Último acceso: 8-nov-2024]. [24] Oracle, "Descargas de Java", [Online]. Disponible en: https://www.oracle.com/java/technologies/downloads/?er=221886 [Último acceso: 9-dic-2024]. [25] Apache Maven, "Descargas de Maven", [Online]. Disponible en: https://maven.apache.org/download.cgi [Último acceso: 9-dic-2024]. 113 [26] Node.js, "Descarga Node.js", [Online]. Disponible en: https://nodejs.org/en [Último acceso: 5-dic-2024]. [27] Apache Tomcat, "Descargas de Apache Tomcat 10", [Online]. Disponible en: https://tomcat.apache.org/download-10.cgi [Último acceso: 5-ene-2024]. [28] MariaDB, "Descargas de MariaDB", [Online]. Disponible en: https://mariadb.org/download/ [Último acceso: 7-dic-2024]. [29] Swagger Editor, "Editor Swagger", [Online]. Disponible en: https://editor.swagger.io/ [Último acceso: 14-dic-2024]. [30] Google Forms, “Cuestionario sobre los Objetivos de Desenvolupament Sostenible (ODS)”, [Online]. Disponible en: https://docs.google.com/forms/d/e/1FAIpQLSfVgBxcxZfh7pB_OVRUNGQmRpF DFlhAskukNcpQBowLRF4-sA/viewform [Último acceso: 8-oct-2024]. 114