Herramienta web para la evaluación de proyectos de la metodologia ABP

id177694   HERRAMIENTA WEB PARA LA EVALUACIÓN DE PROYECTOS DE LA METODOLOGIA ABP CARLOS EXOJO GAVILAN Director/a: ALEJANDRORÍOSJEREZ(DepartamentodeCienciasdelaComputación) Titulación:GradoenIngenieríaInformática(IngenieríadelSoftware) Memoria del proyecto Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 29/06/2023 Resumen Este proyecto se entrega como Trabajo Final de Grado de Ingeniería Informática de la Facultad de Informática de Barcelona. Se pretende poner en práctica los conocimientos adquiridos durante la mención en Ingeniería del Software. El proyecto consiste en diseñar e implementar una herramienta software que permita, por un lado, a profesores crear proyectos para ser evaluados con la metodología de aprendizaje activo ABP (Aprendizaje Basado en Proyectos) y evaluarlos de manera efectiva y, por otro lado, a alumnos disponer de una plataforma donde poder consultar las calificaciones de estos proyectos de manera confidencial. Resum Aquest projecte es lliura com a Treball Final de Grau d'Enginyeria Informàtica de la Facultat d'Informàtica de Barcelona. Es pretén posar en pràctica els coneixements adquirits durant la menció en Enginyeria del Software. El projecte consisteix a dissenyar i implementar una eina software que permeti, per una banda, a professors crear projectes de la metodologia d’aprenentatge actiu ABP (Aprenentatge Basat en Projectes) i avaluar-los de manera efectiva i, per altra banda, a alumnes disposar d’una plataforma on podeu consultar les qualificacions d'aquests projectes. Abstract This project is delivered as the Final Project of Computer Engineering Degree of the Barcelona School of Informatics. It is intended to put into practice the knowledge acquired during the mention in Software Engineering. The project consists of designing and implementing a software tool that allows, on the one hand, teachers to create projects of the active learning methodology PBL (Project Based Learning) and evaluate them effectively and, on the other hand, students to have a platform where they can consult the grades of these projects. 3 Índice de contenidos 1. Introducción 9 1.1 Contextualización 9 1.2 Descripción del problema 9 1.3 Definiciones 10 1.4 Stakeholders 10 2. Justificación 11 2.1 Google Classroom 11 2.2 Moodle 12 2.3 Hojas de cálculo 12 2.4 Conclusiones 13 3. Alcance 13 3.1 Objetivos 13 3.2 Requisitos funcionales 14 3.3 Requisitos no funcionales 14 3.4 Riesgos 15 4. Metodología y rigor 16 4.1 Trello 16 4.2 Git 16 5. Descripción de las tareas 17 5.1 Descripción de las tareas 18 5.1.1 Gestión del proyecto 18 5.1.2 Desarrollo 18 5.1.2.1 Inception 19 5.1.2.2 Sprint 1 19 5.1.2.3 Sprint 2 20 5.1.2.4 Sprint 3 21 5.1.2.5 Sprint 4 21 5.1.3 Documentación 22 5.2 Recursos 22 5.2.1 Recursos humanos 22 5.2.2 Recursos materiales 23 5.3 Estimaciones 23 6. Diagrama de Gantt 25 7. Gestión del riesgo: Planes alternativos y obstáculos 26 7.1 Falta de conocimientos 26 7.2 Bugs 26 7.3 Tiempo limitado 26 8. Presupuesto 27 8.1 Identificación y estimación de costes 27 8.1.1 Costes de Personal por Actividad 27 8.1.2 Costes Generales 29 8.1.3 Contingencias 30 4 8.1.4 Coste de imprevistos 31 8.1.5 Presupuesto final 32 8.2 Control de gestión 32 9. Sostenibilidad 33 9.1 Sostenibilidad ambiental 33 9.2 Sostenibilidad económica 34 9.3 Sostenibilidad social 34 10. Especificación 35 10.1 Diagramas de casos de uso 35 10.2 Descripción de los casos de uso 40 10.3 Modelo conceptual de datos 51 10.3.1 Esquema conceptual de datos 51 10.3.2 Restricciones de integridad 53 10.3.3 Descripción de las clases 54 11. Diseño 56 11.1 Patrón MVC 56 11.2 Patrones de diseño 57 11.2.1 Hook pattern 57 11.2.2 Provider pattern 57 11.3 Diseño del front-end 58 11.3.1 Mapa navegacional Institución 58 11.3.2 Mapa navegacional Profesor Administrador 59 11.3.3 Mapa navegacional Profesor 60 11.3.4 Mapa navegacional Alumno 61 11.3.5 Diseño de la capa de presentación 62 11.4 Diseño del backend 78 11.4.1 Supabase 78 11.4.2 Modelo lógico de datos 80 12. Implementación 81 12.1 Prototipo 81 12.2 Tecnologías usadas 82 12.2.1 React y JSX 82 12.2.2 Vite 83 12.2.3 Supabase 83 12.2.4 Tailwind 84 12.2.5 Flowbite 84 12.2.6 Netlify 85 12.3 Estructura del proyecto 85 12.4 Implementación de las funcionalidades 87 13. Identificación de leyes y regulaciones 92 14. Resultados de la gestión del proyecto 93 14.1 Resultados a nivel de planificación 93 14.2 Informe de sostenibilidad 96 14.4.1 Sostenibilidad ambiental 96 5 14.4.2 Sostenibilidad económica 97 14.4.3 Sostenibilidad social 97 15. Conclusiones 98 15.1 Conclusiones del proyecto 98 15.2 Reflexiones personales 98 15.3 Integración de conocimientos 99 15.4 Trabajo futuro 100 16. Referencias 101 Anexo 1. Casos de uso 104 Anexo 2. Entidades 119 6 Índice de figuras: Figura 1. Ramas en el flujo de Git 16 Figura 2. Diagrama de Gantt 25 Figura 3. Fórmula de amortización 30 Figura 4. Tablas para el control de desviaciones 33 Figura 5. Diagrama de casos de uso para la gestión de la autenticación del usuario 35 Figura 6. Diagrama de casos de uso para la gestión de la autenticación del usuario 36 Figura 7. Diagrama de casos de uso para poder inscribir los ciclos deseados 36 Figura 8. Diagrama de casos de uso para gestionar los profesores y los alumnos 37 Figura 9. Diagrama de casos de uso para gestionar los ciclos formativos y los proyectos 37 Figura 10. Diagrama de casos de uso para el rol de profesor 38 Figura 11. Diagrama de casos de uso para el rol de profesor administrador 39 Figura 12. Diagrama de casos de uso para el rol de alumno 39 Figura 13. Modelo conceptual de datos 52 Figura 14. Patrón MVC 56 Figura 15. Hook Pattern 57 Figura 16. Mapa navegacional Institución 58 Figura 17. Mapa navegacional Profesor Administrador 59 Figura 18. Mapa navegacional Profesor 60 Figura 19. Mapa navegacional Alumno 61 Figura 20. Definición de la tabla Proyecto en Supabase 79 Figura 21. Definición de la tabla Proyecto en Supabase con SQL 79 Figura 22. Modelo lógico de datos 80 Figura 23. React y JSX 83 Figura 24. Logo de Vite 83 Figura 25. Logo de Supabase 84 Figura 26. Clases utilitarias de Tailwind CSS 84 Figura 27. Creación de un proyecto con Vite 85 Figura 28. Estructura de un proyecto base 85 Figura 29. Estructura del proyecto 86 Figura 30. Importaciones de un componente 87 Figura 31. Inicialización de un componente 88 Figura 32. Función handleChange 88 Figura 33. Función randomProjectKey 89 Figura 34. Función insertProject 89 Figura 35. Función handleSubmit 89 Figura 36. Función checkErrors 90 Figura 37. Retorno JSX del componente 92 Figura 38. Matriz de sostenibilidad 96 7 Índice de tablas: Tabla 1. Estimación de horas, dependencias y recursos de las tareas 24 Tabla 2. Coste por hora de los roles del grupo 27 Tabla 3. CPA del contexto de grupo 29 Tabla 4. Costes materiales contexto real 30 Tabla 5. Contingencias 31 Tabla 6. Costes de imprevistos 31 Tabla 7. Presupuesto final de ambos contextos 32 Tabla 8. Desviaciones del proyecto 94 8 1. Introducción El proyecto “Herramienta web para la evaluación de proyectos de la metodología ABP” se trata de un Trabajo de Final de Grado de la modalidad A (Centro), perteneciente a los estudios de Grado en Ingeniería Informática de la Facultad de Informática de Barcelona, Universidad Politécnica de Cataluña, dentro de la especialidad de Ingeniería del Software. Este proyecto está dirigido por Alejandro Ríos Jerez, del departamento de ciencias de la computación. 1.1 Contextualización La metodología ABP, o Aprendizaje Basado en Proyectos[1], es una metodología de enseñanza enfocada en proyectos prácticos. Con este enfoque, los estudiantes trabajan en proyectos que simulan situaciones o problemas reales que deberán ser resueltos mediante sus habilidades y conocimientos. Esta metodología se basa en la premisa de que los estudiantes aprenden mejor cuando están involucrados activamente en el proceso de aprendizaje y cuando se enfrentan a problemas que tienen una aplicación práctica en la vida real. Además, el ABP fomenta el aprendizaje colaborativo y el desarrollo de habilidades sociales y emocionales, como la resolución de problemas, la toma de decisiones, la creatividad y la comunicación efectiva. Se ha demostrado que el ABP es una herramienta eficaz para mejorar el rendimiento académico, fomentar el interés del estudiante en lo que se enseña y desarrollar habilidades de alto valor para el mundo laboral. Por este motivo, en la última década, las corrientes educativas basadas en el aprendizaje activo han ido ganando popularidad en diversos ámbitos educativos, principalmente en educación primaria, secundaria y ciclos formativos. 1.2 Descripción del problema La evaluación de proyectos dentro del ABP puede ser un proceso complejo y tedioso si no contamos con herramientas específicas que nos sirvan para desempeñar este cometido. Actualmente, muchos de los centros educativos que han optado por esta metodología han adaptado herramientas tradicionales, como hojas de cálculo compartidas, para conseguir evaluar estos proyectos, las cuales no se adaptan a la complejidad ni la confidencialidad que requiere la metodología y limitan el potencial y la calidad de la evaluación. Por otro lado, no contar con herramientas especializadas merma el seguimiento y la retroalimentación de los estudiantes a lo largo del proyecto. Es aquí donde nace la necesidad de crear una herramienta web que permita la evaluación de proyectos basados en la metodología ABP de manera efectiva y eficiente que, por un lado, permitirá a docentes realizar una evaluación más precisa y cómoda y a estudiantes tener una plataforma donde tener una continua retroalimentación de manera personalizada y confidencial, que mejore su proceso de aprendizaje y su motivación por este. 9 4. Metodología y rigor La metodología de trabajo escogida para la realización de este proyecto es la metodología Agile[4]. Con este enfoque conseguimos, en primer lugar, una gran flexibilidad y adaptabilidad a los posibles cambios o desviaciones durante el proceso de desarrollo. Esto se consigue gracias a que esta metodología está enfocada en ciclos cortos de trabajo, también llamados Sprints, que nos permiten estar constantemente revisando el producto y reideándolo si se ve necesario. En segundo lugar, esta metodología también nos permite detectar en etapas tempranas de desarrollo las posibles problemáticas que puedan surgir, y que a su vez estas generen un menor impacto para el proceso. Dentro de Agile encontramos diferentes opciones. Entre las más conocidas podemos encontrar a la metodología SCRUM[5] y la Kanban[6]. Por lo que respecta a la metodología SCRUM, encaja mucho mejor en equipos de trabajo grandes y en proyectos que requieran una planificación detallada y una estructura más definida, dividiendo las responsabilidades entre los distintos roles del equipo. Por otro lado, Kanban es una metodología de trabajo más flexible con un mejor desempeño en equipos pequeños y menos estructurados. Debido a que el equipo de desarrollo va a estar compuesto íntegramente por mí, se ha optado por la metodología Kanban para la realización de este proyecto. 4.1 Trello Para aplicar la metodología Kanban se usará la herramienta Trello[7], la cual nos permitirá llevar un control de las historias de usuario y poder saber en todo momento, en qué estado se encuentran. El tablero de Trello contará de tres columnas, To-Do, Doing y Done, por donde las historias de usuario irán moviéndose en función del estado en el que se encuentren. Además de esto, cada una de las historias contará con etiquetas que clasifiquen a qué ámbito del desarrollo pertenecen. 4.2 Git Para el control de versiones, se usará el sistema de control de versiones por excelencia, Git[8]. Git nos permite tener un historial completo, seguro y accesible de los cambios que se han ido realizando en el código durante toda la etapa de su desarrollo. Git cumple este cometido a través de lo que se conocen como repositorios, donde podemos encontrar una serie de ramificaciones que separan el desarrollo por funcionalidades. Para poder gestionar en línea estos repositorios, existen servicios como GitHub, GitLab o BitBucket. En el caso de este proyecto, el flujo de trabajo que se va a seguir consistirá en dos ramas principales. La primera de las ramas, será la rama main, donde podremos encontrar el código ya libre de bugs y testeado. En cuanto a la segunda de las ramas, tendremos la rama de dev, donde se irán añadiendo todas aquellas funcionalidades que vayan siendo finalizadas. Sin embargo, antes de pasar a la rama de dev, las funcionalidades nacerán en unas ramas independientes generadas a partir de dev, donde poder realizar el desarrollo de cada una de ellas sin que se solape código entre ellas. 16 Figura 1. Ramas en el flujo de Git 5. Descripción de las tareas Un aspecto sumamente importante para poder realizar este proyecto es tener una planificación temporal que nos permita cumplir todos los objetivos propuestos, ajustándonos al periodo estipulado por la universidad. La carga de trabajo corresponde a 18 créditos ECTS[9], 15 de estos corresponden al propio proyecto y los tres restantes corresponden al curso GEP (Gestión de Proyectos de Ingeniería[10]). Teniendo esto en cuenta, en el caso de la Facultad de Informática de Barcelona, 1 crédito ECTS del trabajo de fin de grado, corresponde a 30 horas de trabajo, por lo tanto, se concluye en que la carga en horas de este proyecto equivaldría a 540 h. Este proyecto fue iniciado de manera oficial el día 20 de febrero de 2023, con el inicio de GEP, y su fecha de finalización está prevista para el día 26 de junio de 2023, con la presentación del proyecto delante del tribunal. Mencionar que esta fecha de finalización no se trata de la fecha exacta y su función es más bien orientativa. Entre estas dos fechas hay un total de 18 semanas, por lo tanto, teniendo en cuenta que se trabajará de lunes a viernes en este proyecto, la dedicación diaria que se debe invertir son 6 horas. En el marco de este proyecto, se han identificado tres fases. En la primera fase, la de gestión del proyecto, se dividirá en etapas como, la contextualización y definición de su alcance, la planificación, la gestión económica y sostenibilidad y por último, la integración de todas estas tareas en un documento final. A continuación, la segunda fase, la de desarrollo, estará compuesta por una etapa de Inception, seguida de 4 Sprints de 3 semanas, ya que como se ha mencionado en el apartado de metodología, el enfoque que seguirá este proyecto estará basado en Kanban. Por último, la tercera fase, la de refinamiento y documentación, donde se dará forma al documento final que acompañará al desarrollo del proyecto y se acabarán de ultimar los últimos detalles del proyecto y se preparará la presentación. 17 5.1 Descripción de las tareas A continuación, se hará una descripción detallada de las tareas, clasificadas por etapas y por fases. Además, se indicará una estimación de las horas necesarias para su realización y las dependencias de las tareas que las tengan. 5.1.1 Gestión del proyecto -GP1 - Contexto y Alcance: Redacción del primer entregable de GEP, donde se presentará la contextualización, la justificación, el alcance y la metodología del proyecto. Duración: 25 horas. Dependencias: - -GP2 - Planificación: Redacción del segundo entregable de GEP, donde se presentará la planificación temporal a seguir. Se describirán las tareas, su duración y sus dependencias. Se formalizarán los recursos humanos y materiales necesarios para su desarrollo. También, se presentarán estas tareas en un diagrama de Gantt[11] y finalmente se elaborará una gestión de riesgos, donde se verán los posibles obstáculos y planes de acción para abordarlos. Duración: 25 horas Dependencias: GP1 -GP3 - Presupuesto y Sostenibilidad: Redacción del tercer entregable de GEP, donde se identificarán y se estimaran los costes del proyecto. También se describirán maneras de controlar las desviaciones de presupuesto que puedan aparecer y se realizará un informe de sostenibilidad. Duración: 20 horas Dependencias: GP2 -GP4 - Integración documento final GEP: Se preparará la versión final y definitiva del documento que recoge las tres entregas de GEP, con las correspondientes correcciones aportadas por el tutor de la asignatura y que servirá como base para el documento final del proyecto. Duración: 20 horas Dependencias: GP3 5.1.2 Desarrollo Pasamos a describir, las tareas de la etapa de desarrollo. Cabe mencionar que el desarrollo de las siguientes tareas, engloban tanto el desarrollo del back-end[12] como el desarrollo del front-end[13]. 18 5.1.2.1 Inception -I1 - Definición de historias de usuario: Se definirán las historias de usuario[14] dentro de Trello, que compondrán el cómputo global de lo que podrá realizar cada actor en el sistema. Duración: 5 Dependencias: GP3 -I2 - Diseño de las bases de datos: Se realizará un diseño de la arquitectura de datos de la herramienta, para tener claro cómo se relacionarán las diferentes tablas entre sí para poder tener una arquitectura sólida y eficiente. Duración: 10 Dependencias: I1 -I3 - Diseño de las interfaces de usuario: Se realizarán los wireframes[15] y los mock-ups[16] de las pantallas de la herramienta que servirán de mapa a la hora de realizar el desarrollo front-end de la app. Duración: 20 Dependencias: I1 -I4 - Configuración del entorno de desarrollo: Se preparará debidamente el IDE[17] escogido para poder realizar todo el desarrollo de la aplicación. Duración: 5 Dependencias: GP1 5.1.2.2 Sprint 1 -DVLP1 - Autenticación: Desarrollo de las funcionalidades de autenticación del usuario, registro, inicio de sesión y recordar contraseña. Duración: 20 Dependencias: I4 -DVLP2 - Creación de módulos y unidades formativas: Desarrollo de las funcionalidades que permitirán a las instituciones educativas de la herramienta crear módulos y dentro de estos crear unidades formativas. Duración: 20 Dependencias: DVLP1 -DVLP3 - Asociación de profesores con institución educativa: Desarrollo de la funcionalidad que permitirá a los perfiles de profesores de la herramienta asociarse con una institución educativa mediante un código autogenerado. Duración: 15 Dependencias: DVLP2 19 -SR1 - Retrospectiva Sprint 1: Se evaluará si se han cumplido los objetivos propuestos en el sprint y analizar los puntos fuertes y débiles del proceso y ver cómo se puede mejorar en el futuro. Duración: 5 Dependencias: DVLP3 -D1 - Documentación Sprint 1: Se redactará toda aquella documentación correspondiente al trabajo realizado en este primer Sprint. Duración: 10 Dependencias: SR1 5.1.2.3 Sprint 2 -DVL4 - Creación de proyectos: Se implementará la posibilidad de que los profesores administradores puedan crear proyectos con el set de Unidades Formativas de su institución educativa y poder asignarle pesos a dichas UF’s. Duración: 40 Dependencias: D1 -DVL4 - Creación de proyectos: Se implementará la posibilidad de que los profesores administradores puedan crear proyectos con el set de Unidades Formativas de su institución educativa y poder asignarle pesos a dichas UF’s. Duración: 40 Dependencias: D1 -DVLP5 - Asociación de profesores corrientes al proyecto: Se dará la posibilidad de que los profesores administradores puedan agregar al proyecto los profesores que van a evaluarlo y a su vez la asociación de esos profesores con las UF’s de las que se van a encargar. Duración: 30 Dependencias: DVLP4 -SR2 - Retrospectiva Sprint 2: Se evaluará si se han cumplido los objetivos propuestos en el sprint y analizar los puntos fuertes y débiles del proceso y ver cómo se puede mejorar en el futuro. Duración: 5 Dependencias: DVLP5 -D2 - Documentación Sprint 2: Se redactará toda aquella documentación correspondiente al trabajo realizado en el segundo Sprint. Duración: 15 Dependencias: SR2 20 5.1.2.4 Sprint 3 -DVLP6 - Creación de criterios de evaluación: Se implementará la posibilidad de que los profesores que estén evaluando en un proyecto puedan definir criterios de evaluación y asignarles pesos. Duración: 20 Dependencias: D2 -DVL7-Asignación de alumnos a un proyecto: Los usuarios con un perfil de alumno podrán unirse a un proyecto mediante un código autogenerado que dará pie a que puedan ser evaluados. Duración: 15 Dependencias: DVLP6 -DVLP8 - Matriz de evaluación: Se implementará la interfaz visual en forma de matriz que permitirá a los profesores evaluar a los alumnos según los criterios de evaluación definidos. Siendo las filas los criterios de evaluación y las columnas cada alumno. Duración: 45 Dependencias: DVLP7 -SR3 - Retrospectiva Sprint 3: Se evaluará si se han cumplido los objetivos propuestos en el sprint y analizar los puntos fuertes y débiles del proceso y ver cómo se puede mejorar en el futuro. Duración: 5 Dependencias: DVLP8 -D3 - Documentación Sprint 3: Se redactará toda aquella documentación correspondiente al trabajo realizado en el tercer Sprint. Duración: 15 Dependencias: SR3 5.1.2.5 Sprint 4 -DVLP9 - Ver proyectos asignados: Se implementará la interfaz visual que permitirá a los usuarios con perfil de alumno, ver los proyectos en los que está asignado. Duración: 20 Dependencias: D3 -DVLP10 - Ver tus calificaciones: Se implementará la interfaz para los alumnos donde puedan ver sus calificaciones clasificadas por las unidades formativas del proyecto. Duración: 25 Dependencias: DVLP9 21 -SR4 - Retrospectiva Sprint 4: Se evaluará si se han cumplido los objetivos propuestos en el sprint y analizar los puntos fuertes y débiles del proceso y ver cómo se puede mejorar en el futuro. Duración: 5 Dependencias: DVLP10 -D4 - Documentación Sprint 4: Se redactará toda aquella documentación correspondiente al trabajo realizado en el cuarto Sprint. Duración: 10 Dependencias: SR4 5.1.3 Documentación -DVLP11 - Refinamiento: Acabar de pulir la aplicación, sobre todo en cuestiones de diseño responsivo y hacer las modificaciones correspondientes en función de las opiniones recibidas de la herramienta. Duración: 40 Dependencias: D4 -D5 - Documentación final: Se redactará la versión final de la documentación del proyecto, así como la mejora y el refinamiento de la documentación escrita de los sprints previos a esta tarea. Duración: 20 Dependencias: DVLP11 -C1 - Presentación ante el tribunal: Se preparará la presentación que se debe presentar ante el tribunal de defensa, además de todos los recursos que se requieran para este cometido. Duración: 30 Dependencias: D5 5.2 Recursos En este apartado se verán los recursos necesarios para poder llevar a cabo este proyecto de manera satisfactoria. En concreto, los recursos humanos y los recursos materiales. 5.2.1 Recursos humanos En primer lugar, el autor de este proyecto, yo, se compromete a dedicar 6 horas diarias de lunes a viernes para poder sacar adelante este proyecto. Por otro lado, se contará con la guía del director de este proyecto, Alejandro Ríos, además de profesores pertenecientes al Institut Pedralbes que darán su apoyo y opinión de esta herramienta. 22 5.2.2 Recursos materiales Los recursos materiales que se van a necesitar para la realización del proyecto serán, en primer lugar, la residencia del autor del proyecto, donde se contará de una zona de trabajo con un ordenador, dos monitores y otros periféricos como teclado y ratón inalámbricos, además de una conexión por cable a la red. Por otro lado, se cuenta con una webcam que permitirá reunirse con el director de este proyecto e ir comentando el progreso de este. 5.3 Estimaciones En la tabla 3 se muestra de manera sintetizada todo lo comentado en este apartado 5. Para cada una de las tareas se indica su correspondiente código, su nombre, su duración, sus dependencias y los recursos específicos necesarios. Código Tarea Duración (horas) Dependen cias Recursos Gestión de proyecto Total: 120 GP1 Contexto y Alcance 30 - Google Docs GP2 Planificación 30 GP1 Google Docs, Gantt Project GP3 Presupuesto y Sostenibilidad 30 GP2 Google Docs GP4 Integración documento final GEP 30 GP3 Google Docs Desarrollo Total: 360 Inception Total: 42 I1 Definición de historias de usuario 6 GP3 Trello I2 Diseño de las bases de datos 12 I1 MySQLWorkbench I3 Diseño de las interfaces de usuario 18 I1 Drive, Figma I4 Configuración del entorno de desarrollo 6 GP1 Visual Studio Sprint 1 Total: 72 DVLP1 Autenticación 24 I4 Visual Studio, Git DVLP2 Creación de módulos y unidades formativas 18 DVLP1 Visual Studio, Git DVLP3 Asociación de profesores con institución educativa 12 DVLP2 Visual Studio, Git SR1 Retrospectiva Sprint 1 6 DVLP3 Trello D1 Documentación Sprint 1 12 SR1 Google Docs Sprint 2 Total: 84 DVLP4 Creación de proyectos 42 D1 Visual Studio, Git DVLP5 Asociación de profesores corrientes 24 DVLP4 Visual Studio, Git 23 al proyecto SR2 Retrospectiva Sprint 2 6 DVLP5 Trello D2 Documentación Sprint 2 12 SR2 Google Docs Sprint 3 Total: 102 DVLP6 Creación de criterios de evaluación 24 D2 Visual Studio, Git DVLP7 Asociación de alumnos a un proyecto 12 DVLP6 Visual Studio, Git DVLP8 Matriz de evaluación 42 DVLP7 Visual Studio, Git SR3 Retrospectiva Sprint 3 6 DVLP8 Trello D3 Documentación Sprint 3 18 SR3 Google Docs Sprint 4 Total: 60 DVLP9 Ver proyectos asignados 24 D3 Visual Studio, Git DVLP10 Ver tus calificaciones 18 DVLP9 Visual Studio, Git SR4 Retrospectiva Sprint 4 6 DVLP10 Trello D4 Documentación Sprint 4 12 SR4 Google Docs Refinamiento y Documentación Total: 60 DVLP11 Refinamiento 24 D4 Visual Studio, Git D5 Documentación final 18 DVLP11 Google Docs C1 Presentación ante el tribunal 18 D5 Google Presentations TOTAL: 540 Tabla 1. Estimación de horas, dependencias y recursos de las tareas. Fuente: Elaboración propia. 24 6. Diagrama de Gantt A continuación se muestra, el diagrama de Gantt, una herramienta gráfica que tiene por objetivo exponer los periodos de tiempo y las duraciones de cada una de las tareas a realizar. Mencionar que el color de las tareas simplemente pretende ver mejor las etapas. 1 1 Figura 2. Diagrama de Gantt 25 8.1.5 Presupuesto final Concluyendo con los costes, en la siguiente tabla se presenta el presupuesto que requerirá este proyecto en los dos contextos, el real y el de grupo. Contexto CPA Costes Generales Contingencias Imprevistos TOTAL Real 5400 1874,72 1091,21 900 9265,93 Grupo 12425,84 12934,04 3803,98 695,09 29858,95 Tabla 7. Presupuesto final de ambos contextos. Fuente: Elaboración propia. 8.2 Control de gestión Una vez definidos los costes que implicará la creación de este proyecto, es fundamental contar con un control de gestión que nos permita monitorizar y gestionar los gastos generados. Se trata de una herramienta esencial para garantizar la eficiencia y eficacia en la gestión de los recursos, así como para detectar posibles desviaciones y tomar medidas correctivas. Los siguientes mecanismos nos permitirán alcanzar estos objetivos y corregir el rumbo económico del proyecto durante su transcurso, en concreto se actualizarán estos indicadores a mitad del proyecto a modo de seguimiento y al finalizarlo para ver cuáles han sido los resultados finales de estos. ● Desviación coste de horas por tarea: (Horas estimadas - Horas reales) * Coste real ● Desviación de los costes en recursos humanos por tarea: (Coste estimado - Coste real) * Horas reales ● Desviación total costes personales por actividad: CPA estimado - CPA real ● Desviación total costes generales: Coste general estimado - coste general real ● Desviación total costes imprevistos: Coste imprevisto estimado - coste imprevisto real ● Desviación total horas: Horas totales estimadas - Horas totales reales ● Desviación total costes: Coste total estimado - Coste total real 32 A continuación, se muestra la hoja de cálculo que se ha pensado para poder recoger los datos de estas desviaciones. Figura 4. Tablas para el control de desviaciones Fuente: Elaboración propia. 9. Sostenibilidad Después de haber realizado el cuestionario del proyecto de investigación de EDINSOST2-ODS, se ha extraído una conclusión. Queda claro que el ámbito de la sostenibilidad es un pilar fundamental para poder desarrollar un proyecto que tenga un impacto positivo en la sociedad en la que vivimos. Puede que muchas veces no se le otorgue toda la importancia que se merece, pero resulta fundamental contar con un informe de sostenibilidad, en este caso, se ha enfocado dicho informe en tres ámbitos distintos, sostenibilidad ambiental, económica y social, sobre los que se ha respondido a diversas preguntas. 9.1 Sostenibilidad ambiental ¿Se ha estimado el impacto ambiental que tendrá la realización del proyecto? - Sí, aunque al tratarse de una herramienta software, el impacto ambiental de esta no se prevé que sea significativo, ya que no se pretende hacer uso de papel ni otros recursos que puedan perjudicar el medio ambiente más que electricidad. ¿Se ha planteado minimizar el impacto, por ejemplo, reutilizando recursos? - Efectivamente, se prevé el uso de recursos existentes como servidores en la nube o prácticas de programación, lo más eficiente posibles que reduzcan el consumo energético de los utensilios utilizados para desarrollar este proyecto. ¿Cómo se resuelve actualmente el problema que se quiere abordar (estado del arte)? - Actualmente, aunque sí que existen herramientas informáticas que se utilizan en el ámbito educativo, no hay ninguna que satisfaga correctamente el proceso de evaluación de proyectos de la metodología ABP. Esta herramienta se diferencia al 33 ofrecer un enfoque específico para esta metodología, permitiendo a los profesores diseñar proyectos de evaluación que se ajusten a las necesidades específicas de los estudiantes, y a estos últimos, una plataforma donde poder ver de manera eficiente y protegida sus calificaciones. ¿En qué mejorará ambientalmente la solución a las existentes? - En este caso, esta herramienta propuesta permitirá reducir el uso de papel y otros recursos materiales en el ámbito educativo al recoger la gestión de la evaluación de proyectos ABP, en una única página. 9.2 Sostenibilidad económica ¿Se ha estimado el coste de la realización del proyecto (recursos humanos y materiales)? - Efectivamente, se ha elaborado un análisis de todos los gastos que pueden brotar en este proyecto, pasando por los humanos, los materiales, y los debidos a posibles contratiempos y riesgos. ¿En qué mejorará económicamente la solución a las existentes? - La solución propuesta mejorará económicamente la gestión de proyectos educativos al reducir la necesidad de recursos físicos y de tiempo. Esto permitirá a las instituciones educativas optimizar el uso de sus recursos y ahorrar costes asociados a la gestión de proyectos. 9.3 Sostenibilidad social ¿Qué crees que va a aportar a nivel personal la realización de este proyecto? - Personalmente, este proyecto, me aportará disciplina y autocontrol sobre un proyecto que recae íntegramente en mí. Además, podrá enriquecer mis conocimientos en ámbitos del desarrollo de software en los que estoy altamente interesado en profesionalizar mis habilidades. ¿Existe una necesidad real del proyecto? - Sí, existe una necesidad real del proyecto. Actualmente, la gestión de proyectos educativos basados en el aprendizaje activo puede ser una tarea compleja y engorrosa, además sumando al creciente uso de estas metodologías y la falta de herramientas específicas, hace la necesidad de este proyecto imperiosa. 34 10. Especificación Llegados a este punto, ya teniendo claro cuál será la visión, el alcance y cuáles serán los objetivos de este proyecto, en este apartado se especificarán de manera más detallada los requisitos mencionados en el apartado 3.2. Concretamente, en este apartado se definirán casos de uso[25] y el modelo conceptual de datos. Por último, mencionar, pese a que el desarrollo de este proyecto se ha realizado en sprints, la documentación se ha presentado de manera secuencial para mejorar la legibilidad y la comprensión. 10.1 Diagramas de casos de uso En primer lugar, se presentan los casos de uso. Los casos de uso son una herramienta para capturar los requisitos funcionales de un sistema desde la perspectiva de los usuarios finales, donde se describe la interacción entre los usuarios (o actores) y la herramienta, además de las acciones o procesos específicos que se llevan a cabo para lograr un objetivo. A continuación, se muestran los casos de uso del sistema representados mediante diagramas de casos de uso, donde se puede observar que usuarios o actores pueden realizar que acciones. En este sistema se ha hecho una diferenciación entre 4 roles que pueden realizar diferentes acciones, Institución, Profesor, Profesor Administrador y Alumno. Por último cabe mencionar dos aspectos a tener en cuenta, el primero de ellos es la existencia de un quinto actor, Usuario, el cual representa las acciones que pueden ser realizadas por los 4 roles anteriores, y en segundo lugar, el hecho de que todas las acciones realizadas por un profesor pueden ser realizadas por un profesor administrador. Figura 5. Diagrama de casos de uso para la gestión de la autenticación del usuario 35 Figura 6. Diagrama de casos de uso para la gestión de la autenticación del usuario Figura 7. Diagrama de casos para poder inscribir los ciclos deseados 36 Figura 8. Diagrama de casos de uso para gestionar los profesores y los alumnos Figura 9: Diagrama de casos de uso para gestionar los ciclos formativos y los proyectos 37 Figura 10. Diagrama de casos de uso para el rol de profesor 38 Figura 11. Diagrama de casos de uso para el rol de profesor administrador Figura 12. Diagrama de casos de uso para el rol de alumno 39 10.2 Descripción de los casos de uso Como se ha explicado en el apartado anterior, se han presentado las posibles interacciones que pueden realizar los diversos roles con el sistema para conseguir un objetivo concreto en forma de diagrama. En este apartado, se verán estos casos de uso explicados al detalle. Para cada uno de estos casos se describirán las siguientes cláusulas: - Nombre del caso de uso: Un identificador del caso de uso seguido de su nombre - Actor(es) Principal(es): Actor(es) que consigue(n) un objetivo a través del caso de uso. - Precondiciones: Condiciones que deben ser cumplidas para que el actor pueda realizar el caso de uso. - Disparador: Condición que inicia el caso de uso. - Escenario principal: Secuencia de eventos principal que suceden en el caso de uso. - Extensiones: Secuencia de eventos que suceden en caso de desviación en alguno de los eventos del escenario principal. Debido al gran volumen de casos de uso, se ha decidido mostrar únicamente los principales, el resto de ellos se pueden encontrar en el apartado de Anexo 1. Casos de uso. Casos de uso principales Usuario Caso de uso #1 Log In Actor(es) principal(es) Usuario Precondiciones El usuario está registrado en el sistema y se encuentra en la Landing Page Disparador El usuario selecciona la opción “Iniciar sesión” Escenario principal de uso 1. El sistema muestra el formulario de inicio de sesión. 2. El usuario introduce su correo electrónico y su contraseña. 3. El usuario clica sobre el botón “Iniciar Sesión”. 4. El sistema verifica que los datos son válidos. 5. El sistema muestra un mensaje de éxito y a continuación muestra la pantalla de inicio del usuario en función de su rol: Institución, Profesor, Profesor Admin o Alumno. Extensiones 4a. El usuario ha dejado algún campo vacío. 4a1. El sistema indica al usuario que ha de completar todos los campos. 4a2. El usuario regresa al paso 2. 4b. El usuario ha introducido datos que no corresponden a credenciales válidos. 4b1. El sistema indica al usuario que los credenciales introducidos no son válidos. 4b2. El usuario regresa al paso 2. 40 Caso de uso #3 Register Actor(es) principal(es) Institución, Alumno Precondiciones La Institución o el Alumno no están registrados en el sistema y se encuentran en la Landing Page Disparador La Institución o el Alumno seleccionan la opción de “Regístrate” Escenario principal de uso 1. El sistema muestra el formulario de registro. 2. El usuario introduce sus datos personales solicitados por el formulario. 3. El usuario clica sobre el botón “Registrarme” 4. El sistema verifica que los datos son válidos. 5. El sistema crea una cuenta para el usuario, muestra un mensaje de éxito y a continuación muestra la pantalla de inicio del usuario en función de su rol: Institución o Alumno. Extensiones 4a. El usuario ha dejado algún campo vacío. 4a1. El sistema indica al usuario que ha de completar todos los campos. 4a2. El usuario regresa al paso 2. 4b. El usuario ha introducido datos no válidos o no únicos. 4b1. El sistema indica al usuario sobre qué campos debe hacer correcciones para poder realizar correctamente el registro. 4b2. El usuario regresa al paso 2. Casos de uso principales Institución Caso de uso #6 Ver Ciclos Formativos ofrecidos Actor(es) principal(es) Institución Precondiciones La Institución ha iniciado sesión, se encuentra en la pestaña “Inscribir Ciclos Formativos” y existe un catálogo de ciclos formativos a los que inscribirse Disparador La Institución desea ver el listado de ciclos formativos disponibles para impartir en su centro Escenario principal de uso 1. El sistema muestra a la institución el listado de ciclos disponibles con cierta información (nombre, descripción y número de horas). Extensiones 1a. Si no hay ciclos formativos disponibles, el sistema muestra un mensaje de información indicando que no hay ciclos a los que inscribirse en ese momento. 41 Caso de uso #37 Evaluar proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea evaluar el proyecto para todos sus alumnos, concretamente las unidades formativas que le corresponde evaluar a él. Escenario principal de uso 1. El profesor pulsa sobre el botón “Evaluar proyecto”. 2. El sistema muestra la matriz de evaluación del proyecto, donde las filas son todos los criterios de todos los profesores ordenados por módulos, unidades formativas y resultados de aprendizaje, mientras que las columnas son todos aquellos alumnos que han inscrito ese proyecto. 3. El sistema muestra con una opacidad menor las filas de los criterios que no pertenecen al profesor, indicando que él no puede poner notas a esos criterios, en cambio, muestra las filas de sus criterios con una opacidad total indicando que son esas filas las que puede añadir notas. 4. El profesor introduce las notas que considere para cada uno de sus alumnos en cada uno de sus criterios a medida que vaya teniendo notas que introducir. 5. El sistema registra la nota de ese criterio para ese alumno. 6. El sistema calcula la nota actual del alumno en el proyecto y la muestra como la última fila de la matriz. Extensiones 2a. No hay criterios creados o no hay alumnos que hayan inscrito el proyecto. 2a1. El sistema muestra un mensaje indicando que aún no hay alumnos inscritos o aún no se ha creado ningún criterio de evaluación. 48 Caso de uso #38 Evaluar alumno Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea evaluar un alumno en concreto. Escenario principal de uso 1. El profesor pulsa sobre la pestaña “Alumnos” 2. El sistema muestra el listado de alumnos que han inscrito el proyecto, introduciendo su clave. 3. El profesor pulsa sobre el alumno del listado que quiere evaluar. 4. El sistema muestra una tabla de evaluación donde se presentan como filas los criterios de evaluación creados hasta la fecha por el profesor, clasificados por módulos, unidades formativas y resultados de aprendizaje y como columnas el nombre del criterio, el peso del criterio, la descripción y la nota que tenga actualmente el alumno en ese criterio. 5. El profesor introduce, en la columna de la nota, las notas para cada uno de los criterios que desee evaluar. Extensiones 49 Casos de uso principales Alumno Caso de uso #39 Inscribirse a un proyecto Actor(es) principal(es) Alumno Precondiciones El alumno ha iniciado sesión y se encuentra en la pantalla de inicio Disparador El alumno desea inscribirse a un proyecto y posee la key de dicho proyecto proporcionada por su profesor. Escenario principal de uso 1. El sistema muestra un formulario con un único campo donde el alumno debe introducir la key del proyecto que le ha proporcionado su profesor. 2. El alumno introduce la key solicitada por el formulario. 3. El sistema verifica que si se trata de una key válida de un proyecto activo en ese momento. 4. El sistema muestra al alumno en su pantalla de inicio un apartado con tarjetas que muestra los proyectos en los que actualmente está inscrito con una nueva tarjeta con el proyecto en el que acaba de inscribirse. Extensiones 3a. El alumno ha dejado algún campo vacío. 3a1. El sistema indica al alumno que ha de completar todos los campos. 3a2. El alumno regresa al paso 2. 3b. El alumno ha introducido una key que no corresponde a ningún proyecto. 3b1. El sistema indica al alumno que dicha key no es válida. 3b2. El alumno regresa al paso 2. 3c. El alumno ha introducido una key de un proyecto que actualmente ya está cerrado. 3c1. El sistema indica al alumno que la key introducida pertenece a un proyecto que actualmente está cerrado. 3c2. El alumno regresa al paso 2. 3d. El alumno ha introducido una key de un proyecto al cual ya pertenece. 3d1. El sistema indica al alumno que la key introducida pertenece a un proyecto al cual ya está inscrito. 3d2. El alumno regresa al paso 2. 50 Caso de uso #41 Ver mis notas Actor(es) principal(es) Alumno Precondiciones El alumno ha iniciado sesión en su cuenta, está inscrito en un proyecto, hay criterios de evaluación disponibles para ese proyecto Disparador El alumno desea ver sus notas en los criterios de evaluación para el proyecto en el que está inscrito Escenario principal de uso 1. El alumno desde su pantalla de inicio selecciona alguno de los proyectos que tiene inscritos del listado de proyectos inscritos. 2. El sistema muestra el listado de los criterios de evaluación clasificados por UFs, con otra información relevante, entre las que está el peso de cada criterio y el peso de cada UF dentro del proyecto, además de la nota de cada uno de los criterios que ya hayan sido evaluados por los profesores responsables. Extensiones 10.3 Modelo conceptual de datos A continuación se definirá el modelo conceptual de datos. Esto nos ayudará a representar gráficamente las entidades que participan en el sistema, aclarar que representa cada una de estas y como se relacionan entre ellas con una mayor precisión. Además, se trata de un recurso sumamente útil para detectar clases en nuestro sistema, sus atributos y sus restricciones de integridad, tanto gráficas como textuales. 10.3.1 Esquema conceptual de datos El esquema conceptual de datos se trata de una herramienta que permite ver las relaciones entre entidades de nuestro sistema. Por otro lado, cabe mencionar la existencia del modelo lógico de datos, el cual es el diagrama que se toma de referencia para poder construir la infraestructura de datos lógica del sistema. Este diagrama se puede encontrar en el apartado 11.6.2. En la siguiente figura, se presenta el modelo conceptual de datos de este sistema: 51 Figura 13. Modelo conceptual de datos 52 10.3.2 Restricciones de integridad ●RT1: Todas las Unidades Formativas que tenga asignadas un Profesor deben pertenecer a Ciclos Formativos inscritos por la Institución a la que pertenece dicho Profesor. ●RT2: Una Unidad Formativa solo puede ser asignada a un Profesor por Institución. ●RT3: Todas las Unidades Formativas que pertenezcan a un Proyecto deben permanecer a uno de los Ciclos Formativos inscritos por la Institución dueña de ese Proyecto y pertenecer al mismo curso. ●RT4: Un profesor solo puede evaluar Resultados de aprendizaje que pertenezcan a Unidades Formativas que tenga asignadas para evaluar. ●RT5: Todos aquellos Resultados de Aprendizaje que se relacionen con un Proyecto, antes las Unidades Formativas a las que pertenecen dichos resultados deben estar siendo evaluadas en ese Proyecto. ●RT6: Los Estudiantes que reciban notas sobre un Criterio de Evaluación deben pertenecer a la misma Institución que pertenece el Proyecto de dicho criterio y estar inscritos en ese Proyecto. ●RT7: La fecha de inicio de un Proyecto debe ser posterior o igual a la fecha de creación del Proyecto. ●RT8: La fecha de finalización de un Proyecto debe ser posterior a la fecha de inicio del Proyecto. ●RT9: La suma de las horas totales de todas las Unidades Formativas de un Módulo debe ser igual a sus horas totales. ●RT10: La suma de las horas totales de todos los Módulos de un Ciclo Formativo debe ser igual a sus horas totales. ●RT11: La suma de los pesos de todos los Criterios de Evaluación de un Resultado de Aprendizaje en un Proyecto debe sumar un valor entre 0 y 100 ●RT12: La suma de los pesos de todos los Resultados de Aprendizaje de una Unidad Formativa de un Proyecto debe sumar un valor entre 0 y 100. ●RT13:La suma de los pesos de todas las Unidades Formativas de un Proyecto debe sumar un valor entre 0 y 100. 53 10.3.3 Descripción de las clases Institución: Representa los diferentes centros educativos que pueden crear su propia instancia de la aplicación. ● nombre: Nombre de la institución. ● direccion: Dirección donde su ubica la institución. ● telefono: Número de teléfono de la institución. ● email: Dirección de correo electrónico de la institución. User: Representa todos los usuarios del sistema. ● nombre: Nombre del usuario. ● apellido: Apellido del usuario. ● email: Dirección de correo electrónico del usuario. ● password: Contraseña del usuario ● role: El rol que va a asumir el usuario dentro de la institución, alumno, profesor o profesor administrador Alumno: Representa todos los alumnos del sistema. Profesor: Representa todos los profesores del sistema. CicloFormativo: Representa los ciclos formativos que ofrece la aplicación para poder ser inscritos por las instituciones. Es decir, un catálogo de ciclos formativos que recoge los ciclos formativos que pueden cursarse en España. ● nombre: Nombre del ciclo formativo. ● descripcion: Descripción del ciclo formativo. ● horasTotales: Horas totales que requiere el ciclo formativo para ser completado. Modulo: Representa todos los módulos de todos los ciclos del sistema. ● nombre: Nombre del módulo. ● descripcion: Descripción del módulo. ● horasTotales: Horas totales que requiere el módulo para ser completado. UnidadFormativa: Representa todas las unidades formativas de todos los módulos del sistema. ● nombre: Nombre de la unidad formativa. ● descripcion: Descripción de la unidad formativa. ● horasTotales: Horas totales que requiere la unidad formativa para ser completado. ● curso: Representa el curso dentro del ciclo formativo en el que debe ser impartida la unidad formativa. 54 ResultadoDeAprendizaje: Representa todos los resultados de aprendizaje de todas las unidades formativas del sistema. ● nombre: Nombre del resultado de aprendizaje. ● descripcion: Descripción del resultado de aprendizaje. ● orden: Representa la orden de impartición del resultado de aprendizaje en el ciclo formativo. Proyecto: Representa todos los proyectos de todas las instituciones del sistema. ● nombre: Nombre del proyecto. ● descripcion: Descripción del proyecto. ● estado: Representa el estado actual del proyecto, ya sea abierto o cerrado. Solo se podrá gestionar un proyecto si este está abierto. ● fechaInicio: Representa la fecha de inicio del proyecto. ● fechaFin: Representa la fecha de finalización del proyecto. PesoUFProyecto: Representa el peso de evaluación (0-100) que tiene una unidad formativa sobre el proyecto en la que está siendo evaluada. ● peso: Peso de la unidad formativa en el proyecto. PesoRAProyecto: Representa el peso de evaluación(0-100) que tiene un resultado de aprendizaje sobre la unidad formativa a la que pertenecen. ● peso: Peso del resultado de aprendizaje sobre la unidad formativa en el contexto del proyecto. CriterioDeEvaluacion: Representa todos los criterios de evaluación de todos los proyectos del sistema. ● nombre: Nombre del criterio de evaluación. ● descripcion: Descripción del criterio de evaluación. ● peso: Representa el peso del criterio de evaluación dentro del contexto de evaluación del resultado de aprendizaje sobre el que está puesto. ● (metodoEvaluacion: Representa el método por el cual se va a evaluar el criterio, boolenano, numerico, tipo rubrica) NotaAlumno: Representa todas las notas de todos los alumnos en todos criterios de evaluación de todos los proyectos del sistema. ● nota: Representa la nota de un alumno para un criterio de evaluación de un proyecto. ● comentario: Representa el posible comentario que puede dejar el profesor que evalúa el criterio para el alumno. 55 11. Diseño Una vez especificado el proyecto, teniendo más claras sus fronteras, pasamos a su diseño, una fase totalmente crucial donde los requisitos funcionales capturados previamente se transforman en una solución técnica. En este apartado, se establece la arquitectura y la estructura del sistema, además de las tecnologías y patrones de diseño que se usarán, así como el diseño de front-end y el back-end. 11.1 Patrón MVC El primer patrón de diseño que utilizaremos en nuestro sistema se trata del patrón MVC[26]. Consiste en un patrón arquitectónico ampliamente utilizado en el ámbito del desarrollo web que proporciona una forma organizada y modular de diseñar y desarrollar software, separando las responsabilidades en tres componentes principales: el Modelo, la Vista y el Controlador. El modelo representa los datos y la lógica de negocio de la aplicación. Es el componente responsable de acceder, manipular y almacenar los datos mediante cierta lógica. La vista es la capa de presentación de la aplicación, responsable de mostrar la interfaz gráfica al usuario final, donde se presentan los datos del modelo de la manera más intuitiva y comprensible posible. Por último, el controlador actúa como un intermediario entre el modelo y la vista. Es el responsable de gestionar las interacciones del usuario con la capa de presentación y actualizar o recoger datos del modelo en consecuencia de esas interacciones La separación de responsabilidades en diferentes componentes nos ofrece diversos beneficios. En primer lugar, permite una mayor reutilización del código, ya que los componentes pueden modificarse o reemplazarse de manera independiente sin influir en los otros dos componentes. En segundo lugar, mejora la mantenibilidad del código, porque cada componente es responsable de una serie de tareas específicas. Por último, es un patrón de diseño que facilita el trabajo en equipo debido a que se puede trabajar de manera paralela en diversos componentes. Figura 14. Patrón MVC 56 11.2 Patrones de diseño En este apartado se comentan los patrones de diseño que se van a aplicar a la hora de desarrollar este sistema. 11.2.1 Hook pattern Dentro del contexto de React[27], existen los llamados “Hooks” o también Hook pattern[28], que consiste en una técnica que permite almacenar y reutilizar lógica de estado de componentes funcionales. Se basa en la idea principal de dividir la lógica relacionada con el estado de un componente y encapsularla en una pequeña unidad llamada Hook. Una de las principales ventajas de hacer uso de este patrón es la capacidad de reutilización de código que nos ofrecen sin la necesidad de hacer uso de clases o herencia. Esta reutilización del código reporta en mayor eficiencia, mayor modularidad y mayor legibilidad del código, facilitando el desarrollo de aquellas aplicaciones que lo apliquen. Figura 15. Hook Pattern 11.2.2 Provider pattern El Provider pattern[29] se trata de un patrón de diseño altamente utilizado en React que se utiliza para manejar el paso de datos a través del árbol de componentes de React de una manera más sencilla y eficiente. Con este patrón podemos conseguir el paso de datos entre múltiples componentes sin la necesidad de pasar props[30] a través de cada nivel del árbol. En este patrón, se define un componente de React llamado Provider, el cual envuelve a todos aquellos componentes a los que queramos tener la posibilidad de pasarles datos. Este componente tiene la capacidad de almacenar y proporcionar un valor específico que puede ser accedido por los componentes hijos que lo requieran. Es particularmente útil en situaciones en las que diferentes componentes necesitan acceder al mismo conjunto de datos, por ejemplo, la información del usuario autenticado en la aplicación, en lugar de ir pasando esa información a través de un sinfín de componentes, se hace uso de este patrón para acceder directamente a través de uno de los hooks de React, useContext[31], que permite acceder al contexto definido por el componente proveedor. 57 Casos de uso: #1, #5 Institución: Página “Inscribir Ciclos Formativos”: En esta página se le presenta a la Institución el catálogo de Ciclos Formativos que puede inscribir en su centro. Casos de Uso: #6 Página de detalles de un Ciclo Formativo: 64 En esta página la Institución puede consultar la información de un ciclo y valorar si quiere inscribirlo para que los profesores administradores puedan crear proyectos con él. Casos de uso: #7, #8, #9, #10, #11 Página “Mis Ciclos Formativos”: En esta página la Institución puede consultar los Ciclos Formativos que tiene inscritos en su centro y gestionarlos, viendo su información y eliminándolos. Casos de uso: #17, #18 Página “Profesores”: 65 En esta página la Institución puede consultar los profesores que ha creado y su información. Además, también puede gestionarlos, creando, editando o eliminando sus registros. Casos de Uso: #11, #14 Página “Editar Profesor”: En esta página la Institución puede editar la información asociada a un profesor. Casos de uso: #13 Página “Crear Profesor”: 66 En esta página la Institución puede crear un profesor y asociarle información, como su rol y las unidades formativas que evaluará. Casos de Uso: #12 Página “Alumnos” En esta página la Institución puede consultar los alumnos asociados a su centro. Además, también puede gestionarlos eliminando sus registros. Casos de uso: #15, #16 Página “Proyectos” 67 En esta página la Institución puede ver y eliminar los proyectos creados por profesores administradores de su centro. Casos de uso: #19, #20 Profesor Administrador: Página de Inicio Profesor Administrador: Esta es la página de inicio de un profesor administrador, donde puede ver los proyectos que el ha creado y los proyectos que han sido compartidos con el debido a la inclusión en esos proyectos de unidades formativas que tiene asignadas. Además, desde esta página puede crear proyectos y ver la página de detalles de cada uno de los proyectos que se muestran en pantalla. Casos de uso: #27 68 Página de Creación de Proyecto 1: Esta es la primera página de creación de un proyecto, donde el profesor administrador debe introducir cierta información básica del proyecto. Casos de uso: #21 Página de creación de proyecto 2: Esta es la segunda página de creación de un proyecto, donde el profesor administrador debe seleccionar sobre que curso de alguno de los ciclos del centro quiere hacer el proyecto. Casos de uso: #21 69 Página de creación de proyecto 3: Esta es la tercera página de creación de un proyecto, donde el profesor administrador debe seleccionar que unidades formativas se van a evaluar en el proyecto. Casos de uso: #21 Página de creación de proyecto 4: Esta es la última página de creación de un proyecto, donde el profesor administrador debe asignarle un peso a cada una de las unidades formativas y sus correspondientes resultados de aprendizaje para el proyecto que está creando. Casos de uso: #21 70 Profesor: Los siguientes diseños de pantallas son aquellos que se muestran en la página de detalles de un proyecto desde la perspectiva de un profesor administrador. Pese a este hecho, cabe recalcar que tanto la institución dueña del proyecto como los profesores que evalúan unidades formativas en el proyecto, pueden ver estas pantallas. Respecto a la Institución, esta tiene la capacidad únicamente de ver cada una de las pestañas y la matriz de evaluación del proyecto, pero no poder hacer ningún tipo de gestión sobre el proyecto, como sería por ejemplo añadir notas a un alumno o eliminar una unidad formativa. Por lo que respecta a los profesores involucrados por las unidades formativas que hay en el proyecto, lo único que difiere de los diseños que se mostrarán a continuación es, la capacidad de editar o eliminar unidades formativas y cerrar el proyecto. Página de detalles de proyecto, pestaña “Unidades Formativas”: Es esta pestaña, se muestra las unidades formativas que se han seleccionado para el proyecto con los pesos tanto de las propias unidades formativas como de sus resultados de aprendizaje asociados. En el caso de que sea un profesor administrador quien esté viendo esta página, aparece también la posibilidad de que este edite los pesos o elimine las unidades formativas que están siendo evaluados. En el caso de que el total ponderado de un resultado de aprendizaje del proyecto no sea de 100% debido a que no tiene criterios asociados o que los que tiene asociados no cubren el 100%, se muestra una alerta de precaución. Casos de uso: #26, #31, #32 71 Página “Añadir UF”: En esta página, el profesor administrador, añade una unidad formativa para que sea evaluada en el proyecto. Casos de uso: #24 Página “Editar Unidad Formativa”: En esta página, el profesor administrador, edita el peso que tiene una unidad formativa y sus resultados de aprendizaje en el proyecto. Casos de uso: #25 72 Página de detalles de proyecto, pestaña “Criterios de evaluación”: En esta pestaña, se muestran los criterios de evaluación creados por el profesor. Además, también puede crear, editar o eliminar los criterios de evaluación que considere. Casos de uso: #33, #36 Página “Editar Criterio de evaluación”: En esta página, se muestra un formulario con los datos del criterio de evaluación que se ha decidido editar. Casos de uso: #35 73 11.4.2 Modelo lógico de datos A continuación se muestra el diagrama lógico de datos del sistema, el cual se ha generado gracias al diagrama conceptual de datos visto en apartados anteriores. Figura 22. Modelo lógico de datos 80 12. Implementación Especificado ya por completo el proyecto, el presente apartado se centra en la implementación de un prototipo reducido de la aplicación web. Aunque el objetivo inicial era desarrollar una aplicación completa que abarcara todas las funcionalidades especificadas, se ha decidido tomar esta decisión fundada en varias consideraciones con el objetivo de llegar a lograr un producto que mantenga la esencia del proyecto original y que a su vez justifique la viabilidad de crear una aplicación con las tecnologías escogidas. Es importante destacar que el desarrollo de una aplicación web completa y plenamente funcional requiere de un tiempo considerable, especialmente teniendo en cuenta los requerimientos complejos y específicos de la metodología ABP y el hecho de ser una única persona en el equipo. Dado que el periodo de desarrollo para poder trabajar en el proyecto consta de 3 meses, un tiempo ajustado y limitado, se ha decidido que la alternativa más viable era la construcción de un prototipo. La construcción de un prototipo permite demostrar de manera efectiva la viabilidad del proyecto, sin la necesidad de tener una versión completa y totalmente pulida, además de ser una representación tangible de las ideas y los conceptos que hay detrás del proyecto. 12.1 Prototipo El prototipo construido cuenta con 2 roles, Profesor y Alumno. Por un lado, los usuarios que adopten el rol de profesor pueden desempeñar las siguientes funciones: Registro Aquí el usuario introduce su información personal (Nombre, Apellido, email, contraseña) y el rol que quiere desempeñar (Alumno o Profesor). Inicio de Sesión Cerrar Sesión Crear proyecto El profesor introduce la información del proyecto (nombre, descripción, fecha de inicio y finalización) donde podrá crear criterios de evaluación y proporcionando el código del proyecto a sus alumnos, estos podrán unirse a él. CRUD Criterios de evaluación Dentro de un proyecto, el profesor será capaz de crear criterios y asignarles un peso sobre los que evaluar a sus alumnos. 81 Eliminar alumnos proyecto El profesor es capaz de eliminar a aquellos alumnos que desee del proyecto. Cerrar Proyecto El profesor podrá dar por finalizado el proyecto cuando el crea conveniente. Evaluar Proyecto El profesor puede acceder a la matriz de evaluación del proyecto y puntuar a sus alumnos para los criterios de evaluación que previamente ha tenido que crear. Por otro lado, los usuarios que adopten el rol de alumno pueden desempeñar las siguientes funciones: Registro Aquí el usuario introduce su información personal (Nombre, Apellido, email, contraseña) y el rol que quiere desempeñar (Alumno o Profesor). Inicio de Sesión Cerrar Sesión Inscribir Proyecto Introduciendo el código del proyecto proporcionado por el profesor, los alumnos pueden unirse a él. Ver notas Proyecto Para cada uno de los proyectos inscritos por el alumno, este podrá acceder a su página de detalles donde podrá ver las notas que le ha puesto el profesor creador de ese proyecto para cada uno de los criterios. Para ver los detalles completos del prototipo, el repositorio del proyecto es el siguiente: https://github.com/carlosexojo00/AbpHub 12.2 Tecnologías usadas En este apartado se explica cuáles han sido las tecnologías empleadas en esta etapa del desarrollo que han permitido materializar este prototipo. 12.2.1 React y JSX React es una librería de JavaScript ampliamente utilizada en el desarrollo de interfaces de usuario interactivas y dinámicas. Su principal característica es su capacidad para crear componentes reutilizables que facilitan la construcción y el mantenimiento de aplicaciones complejas. 82 Para poder trabajar con React se hace uso de JSX[38], una extensión de sintaxis que nos permite incluir código HTML dentro de JavaScript. De esta manera, React combina la potencia y la flexibilidad de JS con la estructura y facilidad de uso de HTML. Figura 23. React y JSX 12.2.2 Vite Vite[39] es un entorno de desarrollo ultrarápido para aplicaciones web basado en Javascript y TypeScript que destaca por su velocidad de compilación y su recarga de cambios en tiempo real. Vite presenta una arquitectura basada en módulos ESM(EcmaScript Modules), lo que significa que a diferencia de otros entornos de desarrollo como Create React App, en lugar de agrupar y empaquetar los archivos del proyecto en un solo archivo antes de ejecutar la aplicación, Vite carga los módulos de forma individual bajo demanda en tiempo de ejecución, permitiendo de esta manera, una carga mucho más rápida y eficiente. Figura 24. Logo de Vite 12.2.3 Supabase Como se ha mencionado con anterioridad, Supabase se trata de un BaaS que ofrece grandes herramientas para poder generar un entorno de backend de manera muy rápida y simplificada que nos permite centrar nuestros esfuerzos en el desarrollo de la lógica de negocio y las interfaces de nuestro proyecto. 83 Figura 25. Logo de Supabase 12.2.4 Tailwind Tailwind CSS[40] es un framework de diseño de UI de bajo nivel altamente configurable que presenta un aspecto claramente diferenciador, su amplia gama de clases utilitarias predefinidas, qué combinadas, permiten construir rápidamente interfaces personalizadas. Es cierto que en un inicio, Tailwind puede presentar una curva de aprendizaje algo pronunciada debido a la gran cantidad de clases que presenta y a la dificultad de leer los archivos HTML donde van a ir colocadas dichas clases. Sin embargo, a largo plazo, resulta una apuesta segura que agiliza en gran medida el proceso de estilizado y genera código mucho más estandarizado y mantenible. Figura 26. Clases utilitarias de Tailwind CSS 12.2.5 Flowbite Flowbite[41] es una biblioteca que ofrece componentes reutilizables y responsivos estilizados con Tailwind CSS de libre uso. Hacer uso de estos componentes modernos nos permite agilizar tiempo en el estilizado de muchos de los componentes que aparecen en una aplicación web, como por ejemplo, una barra de navegación, una tarjeta, una alerta, o una tabla. 84 12.2.6 Netlify Netlify es una plataforma que proporciona servicios de alojamiento web considerada la opción más popular para desplegar proyectos de una forma rápida y sencilla. La característica principal de Netlify es su integración con plataformas como GitHub, que permite a los desarrolladores simplemente vincular el repositorio del proyecto con Netlify para que este pueda ser accedido en línea. Si el código fuente de GitHub sufre cambios, automáticamente esos cambios se ven reflejados en la página publicada por Netlify. La dirección web de la herramienta es la siguiente: https://timely-chimera-9fb1f5.netlify.app 12.3 Estructura del proyecto Empecemos hablando de la estructura que presenta el proyecto, la cual ha sido generada mediante Vite con el comando: npm create vite@latest Figura 27. Creación de un proyecto con Vite En la siguiente figura se muestra el proceso de creación mediante Vite, donde se le debe dar un nombre al proyecto, el paquete y seleccionar en que framework y variante deseas trabajar, así de simple y en tan solo 2,6 segundos. Posteriormente, después de instalar las dependencias básicas del proyecto con npm install, podemos ver la estructura básica que nos proporciona Vite: - Package.json: Este archivo es el punto de entrada para administrar las dependencias del proyecto y definir los scripts de desarrollo, construcción y ejecución. - node_modules: Aquí se almacenan todas las dependencias externas instaladas mediante npm (Node Package Manager). Figura 28. Estructura de un proyecto base 85 - public: Contiene los archivos estáticos que se sirven directamente al navegador, como el archivo HTML principal, las imágenes o los archivos de estilos globales. - Carpeta src: Esta carpeta es donde se encuentra el código fuente del proyecto. Sus subcarpetas y archivos son los siguientes: - Carpeta assets: Aquí se almacenan los archivos estáticos, como imágenes, fuentes, videos, etc. - Archivo App.jsx: Es el componente principal de la aplicación React donde se define la estructura y lógica general. Otros archivos y carpetas opcionales: Además de los elementos mencionados, también puedes encontrar otros archivos o carpetas, como los de configuración específica de Vite (por ejemplo, vite.config.js). A partir de este proyecto base, se ha modificado la carpeta src de la siguiente manera: Figura 29. Estructura del proyecto Se han añadido las siguientes carpetas: - components: En esta carpeta se ha realizado la programación de los componentes que se han utilizado en el prototipo. - contexts: En esta carpeta se ha almacenado el código del patrón proveedor anteriormente mencionado para obtener la información del usuario activo. - pages: Código que maqueta y estiliza las páginas donde son usados los componentes - supabase: En esta carpeta se encuentra el código necesario para vincular el proyecto de Supabase con el de Vite. 86 12.4 Implementación de las funcionalidades Para simplificar este apartado, veremos como se ha implementado uno de los componentes del sistema llamado “CreateProjectForm” el cual representa el formulario de creación de un proyecto. Se podrá ver el uso de los patrones de diseño mencionados anteriormente, como se gestionan los errores de dicho formulario y como este componente interactúa con Supabase. Importaciones: ● Se importa “useState” desde la biblioteca de React. El hook useState se utilizará para gestionar el estado interno del componente. ● Se importa “supabase”, un objeto que será utilizado para interactuar con una base de datos de Supabase. ● Se importa “useCurrentUser” desde el contexto "CurrentUserContext", un hook personalizado própio utilizado para acceder a la información del usuario actual en la aplicación. ● Se importa “HorizontalLinearStepper” el cual es un componente del sistema que será utilizado en este componente. ● Se importa “Alert” el cual es un componente del sistema que será utilizado en este componente. ● Se importa “useNavigate” desde la biblioteca "React-Router-Dom". Esta biblioteca nos va a permitir redirigir al usuario de la aplicación a otras páginas del sistema. Figura 30. Importaciones de un componente Inicializaciones: Nada más iniciar el componente, se han declarado sus estados iniciales mediante el hook useState. El funcionamiento de este hook consiste en definir una variable de estado y una función para alterar el valor de esa variable. Adicionalmente, aquello que se pase como parámetro del hook será el valor del estado inicial. En este caso, se ha hecho uso este hook en dos ocasiones, la primera de ellas para iniciar el valor del formulario y en segundo lugar, para gestionar los posibles errores que puedan surgir con la interacción del usuario con el formulario. En ambos casos, el valor inicial ha sido un objeto, aunque en el caso del estado interno “errors”, este se ha iniciado vacío. 87 Por otro lado, se ha hecho uso del hook propio y personalizado “useCurrentUser” el cual retorna en la variable currentUser, la información del usuario activo. Hacer uso de este hook aplica el patrón provider, mencionado anteriormente. Por último, para poder redirigir al usuario a una nueva página del sistema debemos hacer uso del hook personalizado de ReactRouterDom, useNavigate. Figura 31. Inicialización de un componente Función handleChange(e): Se utiliza como un controlador de eventos para gestionar los cambios en los campos del formulario cuando reciben una entrada. Básicamente, lo que hace esta función es extraer, utilizando la sintaxis de destructuring de JavaScript, el nombre (name) y el valor (value) del elemento que generó el evento (e.target). A continuación, utiliza el setter setProject, obtenido del hook useState, para actualizar el estado de project con el nuevo valor value ingresado en el campo de entrada correspondiente al nombre (name). Figura 32. Función handleChange 88 Función randomProjectKey(): Esta función genera y devuelve una clave aleatoria para el proyecto. Utiliza el método Math.random() para generar un número aleatorio y toString(36) para convertirlo en una cadena alfanumérica. Figura 33. Función randomProjectKey Función insertProject(): Esta función asincrónica sirve para insertar el objeto project en la tabla de Supabase que almacena los proyectos del sistema. Espera la respuesta (data) y el posible error (error) de la operación de inserción. Si hay un error, se muestra un mensaje en la consola y se detiene la ejecución, si la operación es exitosa, se utiliza la función navigate para navegar a la página de detalles del proyecto recién creado. Figura 34. Función insertProject Función handleSubmit(e): ● Esta función se utiliza como un controlador de eventos para el envío del formulario. ● Se evita que el evento predeterminado se ejecute mediante e.preventDefault() para que de esta manera no se recargue la página al enviar el formulario. Figura 35. Función handleSubmit 89 14.2 Informe de sostenibilidad El presente apartado tiene como objetivo evaluar el impacto ambiental, económico y social del proyecto una vez finalizado. En la actualidad, la sostenibilidad se ha convertido en un aspecto clave en cualquier proyecto debido a la creciente consciencia sobre los impactos negativos que nuestros actos pueden provocar en el medio ambiente, la economía y la sociedad. Para poder realizar este informe se utilizará la matriz de sostenibilidad que se nos ha otorgado durante el curso de GEP. Figura 38. Matriz de sostenibilidad 14.4.1 Sostenibilidad ambiental Consumo de diseño: Para minimizar los impactos ambientales provocados por el diseño del sistema, se ha optado por hacer uso de tecnologías eficientes y optimizadas. Evitando la duplicación innecesaria del código, y la reutilización de componentes. Además de esto, al haber hecho uso de frameworks y bibliotecas, como es React y Flowbite, se ha promovido la eficiencia energética y la optimización de recursos. Huella ecológica: Al desarrollar este proyecto desde casa con mi propio equipo, se ha reducido la necesidad de realizar desplazamientos, por lo que la emisión de gases de efecto invernadero asociados a esto, se ha reducido al mínimo. Además, se ha alimentado el equipo utilizado con energías renovables producidas por placas solares. Riesgos ambientales: Respecto a los riesgos ambientales asociados a este proyecto, estos son mínimos. Se ha evitado el uso de materiales o productos que puedan representar un peligro para el medio ambiente y para futuros proyectos, en el caso de tener que sustituir equipos, se adoptarán las medidas necesarias para hacer una buena gestión de residuos electrónicos. 96 14.4.2 Sostenibilidad económica Factura: Respecto a los costes del proyecto, se ha buscado aprovechar recursos gratuitos y de código abierto siempre que ha sido posible, minimizando los gastos asociados al desarrollo. Plan de viabilidad: Actualmente, con las tecnologías escogidas para sostener el proyecto, no hay ninguna que suponga un coste económico. Sin embargo, en el caso de llegar en un futuro a implementar la aplicación final, si se requiere por volumen de usuarios y peticiones, Supabase ofrece planes de pago que amplían estos aspectos para poder llegar a mantener una aplicación de mayores dimensiones. Por lo tanto, en un futuro hipotético debería estudiarse cuáles de estos planes es el más recomendable. Riesgo económico: En el contexto de este proyecto el riesgo económico es relativamente bajo. En el caso de un contexto de un proyecto real, el principal riesgo económico es el rechazo de la propuesta creada por parte del mercado, ya que implicaría una perdida de dinero y tiempo. 14.4.3 Sostenibilidad social Impacto personal: El desarrollo de este proyecto ha supuesto un aprendizaje significativo y un crecimiento personal. Me ha permitido conocer y profundizar en tecnologías en las que nunca había trabajado y mejorar mis habilidades técnicas. Por otro lado, me ha servido para aprender a gestionar mi tiempo y ser responsable con él para sacar adelante el proyecto. Impacto social: Respecto al impacto social que puede implicar este proyecto, considero que si en un futuro se llega a implementar esta aplicación, como se ha especificado en este proyecto, va a representar un fuerte impacto en el panorama nacional debido a que actualmente las metodologías de aprendizaje basadas en el aprendizaje activo no cuentan con ninguna aplicación sólida que esté adaptada específicamente para gestionar proyectos de este tipo de metodologías. Riesgos sociales: Considero que no existen riesgos sociales que puedan generarse a parir de este proyecto, debido a que simplemente se trata de una herramienta de trabajo dentro de el sector educativo. 97 15. Conclusiones Finalmente, para dar por concluido este proyecto vamos a presentar las conclusiones que hemos extraído del trabajo realizado, las reflexiones personales, los conocimientos adquiridos en las asignaturas del grado que hemos aplicado y el trabajo futuro que queda pendiente. 15.1 Conclusiones del proyecto Al principio del proyecto se sufrió un cambio en la hoja de ruta de este mismo que implicó optar por una especificación mucho más exhaustiva que permitió poder crear un prototipo usable que ha permitido demostrar mi capacidad de implementar un sistema de software complejo. Durante el transcurso del desarrollo del proyecto he podido poner en práctica todos los conocimientos que he adquirido durante el grado, como por ejemplo, aplicar una metodología agile, la identificación y definición de requisitos, aplicar técnicas de calidad de código como son los patrones de diseño o trabajar con bases de datos relacionales. No solo eso, sino que también he podido experimentar con stack de tecnologías que nunca antes había utilizado, alcanzando un resultado satisfactorio y pudiendo haber construido un producto tangible construido a partir de estas tecnologías. 15.2 Reflexiones personales La experiencia de hacer este trabajo de final de grado, ha sido una experiencia totalmente diferente a las asignaturas que he cursado durante estos años en el grado. He tenido la oportunidad de crear desde 0 una aplicación web haciendo uso de tecnologías y herramientas con las que nunca antes había interactuado. Pese a los obstáculos que han surgido durante todo este periodo de tiempo, ha sido una constante sensación de estar superándose a uno mismo, día tras día. Puedo decir sin temor a equivocarme que este proyecto me ha enriquecido como profesional y me ha servido en gran medida para poner fin a esta etapa de 5 años. No puedo no mencionar a mi tutor, Alejandro, quien me ha tendido la mano y me ha ayudado en todo lo que he podido necesitar y por el magnífico trato que me ha brindado durante todo el proceso, sin él, nada de esto hubiera sido posible. Echando la vista atrás en estos meses, me siento orgulloso del trabajo realizado y la dedicación y constancia que he tenido que tener para sacar este proyecto adelante. Sin duda, ha sido una experiencia desafiante, pero a su vez muy gratificante que me ha permitido adquirir conocimientos y habilidades técnicas y personales de valor para el mercado laboral del cual voy a empezar a formar parte de manera integral. 98 15.3 Integración de conocimientos A lo largo de este proyecto se han aplicado diversos conocimientos adquiridos en las asignaturas del grado. En este apartado, se nombrarán las asignaturas que han tenido un peso más significativo y que conocimientos han aportado al trabajo. PRO1 y PRO2: Proporcionaros los primeros conocimientos que aprendí en el mundo de la programación, los cuales sentaron las bases de la lógica de programación a seguir. BD: Representó el primero contacto con bases de datos relacionales SQL, que ha servido de manera indudable para entender como se almacenan y relacionan los datos de un sistema. IDI: Proporcionó los conocimientos básicos sobre como crear interfaces eficientes e intuitivas, un aspecto absolutamente clave para que un proyecto tenga éxito hoy en dia. IES: Ha proporcionado conocimientos sobre como diseñar y especificar un sistema sofware, sobre todo mencionar el diseño en UML y el primer contacto con los patrones de diseño. PROP: Representó la primera experiencia medianamente real de un proyecto donde pude aplicar conocimientos de otras asignaturas y hacer uso de patrones como el MVC. AS: Sirvió para profundizar los conocimientos adquiridos en IES, y además representó el primer contacto que tuve con el mundo de los tests. ASW: Fue la asignatura que me introdujo conocimientos sobre el desarrollo de web e introdujo por primera vez los conceptos de los frameworks, back-en y front-end. ER: Proporcionó conocimientos sobre los requisitos, una parte totalmente fundamental en lo que es el proceso de desarrollo de un proyecto, haciendo especial hincapié en la importancia en tener una especificación sólida antes de empezar con el desarrollo en sí. GPS: Aprendí sobre metodologías de trabajo y crear un proyecto desde 0 centrado en la especificación de un proyecto. PES: Permitió generar un proyecto integral colaborativo donde se hizo uso de las metodologías aprendidas en GPS, como por ejemplo, la metodología Agile. Y se pudo experimentar lo que es estar dentro de un proyecto real. 99 15.4 Trabajo futuro El desarrollo de este proyecto ha dejado la puerta abierta a futuras implementaciones que darán gran valor al producto final. - Ampliación del prototipo construido: Uno de los objetivos principales en un futuro es completar la especificación que se ha reflejado en este proyecto. Esto representaría un valor añadido muy importante para el sistema. - Nuevas funcionalidades: Debido al tiempo limitado con el que se ha contado, hay ciertas ideas que me hubiera gustado añadir que se han quedado fuera. Entre ellas, añadir un chat entre el alumno y el profesor, donde estos podrían comentar temas relacionados con los proyectos. Realizar una integración con el sistema de registro de las notas que tienen los centros educativos para que de esta manera no hiciera falta pasar las notas de mi sistema al usado por los centros. - Hacer pruebas reales de uso con usuarios: Pese a que considero que la interfaz de usuario ha quedado bastante bien, pienso que hubiera sido de gran ayuda contar con ciertos tests de usabilidad que reportaran un feedback en cuanto hacer las interfaces más intuitivas. - Patrocinio: Algo que ha quedado también pendiente ha sido hacer difusión real de este sistema, ya que considero que se trata de un producto que tiene una aplicación muy factible en los centros y el sistema educativo de hoy en día y que podría llegar a reportar un beneficio económico si se llega a comercializar. 100 16. Referencias [1] Guía, A. O. P. (s/f). Servicio de Innovación Educativa 2008. Upm.es. Recuperado el 23 de febrero de 2023, de https://innovacioneducativa.upm.es/sites/default/files/guias/AP_PROYECTOS.pdf [2] Herramientas y recursos para la administración del aula. (s/f). Google for Education. Recuperado el 24 de febrero de 2023, de https://edu.google.com/intl/es-419/workspace-for-education/classroom/ [3] Moodle - Open-source learning platform. (s/f). Moodle.org. Recuperado el 24 de febrero de 2023, de https://moodle.org/ [4] Atlassian. (s/f). What is agile? Atlassian. Recuperado el 25 de febrero de 2023, de https://www.atlassian.com/agile [5] Atlassian. (s/f). What is agile? Atlassian. Recuperado el 25 de febrero de 2023, de https://www.atlassian.com/agile [6] Fowler, F. M. (2019). What is scrum? En Navigating Hybrid Scrum Environments (pp. 3–8). Apress. Recuperado el 25 de febrero de 2023, de https://www.scrum.org/resources/what-is-scrum [7] Rehkopf, M. (s/f). Kanban vs Scrum. Atlassian. Recuperado el 25 de febrero de 2023, de https://www.atlassian.com/agile/kanban/kanban-vs-scrum [8] What is Trello: Learn Features, Uses & More. (s/f). Trello.com. Recuperado el 28 de febrero de 2023, de https://trello.com/tour [9] About. (s/f). Git-scm.com. Recuperado el 28 de febrero de 2023, de https://git-scm.com/about [10] Atlassian. (s. f.). Flujo de trabajo de Gitflow | Atlassian Git Tutorial. Recuperado el 28 de febrero de 2023, de https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow [11] Treball de Fi de Grau. (s/f). Upc.edu. Recuperado el 1 de marzo de 2023, de https://www.fib.upc.edu/ca/estudis/graus/grau-en-enginyeria-informatica/treball-de-fi-de-grau [12] GESTIÓ DE PROJECTES (GEP) Guia de l’assignatura. (s/f). Upc.edu. Recuperado el 1 de marzo de 2023, de https://www.fib.upc.edu/sites/fib/files/documents/estudis/guia-gep-raco-fib.pdf [13] Gantt.com. (s/f). Gantt.com. Recuperado el 4 de marzo de 2023, de https://www.gantt.com/ 101 [14] What does a back-end developer do? (2022, marzo 23). Coursera. Recuperado el 2 de marzo de 2023, de https://www.coursera.org/articles/back-end-developer [15] What is a front-end developer? (s/f). Frontendmasters.com. Recuperado el 2 de marzo de 2023, de https://frontendmasters.com/guides/front-end-handbook/2018/what-is-a-FD.html [16] Wireframe vs mockup vs prototype: What’s the difference? (s/f). Sketch. Recuperado el 2 de marzo de 2023, de https://www.sketch.com/blog/wireframe-vs-mockup-vs-prototype/ [17] Wireframe vs mockup vs prototype: What’s the difference? (s/f). Sketch. Recuperado el 2 de marzo de 2023, de https://www.sketch.com/blog/wireframe-vs-mockup-vs-prototype/ [18] Zayour, I., & Hajjdiab, H. (2013). How much integrated development environments (IDEs) improve productivity? Journal of software, 8(10). Recuperado el 3 de marzo de 2023, de https://doi.org/10.4304/jsw.8.10.2425-2431 [19] Esneca. (2022, noviembre 23). Ser Project Manager: funciones, formación y salidas. Esneca; Esneca Business School. Recuperado el 10 de marzo de 2023, de http://esneca.com/blog/funciones-del-project-manager/ [20] Wikipedia contributors. (2023, febrero 11). Software analyst. Wikipedia, The Free Encyclopedia. Recuperado el 10 de marzo de 2023, de https://en.wikipedia.org/w/index.php?title=Software_analyst&oldid=1138786863 [21] Ahmed, K. (2023, enero 5). Software Architect Roadmap. roadmap.sh. Recuperado el 12 de marzo de 2023, de https://roadmap.sh/software-architect [22] What does a UX designer do? (2021, diciembre 8). BrainStation®. Recuperado el 13 de marzo de 2023, de https://brainstation.io/career-guides/what-does-a-ux-designer-do [23] What is Software Testing and How Does it Work? (s/f). Ibm.com. Recuperado el 13 de marzo de 2023, de https://www.ibm.com/topics/software-testing [24] (S/f). Indeed.com. Recuperado el 13 de marzo de 2023, de https://es.indeed.com/ [25] Assistant Secretary for Public Affairs. (2013). Use cases. Recuperado el 20 de marzo, de https://www.usability.gov/how-to-and-tools/methods/use-cases.html [26] MVC - Glosario de MDN Web Docs: Definiciones de términos relacionados con la Web. (s. f.). Mozilla.org. Recuperado el 20 de marzo de 2023, de https://developer.mozilla.org/es/docs/Glossary/MVC [27] Herbert, D. (2022, junio 27). What is React.js? (Uses, Examples, & More). HubSpot. Recuperado el 22 de marzo, de https://blog.hubspot.com/website/react-js 102 [28] Hooks pattern. (s. f.). Patterns.dev. Recuperado 2 de junio de 2023, de https://www.patterns.dev/posts/hooks-pattern [29] Eagles, L. (2022, diciembre 7). A guide to React design patterns. LogRocket Blog. Recuperado el 4 de junio, de https://blog.logrocket.com/react-design-patterns/ [30] Nnamdi, C. (2022, noviembre 16). React props explained with examples. Refine.dev. Recuperado el 4 de junio, de https://refine.dev/blog/react-props/ [31] UseContext. (s. f.). React.dev. Recuperado 4 de junio de 2023, de https://react.dev/reference/react/useContext [32] Fetecua, A. (2021, mayo 28). ¿qué es Un mapa DE navegación web? ¡lo Que Debes saber! DesignPlus. Recuperado el 4 de junio, de https://designplus.co/blog/diseno-web/que-es-un-mapa-de-navegacion-web/ [33] Supabase: An agile open source alternative. (s. f.). Aplyca Tecnología SAS. Recuperado el 8 de junio de 2023, de https://www.aplyca.com/en/blog/blog-supabase-an-agile-open-source-alternative [34] PostgreSQL. (2023, junio 8). PostgreSQL. Recuperado el 8 de junio, de https://www.postgresql.org/ [35] ¿Qué es una API REST? (s/f). Ibm.com. Recuperado el 10 de junio de 2023, de https://www.ibm.com/es-es/topics/rest-apis [36] Supabase - open source BaaS, can it work? - Happy Team. (s/f). Happyteam.io. Recuperado el 12 de junio de 2023, de https://happyteam.io/blog/supabase-open-source-baas-can-it-work/ [37] JSON requests and responses. (s/f). Atlassian.com. Recuperado el 12 de junio de 2023, de https://developer.atlassian.com/server/crowd/json-requests-and-responses/ [38] Arancio, S. (2021, octubre 5). What is JSX? Medium. Recuperado el 12 de junio, de https://medium.com/@sjarancio/what-is-jsx-e3dda0af3490 [39] Vite. (s/f). Vitejs.dev. Recuperado el 13 de junio de 2023, de https://vitejs.dev/guide/why.html [40] Fitzgerald, A. (2022, mayo 30). Tailwind CSS: What it is, why use it & examples. Recuperado el 15 de junio, de HubSpot. https://blog.hubspot.com/website/what-is-tailwind-css [41] Zoltán, S. (2021, septiembre 11). FlowBite — Tailwind CSS components library - Themesberg blog - medium. Themesberg Blog. Recuperado el 16 de junio de, https://medium.com/themesberg-blog/flowbite-tailwind-css-components-library-eb19014ebb6 9 103 Anexo 1. Casos de uso Caso de uso #2 Log Out Actor(es) principal(es) Usuario Precondiciones El usuario ha iniciado sesión y está autenticado Disparador El usuario selecciona la opción de cerrar sesión desde la barra de navegación Escenario principal de uso 1. El sistema finaliza la sesión del usuario, que está activo y autenticado. 2. El sistema redirige al usuario a la Landing Page de la aplicación web. Extensiones Caso de uso #4 Register con proveedor Actor(es) principal(es) Institución, Alumno Precondiciones La Institución o el Alumno no están registrados en el sistema y se encuentran en la Landing Page Disparador La Institución o el Alumno seleccionan la opción de “Regístrate” Escenario principal de uso 1. El usuario selecciona alguna de las diversas opciones para registrarse con un proveedor (Google o Apple). 2. El sistema redirige al usuario al portal del proveedor. 3. El usuario selecciona la cuenta con la que desea registrarse. 4. El sistema registra el registro mediante proveedor y redirige al usuario a su página de inicio en función de su rol. Extensiones 104 Caso de uso #5 Log In con proveedor Actor(es) principal(es) Institución, Alumno Precondiciones La Institución o el Alumno está registrado en el sistema y se encuentra en la Landing Page Disparador La institución o el alumno selecciona la opción “Iniciar sesión” Escenario principal de uso 1. La institución o el alumno selecciona alguna de las diversas opciones para iniciar sesión con un proveedor (Google o Apple). 2. El sistema redirige al usuario al portal del proveedor. 3. La institución o el alumno selecciona la cuenta con la que desea iniciar sesión. 4. El sistema autentica a la institución o el alumno y lo redirige a su página de inicio en función de su rol. Extensiones Caso de uso #8 Ver Unidades Formativas ofrecidas Actor(es) principal(es) Institución Precondiciones La Institución se encuentra en la página de detalles de un Ciclo Formativo Disparador La Institución desea ver el listado de unidades formativas asociadas a un módulo del listado de módulos del ciclo formativo Escenario principal de uso 1. La institución pulsa sobre el icono en forma de flecha hacia abajo en uno de los elementos del listado de módulos del ciclo formativo que está consultando. 2. El sistema muestra en forma de desplegable el listado de unidades formativas asociadas a dicho módulo con información de esta(nombre, descripción, horas) Extensiones 105 Caso de uso #25 Editar Unidad Formativa de Proyecto Actor(es) principal(es) Profesor administrador Precondiciones El profesor administrador ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor administrador desea editar el peso de una de las unidades formativas de su proyecto Escenario principal de uso 1. El profesor administrador pulsa sobre la opción “Editar” junto a la unidad formativa del listado que quiere eliminar. 2. El sistema muestra el formulario de edición de la unidad formativa, donde se ve su nombre y su descripción y un campo editable con el peso actual de la unidad formativa. 3. El profesor administrador introduce el nuevo peso de la unidad formativa. 4. El sistema actualiza el peso de esa unidad formativa en el proyecto. Extensiones 4a. El nuevo peso de la uf sumado al resto de pesos de las demás supera 100. 4a1. El sistema informa el usuario que la suma de los pesos de las unidades formativas en un proyecto deben sumar 100 como máximo. 4a2. El profesor administrador regresa al paso 3. Caso de uso #26 Eliminar Unidad Formativa de Proyecto Actor(es) principal(es) Profesor administrador Precondiciones El profesor administrador ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor administrador desea eliminar una de las unidades formativas de su proyecto Escenario principal de uso 1. El profesor administrador pulsa sobre la opción “Eliminar” junto a la unidad formativa del listado que quiere eliminar. 2. El sistema muestra un mensaje de confirmación preguntando si el profesor administrador está seguro de querer eliminar esa unidad formativa del proyecto. 3. El profesor administrador confirma la eliminación de la unidad formativa. 4. El sistema elimina el registro de la unidad formativa que desea eliminar. 5. El sistema muestra un mensaje indicando que la unidad formativa ha sido eliminado correctamente del proyecto. Extensiones 3a. El profesor administrador cancela la eliminación de la unidad formativa. 3a1. El sistema cierra el modal de la confirmación de la eliminación 3a2. El sistema muestra la lista de unidades formativas del proyecto. 112 Caso de uso #27 Ver proyectos asignados Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en su página de inicio Disparador El profesor desea ver a qué proyectos está asignado Escenario principal de uso 1. El sistema muestra una sección en la página de inicio donde se muestran los diferentes proyectos a los que está asignado el profesor debido a la presencia de unidades formativas asociadas a ese profesor en los diferentes proyectos existentes en su institución, presentados en forma de tarjetas que muestran información general de este, como el nombre y la descripción del proyecto. Extensiones 1a. El profesor no está asignado a ningún proyecto. 1a1. El sistema muestra un mensaje de información al profesor indicando que aún no está asignado a ningún proyecto. En cuanto se evalúe alguna de las unidades formativas que tiene asignadas en algún proyecto, se le asignará dicho proyecto. Caso de uso #28 Ver Alumnos proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea ver los alumnos que están siendo evaluados en el proyecto Escenario principal de uso 1. El profesor accede a la pestaña “Alumnos” en la página de detalles del proyecto. 2. El sistema muestra el listado de alumnos que han introducido la clave del proyecto y, por lo tanto, se han inscrito a él. Extensiones 2a. El proyecto no tiene ningún alumno inscrito aún. 2a1. El sistema muestra un mensaje informando de que tan pronto como algún alumno introduzca la clave del proyecto, se mostrarán los alumnos. 113 Caso de uso #29 Ver Profesores proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea ver los profesores que están evaluando el proyecto Escenario principal de uso 1. El profesor accede a la pestaña “Profesores” en la página de detalles del proyecto. 2. El sistema muestra el listado de profesores que están evaluando el proyecto debido a la presencia de alguna de las unidades formativas que tienen asignadas en el proyecto. Extensiones Caso de uso #30 Ver información proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea ver los detalles del proyecto Escenario principal de uso 1. El profesor accede a la pestaña “Información proyecto” en la página de detalles del proyecto. 2. El sistema muestra la información del proyecto (nombre, descripción, fecha de inicio y fecha de finalización). Extensiones 2a. El sistema muestra la opción “Cerrar proyecto” si se trata de un profesor administrador. 114 Caso de uso #31 Ver Unidades Formativas proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea ver las unidades formativas que están siendo evaluadas en el proyecto Escenario principal de uso 1. El profesor accede a la pestaña “Unidades Formativas” en la página de detalles del proyecto. 2. El sistema muestra el listado de unidades formativas que el profesor administrador ha decidido evaluar en el proyecto. Dando la posibilidad al profesor de desplegar dichas unidades formativas para desplegar el listado de resultados de aprendizaje asociados a cada una de ellas. Extensiones Caso de uso #32 Ver Resultados de Aprendizaje proyecto Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto en la pestaña “Unidades Formativas” Disparador El profesor desea ver los resultados de aprendizaje asociados a una unidad formativa de un proyecto. Escenario principal de uso 1. El profesor pulsa sobre el símbolo de flecha hacia abajo en alguna de las unidades formativas. 2. El sistema muestra el listado de resultados de aprendizaje asociados a la unidad formativa del proyecto que ha desplegado. Extensiones 115 Caso de uso #33 Ver mis Criterios de Evaluación Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto Disparador El profesor desea ver sus criterios de evaluación dentro del proyecto Escenario principal de uso 1. El profesor accede a la pestaña “Criterios de Evaluación” en la página de detalles del proyecto. 2. El sistema muestra el listado de criterios de evaluación que el profesor ha creado hasta la fecha para los resultados de aprendizaje de las unidades formativas que tiene asociadas en el proyecto. Extensiones 2a. El profesor aún no ha creado ningún criterio de evaluación. 2a1. El sistema informa al usuario que aún no ha creado ningún criterio de evaluación para el proyecto. 116 Caso de uso #35 Editar Criterio de Evaluación Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto, concretamente en la pestaña “Criterios de evaluación” Disparador La Institución desea editar los datos de uno de sus criterios de evaluación en el proyecto Escenario principal de uso 1. El profesor pulsa sobre la opción “Editar” en alguno de los criterios del listado. 2. El sistema muestra un formulario con la información actual del criterio seleccionado. (nombre, descripción, método de evaluación, peso) 3. El profesor modifica los campos que desee y envía la información actualizada al sistema. 4. El sistema verifica que la información ingresada sea válida y actualiza el registro del criterio en la base de datos. 5. El sistema muestra un mensaje indicando que la información del criterio ha sido actualizada exitosamente. Extensiones 4a. El profesor no completa todos los campos obligatorios del formulario o ingresa información inválida 4a1. El sistema muestra un mensaje indicando que se deben llenar todos los campos o corregir la información. 4a2. El usuario regresa al paso 3. 4b. El profesor introduce un peso al criterio que hace que la suma total de todos los pesos de todos los criterios asociados al mismo resultado de aprendizaje sume un valor superior a 100. 4b1. El sistema indica que los pesos de los criterios asociados a un resultado de aprendizaje debe sumar como mucho 100 117 Caso de uso #36 Eliminar Criterio de Evaluación Actor(es) principal(es) Profesor Precondiciones El profesor ha iniciado sesión y se encuentra en la página de detalles de un proyecto, concretamente en la pestaña “Criterios de evaluación” Disparador El profesor desea eliminar uno de sus criterios de evaluación Escenario principal de uso 1. El profesor pulsa sobre la opción “Eliminar” junto al criterio de evaluación del listado que quiere eliminar. 2. El sistema muestra un mensaje de confirmación preguntando si el profesor está seguro de querer eliminar ese criterio de evaluación del proyecto. 3. El profesor confirma la eliminación del criterio de evaluación. 4. El sistema elimina el registro del criterio de evaluación que desea eliminar. 5. El sistema muestra un mensaje indicando que el criterio de evaluación ha sido eliminado correctamente del proyecto. Extensiones 3a. El profesor cancela la eliminación del criterio de evaluación. 3a1. El sistema cierra el modal de la confirmación de la eliminación 3a2. El sistema muestra la lista de criterios de evaluación del proyecto. Caso de uso #40 Ver proyectos inscritos Actor(es) principal(es) Alumno Precondiciones El alumno ha iniciado sesión y se encuentra en su página de inicio Disparador El alumno desea ver a qué proyectos está inscrito Escenario principal de uso 1. El sistema muestra una sección en la página de inicio donde se muestran los diferentes proyectos a los que está inscrito el alumno. Extensiones 1a. El alumno no está inscrito a ningún proyecto. 1a1. El sistema muestra un mensaje de información al alumno indicando que aún no está inscrito a ningún proyecto. En cuanto se inscriba a uno podrá verlo. 118 Anexo 2. Entidades 119 120 121