Millorant el Learning Dashboard: integració de gamificació i visualització avançada

id192266 MILLORANT EL LEARNING DASHBOARD: INTEGRACIÓ DE GAMIFICACIÓ I VISUALITZACIÓ AVANÇADA NICOLA SCOGNAMILLO Director/a CARLES FARRE TOST (UNIVERSITAT POLITÈCNICA DE CATALUNYA) Ponent: MARC ORIOL HILARI (Departament d'Enginyeria de Serveis i Sistemes d'Informació) Titulació Grau en Enginyeria Informàtica (Enginyeria del Software) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 23/01/2025 Abstract The Learning Dashboard (LD) is a tool used in some subjects of the Universitat Politècnica de Catalunya (UPC) related to software engineering, designed to help students to track their progress in team based projects. The Integrated Gamified Learning Dashboard Environment (GLiDE) is a new version of the LD that aims to improve user experience through a visual overhaul and the introduction of gamification elements. In its current version the GLiDE is only a proof of concept, this project pretends to integrate the components that make up the GLiDE and develop new functionalities that allow it to be put into production. This project has been done following a version of the scrum methodology adapted to the academic environment (a backlog has been defined and been taken care of in a series of sprints, all while holding weekly meetings with the product owner). Resum El Learning Dashboard (LD) és una eina utilitzada a algunes assignatures de la Universitat Politècnica de Catalunya (UPC) relacionades a l’enginyeria del software dissenyada per a ajudar els alumnes a fer un seguiment del seu progrés en projectes grupals. L’Integrated Gamified Learning Dashboard Environment (GLiDE) és una nova versió del LD que busca millorar l’experiència de l’usuari i animar el seu ús mitjançant una nova interfície gràfica i la introducció d’elements de gamificació. En la seva versió actual el GLiDE és una prova de concepte, aquest projecte té com a objectiu integrar els components que formen el GLiDE i desenvolupar noves funcionalitats que permetin posar-lo en producció. Aquest projecte s’ha portat a terme seguint la metodologia scrum adaptada a l’entorn acadèmic (s’ha definit un backlog que s’ha executat en una sèrie de sprints mentre es mantenien reunions setmanals amb el product owner). Resumen El Learning Dashboard (LD) es una herramienta usada en algunas asignaturas de la Universitat Politècnica de Catalunya (UPC) relacionadas con la ingeniería del software diseñada para ayudar a los alumnos a hacer un seguimiento de su progreso en proyectos grupales. El Integrated Gamified Learning Dashboard Environment (GLiDE) es una nueva versión del LD que busca mejorar la experiencia del usuario y animar su uso mediante una nueva interfaz gráfica y la introducción de elementos de gamificación. En su versión actual el GLiDE es una prueba de concepto, este proyecto tiene como objetivo integrar los componentes que forman el GLiDE y desarrollar nuevas funcionalidades que permitan ponerlo en producción. Este proyecto se ha realizado siguiendo la metodología scrum adaptada al entorno académico (se ha definido un backlog que se ha ejecutado en una serie de sprints mientras se mantenían reuniones semanales con el product owner). 2 Índex de continguts 1. Introducció i contextualització............................................................................................8 1.1. Context........................................................................................................................................8 1.2. Definicions..................................................................................................................................9 1.3. Identificació del problema..........................................................................................................9 1.4. Actors implicats........................................................................................................................10 2. Justificació...........................................................................................................................11 3. Abast....................................................................................................................................14 3.1. Objectius del projecte...............................................................................................................14 3.2. Possibles obstacles i riscos.......................................................................................................14 4. Metodologia i rigor.............................................................................................................16 4.1. Metodologia de treball..............................................................................................................16 4.2. Metodologia de desenvolupament............................................................................................16 4.3. Execució de la metodologia......................................................................................................17 5. Planificació..........................................................................................................................19 5.1. Descripció de les tasques..........................................................................................................19 5.2. Recursos....................................................................................................................................21 5.2.1. Recursos humans.............................................................................................................21 5.2.2. Recursos materials.......................................................................................................... 22 5.3. Estimacions...............................................................................................................................22 5.4. Diagrama de Gantt....................................................................................................................24 5.5. Gestió de risc: Plans alternatius i obstacles..............................................................................25 5.5.1. Ús de noves tecnologies..................................................................................................25 5.5.2. Partir d’un projecte existent............................................................................................25 5.5.3. Bugs................................................................................................................................ 26 5.6. Execució de la planificació.......................................................................................................26 6. Pressupost............................................................................................................................29 6.1. Identificació dels costos............................................................................................................29 6.1.1. Recursos humans.............................................................................................................29 6.1.2. Hardware.........................................................................................................................31 6.1.3. Software..........................................................................................................................31 6.1.4. Costos addicionals...........................................................................................................31 6.2. Estimació dels costos................................................................................................................32 6.3. Control de gestió.......................................................................................................................33 6.4. Execució del pressupost............................................................................................................34 7. Estat inicial del GLiDE......................................................................................................37 7.1. Arquitectura..............................................................................................................................37 7.2. Conceptes principals.................................................................................................................38 7.2.1. Gamification Engine.......................................................................................................38 7.2.2. Advanced Interaction......................................................................................................39 7.3. Interfície d’usuari (Advanced Interaction)...............................................................................40 8. Especificació de requisits...................................................................................................42 8.1. Requisits funcionals..................................................................................................................42 3 8.2. Requisits no funcionals.............................................................................................................44 9. Tecnologies utilitzades........................................................................................................47 10. Nova arquitectura del sistema.........................................................................................50 11. Integració i resolució de bugs del GLiDE.......................................................................51 11.1. Identificació i resolució de problemes....................................................................................51 11.1.1. Problemes resolts.......................................................................................................... 51 11.1.2. Problemes pendents.......................................................................................................55 11.2. Validació.................................................................................................................................57 12. Desenvolupament d’una solució per l'autenticació individual d’estudiants...............59 12.1. Anàlisi d’alternatives..............................................................................................................59 12.2. Desenvolupament................................................................................................................... 59 12.3. Validació.................................................................................................................................65 13. Desenvolupament d’una eina d’administració.............................................................. 66 13.1. Anàlisi d’alternatives..............................................................................................................66 13.2. Desenvolupament................................................................................................................... 66 13.3. Integració d’IA generativa......................................................................................................74 13.4. Validació.................................................................................................................................76 14. Contenerització i desplegament...................................................................................... 79 15. Informe de Sostenibilitat................................................................................................. 85 15.1. Autoavaluació.........................................................................................................................85 15.2. Dimensió econòmica.............................................................................................................. 86 15.3. Dimensió ambiental................................................................................................................87 15.4. Dimensió social...................................................................................................................... 88 16. Lleis i regulacions.............................................................................................................90 16.1. Protecció de dades..................................................................................................................90 16.1.1. Principis de protecció de dades.....................................................................................90 16.1.2. Drets de les persones.....................................................................................................90 16.1.3. Responsable i encarregat del tractament.......................................................................91 16.2. Propietat intel·lectual..............................................................................................................91 16.3. Llicència de software..............................................................................................................92 17. Integració de coneixements............................................................................................. 93 18. Conclusions i treball futur...............................................................................................94 18.1. Objectius i aprenentatge......................................................................................................... 94 18.2. Assoliment de les competències tècniques.............................................................................94 18.3. Treball futur............................................................................................................................96 19. Referències........................................................................................................................97 Annex.....................................................................................................................................100 Annex A. Documentació de les API..............................................................................................100 Annex A1. Advanced Interaction Backend.............................................................................100 Annex A2. Gamification Engine.............................................................................................103 Annex B. Models conceptuals de la primera versió del GLiDE....................................................116 Annex C. Repositoris de GitHub...................................................................................................119 Annex D. Manual per desplegar el GLiDE................................................................................... 120 4 Índex de taules [Taula 1] Comparativa de les funcionalitats del GLiDE amb les alternatives......................... 12 [Taula 2] Anàlisi DAFO...........................................................................................................13 [Taula 3] Estimació d’hores, recursos i dependències entre tasques........................................23 [Taula 4] Probabilitat i impacte per cada risc...........................................................................25 [Taula 5] Sous pels rols del projecte........................................................................................ 29 [Taula 6] Hores i cost de personal per cada tasca del projecte.................................................30 [Taula 7] Cost del hardware..................................................................................................... 31 [Taula 8] Cost de l’espai de treball...........................................................................................31 [Taula 9] Valor de la partida per contingències........................................................................32 [Taula 10] Costos per imprevistos...........................................................................................32 [Taula 11] Cost total del projecte............................................................................................. 33 [Taula 12] Pressupost pel sprint 4 després dels canvis de planificació....................................34 [Taula 13] Taula de control de gestió final...............................................................................36 [Taula 14] Cost total del projecte final.....................................................................................36 [Taula 15] Especificació GET evaluable actions................................................................... 100 [Taula 16] Especificació POST import data...........................................................................101 [Taula 17] Especificació GET leaderboards...........................................................................101 [Taula 18] Especificació PATCH selected dates.................................................................... 102 [Taula 19] Especificació POST login.....................................................................................103 [Taula 20] Especificació GET student players.......................................................................103 [Taula 21] Especificació POST game.................................................................................... 104 [Taula 22] Especificació PUT game.......................................................................................105 [Taula 23] Especificació POST game group..........................................................................106 [Taula 24] Especificació POST import data...........................................................................106 [Taula 25] Especificació DELETE leaderboard.....................................................................107 [Taula 26] Especificació PUT leaderboard............................................................................ 108 [Taula 27] Especificació POST OpenAI API.........................................................................109 [Taula 28] Especificació DELETE simple rule......................................................................109 [Taula 29] Especificació PUT simple rule..............................................................................111 [Taula 30] Especificació DELETE date rule..........................................................................112 [Taula 31] Especificació PUT date rule..................................................................................113 [Taula 32] Especificació GET subjects.................................................................................. 114 [Taula 33] Especificació POST subject..................................................................................115 5 Índex de figures [Figura 1] Interfície del GLiDE................................................................................................. 8 [Figura 2] Exemple d’història d’usuari i tasques en un sprint a Taiga.....................................16 [Figura 3] Exemple d’estructura de branques seguint Gitflow................................................ 17 [Figura 4] Diagrama de Gantt.................................................................................................. 24 [Figura 5] Diagrama de Gantt final..........................................................................................28 [Figura 6] Taula de càlcul pel control de gestió.......................................................................34 [Figura 7] Arquitectura del GLiDE..........................................................................................37 [Figura 8] Pantalla de monitoratge...........................................................................................40 [Figura 9] Pantalla de gamificació........................................................................................... 41 [Figura 10] Nova arquitectura del GLiDE............................................................................... 50 [Figura 11] Injecció de mocks al fitxer de proves....................................................................57 [Figura 12] Exemple de prova per cas d’èxit........................................................................... 58 [Figura 13] Exemple de prova per cas de fallada.....................................................................58 [Figura 14] Pantalla d’inici de sessió.......................................................................................60 [Figura 15] Finestra per inserir credencials de Google............................................................60 [Figura 16] Pantalla de selecció de perfil.................................................................................61 [Figura 17] Credencials a Google Cloud Platform Console.................................................... 61 [Figura 18] Codi per afegir el botó de login de Google...........................................................62 [Figura 19] Seqüencia per enviar un id_token a un servidor................................................... 63 [Figura 20] Seqüència per POST login.................................................................................... 64 [Figura 21] Seqüència per GET studentPlayers....................................................................... 64 [Figura 22] Nova base de dades de l’Advanced Interaction Backend..................................... 65 [Figura 23] Creació de partida, tria d’assignatura....................................................................67 [Figura 24] Creació de partida, creació d’assignatura..............................................................67 [Figura 25] Creació de partida, definició d’atributs.................................................................68 [Figura 26] Creació de partida, importació de regles...............................................................69 [Figura 27] Creació de partida, política de nivells...................................................................69 [Figura 28] Creació de partida, importació d’alumnes i equips...............................................70 [Figura 29] Creació d’achievements........................................................................................ 71 [Figura 30] Creació de regles...................................................................................................71 [Figura 31] Creació de leaderboards........................................................................................ 71 [Figura 32] Edició de regles.....................................................................................................72 [Figura 33] Edició de leaderboards.......................................................................................... 72 [Figura 34] Seqüència per POST subject.................................................................................73 [Figura 35] Seqüència per POST subject a l’Admin Tool........................................................73 [Figura 36] Cos de la sol·licitud a l’API d’OpenAI.................................................................75 [Figura 37] Seqüència per POST openAiApi...........................................................................76 [Figura 38] Exemple de configuració i inicialització de l’entorn de proves............................76 [Figura 39] Primer exemple de test a Angular......................................................................... 77 6 [Figura 40] Segon exemple de test a Angular..........................................................................78 [Figura 41] Dockerfile per l’Admin Tool.................................................................................79 [Figura 42] Continguts del fitxer nginx.conf........................................................................... 80 [Figura 43] Dockerfile pels backends del GLiDE....................................................................81 [Figura 44] Components del GLiDE al docker compose.........................................................82 [Figura 45] Beses de dades, xarxes i volum al compose..........................................................83 [Figura 46] Diagrama de desplegament del GLiDE.................................................................84 [Figura 47] Model conceptual de la gestió general................................................................ 116 [Figura 48] Model conceptual de la preparació de gamificació.............................................117 [Figura 49] Model Conceptual de l’Advanced Interaction.....................................................118 [Figura 50] Contenidors funcionant a Docker Desktop......................................................... 121 7 1. Introducció i contextualització Aquest document s’ha realitzat com a part d’un Treball de Fi de Grau (TFG) per l’especialitat d’Enginyeria del Software del Grau en Enginyeria Informàtica cursat a la Facultat d’Informàtica de Barcelona (FIB) de la Universitat Politècnica de Catalunya (UPC). 1.1. Context L’Integrated Gamified Learning Dashboard Environment (GLiDE) [1], una captura del qual es pot veure a la figura 1, es tracta d’una eina ideada per a ser utilitzada en el desenvolupament de software en equip dins d’un entorn educatiu, aquesta permet que estudiants i professors rebin retroacció contínua, precisa i objectiva del procés d’aprenentatge individual i en equip sobre la qual poder basar la presa de decisions i l’avaluació de les actuacions durant el transcurs dels projectes [2], tot mentre utilitza la gamificació per a millorar l’experiència de l’usuari. [Figura 1] Interfície del GLiDE. Font: [3] El GLiDE va sorgir de la necessitat de millorar el Learning Dashboard (LD) [2], una eina basada en el Q-Rapids Dashboard [4] que integra dades d’eines de desenvolupament de 8 software com Taiga i GitHub i que ha estat utilitzada a les assignatures Aplicacions i Serveis Web (ASW) i Projecte d’Enginyeria del Software (PES) de la Facultat d’Informàtica de Barcelona (FIB) i a l’assignatura Ampliació a l’Enginyeria del Programari (AMEP) de l’Escola Politècnica Superior d'Enginyeria de Vilanova i la Geltrú (EPSEVG), per intentar resoldre les dificultats que van expressar els estudiants per afegir el LD al seu flux de treball [1]. Per fer-ho, el GLiDE integraria elements de gamificació a les funcionalitats del LD. El projecte del GLiDE es va marcar com a objectius millorar la implicació i motivació dels estudiants, millorar les dinàmiques i rendiment dels equips, ajudar a produir projectes de major qualitat i explorar estratègies innovadores de gamificació [1]. 1.2. Definicions ● Dashboard: Interfície gràfica que permet visualitzar dades de manera fàcil mitjançant gràfics o altres elements visuals. ● GitHub: Eina que permet mantenir repositoris de codi en línia i fer control de versions. ● Gamificació: Ús d’elements del disseny de jocs en contextos no de joc [5] com ara leaderboards i achievements. ● Integrated Gamified Learning Dashboard: Versió del Learning Dashboard que integra elements de gamificació i ofereix una experiència d’usuari millorada. ● Learning Dashboard: Evolució del Q-Rapids Dashboard que col·lecciona i integra les dades del Taiga i GitHub dels projectes desenvolupats pels alumnes i en calcula mètriques. ● Q-Rapids Dashboard: Eina per avaluar i monitorar la producció de software en entorns àgils. ● Taiga: Eina de gestió de projectes dirigida a desenvolupadors en entorns àgils. 1.3. Identificació del problema El problema amb el GLiDE rau en el fet que en el seu estat actual és només una prova de concepte. Això significa que en el present, el GLiDE encara està lluny d’estar preparat per a ser utilitzat en un entorn educatiu real. Per ser més específic, el GLiDE consta de dues parts separades, la part d’interacció [6] i la de gamificació [7], que encara fa falta integrar i testejar. Això implica comprovar que els components software que formen aquestes parts (l’Advanced Interaction Frontend, 9 4. Metodologia i rigor 4.1. Metodologia de treball Per aquest projecte se seguirà la metodologia scrum, es tracta d’una metodologia àgil iterativa i incremental per gestionar el desenvolupament on es defineix un backlog d’històries d’usuari, aquest s’executarà en una sèrie de sprints que duren un període determinat de temps [8]. El projecte avança a mesura que es buida el backlog. Ara bé, aquesta metodologia s’ha d’adaptar per fer-la funcionar en un entorn acadèmic, ja que cal generar artefactes requerits per la normativa i per GEP i perquè per aquest projecte només hi ha un únic desenvolupador. Per fer el seguiment s’utilitzarà Taiga, aquesta eina ens permet definir-hi les històries d’usuari, èpiques i sprints. Les històries es poden assignar a les èpiques i dividir en tasques per les quals es pot seguir el progrés, un exemple del que podem trobar per un sprint es pot veure a la figura 2. Addicionalment, per al seguiment del projecte, se celebraran reunions setmanals amb l’equip de treball del GLiDE on es controlarà el progrés de la feina feta i es resoldran les qüestions que hagin sorgit durant la setmana. [Figura 2] Exemple d’història d’usuari i tasques en un sprint a Taiga. Font: Elaboració pròpia. 4.2. Metodologia de desenvolupament Durant el desenvolupament s’utilitzarà Git pel control de versions. Aquest ens permet fer un seguiment de tots els canvis efectuats sobre el codi base, cosa que permet tornar enrere a versions anteriors, proporcionant-nos així protecció contra danys irreversibles [9]. També és ideal pel treball cooperatiu, ja que ajuda a resoldre canvis incompatibles realitzats per diferents persones, però això no és rellevant aquí perquè aquest és un projecte individual. Es treballarà amb GitHub, que és on es troba tot el codi del GLiDE repartit entre els següents repositoris: GLiDE-frontend, GLiDE-backend i GLiDE-gamification-engine. 16 La metodologia per treballar en aquests repositoris serà Gitflow [10], aquí s’hi mantenen sempre dues branques: main (on hi ha l’última versió estable preparada per ser llançada) i development (on es desenvolupen les noves funcions i es corregeixen errors). Per cada nova funció es crea una nova branca a partir de development i quan s’enllesteix es fa merge. Si es vol preparar una versió de llançament, es crea una branca a partir de development amb el número de la versió al nom, després es fa merge d’aquesta branca a main. En el cas que sorgeixi cap error a main, es crea una branca de hotfix on s’arreglen els problemes, aquests canvis en ser acabats s’incorporen a main. A la figura 3 podem veure un exemple de com queden les branques quan se segueix Gitflow. Aquesta metodologia ens ajuda a mantenir el codi net i organitzat, facilita el seguiment dels canvis al projecte i permet fer releases de manera senzilla [11]. A sobre, l’autor d’aquest treball ja està familiaritzat amb aquesta metodologia, això significa que es podrà treballar amb ella de manera eficient. [Figura 3] Exemple d’estructura de branques seguint Gitflow. Font: [10] 4.3. Execució de la metodologia Durant l’execució del projecte s’ha estat seguint la metodologia que s’acaba de descriure. Gràcies al seguiment que s’està fent amb Taiga es pot veure clarament l’estat del projecte, això permet controlar fàcilment quina és la feina feta i què falta per fer. Gitflow ha permès mantenir un repositori organitzat que facilita el desenvolupament. A més, les reunions setmanals han estat útils per aclarir dubtes i per garantir que el software que s’està desenvolupant compleix amb la visió i les necessitats del projecte GLiDE. 17 Per aquestes raons, s’ha considerat que la metodologia és exitosa i no convé fer cap canvi significatiu. Només s’ha decidit explicitar la definition of done per les funcionalitats desenvolupades, s’ha determinat que una funcionalitat es pot considerar completada quan aquesta s’ha desenvolupat, passa els tests que demostren el seu correcte funcionament i s’ha fet merge de la seva branca a la branca development. 18 5. Planificació Aquest projecte prendrà lloc entre el 9 de setembre de 2024 i el 6 de gener de 2025, això suposa un total de 120 dies, dels quals 79 són laborables. Pel projecte, com es justificarà a continuació, s’ha estimat una durada de 545 hores. Considerant aquests dos factors, s’ha decidit dedicar 6 hores en dies laborables i aproximadament 2 hores en dies no-laborables per elaborar el projecte. 5.1. Descripció de les tasques Gestió del projecte ● GP1 - Contextualització i abast (25 hores) ○ Es redactarà un document on es defineix el context del projecte, la justificació per la solució triada, l’abast que tractarà i la metodologia que se seguirà. ● GP2 - Planificació temporal (20 hores) ○ Es definiran en un document les tasques que s’assoliran durant el projecte amb les seves estimacions temporals, els recursos que s’utilitzaran i les maneres de gestionar els riscos. També s’elaborarà un diagrama de Gantt per les tasques. ○ Dependències: GP1. ● GP3 - Pressupost i sostenibilitat (20 hores) ○ Es calcularà el cost de dur a terme les tasques definides anteriorment i es farà una anàlisi de sostenibilitat del projecte. ○ Dependències: GP2. ● GP4 - Integració del document final (25 hores) ○ S’elaborarà un document que inclogui la informació dels documents previs incorporant-hi els canvis i correccions que hagin sorgit. ○ Dependències: GP3. ● GP5 - Reunions (15 hores) ○ Es portaran a terme reunions setmanals amb el tutor del projecte per supervisar la feina feta. Incepció ● I1 - Preparació de l’entorn (15 hores) ○ S’instal·larà tot el software necessari per al desenvolupament. ● I2 - Estudi de les tecnologies a utilitzar (15 hores) 19 ○ S’estudiaran els dos frameworks que utilitza el GLiDE (Angular i Spring Boot) per estar preparat per a treballar amb el seu codi. ● I3 - Estudi de l’arquitectura del GLiDE (20 hores) ○ S’estudiarà l’estructura del codi i de les bases de dades del GLiDE. ● I4 - Executar els components del GLiDE (15 hores) ○ S’executaran tots els components del GLiDE (frontend, backend i gamification engine) en local. Sprint 1 ● S11 - Planificació del sprint (5 hores) ○ Es planificaran a nivell fine-grained les tasques a executar durant el sprint. ○ Dependències: I3, I4. ● S12 - Integració dels components software (60 hores) ○ Es faran aquelles tasques relacionades a la integració dels components del GLiDE. ○ Dependències: I1, S11. ● S13 - Documentació (10 hores) ○ Es documentarà la feina feta durant el sprint. Sprint 2 ● S21 - Planificació del sprint (5 hores) ○ Es planificaran a nivell fine-grained les tasques a executar durant el sprint. ○ Dependències: S12. ● S22 - Desenvolupar funcions d’usuari (40 hores) ○ Es desenvoluparan les funcions relacionades a l’autenticació d’usuaris. ○ Dependències: S21. ● S23 - Documentació (10 hores) ○ Es documentarà la feina feta durant el sprint. Sprint 3 ● S31 - Planificació del sprint (5 hores) ○ Es planificaran a nivell fine-grained les tasques a executar durant el sprint. ○ Dependències: S22. ● S32 - Desenvolupar funcions d’administrador (40 hores) ○ Es desenvoluparan les funcions relacionades a l’eina d’administrador per als professors. 20 ○ Dependències: S31. ● S33 - Documentació (10 hores) ○ Es documentarà la feina feta durant el sprint. Sprint 4 ● S41 - Planificació del sprint (5 hores) ○ Es planificaran a nivell fine-grained les tasques a executar durant el sprint. ○ Dependències: S32. ● S42 - Desenvolupar funcions extra (40 hores) ○ Es desenvoluparan funcions addicionals que no són vitals pel funcionament del GLiDE. ○ Dependències: S41. ● S43 - Documentació (10 hores) ○ Es documentarà la feina feta durant el sprint. ● S44 - Validació (20 hores) ○ Es posarà el GLiDE en mans d’alguns alumnes i professors perquè el puguin provar. Després aquests professors i alumnes seran enquestats per veure’n l’opinió. Redacció de la memòria del TFG ● RM1 - Redacció de la memòria del TFG (75 hores) ○ S’elaborarà el document de la memòria del TFG, aquest inclourà una versió refinada dels continguts dels documents de gestió del projecte. Preparació de la defensa del TFG ● PD1 - Preparació de la defensa del TFG (40 hores) ○ Es prepararà la presentació final del projecte i tots els materials que aquesta necessiti. 5.2. Recursos 5.2.1. Recursos humans Els recursos humans requerits pel projecte són els següents: ● [AP] Autor del projecte: assumirà diferents rols d’un equip de desenvolupament del software (cap de projecte, arquitecte del software, desenvolupador, dissenyador de UI/UX i tester) per tal d’assolir els objectius marcats a la contextualització. 21 ● [DP] Director del projecte: serà qui s’encarregarà de supervisar el projecte durant el seu desenvolupament. ● [TG] Tutor de GEP: serà qui donarà retroacció per tots els lliuraments de l’assignatura. 5.2.2. Recursos materials Respecte a recursos materials, per poder realitzar el projecte serà necessari un espai de treball amb accés a la xarxa i un ordinador, també caldrà un espai on poder fer les reunions setmanals de seguiment. Pel que fa a software, s’utilitzarà el que està llistat a continuació: ● [ATN] Atenea: la plataforma on es faran els lliuraments de GEP. ● [DKR] Docker: una eina que facilitarà el desplegament dels diferents components software que formen el projecte. ● [DRW] Draw.io: eina que s’utilitzarà per a l’elaboració de diagrames UML. ● [GIT] GitHub i Git: permeten emmagatzemar el codi en repositoris i fer control de versions. ● [GNT] GanttProject: una eina que serveix per crear diagrames de Gantt. ● [GWS] Google Workspace: conjunt d’eines on s’utilitzarà Drive per editar els documents del projecte, Gmail per la comunicació amb el director del projecte i el tutor de GEP i Calendar per planificar les reunions de seguiment. ● [ITJ] IntelliJ IDEA: és un IDE pensat per desenvolupar amb Java. ● [TGA] Taiga: eina que es farà servir per gestionar el projecte. ● [ZTO] Zotero: una eina per gestionar les referències del treball. 5.3. Estimacions Codi Tasca Duració (h) Dependències Recursos GP Gestió del projecte 105 GP1 Contextualització i abast 25 AP, ATN, GWS, TG, ZTO GP2 Planificació temporal 20 GP1 AP, ATN, GNT, GWS, TG, ZTO GP3 Pressupost i sostenibilitat 20 GP2 AP, ATN, GWS, TG, ZTO GP4 Integració del document final 25 GP3 AP, ATN, GWS, TG, ZTO GP5 Reunions 15 AP, DP, GWS 22 I Incepció 65 I1 Preparació de l'entorn 15 AP, DKR, GIT, ITJ I2 Estudi de les tecnologies a utilitzar 15 AP, ITJ I3 Estudi de l’arquitectura del GLiDE 20 AP, GIT, ITJ I4 Executar els components del GLiDE 15 AP, DKR, GIT, ITJ S1 Sprint 1 75 S11 Planificació del sprint 5 I3, I4 AP, TGA S12 Integració dels components software 60 I1, S11 AP, DKR, GIT, ITJ S13 Documentació 10 AP, DRW, GWS, TGA S2 Sprint 2 55 S21 Planificació del sprint 5 S12 AP, TGA S22 Desenvolupar funcions d’usuari 40 S21 AP, DKR, GIT, ITJ S23 Documentació 10 AP, DRW, GWS, TGA S3 Sprint 3 55 S31 Planificació del sprint 5 S22 AP, TGA S32 Desenvolupar funcions d’administrador 40 S31 AP, DKR, GIT, ITJ S33 Documentació 10 AP, DRW, GWS, TGA S4 Sprint 4 75 S41 Planificació del sprint 5 S32 AP, TGA S42 Desenvolupar funcions extra 40 S41 AP, DKR, GIT, ITJ S43 Documentació 10 AP, DRW, GWS, TGA S44 Validació 20 AP, DP RM Redacció de la memòria del TFG 75 RM1 Redacció de la memòria del TFG 75 AP, DP, GWS, ZTO PD Preparació de la defensa del TFG 40 PD1 Preparació de la defensa del TFG 40 AP, DP, GWS Total 545 [Taula 3] Estimació d’hores, recursos i dependències entre tasques. Font: Elaboració pròpia. 23 5.4. Diagrama de Gantt [Figura 4] Diagrama de Gantt. Font: Elaboració pròpia. 24 5.5. Gestió de risc: Plans alternatius i obstacles Prèviament, s’han identificat els obstacles i riscos que es poden trobar durant l'elaboració d’aquest projecte, a la taula 4 aquests es poden veure juntament amb la probabilitat de la seva ocurrència i l’impacte que poden tenir. En aquest apartat s’explicaran els plans per mitigar els seus efectes. Risc Probabilitat Impacte Ús de noves tecnologies Mitjana Mitjà Partir d’un projecte existent Alta Baix Bugs Alta Alt [Taula 4] Probabilitat i impacte per cada risc. Font: Elaboració pròpia. 5.5.1. Ús de noves tecnologies Com s’ha comentat prèviament, el GLiDE consta de tres parts: el frontend que utilitza Angular i el backend i gamification engine que fan servir Spring Boot. L’autor d’aquest projecte no està del tot ben versat en aquests frameworks, per fer front a aquesta situació s’ha dedicat un temps a l’estudi d’aquestes tecnologies. A més, per garantir que aquest obstacle no suposi un problema per la temporització del projecte, s’ha decidit afegir un marge de temps a la duració de les tasques d’integració i desenvolupament dels sprints. No es necessiten recursos addicionals. 5.5.2. Partir d’un projecte existent El GLiDE ha estat desenvolupat per dos altres alumnes, això significa que si l’autor el vol ampliar, primer s’haurà de familiaritzar amb el codi existent, cosa que suposa haver de dedicar un temps d’estudi a aquest codi i també a comprovar que es pot executar sense problemes a l’ordinador on es desenvoluparà el projecte. Per evitar problemes amb la planificació s’ha afegit una tasca d’estudi de l’arquitectura del GLiDE i s’ha tingut en compte a l’hora de triar la duració de les tasques. No es necessiten recursos addicionals. 25 6.2. Estimació dels costos Per tal de fer front a qualsevol contingència s’ha establert una partida equivalent al 15% dels costos que s’han llistat fins aquest punt. El valor d’aquesta partida es pot veure a la taula 9. Contingència Valor (€) Partida (€) Recursos humans 15.697 2.354,55 Hardware 136 20,40 Costos addicionals 1.325 198,75 Total 2.574 [Taula 9] Valor de la partida per contingències. Font: Elaboració pròpia. També s’han calculat els costos pels imprevistos ja identificats a la taula 10. Aquests tenen en compte la probabilitat que succeeixi cada imprevist, el temps necessari per gestionar-lo i el sou dels rols que es vegin afectats. Imprevist Probabilitat (%) Temps (h) Rols afectats Sous (€/h) Cost (€) Ús de noves tecnologies 50 20 AS (50%) D (50%) 35,67 25 303,35 Partir d’un projecte existent 75 10 AS (50%) D (50%) 35,67 25 227,52 Bugs 75 30 D (50%) T (50%) 25 22,65 536,07 Total 1.067 [Taula 10] Costos per imprevistos. Font: Elaboració pròpia. Arribats a aquest punt ja disposem de tots els costos, només fa falta sumar-los per arribar al cost total del projecte, aquest càlcul es pot veure a la taula 11. Partida Cost (€) Recursos humans 15.697 32 Hardware 136 Costos addicionals 1.325 Contingències 2.574 Imprevistos 1.067 Total 20.799 [Taula 11] Cost total del projecte. Font: Elaboració pròpia. 6.3. Control de gestió Mentre s’està portant a terme el projecte voldrem controlar si hi ha cap desviació entre el pressupost i els costos reals que s’estan incorrent. De la manera que s’ha plantejat el projecte només podem veure una desviació en el cost de personal a causa d’una diferència entre el temps esperat per complir una tasca i el real. Per tant, serà necessari que durant el desenvolupament es vagin registrant les hores emprades per assolir cada tasca, això ens permetrà calcular dues mètriques per cada tasca: ● Desviació d’hores: Es resten les hores reals a les hores estimades per cada tasca, això en permet determinar si les estimacions han estat correctes i ens ajuda de cara a fer front a les següents iteracions, ja que ens permet planificar amb una idea més precisa del nostre ritme de treball. 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó 𝑑'ℎ𝑜𝑟𝑒𝑠 = ℎ𝑜𝑟𝑒𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑒𝑠 − ℎ𝑜𝑟𝑒𝑠 𝑟𝑒𝑎𝑙𝑠 ● Desviació de cost: Es multiplica la desviació d’hores de la tasca pel cost per hora, d’aquesta manera podem saber la diferència entre el cost real de la tasca i el seu cost planificat. Aquesta mètrica és la que resulta més útil per fer un control del pressupost. 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó 𝑑𝑒 𝑐𝑜𝑠𝑡 = 𝑑𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó 𝑑'ℎ𝑜𝑟𝑒𝑠 × 𝑐𝑜𝑠𝑡 𝑝𝑒𝑟 ℎ𝑜𝑟𝑎 Si sumem les desviacions de cost per totes les tasques aconseguim la desviació de cost total, si aquesta és negativa significa que el cost real ha estat superior al planificat. Per una situació així disposem de la partida per contingències, l’autor del projecte haurà de determinar si s’utilitza i en el cas afirmatiu com s’utilitza. 33 El control d’aquestes mètriques es farà a una taula de càlcul, una captura d’aquesta taula es pot veure a la figura 6. [Figura 6] Taula de càlcul pel control de gestió. Font: Elaboració pròpia. 6.4. Execució del pressupost Considerant els canvis en la planificació en el sprint 4, ha fet falta recalcular el pressupost per aquesta part de projecte, cosa que es pot veure a la taula 12. Codi Tasca Duració (h) Dedicació (h) Cost (€) CP AS D DU T S41 Planificació del sprint 5 5 154,2 S42 Desenvolupar funcions d’administrador extra 30 4 18 4 4 757,96 S43 Contenerització del GLiDE 20 5 10 5 541,6 S44 Revisió i preparació de la demo 10 3 5 2 262,82 S45 Documentació 10 5 5 279,2 Totals 75 10 9 33 4 19 1.996 [Taula 12] Pressupost pel sprint 4 després dels canvis de planificació. Font: Elaboració pròpia. 34 Per acabar de calcular el cost del projecte s’han inserit totes les desviacions temporals i els canvis de planificació a la taula de control de la gestió. Els resultats es poden veure a la taula 13. Codi Tasca Duració Estimada (h) Dedicació (h) Cost Estimat (€) Duració Real (h) Desviació Cost (€) CP AS D DU T GP1 Contextualització i abast 25 25 771 26 30,84 GP2 Planificació temporal 20 20 616,8 22 61,68 GP3 Pressupost i sostenibilitat 20 20 616,8 20 0 GP4 Integració del document final 25 25 771 24 -30,84 GP5 Reunions 15 9 2 2 1 1 440,22 15 0 I1 Preparació de l'entorn 15 5 10 428,35 15 0 I2 Estudi de les tecnologies a utilitzar 15 5 10 428,35 15 0 I3 Estudi de l’arquitectura del GLiDE 20 20 713,4 20 0 I4 Executar els components del GLiDE 15 15 375 18 75 S11 Planificació del sprint 5 5 154,2 5 0 S12 Integració dels components software 60 10 20 20 10 1.748,3 72 349,66 S13 Documentació 10 5 5 279,2 10 0 S21 Planificació del sprint 5 5 154,2 5 0 S22 Desenvolupar funcions d’usuari 40 5 25 5 5 1.009,95 40 0 S23 Documentació 10 5 5 279,2 12 55,84 S31 Planificació del sprint 5 5 154,2 5 0 S32 Desenvolupar funcions d’administrador 40 5 25 5 5 1.009,95 44 101 S33 Documentació 10 5 5 279,2 10 0 S41 Planificació del sprint 5 5 154,2 5 0 S42 Desenvolupar funcions d'administrador extra 30 4 18 4 4 757,96 30 0 S43 Contenerització del GLiDE 20 5 10 5 541,6 24 108,32 35 S44 Revisió i preparació de la demo 10 3 5 2 262,82 10 0 S45 Documentació 10 5 5 279,2 10 0 RM1 Redacció de la memòria del TFG 75 70 5 2.337,15 80 155,81 PD1 Preparació de la defensa del TFG 40 40 1233,6 44 123,36 Totals 545 262 76 160 15 32 15.796 581 1.031 [Taula 13] Taula de control de gestió final. Font: Elaboració pròpia. Com es pot veure, el cost de recursos humans després del canvi de planificació és de 99 euros més que a la planificació inicial. També tenim que les desviacions temporals de les tasques han suposat un sobrecost de 1.031 euros. Una altra modificació que s’ha fet té a veure amb el software, donat que s’ha decidit integrar l’API d’OpenAI, que és de pagament. Tot i això, l’ús que s’ha fet durant el projecte no ha arribat a costar un cèntim i no ha fet falta fer cap pagament. Amb tot, el cost final del projecte és el que tenim a la taula 14. En aquesta s’hi pot veure que encara que hi ha hagut certes desviacions, el projecte s’ha pogut completar amb un cost total per sota del pressupost inicial. Partida Cost Estimat (€) Cost Real (€) Recursos humans 15.697 16.827 Hardware 136 136 Costos addicionals 1.325 1.325 Contingències 2.574 - Imprevistos 1.067 - Total 20.799 18.288 [Taula 14] Cost total del projecte final. Font: Elaboració pròpia. 36 7. Estat inicial del GLiDE Aquest projecte parteix de l’aplicació resultant dels treballs GLiDE - Advanced Interaction [6] i GLiDE - Gamification Engine [7]. Per tant, fa falta explicar l’estat inicial del GLiDE per poder deixar clar què s’ha fet en aquest projecte i què ja existia. Aquest apartat també ens permetrà familiaritzar-nos amb conceptes bàsics del GLiDE que s’aniran tractant en els pròxims apartats. 7.1. Arquitectura Com es pot veure a la figura 7, la primera versió del GLiDE consta de tres components: ● Advanced Interaction Backend: Component que fa d’intermediari entre el Learning Dashboard, el Gamification Engine i l’Advanced Interaction Frontend, proporcionant-li al darrer les dades que vol mostrar. Compta amb la seva pròpia base de dades PostgreSQL. Implementat amb Spring Boot. ● Advanced Interaction Frontend: Component responsable de renderitzar la informació del Learning Dashboard i els elements de gamificació. Implementat amb Angular. ● Gamification Engine: Component responsable de proporcionar les funcionalitats de gamificació. Compta amb la seva pròpia base de dades PostgreSQL. Implementat amb Spring Boot. [Figura 7] Arquitectura del GLiDE. Font: Elaboració pròpia. 37 7.2. Conceptes principals En aquest apartat es parlarà de manera resumida d’aquells conceptes dels models del Gamification Engine [7] i l’Advanced Interaction [6] que són rellevants per les funcionalitats implementades durant el projecte. Els models conceptuals es poden trobar a l’annex B. 7.2.1. Gamification Engine Respecte del Gamification Engine, el concepte central és la partida, aquesta ve determinada per una assignatura, un quadrimestre (quadrimestre 1 o quadrimestre 2) i el primer any del curs. La partida té una data d’inici i una de final que determinen el període en el qual es pot executar la gamificació, també té tres atributs a, b i c que determinen la dificultat per pujar de nivell. Cada partida té una sèrie de subgrups que corresponen als subgrups de l’assignatura en el curs i quadrimestre de la partida. A cada subgrup tenim associats els projectes que estan realitzant els seus alumnes, aquests contenen els identificadors del projecte al Learning Dashboard, GitHub i Taiga. El següent concepte important per la part de gestió general són els jugadors, dels quals tenim dos tipus: els individuals i els equips. Els primers representen els alumnes a les partides i els segons els equips. Aquestes són les entitats que guanyen punts, badges i poden pujar de nivell. Cada equip té relacionat un projecte. Tot seguit, tenim el concepte dels estudiants, aquests representen els alumnes al GLiDE i estan identificats pel seu nom d’usuari. Donat que un alumne pot participar en diferents partides (per exemple si cursa diferents assignatures on s’utilitza el GLiDE), aquest es pot associar a múltiples usuaris individuals. També tenen com a atributs els identificadors de GitHub i Taiga de l’alumne. Després tenim els conceptes relacionats a la gamificació, aquí els centrals són les accions avaluables, els achievements, les regles i les leaderboards. Les accions avaluables representen les mètriques del Learning Dashboard, per això tenen un atribut que correspon a l’endpoint de l’API del Learning Dashboard necessari per aconseguir el valor de la mètrica. Aquestes mètriques es calculen a partir de les dades dels repositoris de GitHub i els projectes de Taiga dels equips. Els següents són dos exemples de mètrica: 38 ● LDIM Student commits: Percentatge de commits fets per un alumne respecte del total de commits del projecte. ● LDTM Unassigned tasks: Percentatge de tasques no assignades a cap alumne respecte del total. Els achievements són necessaris per poder utilitzar les accions avaluables, aquests poden assignar punts o badges segons el valor de l’atribut “category”. A continuació, tenim les regles que poden ser o simples o temporals, la diferència és que les segones només es poden complir en un període determinat per una data d’inici i una final. Les regles relacionen achievements amb accions avaluables, establint la condició que ha de superar el valor de l’acció avaluable per aconseguir l’achievement, com per exemple: LDIM Student tasks és major que 20%. Aquesta condició, juntament amb atributs com la quantitat de vegades que cal complir una regla per aconseguir l’achievement i la recompensa que s’aconsegueix queden registrats dins del concepte assignació d’achievement. La comprovació per veure si un alumne o equip compleix una regla, de la mateixa manera que l’actualització de les dades del Learning Dashboard, no es fa en temps real, aquesta pren lloc quan s’avalua la partida. L’avaluació comporta agafar els valors de totes les mètriques del Learning Dashboard i veure si passen les condicions de les regles. L’últim concepte que cal comentar és el de les leaderboards, aquestes ordenen els alumnes o equips segons les recompenses que han rebut. D’aquesta manera els alumnes es poden comparar amb els seus companys, això crea una competició amistosa que anima a millorar el rendiment propi i de l’equip. Amb tot, la idea és crear les regles de manera que s’alineïn amb els objectius d’aprenentatge de l’assignatura i animin la participació dels estudiants. 7.2.2. Advanced Interaction Pel que fa al model conceptual de l’Advanced Interaction, els primers conceptes són els estudiants i els jugadors, tant els de tipus individual com els de tipus equip. Aquests són idèntics als del Gamification Engine dels quals ja s’ha parlat. La resta del model té a veure principalment amb els elements de visualització per pantalla. Cada jugador en una partida té un dashboard format per diferents pantalles que contenen diferents components visuals com gràfics, text o imatges. 39 7.3. Interfície d’usuari (Advanced Interaction) Tenim les dues pantalles presents a la primera versió del GLiDE. La primera és la de monitoratge on l’usuari pot visualitzar les mètriques del Learning Dashboard, tant les individuals com les de l’equip. Aquesta es pot veure a la figura 8. [Figura 8] Pantalla de monitoratge. Font: [6] La segona pantalla és la de gamificació, aquí l’usuari pot veure el seu nivell, els punts que ha acumulat, les badges que ha aconseguit i les que pot aconseguir. També s’hi poden veure les leaderboards, tenim el podi pel top 3 i la pestanya del rànquing, on podem veure els punts i les posicions de tots els jugadors. Aquesta es pot veure a la figura 9. 40 [Figura 9] Pantalla de gamificació. Font: [6] 41 ● Chart.js: És una llibreria JavaScript que proporciona gràfics HTML. S’utilitza per generar alguns dels gràfics que es mostren al GLiDE. ● JSON in Java: És una llibreria que permet fer la traducció de documents JSON a objectes Java i viceversa. ● ModelMapper: És una llibreria que facilita la conversió entre objectes similars. S’utilitza per facilitar la conversió entre models de la base de dades i Data Transfer Objects (DTO). ● Springdoc-openapi: És una llibreria que genera la documentació de l’API seguint l’especificació OpenAPI per un projecte elaborat amb Spring Boot. Springdoc-openapi es basa en la configuració del projecte, les seves classes i un sistema d’anotacions per produir la documentació. En l’anàlisi cost-benefici s'ha considerat principalment algun canvi per millorar. Ara bé, s’ha determinat que el rendiment ja és satisfactori per les necessitats del projecte i que el cost temporal de refer el GLiDE utilitzant altres tecnologies és massa elevat i reduiria dràsticament el temps dedicat a les tasques d’integració i desenvolupament de noves funcionalitats. Per aquestes raons s’ha decidit fer servir les tecnologies que s’han heretat. Durant el desenvolupament d’aquest projecte s’han afegit al stack tecnològic els elements que s'esmenten a continuació: Llibreries: ● Apache Commons CSV: Permet la lectura de fiitxers en el format Comma Separated Value (CSV) [16]. Aquesta llibreria s’ha utilitzat per permetre l’entrada de dades dels estudiants i els seus equips en format CSV. ● Google API Client Library for Java: Ofereix funcionalitats presents a les API de Google com transport HTTP, gestió d’errors, autenticació, JSON parsing, pujada i baixada de continguts multimèdia i batching [17]. Aquesta llibreria s’ha utilitzat principalment per verificar tokens d’identitat de Google. ● Google Identity Services JavaScript: Dona suport per l’autenticació i l’obtenció de tokens d’accés de Google [18]. Aquesta llibreria s’ha utilitzat per implementar l’autenticació d’usuaris mitjançant un compte Google. ● Ngx-toastr: Facilita l’enviada de missatges Toast a l’usuari, aquests serveixen per donar retroacció a l’usuari de manera simple i estètica [19]. Aquesta llibreria s’ha 48 utilitzat principalment per mantenir informat l’usuari quan inicia i tanca sessió o si sorgeix cap error. ● RxJS: Proporciona eines dirigides a l’elaboració de programes asíncrons i basats en esdeveniments [20]. Aquesta llibreria s’ha utilitzat principalment per resoldre errors causats per una gestió incorrecta d’operacions asíncrones. Proves: ● Jasmine: Framework de proves per JavaScript [21]. Permet definir proves i crear mocks mitjançant una sintaxi simple. S’ha utilitzat per escriure les proves de l’eina d’administració. ● JUnit: Framework de proves per Java [22]. S’ha usat per escriure les proves unitàries a l’Advanced Interaction Backend i al Gamification Engine. ● Karma: Test runner per JavaScript [23]. Permet executar les proves creades amb Jasmine al navegador, també és capaç de detectar quan s’han donat canvis al codi per tornar a executar les proves de manera automàtica. S’ha utilitzat per executar proves per l’eina d’administració. ● Mockito: Framework de mocking per Java [24]. És una eina que permet crear mocks de dependències, s’ha fet servir juntament amb JUnit per elaborar les proves per l’Advanced Interaction Backend i el Gamification Engine. 49 10. Nova arquitectura del sistema Durant la realització del projecte, tal com es concretarà als següents capítols, s’han modificat els elements del GLiDE i se n’ha afegit un de nou, l’arquitectura final és el de la figura 10. A la integració i resolució de bugs s’han modificat de manera parcial l’Advanced Interaction Frontend, l’Advanced Interaction Backend i el Gamification Engine. Desenvolupar una solució per l’autenticació d’usuaris ha comportat modificar l’Advanced Interaction Frontend i l’Advancced Interaction Backend. Finalment, crear l’eina d’administració ha requerit crear un nou component, l’Admin Tool, i introduir canvis al Gamification Engine i a l’Advanced Interaction Backend. [Figura 10] Nova arquitectura del GLiDE. Font: Elaboració pròpia. 50 11. Integració i resolució de bugs del GLiDE 11.1. Identificació i resolució de problemes El primer pas per iniciar el procés d’integració i resolució de bugs ha estat configurar en quin port funcionaria cada component i establir les connexions entre aquests i les bases de dades. Aquest pas ha comportat modificar els fitxers de configuració a l’Advanced Interaction Backend i al Gamification Engine, i assegurar que els serveis de l’Advanced Interaction Frontend feien les crides al seu backend. En aquest primer pas, amb modificacions mínimes, es va poder comprovar que els diferents es connectaven correctament i funcionaven de manera conjunta sense problemes. El segon pas ha estat el d’identificar problemes en el sistema i trobar aspectes a millorar. Per cada problema que s’ha trobat s’ha creat un issue al respectiu repositori de GitHub, assignant-li una etiqueta per indicar-ne el tipus i la prioritat, les etiquetes s’han determinat juntament amb l’equip de treball del GLiDE a les reunions setmanals. 11.1.1. Problemes resolts En aquest apartat es detallen els problemes que s’han identificat com a més prioritaris i que, per tant, s’han assegurat de resoldre. També s’inclouen alguns problemes més menors, però que la seva resolució no suposava un temps de desenvolupament excessiu. Advanced Interaction 1. En iniciar l'aplicació no es mostren els gràfics a la pantalla de monitoratge individual. ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: En entrar a la pantalla de monitoratge per primera vegada podem trobar que no es dibuixen els gràfics. ○ Solució: El problema residia en el fet que es feia una sèrie de crides asíncrones al backend per aconseguir les dades que es volen dibuixar i es podia executar la funció per dibuixar els gràfics abans d’obtenir les respostes. Gràcies a les eines que proporciona RxJS s’ha pogut garantir que s’obtenen els resultats de totes les crides asíncrones abans de dibuixar els gràfics. 2. No es mostra correctament el top 3 en casos d'empat. 51 ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: Quan tenim un empat per qualsevol posició del top 3 d’un rànquing al podi només es mostra el primer usuari per ordre alfabètic d’entre els empatats. ○ Solució: Per restriccions de temps s’ha decidit aplicar la solució més simple, on només es mostra el podi en situacions en què no hi ha cap empat en el top 3. 3. A la pantalla de monitoratge de l’equip si s'afegeixen massa històrics o diagrames de barres, aquests no es poden veure. ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: Si es van afegint gràfics històrics o de barres, aquests van apareixent l’un sota l’altre fins a sortir de la pantalla i no és possible fer-hi scroll. ○ Solució: S’han modificat els contenidors que contenen els gràfics per fer que si el seu contingut és massa gros, aparegui una scroll bar, evitant que els continguts surtin de la pantalla i assegurant que tots es poden veure. 4. A la pantalla monitoratge de l’equip si es demana el gràfic històric per una mètrica, aquest no es dibuixa correctament. ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: En entrar a la pantalla de monitoratge de l’equip es mostren correctament els gràfics, però si volem visualitzar els històrics de més mètriques només apareix el títol, però no es dibuixa el gràfic. ○ Solució: La causa del problema era el mateix que per l’issue 2 i s’ha pogut resoldre de la mateixa manera. 5. El podi no escala a la mida de la finestra. ○ Etiqueta: Low priority bug. ○ Estat: Solucionat ○ Descripció: Quan s’escala la finestra el podi manté la seva mida, cosa que no fa cap altre element de la pantalla. 52 ○ Solució: A l’html del s’ha embolicat el canvas on es dibuixa el podi amb una div amb “responsive: true” a l’estil. També ha fet falta afegir un petit retard entre el canvi de mida de la finestra i el del gràfic per evitar problemes en la visualització. 6. Errors a la consola en entrar a la part de gamification. ○ Etiqueta: Low priority bug. ○ Estat: Solucionat. ○ Descripció: En entrar a la pantalla de gamificació salten errors a la consola, aquests indiquen que hi ha hagut un problema a dibuixar l’avatar de l’usuari i el logo de l’equip. ○ Solució: L’error ve del fet que s’intenta dibuixar les imatges abans que aquestes s'aconsegueixin del backend. Per solucionar el problema, a l’html del component s’ha afegit com a condició que les imatges tinguin valor per dibuixar-les. 7. Visualització de noms de les mètriques. ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: A la pantalla de monitoratge de l’equip es mostren els identificadors de les mètriques com ara “closed_tasks_with_AE” en comptes de “Closed tasks with actual effort information”. ○ Solució: S’ha establert un sistema simple on s’emmagatzemen els identificadors i els títols de les mètriques, això permet fer la traducció i mostrar el valor correcte per pantalla. 8. Millorar responsiveness dels gràfics. ○ Etiqueta: Enhancement. ○ Estat: Solucionat. ○ Descripció: Els gràfics de calibre a la pantalla de monitoratge escalen a la mida de la pantalla, però no ho fan les lletres i els valors de l’interior. ○ Solució: Al codi on es defineix el gràfic s’han canviat les parts on es defineixen les mides del text per fer que escalin de manera proporcional a l’amplada de la resta del gràfic. 9. Uniformitzar les gràfiques històriques. ○ Etiqueta: Bug. 53 ○ Estat: Solucionat. ○ Descripció: Pels gràfics històrics a la pantalla de monitoratge de l’equip els extrems de l’eix y canvien segons els valors màxims i mínims d’y. Considerant que representen percentatges, s’ha acordat amb l’equip de treball del GLiDE que aquests extrems sempre haurien de ser 0 i 100. ○ Solució: Al codi on es defineixen els gràfics històrics es poden establir els extrems de l’eix y i s’han posat els valors a 0 i 100. 10. Error en el format de les dates. ○ Etiqueta: Low priority bug. ○ Estat: Solucionat. ○ Descripció: A les pantalles de monitoratge hi ha un selector de dates que permet determinar el període pel qual es volen veure les mètriques. Aquest selector permet inserir manualment la data o seleccionar-la clicant les dates d’inici i final en un calendari. El problema és que el selector mostra les dates en format DD/MM/YYYY, però quan s’insereixen manualment s’interpreten de manera MM/DD/YYYY. ○ Solució: En veure que el problema passa per culpa d’un bug del component per seleccionar les dades, s’ha triat no permetre l’entrada manual de dates. 11. No hi ha memòria dels rangs de dates seleccionats pels gràfics històrics. ○ Etiqueta: Bug, enhancement. ○ Estat: Solucionat. ○ Descripció: Si se surt de les pantalles de monitoratge o es refresca la pàgina els valors establerts al selector de dates es perden, això és problemàtic perquè, per exemple, si l’alumne vol poder veure les mètriques pel sprint en el qual es troba haurà de posar les dates cada vegada que entri. ○ Solució: S’ha afegit una operació al backend per guardar les dates, aquesta es crida cada vegada que l’usuari fa una selecció del període. 12. L'usuari només pot veure una leaderboard individual i d'equip. ○ Etiqueta: Enhancement. ○ Estat: Solucionat. ○ Descripció: Les leaderboards que pot veure l’usuari venen condicionades pels atributs “individual_leaderboard_id” i “team_leaderboard_id” de la taula “gamification_dashboard” a la base de dades. Això significa que l’usuari 54 només pot veure una leaderboard individual i una d’equip i el professor necessita saber l’id d’aquestes quan inicialitza la informació de l’alumne. ○ Solució: La solució està relacionada al canvi de la base de dades que s’ha descrit en un apartat anterior, ara la taula “gamification_dashboard” conté l’identificador de la partida (“game_course”, “game_period” i “game_subject_acronym”) cosa que permet buscar totes les leaderboards de la partida. A la interfície s’ha afegit un selector que permet triar d’entre les leaderboards, aquella que s’ha triat es mostrarà per pantalla. Gamification Engine 1. Evaluate game causa l’aturada del Gamification Engine per algunes regles. ○ Etiqueta: Bug. ○ Estat: Solucionat. ○ Descripció: El Learning Dashboard té dos tipus de mètriques anomenades factors de qualitat i indicadors estratègics que necessiten ser definits pel professor si es volen utilitzar. Si aquesta definició no s’ha fet i es creen al Gamification Engine regles que usen aquests tipus de mètriques, avaluar la partida amb regles així causen un error que atura el Gamification Engine. ○ Solució: El problema passa perquè en avaluar la partida es fa una crida a l’API del Learning Dashboard per cada regla i si la regla és d’un dels tipus de mètrica que s’ha mencionat quan no s’han definit, la crida retorna un error i això fa saltar una excepció que no es gestiona enlloc. Per arreglar el problema només ha fet falta afegir un try-catch que en cas d’error n’informa la causa. 11.1.2. Problemes pendents En aquest apartat es detallen aquells problemes que tot i haver-se identificat la seva resolució ha quedat fora de l’abast del projecte. Aquests són problemes que no tenen un impacte significatiu de cara a l’usuari i que, per tant, deixar-los sense resoldre no afectarà negativament la seva experiència. Advanced Interaction 1. Només es mostren els rànquings per un grup. ○ Etiqueta: Wontfix. 55 ○ Estat: Pendent. ○ Descripció: A la pantalla de gamificació quan volem consultar un rànquing, si aquest és a escala de subgrup de l’assignatura, només es mostra el rànquing del subgrup identificat pel número més baix. S’ha decidit no arreglar aquest issue, ja que l’avaluació per subgrups no s’ajusta a les necessitats del product owner, donat que a les assignatures sovint podem trobar que els integrants d’un equip pertanyen a diferents subgrups i fa que aquest tipus de rànquing no tingui sentit. Per aquesta raó, només s’utilitzaran els rànquings per la matèria. 2. Queden forats a la pantalla de monitoratge de l’equip quan no s’ha seleccionat cap mètrica. ○ Etiqueta: Enhancement, wontfix. ○ Estat: Pendent. ○ Descripció: Quan no hi ha cap mètrica seleccionada pels gràfics històrics o de barres queden espais en blanc a la pantalla. S’ha decidit no solucionar aquest issue, ja que solucionar-lo seria una millora estètica menor que requeriria una quantitat de dedicació considerable. 3. Afegir Favicon a la pàgina web. ○ Etiqueta: Enhancement, wontfix. ○ Estat: Pendent. ○ Descripció: La icona que es pot veure a la pestanya del GLiDE al navegador encara és la que podem trobar per defecte a Angular. Aquest issue no se solucionarà perquè en aquest moment encara no existeix un logotip pel GLiDE, quan aquest es creï s’afegirà. Gamification Engine 1. No funciona la creació de regles a través de Swagger. ○ Etiqueta: Wontfix. ○ Estat: Pendent. ○ Descripció: Swagger és una eina que permet generar una interfície a partir d’una especificació OpenAPI d’un API i provar-ne les crides. En el cas del Gamification Engine, gràcies a un sistema d’anotacions que s’utilitza per documentar cada crida de l’API, aquesta interfície es genera automàticament. Quan s’intenta crear una regla amb la interfície l’operació falla per culpa de com es codifica un dels paràmetres que és de tipus array. S’ha triat no 56 solucionar aquest problema perquè les especificacions de les operacions per crear regles són correctes i, en principi, no hi hauria d’haver mai la necessitat de fer aquestes crides a través d’aquesta interfície. 11.2. Validació Per comprovar el funcionament del GLiDE s’han portat a terme una sèrie de proves. Per aquells components desenvolupats amb Spring Boot s’han creat des de zero proves unitàries per la ja mencionada capa de serveis, donat que la lògica de l’aplicació resideix aquí. Per dur a terme aquestes proves s’ha utilitzat JUnit, un testing framework per Java i el mocking framework Mockito. Per cada servei tenim un document de proves equivalent, en aquests hi podem trobar l’anotació “@InjectMocks” i una declaració del servei objecte de les proves, això permet injectar mocks de les seves dependències mitjançant l’anotació “@Mock” tal com es pot veure a la figura 11. [Figura 11] Injecció de mocks al fitxer de proves. Font: Elaboració pròpia. Després podem trobar els tests pròpiament dits que estan indicats amb l’anotació “@Test”. Aquí es defineix amb el mètode when de Mockito el que volem que tornin les funcions dels mocks de les dependències, s’executa la funció que s’està provant amb uns determinats paràmetres i s’utilitzen mètodes com “assertEquals” i “assertNull” per comprovar que es retornen els valors esperats i mètodes com “verify” per comprovar que s’han fet certes crides als mocks. Tot això està exemplificat a les figures 12 i 13. Per cada funció es fan proves tant per escenaris d’èxit com per escenaris de fallada, com a mostra, en el cas de la figura 12 tenim un cas en què es crea una partida de manera exitosa i a la figura 13 podem veure una situació on la creació falla perquè la partida ja existeix. 57 [Figura 20] Seqüència per POST login. Font: Elaboració pròpia. [Figura 21] Seqüència per GET studentPlayers. Font: Elaboració pròpia. Per desenvolupar aquesta funcionalitat ha fet falta introduir una petita modificació a la base de dades de l’Advanced Interaction Backend. S’ha afegit l’atribut “username” a la taula “student_user”, aquest passa a ser la nova clau primària, i s’ha canviat l’atribut “learningdashboard_username” per “student_user_username”, aquest fa de clau forana que apunta a la taula “student_user”. D’aquesta manera, la taula “student_user” pren la mateixa forma que el seu equivalent a la base de dades del Gamification Engine i ens permet utilitzar username, que ara contindrà l’email de l’alumne, per identificar cada usuari. El diagrama de la base de dades resultat es pot veure a la figura 22. 64 [Figura 22] Nova base de dades de l’Advanced Interaction Backend. Font: Elaboració pròpia. 12.3. Validació Per validar el funcionament de l’autenticació via Google per la part de l’Advanced Interaction Backend s’han creat les proves unitàries per StudentService tal com s’ha descrit a l'apartat d’integració, resolució de bugs i refactoring. Per l’Advanced Interaction Frontend, en canvi, la comprovació s’ha fet de manera manual. El procés per fer-ho comporta afegir un usuari a la base de dades amb el mail d’estudiant de l’autor del projecte, això ha permès veure que el sistema funciona correctament. També s’han fet proves amb adreces que no pertanyen a la UPC o que no estan registrades a l’aplicació per verificar que aquestes no podien completar l’autenticació. 65 13. Desenvolupament d’una eina d’administració 13.1. Anàlisi d’alternatives Abans de tot s’han considerat les alternatives, les opcions eren o bé expandir el frontend del GLiDE per permetre que els professors també hi puguin entrar i tenir accés a una sèrie d’eines per definir partides, achievements, regles de joc i leaderboards o bé crear un nou component només accessible pel professorat on es pot fer el mateix. La tria s’ha fet considerant que no hi ha cap superposició entre les funcionalitats per estudiants i professors i que si es vol expandir el GLiDE, caldrà afegir la gestió per un nou tipus d’usuari. Per aquestes raons s’ha decidit desenvolupar un nou component. 13.2. Desenvolupament Per desenvolupar l’eina d’administració s’ha agafat com a guia el punt 11.8 de la memòria del Gamification Engine [7], en concret els punts 11.8.1 i 11.8.2, on s’explica el procés per preparar una partida al GLiDE. En primer lloc, tenim el punt de gestió general, on es parla de quins elements bàsics fa falta inicialitzar abans de poder passar a preparar la gamificació. Aquí s’explica que cal crear l’assignatura, la partida, definir la dificultat per pujar de nivell i després inserir la informació dels alumnes i els seus equips. Per possibilitar això s’ha creat una interfície que permet fer aquests quatre passos. El primer és el de la selecció o creació de l’assignatura. Aquí l’usuari té la possibilitat de triar d’entre les assignatures existents, com és el cas de la figura 23, o inserir la informació d’una nova, que és el cas de la figura 24. 66 [Figura 23] Creació de partida, tria d’assignatura. Font: Elaboració pròpia. [Figura 24] Creació de partida, creació d’assignatura. Font: Elaboració pròpia. El segon és el de la definició dels atributs de la partida, que es pot veure a la figura 25. Aquí l’usuari pot inserir el curs (posant el primer any d’aquest), el quadrimestre i les dates d’inici i 67 final de la partida. També es té l’opció de triar una altra partida per poder importar-ne les regles, tal com es veu a la figura 26. [Figura 25] Creació de partida, definició d’atributs. Font: Elaboració pròpia. 68 [Figura 26] Creació de partida, importació de regles. Font: Elaboració pròpia. El tercer és el de la definició de la política de nivells, que es pot veure a la figura 27. En aquest pas es pot definir la quantitat de punts necessària per pujar de cada nivell, això es fa definint els paràmetres a, b i c de la següent fórmula: 𝑝𝑢𝑛𝑡𝑠 𝑝𝑒𝑟 𝑝𝑢𝑗𝑎𝑟 𝑎𝑙 𝑛𝑖𝑣𝑒𝑙𝑙 𝑛 = 𝑎·𝑏(𝑛·𝑐) Per fer el procés més intuïtiu, a la pantalla es mostra la corba de dificultat, cosa que ens ajuda a veure com escala la dificultat de pujar de nivell a mesura que aquest augmenta. [Figura 27] Creació de partida, política de nivells. Font: Elaboració pròpia. El quart pas és el de la importació d’alumnes i equips, que es pot veure a la figura 28. Aquí l’usuari pot pujar un fitxer CSV per importar les dades dels alumnes i equips, aquestes serveixen per crear els jugadors i equips de la partida. 69 [Figura 28] Creació de partida, importació d’alumnes i equips. Font: Elaboració pròpia. En segon lloc, tenim el punt de preparació de la gamificació, on es parla de com inicialitzar aquells elements directament relacionats a la gamificació: achievements, regles i leaderboards. En aquest cas l’API sí que ofereix crides per la seva creació, en conseqüència, només ha estat necessari crear els formularis corresponents, aquests són visibles a les figures 29, 30 i 31. Un detall és que la creació de regles ofereix la possibilitat de generar el títol i missatge de manera automàtica a partir de les característiques d’aquesta. 70 [Figura 29] Creació d’achievements. Font: Elaboració pròpia. [Figura 30] Creació de regles. Font: Elaboració pròpia. [Figura 31] Creació de leaderboards. Font: Elaboració pròpia. 71 A més d’això, també s’han afegit formularis per editar regles, leaderboards i per afegir alumnes i equips a una partida ja existent amb l’objectiu de facilitar la gestió del GLiDE per part del professorat. Aquí també ha fet falta afegir noves operacions a l’API del Gamification Engine. Les pantalles es poden veure a les figures 32 i 33. [Figura 32] Edició de regles. Font: Elaboració pròpia. [Figura 33] Edició de leaderboards. Font: Elaboració pròpia. Per desenvolupar les noves operacions s’ha aplicat el patró Controlador-Servei-Repositori de la mateixa manera que es fa per les operacions ja existents. Això significa que, per exemple, per les assignatures s’ha creat el controlador i el servei, el repositori ja existeix. Amb això, les seqüències de les noves operacions tenen una forma similar a la de la figura 34. Per veure les especificacions d’aquestes crides a l’API es pot consultar l’annex A. 72 [Figura 34] Seqüència per POST subject. Font: Elaboració pròpia. També, a l’Admin Tool s’ha aplicat el patró Singleton. Això permet tenir un servei, del qual només existeix una instància, des d’on es fan totes les crides al Gamification Engine i al qual poden accedir tots els components. Per tant, la seqüència per fer una crida a l’API des dels components queden com a la figura 35. [Figura 35] Seqüència per POST subject a l’Admin Tool. Font: Elaboració pròpia. 73 3. Es copien els fitxers package.json i package-lock.json, on es defineixen les dependències, al directori de treball. 4. S’instal·len les dependències. 5. Es copien la resta de fitxers al directori de treball. 6. Es crea la build de producció de l’aplicació. Desplegament de l’aplicació amb nginx: 1. Es tria la imatge de nginx que es vol utilitzar. 2. S’esborra el fitxer de configuració per defecte de nginx i se substitueix per un document amb els continguts de la figura 42. El codi fa que a l’adreça arrel se serveixi el document index.html del nostre projecte Angular. [Figura 42] Continguts del fitxer nginx.conf. Font: Elaboració pròpia. 3. Es copien els fitxers resultants del muntatge del projecte Angular a la carpeta html de nginx. 4. Es marca en quin port intern del contenidor funcionarà el servidor nginx. 5. S’inicia el servidor nginx. Per l’Advanced Interaction Backend i el Gamification tenim el següent dockerfile de la figura 43. 80 [Figura 43] Dockerfile pels backends del GLiDE. Font: Elaboració pròpia. Aquest dockerfile també té dues parts: Muntatge de l’aplicació: 1. Es tria la imatge de gradle que es vol utilitzar. 2. Es marca el directori de treball. 3. Es copien els fitxers de gradle i el codi font al directori de treball. 4. S’executa la comanda per generar el fitxer JAR. Desplegament de l’aplicació: 1. Es tria la imatge de JDK que es vol utilitzar. 2. Es copia el fitxer JAR. 3. S’executa l’aplicació Java. Si volem fer funcionar qualsevol d’aquests components per separat simplement fa falta user les comandes “docker build -t ‘nom_de_la_imatge’ .” i “docker run -d ‘nom_de_la_imatge’”. Ara bé, si volem fer funcionar tots els components del GLiDE a la vegada, fa falta utilitzar el fitxer docker-compose.yml. Aquest permet executar el GLiDE fent servir només la comanda “docker compose up”. 81 Aquest fitxer té una primera part on s’executen els quatre dockerfiles dels quals s’acaba de parlar, es marquen les variables d’entorn i es determina la xarxa per la qual es comunicaran els components. Això es pot veure a la figura 44. [Figura 44] Components del GLiDE al docker compose. Font: Elaboració pròpia. Al fitxer també hi ha el codi que s’encarrega de crear el contenidor de PostgreSQL i les dues bases de dades de l’Advanced Interaction Backend i el Gamification Engine. També s’hi fa la definició de la xarxa per la comunicació entre contenidors i del volum que manté la persistència de manera que no es perd si s’apaguen els contenidors. Això es pot veure a la figura 45. 82 [Figura 45] Beses de dades, xarxes i volum al compose. Font: Elaboració pròpia. Amb tot això, en aixecar tota l’aplicació, el desplegament queda tal com s’indica al diagrama de la figura 46. 83 [Figura 46] Diagrama de desplegament del GLiDE. Font: Elaboració pròpia. 84 15. Informe de Sostenibilitat 15.1. Autoavaluació En contestar l’enquesta proporcionada a GEP, l’autor ha pogut reflexionar sobre els coneixements i les capacitats que té respecte a les tres dimensions de la sostenibilitat: l’econòmica, l’ambiental i la social. En primer lloc, aquests aspectes es van tractar de manera bastant explícita a una de les assignatures cursades per l’autor, Arquitectura del PC (APC). En aquesta assignatura es plantejava un escenari, en concret la construcció d’un data center, que calia analitzar tenint en compte les tres dimensions. També s’hi elaborava un estudi sobre algun tema del món de la informàtica on calia tenir en consideració les tres dimensions. A part d’això, al llarg dels estudis la dimensió ambiental ha estat present en múltiples ocasions, sobretot quan es parla de hardware. Respecte a això, la conversa s’ha centrat sobretot en el tema de l’e-waste (els residus electrònics) i l’alumnat ha tingut múltiples ocasions de participar en una iniciativa que hi fa front a través de les jornades reutilitza de l’associació Tecnologia per a Tothom (TxT) [27], on ordinadors que haurien estat descartats s’arreglen de manera que es puguin reutilitzar en tota mena de projecte. Pel que fa a l’aspecte social, en algunes assignatures com Aplicacions i Serveis Web (ASW) i Projecte d’Enginyeria del Software (PES) es desenvolupen projectes en equip, d’aquesta manera s’aprenen en profunditat tots els aspectes del treball col·laboratiu. A més, a GPS s’emfatitzava força que el projecte aportés algun valor a la societat, en el cas de l’autor es va desenvolupar una aplicació que animava a l’usuari a prendre consciència del seu consum energètic a casa i de maneres de reduir-lo. Respecte a la dimensió econòmica, a part de l’anàlisi del pressupost que s’ha fet en aquest treball, s’ha tingut l’experiència d’estudiar la viabilitat i sostenibilitat econòmica d’un projecte hipotètic a l’assignatura Gestió de Projectes de Software (GPS). En fer aquesta reflexió, l’autor ha estat capaç d’identificar algunes mancances en el seu coneixement. La primera té a veure amb no estar familiaritzat amb l’ús d’indicadors que permeten mesurar l’impacte del projecte en les tres dimensions. La segona té a veure amb la dificultat per identificar l’impacte ambiental d’un projecte software, ja que durant la carrera la dimensió ambiental sempre s’ha centrat més en l’impacte del hardware. 85 15.2. Dimensió econòmica Has estimat el cost de la realització del projecte? Com es pot veure en apartats anteriors, s’han analitzat els costos per tot el projecte. Això ha suposat considerar els costos de personal, on s’han tingut en compte les hores de treball i els salaris de cada rol, les despeses en hardware i software i també els costos dels espais de treball i reunions. Has pres decisions per reduir el cost? Has quantificat aquest estalvi? En primer lloc, s’ha decidit utilitzar software gratuït per desenvolupar el projecte. A part d’això la major part del cost del projecte era dedicat al cost de personal i l’única manera de reduir-lo seria retallant la quantitat d’hores de treball, cosa que no era possible. S’ha ajustat el cost previst al cost final? El cost previst sí que s’ha ajustat al cost final, per veure els detalls del cost per portar a terme el projecte es pot consultar l’apartat 6.4. Execució del pressupost. Com es resol el problema que vols abordar? En què millorarà econòmicament la teva solució a les existents? Actualment, el més proper a una alternativa al GLiDE són eines de gestió de projectes software, aquestes s’han identificat quan s’ha fet l’anàlisi de l’estat de l’art. La principal millora econòmica que suposarà aquest projecte és respecte a la primera versió del GLiDE, que fins aquest moment s’han invertit uns diners a desenvolupar-la, però com ja s’ha expressat, aquesta no està llesta per posar-se en mans d’alumnes i professors, la nova versió assegura que es pugui treure un valor d’aquesta inversió. Quin cost estimes que tindrà el projecte durant la seva vida útil? El cost que tindrà el projecte durant la seva vida útil ve relacionat al seu consum energètic i al cost d’ampliar o actualitzar-lo, per determinar aquest segon cost faria falta efectuar un càlcul com el que es fa a l’apartat 6. Pressupost d’aquesta memòria. S’ha tingut en compte el cost dels ajustaments / actualitzacions / reparacions durant la vida útil del projecte? 86 Si fa falta ajustar o reparar el GLiDE el fet que tots els seus components estan conteneritzats significa que aquest es podrà tornar a desplegar fàcilment, cosa que significa un estalvi. El cost d’actualitzar l’aplicació dependrà del temps de desenvolupament, però durant la realització del projecte s’ha buscat garantir que l’aplicació sigui mantenible i fàcil d’ampliar, això ajudarà a evitar que aquest temps s’allargui massa. Podrien produir-se escenaris que perjudiquessin la viabilitat econòmica del projecte? No s’ha identificat cap risc significatiu a la viabilitat econòmica del projecte. 15.3. Dimensió ambiental Has estimat l’impacte ambiental que tindrà la realització del projecte? T’has plantejat minimitzar l’impacte? Aquest es tracta d’un projecte software que només fa servir una tecnologia que pot suposar un impacte ambiental significatiu, el servei d’OpenAI. Els data centers que possibiliten la intel·ligència artificial empren una gran quantitat de recursos per ser construïts, generen residus electrònics que poden contenir substàncies perilloses com plom o mercuri, consumeixen grans volums d’aigua per refrigeració i tenen un gran consum elèctric [28]. Tot i això, l’ús que fa el GLiDE de la intel·ligència artificial és tan menor que no s’ha considerat un aspecte rellevant per l’impacte ambiental d’aquest projecte. Aleshores, l’impacte ambiental que tindrà bàsicament es limita al consum energètic que implicarà el desenvolupament i tenir l’aplicació funcionant. S’ha considerat com minimitzar l’impacte ambiental, però s’ha arribat a la conclusió que qualsevol acció presa tindria un efecte negligible sobre un impacte que no és significatiu. Si tornessis a fer el projecte, podries realitzar-lo amb menys recursos? Considerant l’experiència que s’ha guanyat realitzant aquest projecte, si aquest s’hagués de tornar a fer, faria falta menys temps per completar-lo. Per tant, el principal recurs que es podria reduir seria el temps, això també implicaria una menor despesa energètica. Com es resol actualment el problema que vols abordar? En què millorarà ambientalment la teva solució a les existents? Actualment, el més proper a una alternativa al GLiDE són eines de gestió de projectes software, aquestes s’han identificat quan s’ha fet l’anàlisi de l’estat de l’art. 87 Aquesta nova versió del GLiDE no suposarà cap millora ambiental real respecte cap de les alternatives que s’han analitzat. El projecte permetrà reduir l’ús d’altres recursos? Globalment, l’ús del projecte millorarà o empitjorarà l’empremta ecològica? El projecte no permetrà reduir l’ús d’altres recursos. Globalment, no tindrà cap impacte significatiu sobre l’empremta ecològica. Podrien produir-se escenaris que fessin augmentar l'empremta ecològica del projecte? L’únic cas que podria fer augmentar l'empremta ecològica del projecte és si l’electricitat que s’utilitza a la màquina on està desplegat el GLiDE es produeix usant fonts d’energia no renovables. 15.4. Dimensió social Què creus que t’aportarà personalment la realització d’aquest projecte? Des d'un punt de vista personal, aquest projecte suposa l’oportunitat per aprendre a treballar amb tecnologies que són noves per l’autor i per guanyar experiència en integrar i desenvolupar software. El projecte també dona a l’autor l'oportunitat d’aplicar bones pràctiques de programació i gestió. La realització d’aquest projecte ha implicat reflexions significatives en l’àmbit personal, professional o ètic de les persones que han intervingut? La realització d’aquest projecte no ha implicat cap reflexió significativa. El GLiDE simplement és una eina que pretén ajudar alumnes en els seus projectes de software desenvolupats en equip. Com es resol actualment el problema que vols abordar? En què millorarà socialment la teva solució a les existents? Actualment, el més proper a una alternativa al GLiDE són eines de gestió de projectes software, aquestes s’han identificat quan s’ha fet l’anàlisi de l’estat de l’art. La principal millora social que presenta aquest projecte és que ajudarà alumnes a tenir una millor experiència quan desenvolupin projectes software en equip, ja que tindran una eina 88 que els ajuda a fer un seguiment i veure com assoleixen els objectius de l’aprenentatge de manera interactiva. Existeix una necessitat real del projecte? Sí que existeix una necessitat real del projecte. Com s’ha mencionat en apartats anteriors, la versió original del GLiDE no és usable. Poder posar el GLiDE en funcionament permetrà ajudar alumnes a fer un millor seguiment dels seus projectes. Qui es beneficiarà de l’ús del projecte? Hi ha cap col·lectiu que es pot veure perjudicat pel projecte? En quina mesura? Els principals beneficiats de l’ús del projecte seran els alumnes que l’utilitzin. El GLiDE els ajudarà a fer un seguiment dels seus projectes d’una manera interactiva. No s’ha identificat cap col·lectiu que es pugui veure perjudicat pel projecte. En quina mesura soluciona el projecte el problema plantejat inicialment? El problema soluciona el problema plantejat inicialment completament. En acabar el projecte el GLiDE és plenament funcional i llest per a ser posat en ús. Podrien produir-se escenaris que fessin que el projecte fos perjudicial per a algun segment particular de la població? El GLiDE no presenta cap funcionalitat que podria portar a perjudicar un segment particular de la població. Podria crear el projecte alguna mena de dependència que deixés els usuaris en posició de debilitat? S’ha considerat que el projecte no pot generar cap mena de dependència perjudicial per als usuaris. 89 necessiten els professors al GLiDE, per tant, s’han anat ajustant els requisits per assegurar que el software desenvolupat s’ajustés a les seves necessitats. 18.3. Treball futur El projecte GLiDE encara presenta oportunitats de treball de cara al futur. La primera, i la que més s’ha trobat a faltar en aquest projecte, és poder fer un procés de validació de l’aplicació. Hauria estat realment interessant poder posar el GLiDE en mans d’alumnes i veure quina retroacció en donen, cosa que sens dubte ajudaria a veure si fa falta fer ajustos a la interfície i també seria útil per ajudar a refinar el sistema de partides. La segona, té a veure amb ampliar la gestió d’usuaris. De cara als usuaris faltaria afegir l’opció d’editar el perfil, afegint formularis per editar el seu nom de jugador i poder pujar les imatges que s’utilitzen com a avatar. També tenim que a la nova versió del GLiDE es poden crear a la base de dades alumnes i equips en massa a través d’un CSV, però faltaria afegir les eines per poder fer una edició a nivell més detallat, podent modificar amb facilitat les dades d’un alumne o equip individual. La tercera és que alguns conceptes de la primera versió del GLiDE no s’han acabat utilitzant, com per exemple els subgrups de les assignatures, aleshores estaria bé fer la feina d’acabar d’avaluar si es vol ampliar el GLiDE perquè en faci ús o si es prefereix eliminar-los. 96 19. Referències [1] C. Farré, L. López, M. Oriol, A. Espinola, A. Miñana, i X. Franch, «GLiDE: Integrated Gamified Learning Dashboard Environment», CAiSE Research Projects Exhibition, 2024, p. 34-42. [2] A. Volkova, C. Farré, X. Franch, i J. D. Conejos, «Implantación de un cuadro de mando para el seguimiento del progreso de proyectos software desarrollados por equipos de estudiantes», 2022. Master’s thesis, Universitat Politècnica de Catalunya. Disponible a: http://hdl.handle.net/2117/371383 [3] L. L. Cuesta, «2023-24 Q2.AMEP», 27 maig 2024. Consulta: 13 octubre 2024. [En línia]. Disponible a: https://docs.google.com/presentation/d/1WHUGzZzVDFb_lPzdY14mLVxYib78Rp6WL 3mA-wNi5Uw [4] L. López et al., «Q-Rapids Tool Prototype: Supporting Decision-Makers in Managing Quality in Rapid Software Development», en Information Systems in the Big Data Era, vol. 317, J. Mendling i H. Mouratidis, Ed., en Lecture Notes in Business Information Processing, vol. 317. , Cham: Springer International Publishing, 2018, p. 200-208. doi: 10.1007/978-3-319-92901-9_17. [5] S. Deterding, R. Khaled, L. Nacke, i D. Dixon, «Gamification: Toward a definition», gen. 2011, p. 12-15. [6] A. Espinola Garcia, «GLiDe-I: Integrated Gamified Learning Dashboard Environment - Advanced Interaction», Master thesis, Universitat Politècnica de Catalunya, 2024. Consulta: 16 desembre 2024. [En línia]. Disponible a: https://upcommons.upc.edu/handle/2117/419114 [7] A. Miñana Montecino, «GLiDe-G: Integrated Gamified Learning Dashboard Environment : Gamification Engine», Master thesis, Universitat Politècnica de Catalunya, 2024. Consulta: 16 desembre 2024. [En línia]. Disponible a: https://upcommons.upc.edu/handle/2117/418504 [8] «Create Project», Taiga - Love your projects. Consulta: 22 setembre 2024. [En línia]. Disponible a: https://tree.taiga.io/project/new [9] «¿Qué es el control de versiones?» Consulta: 13 octubre 2024. [En línia]. Disponible a: https://about.gitlab.com/es/topics/version-control/ [10] Atlassian, «Flujo de trabajo de Gitflow | Atlassian Git Tutorial», Atlassian. Consulta: 13 octubre 2024. [En línia]. Disponible a: https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow [11] A. Isla, «¿Por qué es una buena idea utilizar Git Flow?», Medium. Consulta: 22 setembre 2024. [En línia]. Disponible a: https://willywes.medium.com/por-qu%C3%A9-es-una-buena-idea-utilizar-gitflow-c92c5 e7754e0 [12] «Salario en España - Salario Medio», Talent.com. Consulta: 4 octubre 2024. [En línia]. Disponible a: https://es.talent.com/salary [13] «Asus UX530UX-FY021T Intel Core i7-7500U/8GB/256GB SSD/GTX950/15.6"», PcComponentes. Consulta: 5 octubre 2024. [En línia]. Disponible a: https://www.pccomponentes.com/asus-ux530ux-fy021t-intel-core-i7-7500u-8gb-256gb-s sd-gtx950-156 [14] «Días laborables calculadora en España | Cataluña». Consulta: 5 octubre 2024. [En línia]. Disponible a: https://www.dias-laborables.es/Catalu%C3%B1a.htm#a3 [15] «Plan Sower - SOWO». Consulta: 5 octubre 2024. [En línia]. Disponible a: https://www.sowo.es/plan-sower/ 97 [16] «Commons CSV – Home». Consulta: 2 gener 2025. [En línia]. Disponible a: https://commons.apache.org/proper/commons-csv/ [17] «API Client Library for Java | Google for Developers». Consulta: 18 novembre 2024. [En línia]. Disponible a: https://developers.google.com/api-client-library/java [18] «Authorizing for Web | Authorization», Google for Developers. Consulta: 18 novembre 2024. [En línia]. Disponible a: https://developers.google.com/identity/oauth2/web/guides/overview [19] «ngx-toastr», npm. Consulta: 24 novembre 2024. [En línia]. Disponible a: https://www.npmjs.com/package/ngx-toastr [20] «RxJS - Introduction». Consulta: 18 novembre 2024. [En línia]. Disponible a: https://rxjs.dev/guide/overview [21] «Jasmine Documentation». Consulta: 14 gener 2025. [En línia]. Disponible a: https://jasmine.github.io/ [22] «JUnit 5». Consulta: 14 gener 2025. [En línia]. Disponible a: https://junit.org/junit5/ [23] «Karma - Spectacular Test Runner for Javascript». Consulta: 14 gener 2025. [En línia]. Disponible a: https://karma-runner.github.io/latest/index.html [24] «Mockito framework site». Consulta: 14 gener 2025. [En línia]. Disponible a: https://site.mockito.org/ [25] «Integrating Google Sign-In into your web app | Authentication», Google for Developers. Consulta: 3 gener 2025. [En línia]. Disponible a: https://developers.google.com/identity/sign-in/web/sign-in [26] «Authenticate with a backend server | Authentication», Google for Developers. Consulta: 3 gener 2025. [En línia]. Disponible a: https://developers.google.com/identity/sign-in/web/backend-auth [27] «Tecnlogia per a tothom | Facultat d’Informàtica de Barcelona». Consulta: 7 octubre 2024. [En línia]. Disponible a: https://txt.upc.edu/ [28] «AI has an environmental problem. Here’s what the world can do about that.» Consulta: 12 gener 2025. [En línia]. Disponible a: https://www.unep.org/news-and-stories/story/ai-has-environmental-problem-heres-whatworld-can-do-about [29] «REGLAMENTO (UE) 2016/ 679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO - de 27 de abril de 2016 - relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/ 46/ CE (Reglamento general de protección de datos)», [En línia]. Disponible a: https://www.boe.es/doue/2016/119/L00001-00088.pdf [30] «Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales.», set. 2020, Consulta: 24 novembre 2024. [En línia]. Disponible a: https://www.boe.es/buscar/pdf/2018/BOE-A-2018-16673-consolidado.pdf [31] «10.- Modificació de la Normativa sobre els Drets de la Propietat Industrial i Intel·lectual de la UPC.pdf». Consulta: 25 novembre 2024. [En línia]. Disponible a: https://govern.upc.edu/ca/consell-de-govern/consell-de-govern/sessio-05-2022-del-consel l-de-govern/comissio-deconomia-i-infraestructures/aprovacio-de-la-modificacio-de-la-no rmativa-sobre-els-drets-de-la-propietat-industrial-i-intel-lectual-de-la-upc/aprovacio-de-l a-modificacio-de-la-normativa-sobre-els-drets-de-la-propietat-industrial-i-intel-lectual-de -la-upc/@@display-file/visiblefile/10.-%20Modificaci%C3%B3%20de%20la%20Norma tiva%20sobre%20els%20Drets%20de%20la%20Propietat%20Industrial%20i%20Intel% C2%B7lectual%20de%20la%20UPC.pdf [32] «Propietat intel·lectual dels treballs acadèmics UPC | Bibliotècnica». Consulta: 25 novembre 2024. [En línia]. Disponible a: 98 https://bibliotecnica.upc.edu/propietat-intellectual/propietat-intellectual-treballs-academic s-upc#titularitat-propietat-industrial-intellectual-treball-academic-tfg-tfm-o-treball-assign atura [33] «Apache License, Version 2.0». Consulta: 25 novembre 2024. [En línia]. Disponible a: https://www.apache.org/licenses/LICENSE-2.0 [34] «Open Source Licenses 101: Apache License 2.0 - FOSSA», Dependency Heaven. Consulta: 25 novembre 2024. [En línia]. Disponible a: https://fossa.com/blog/open-source-licenses-101-apache-license-2-0/ 99 Annex Annex A. Documentació de les API En realitzar aquest projecte ha fet falta afegir noves crides a les API de l’Advanced Interaction Backend i el Gamification Engine per poder implementar les noves funcionalitats del GLiDE. Aquestes noves crides queden documentades a continuació. Annex A1. Advanced Interaction Backend Operació per aconseguir totes les accions avaluables: Mètode Endpoint GET /api/gamification/evaluableActions Respostes (application/json) Codi Descripció 200 OK: List of EvaluableActionDTO objects. [ { "id": "LDTM-Tasks_standard_deviation", "name": "tasks_sd", "description": "Percentage of variation in the number of tasks between team members", "category": "PlayerPerformance", "assessmentLevel": "Team", "sourceDataTool": "LearningDashboard", "sourceDataAPIEndpoint": "/metrics/*/current?prj=*" } ] [Taula 15] Especificació GET evaluable actions. Font: Elaboració pròpia. Operació per importar les dades d’alumnes i equips a partir d’un fitxer CSV: Mètode Endpoint POST /api/importData Paràmetres de la sol·licitud Nom Tipus gameSubjectAcronym String gameCourse Integer gamePeriod String 100 Cos de la sol·licitud (multipart/form-data) Nom Tipus importedData MultipartFile Respostes (application/json) Codi Descripció 201 CREATED: Successfully imported data. 409 CONFLICT: Invalid CSV record. [Taula 16] Especificació POST import data. Font: Elaboració pròpia. Operació per aconseguir totes les leaderboards d’una partida: Mètode Endpoint GET /api/leaderboards Paràmetres de la sol·licitud Nom Tipus gameSubjectAcronym String gameCourse Integer gamePeriod String Respostes (application/json) Codi Descripció 200 OK: List of LeaderboardDTO objects. [ { "id": 1, "name": "AMEP 2024 Quadrimester1 work distribution leaderboard", "startDate": "2024-09-02", "endDate": "2024-12-31", "assessmentLevel": "Team", "extent": "Subject", "anonymization": "Full", "studentVisible": true, "achievementId": 1 } ] [Taula 17] Especificació GET leaderboards. Font: Elaboració pròpia. 101 Operació per modificar el període pel qual es mostren les mètriques històriques per un usuari: Mètode Endpoint PATCH /api/players/{playername}/monitoring/selectedDates Paràmetres de ruta Nom Tipus playername String Paràmetres de la sol·licitud Nom Tipus startDate String endDate String Respostes (application/json) Codi Descripció 200 OK: PlayerMonitoringDTO object. { "id": 1, "playername": "player.name", "startDate": "2024-12-01", "endDate": "2024-12-31", "selectedMetrics": "acceptance_critera_check", "selectedHistoryMetrics": "acceptance_critera_check", "selectedBarMetrics": "acceptance_critera_check" } 404 NOT FOUND: Individual player with given id not found. [Taula 18] Especificació PATCH selected dates. Font: Elaboració pròpia. Operació per fer login d’un usuari: Mètode Endpoint POST /api/students/login Headers Nom Tipus idToken String Respostes (application/json) Codi Descripció 102 200 OK: Login successful. 400 BAD REQUEST: No idToken was provided. 401 UNAUTHORIZED: Issue verifying idToken. 404 NOT FOUND: Student user not found. [Taula 19] Especificació POST login. Font: Elaboració pròpia. Operació per aconseguir els diferents jugadors d’un usuari (donat que un alumne pot cursar múltiples assignatures on s’utilitza el GLiDE): Mètode Endpoint GET /api/students/players Headers Nom Tipus idToken String Respostes (application/json) Codi Descripció 200 OK: List of IndividualPlayerDTO objects. [ { "playername": "player.name", "points": 10, "level": 1, "type": "Individual", "role": "Student", "teamPlayername": "TeamName", "project": "ProjectName", "learningdashboardUsername": "ld.username", "githubUsername": "github.username", "taigaUsername": "taiga.username" } ] 400 BAD REQUEST: No idToken was provided. 401 UNAUTHORIZED: Issue verifying idToken. 404 NOT FOUND: Student user not found. [Taula 20] Especificació GET student players. Font: Elaboració pròpia. Annex A2. Gamification Engine Operació per crear una nova partida: 103 Mètode Endpoint POST /api/games Cos de la sol·licitud (multipart/form-data) Nom Tipus subjectAcronym String course Integer period String startDate String endDate String firstLevelPolicyParameter Float secondLevelPolicyParameter Float thirdLevelPolicyParameter Float Respostes (application/json) Codi Descripció 201 CREATED: GameDTO object. { "subjectAcronym": "AMEP", "course": 2024, "period": "Quadrimester1", "startDate": "2024-09-02", "endDate": "2024-12-31", "levelPolicyFunctionParameters": [ 1, 1.4, 2 ], "state": "Playing" } 404 NOT FOUND: Subject with the given subject acronym not found. 409 CONFLICT: (1) Game parameters cannot be blank. (2) The given game already exists. [Taula 21] Especificació POST game. Font: Elaboració pròpia. Operació per editar una partida: Mètode Endpoint 104 PUT /api/games Cos de la sol·licitud (multipart/form-data) Nom Tipus subjectAcronym String course Integer period String startDate String endDate String Respostes (application/json) Codi Descripció 200 OK: GameDTO object. { "subjectAcronym": "AMEP", "course": 2024, "period": "Quadrimester1", "startDate": "2024-09-02", "endDate": "2024-12-31", "levelPolicyFunctionParameters": [ 1, 1.4, 2 ], "state": "Playing" } 404 NOT FOUND: Game with the given identifier not found. 409 CONFLICT: Invalid date parameters. [Taula 22] Especificació PUT game. Font: Elaboració pròpia. Operació per crear un nou grup d’una partida: Mètode Endpoint POST /api/gameGroups Cos de la sol·licitud (multipart/form-data) Nom Tipus gameSubjectAcronym String gameCourse Integer 105 404 NOT FOUND: Date rule with the given id not found. [Taula 30] Especificació DELETE date rule. Font: Elaboració pròpia. Operació per editar una regla de dates: Mètode Endpoint PUT /api/rules/dates/{id} Paràmetres de ruta Nom Tipus id Long Cos de la sol·licitud (multipart/form-data) Nom Tipus name String repetitions Integer startDate String endDate String gameSubjectAcronym String gameCourse Integer gamePeriod String evaluableActionId String achievementAssignment Message String achievementAssignmentOnly FirstTime Boolean achievementAssignment Condition String achievementAssignment ConditionParameters List<Float> achievementAssignmentUnits Integer achievementAssignment AssessmentLevel String Respostes (application/json) 112 Codi Descripció 200 OK: DateRuleDTO object. { "id": 1, "name": "Minimum Task Assignment Threshold", "type": "Simple", "repetitions": 1, "startDate": "2024-12-01", "endDate": "2024-12-31", "gameSubjectAcronym": "AMEP", "gameCourse": 2024, "gamePeriod": "Quadrimester1", "evaluableActionId": "LDIM-Student_tasks", "achievementId": 1, "achievementAssignmentMessage": "To ensure equitable distribution of workload, each student must be assigned more than 12% of the total tasks in the project. This rule promotes balanced participation and encourages collaborative effort among all students.", "achievementAssignmentOnlyFirstTime": false, "achievementAssignmentCondition": "ValueGreaterThanOrEqualTo", "achievementAssignmentConditionParameters": [ 0.20 ], "achievementAssignmentUnits": 10, "achievementAssignmentAssessmentLevel": "Individual" } 400 BAD REQUEST: (1) The given game period name not a valid period type (Only available: Quadrimester1, Quadrimester2); (2) The given achievement assignment condition name not a valid condition type (Only available: ValueGreaterThan, ValueLessThan, ValueEqualTo, ValueGreaterThanOrEqualTo, ValueLessThanOrEqualTo, ValueOutsideOfRange, ValueInsideOfRange); (3) The given number of achievement assignment condition parameters not the expected by the condition type; (4) The given achievement assignment assessment level name not a valid player type (Only available: Team, Individual). 404 NOT FOUND: (1) Game with the given subject acronym, course and period not found; (2) Evaluable action with the given id not found; (3) Achievement with the given id not found; (4) No date rule exists with the given Id. 409 CONFLICT: (1) Date rule name cannot be blank; (2) Date rule repetitions cannot be less than 1; (3) Date rule start date cannot be posterior to date rule end date. [Taula 31] Especificació PUT date rule. Font: Elaboració pròpia. Operació per consultar totes les assignatures definides: 113 Mètode Endpoint GET /api/subjects Respostes (application/json) Codi Descripció 200 OK: List of SubjectDTO objects [ { "acronym": "AMEP", "code": 340379, "name": "Ampliació a l’Enginyeria del Programari", "school": "340-EPSEVG", "studies": "340GREIN18" } ] [Taula 32] Especificació GET subjects. Font: Elaboració pròpia. Operació per crear una assignatura: Mètode Endpoint POST /api/subject Cos de la sol·licitud (multipart/form-data) Nom Tipus acronym String code Integer name String school String studies String Respostes (application/json) Codi Descripció 201 CREATED: SubjectDTO object { "acronym": "AMEP", "code": 340379, "name": "Ampliació a l’Enginyeria del Programari", "school": "340-EPSEVG", "studies": "340GREIN18" } 409 CONFLICT: (1) Subject acronym cannot be blank. (2) The given 114 subject acronym is already used. [Taula 33] Especificació POST subject. Font: Elaboració pròpia. 115 Annex B. Models conceptuals de la primera versió del GLiDE [Figura 47] Model conceptual de la gestió general. Font: [7] 116 [Figura 48] Model conceptual de la preparació de gamificació. Font: [7] 117 [Figura 49] Model Conceptual de l’Advanced Interaction. Font: [6] 118 Annex C. Repositoris de GitHub Repositori de l’Advanced Interaction Frontend: ● https://github.com/Learning-Dashboard/GLiDe-Frontend Repositori de l’Advanced Interaction Backend: ● https://github.com/Learning-Dashboard/GLiDe-Backend Repositori del Gamification Engine: ● https://github.com/Learning-Dashboard/GLiDe-Gamification-Engine Repositori de l’Admin Tool: ● https://github.com/Learning-Dashboard/GLiDe-Admin 119 Annex D. Manual per desplegar el GLiDE Instal·lació de Docker El primer pas per poder arrencar el GLiDE és instal·lar Docker, durant aquest projecte s’ha fet servir Docker Desktop que es pot trobar al següent enllaç: ● https://www.docker.com/ Simplement, fa falta executar l’instal·lador i seguir els passos que surten. En acabar això ja podem executar Docker Desktop. Creació de les credencials d’autorització El segon pas és crear les credencials d’autorització de Google. Les instruccions per aconseguir això són les següents: 1. Anar a la Google Cloud Platform Console (https://console.cloud.google.com/?hl=es). 2. Crear un nou projecte. 3. Anar a la pàgina APIs & services i seleccionar Credentials. 4. Crear una nova credencial OAuth client ID per aplicacions web. Després d’haver completat les instruccions podem aconseguir l’identificador del client OAuth, aquest ens farà falta més endavant. Descàrrega i configuració Per facilitar el desplegament s’ha creat un nou repositori a GitHub que inclou tot el codi del GLiDE, el fitxer docker-compose.yml i fitxers addicionals que permeten crear les bases de dades de l’Advanced Interaction Engine i el Gamification Engine. Senzillament, fa falta descarregar o clonar el següent repositori: ● GLiDE Deploy: https://github.com/SnappySM/GLiDe-Deploy Després hem d’anar al directori on es troba el codi i crear-hi un fitxer .env. En aquest definirem la contrasenya de la base de dades, l’identificador del client OAuth (que hem aconseguit en passos anteriors i, si volem poder utilitzar les funcionalitats d’IA generativa, el token de l’API d’OpenAI. Els continguts del .env han de tenir la següent forma: 120 DB_PASSWORD=contrasenya GOOGLE_CLIENT=id-client-oauth OPENAI_API_KEY=api-key-openai Posada en marxa Finalment, només fa falta obrir una consola al directori on es troba el codi i executar la comanda “docker compose up”, això engegarà tots els contenidors. Si obrim Docker Desktop veurem que tenim l’estructura de la figura 11, en aquest moment podrem utilitzar el GLiDE. [Figura 50] Contenidors funcionant a Docker Desktop. Font: Elaboració pròpia. 121