Creació d'un sistema SAAS per a votacions electròniques

id191841   CREACIÓ D'UN SISTEMA SAAS PER A VOTACIONS ELECTRÒNIQUES SARA MÉNDEZ BRAVO Director/a MARTACUATRECASASCAPDEVILA(UNIVERSITATPOLITÈCNICADECATALUNYA) Ponent:MANUELRELLOSALTOR(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  ´ Index 1 Context 10 1.1 Introducci´o ................................ 10 1.2 Definici´o del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3 Actorsimplicats.............................. 12 2 Justificaci´o 13 3 Abast 14 3.1 Objectius ................................. 14 3.2 Requisitsfuncionals............................ 15 3.3 Requisits no funcionals . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Riscos ................................... 18 4 An`alisi d’alternatives 21 4.1 Elecci´o del model de servei . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Tecnologies per al desenvolupament web . . . . . . . . . . . . . . . . 22 4.3 Plataformes per al metavers . . . . . . . . . . . . . . . . . . . . . . . 23 4.4 Conclusi´o ................................. 23 5 Especificaci´o de requisits 24 5.1 Casosd’´us................................. 24 5.1.1 Compra de votacions . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.2 Participaci´o en votacions . . . . . . . . . . . . . . . . . . . . . 27 5.2 Diagrama de classes d’especificaci´o . . . . . . . . . . . . . . . . . . . 31 5.2.1 Restriccions textuals . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.2 Descripci´o de les classes . . . . . . . . . . . . . . . . . . . . . 32 6 Disseny del sistema 37 6.1 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2 Arquitectura del Backend . . . . . . . . . . . . . . . . . . . . . . . . 39 6.3 Patrons de disseny utilitzats . . . . . . . . . . . . . . . . . . . . . . . 41 6.4 Dissenydelfrontend ........................... 43 6.4.1 Diagrames de Seq¨u`encia . . . . . . . . . . . . . . . . . . . . . 43 6.5 Integraci´o amb Minecraft . . . . . . . . . . . . . . . . . . . . . . . . . 46 7 Gesti´o del risc: Plans alternatius i obstacles 50 8 Planificaci´o 53 8.1 Canvis respecte a la planificaci´o inicial . . . . . . . . . . . . . . . . . 53 8.2 Justificaci´o dels canvis i planificaci´o definitiva . . . . . . . . . . . . . 53 8.3 Impacte en els objectius i desenvolupament del projecte . . . . . . . . 53 8.4 Impacte en els costos del projecte . . . . . . . . . . . . . . . . . . . . 54 8.5 Estat actual del projecte . . . . . . . . . . . . . . . . . . . . . . . . . 54 9 Metodologia i rigor 55 10 Pressupost 56 2 10.1 Cost de personal per activitat (CPA) . . . . . . . . . . . . . . . . . . 56 10.2Amortitzacions .............................. 58 10.3Costosgenerals .............................. 58 10.4Conting`encies ............................... 59 10.5Imprevistos ................................ 60 10.6 Estimaci´o dels costos . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.7Controldegesti´o ............................. 61 11 Informe de sostenibilitat 62 11.1 Dimensi´o econ`omica . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 11.2 Dimensi´o ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 11.3Dimensi´osocial .............................. 64 12 ` Arees legals i normatives rellevants 66 12.1 Protecci´o de dades personals . . . . . . . . . . . . . . . . . . . . . . . 66 12.2 Seguretat en els sistemes de pagament . . . . . . . . . . . . . . . . . 66 12.3 Drets d’autor i propietat intel·lectual ................. 66 12.4 Llei de serveis digitals i accessibilitat . . . . . . . . . . . . . . . . . . 67 12.5 Normativa sobre videojocs i entorns virtuals . . . . . . . . . . . . . . 67 13 Integraci´o de coneixements 68 13.1 Disseny i arquitectura del sistema . . . . . . . . . . . . . . . . . . . . 68 13.2 Desenvolupament Web i Backend . . . . . . . . . . . . . . . . . . . . 68 13.3 Enginyeria de Requisits i Gesti´o . . . . . . . . . . . . . . . . . . . . . 68 13.4 Integraci´o de Solucions Creatives . . . . . . . . . . . . . . . . . . . . 68 13.5 Projecte i Col·laboraci´o......................... 68 14 Conclusions 69 14.1 Assoliment dels objectius . . . . . . . . . . . . . . . . . . . . . . . . . 69 14.2Valoraci´opersonal ............................ 69 14.3Futuresampliacions............................ 70 15 Annex 71 15.1 Manual d’usuari pel Plugin Minecraft . . . . . . . . . . . . . . . . . . 71 15.1.1 Instal·laci´o de Minecraft . . . . . . . . . . . . . . . . . . . . 71 15.1.2 Configuraci´o del Plugin . . . . . . . . . . . . . . . . . . . . . . 73 15.1.3 Obtenci´o del Token . . . . . . . . . . . . . . . . . . . . . . . . 75 15.1.4InicideSessi´o........................... 76 15.1.5 Proc´es de Votaci´o . . . . . . . . . . . . . . . . . . . . . . . . . 77 15.1.6 Resultats de la Votaci´o . . . . . . . . . . . . . . . . . . . . . . 79 3 ´ Index de Figures 1 Casos d’´us del sistema. Elaboraci´o pr`opia. . . . . . . . . . . . . . . . 24 2 Diagrama de classes d’especificaci´o. . . . . . . . . . . . . . . . . . . . 31 3 Diagrama d’arquitectura. Font: TFG: Creaci´o de l’entorn d’autenticaci´o i gesti´o d’usuaris al sistema de votaci´o d’Ekratos en minecraft. . 38 4 Exemple d’´us del patr´o Promesa. Font: Elaboraci´o pr`opia. . . . . . . 42 5 Diagrama de seq¨u`encia per la compra d’un servei. Font: Elaboraci´o pr`opia.................................... 44 6 Captura de pantalla de la p`agina principal del projecte web. Font: Elaboraci´opr`opia. ............................ 45 7 Captura de pantalla elecci´o de pagament de la web. Font: Elaboraci´o pr`opia.................................... 45 8 Captura de pantalla informativa de la web. Font: Elaboraci´o pr`opia. . 46 9 Diagrama de l’arquitectura del plugin de Minecraft. Font: Elaboraci´o pr`opia.................................... 47 4 ´ Index de Taules 1 Facilitat d’´us. Font: Elaboraci´o pr`opia . . . . . . . . . . . . . . . . . 15 2 Escalabilitat i rendiment. Font: Elaboraci´o pr`opia . . . . . . . . . . . 16 3 Seguretat i privacitat. Font: Elaboraci´o pr`opia . . . . . . . . . . . . . 16 4 Fiabilitat i disponibilitat. Font: Elaboraci´o pr`opia . . . . . . . . . . . 17 5 Manteniment i suport. Font: Elaboraci´o pr`opia . . . . . . . . . . . . 17 6 Descripci´o cas d’´us CU1 (Elaboraci´o pr`opia). . . . . . . . . . . . . . . 25 7 Descripci´o cas d’´us CU2 - Seleccionar canvi d’idioma (Elaboraci´o pr`opia). 26 8 Descripci´o cas d’´us CU3 - Login a Minecraft (Elaboraci´o pr`opia). . . 27 9 Descripci´o cas d’´us CU4 - Votar dins de Minecraft (Elaboraci´o pr`opia). 28 10 Descripci´o cas d’´us CU5 - Veure resultats dins de Minecraft (Elaboraci´opr`opia). ................................ 29 11 Descripci´o cas d’´us CU6 - Logout de Minecraft (Elaboraci´o pr`opia). . 30 12 Costos de personal. Elaboraci´o pr`opia. . . . . . . . . . . . . . . . . . 56 13 Costos per activitat amb hores dedicades. Elaboraci´o pr`opia. . . . . . 57 14 Taula d’amortitzacions del hardware i software. Elaboraci´o pr`opia. . . 58 15 Taula de costos generals. Elaboraci´o pr`opia. . . . . . . . . . . . . . . 59 16 Taula d’imprevistos amb assignaci´o de rols. Elaboraci´o pr`opia . . . . 60 17 Pressupost total del projecte amb conting`encies. Elaboraci´o pr`opia . 60 5 Resum Aquest Treball de Final de Grau, desenvolupat en el marc del grau en Enginyeria Inform`atica a la Facultat d’Inform`atica de Barcelona (FIB), t´e com a objectiu el desenvolupament d’una plataforma SaaS per gestionar el proc´es de compra del servei de votacions electr`oniques de l’empresa ` Ekratos. El projecte combina una interf´ıcie intu¨ıtiva amb un sistema de pagaments integrat, mitjan¸cant PayPal i Stripe, per facilitar una experi`encia d’usuari eficient i segura. Addicionalment, la soluci´o explora la incorporaci´o de Minecraft com a metavers per expandir el servei, oferint una experi`encia immersiva que connecta els usuaris amb un entorn digital que els permet realitzar la votaci´o d’una manera m´es visual i intu¨ıtiva. 6 Resumen Este Trabajo de Final de Grado, desarrollado en el marco del grado en Ingenier´ıa Inform´atica en la Facultad de Inform´atica de Barcelona (FIB), tiene como objetivo el desarrollo de una plataforma SaaS para gestionar el proceso de compra del servicio de votaciones electr´onicas de la empresa ` Ekratos. El proyecto combina una interfaz intuitiva con un sistema de pagos integrado (mediante PayPal y Stripe) para facilitar una experiencia de usuario eficiente y segura. Adem´as, la soluci´on explora la incorporaci´on de Minecraft como metaverso para expandir el servicio, ofreciendo una experiencia inmersiva que conecta a los usuarios con un entorno digital que les permite realizar la votaci´on de una manera m´as visual e intuitiva. 7 Abstract This Final Degree Thesis, developed within the framework of the Computer Science degree at the Barcelona School of Informatics (FIB), aims to develop a SaaS platform to manage the purchase process of the electronic voting service offered by the company ` Ekratos. The project combines an intuitive user interface with an integrated payment system (via PayPal and Stripe) to ensure an efficient and secure user experience. Additionally, the solution explores the integration of Minecraft as a metaverse to expand the service, offering an immersive experience that connects users with a digital environment enabling them to vote in a more visual and intuitive way. 8 Agra¨ıments Primerament, vull expressar el meu agra¨ıment als directors d’aquest treball, la Marta Cuatrecasas i el Manuel Rello, pel seu suport i dedicaci´o durant totes les fases del projecte. La seva experi`encia i consells han estat claus per dur a terme aquesta feina amb `exit. Tamb´e vull agrair als meus companys de projecte, el Ricard Vi˜nas i el Lucas Valen, per la seva col·laboraci´o, esfor¸c i companyia al llarg d’aquest treball. Ha estat un plaer compartir aquesta experi`encia amb vosaltres. Voldria donar les gr`acies a tot l’equip de l’inLab FIB, per haver-me acollit. Treballar amb aquest equip m’ha perm`es cr´eixer tant a nivell professional com personal. Finalment, vull fer un reconeixement especial a la meva fam´ılia i amics, per sempre estar al meu costat, oferint-me el seu suport incondicional, especialment en els moments m´es intensos. Gr`acies per creure en mi i ajudar-me a arribar on s´oc avui. 9 •RNF2: Escalabilitat i rendiment N´umero Volere 6a Descripci´o El sistema ha de ser escalable per suportar un nombre creixent d’usuaris i a la vegada mantenir un bon rendiment. Justificaci´o S’ha de garantir que el sistema pugui gestionar increments en el nombre d’usuaris sense empitjorar la qualitat en l’experi`encia d’usuari. Condici´o de satisfacci´o Ha de suportar fins a 1000 usuaris concurrents.. M`etode de validaci´o Realitzar proves de c`arrega amb el m`axim nombre d’usuaris possibles simult`aniament. Taula 2: Escalabilitat i rendiment. Font: Elaboraci´o pr`opia •RNF3: Seguretat i privacitat N´umero Volere 9a Descripci´o S’han de protegir les dades personals i garantir la privacitat del vot. Justificaci´o La seguretat i la privacitat s´on requisits legals i `etics s’han de complir per protegir l’usuari en tot moment. Condici´o de satisfacci´o Assegurar l’anonimat dels vots. M`etode de validaci´o Proves de seguretat realitzades per l’equip d’´ Ekratos. Taula 3: Seguretat i privacitat. Font: Elaboraci´o pr`opia 16 •RNF4: Fiabilitat i disponibilitat N´umero Volere 5a Descripci´o Hem de proporcionar un sistema disponible durant tot el per´ıode de les votacions, sense interrupcions. Justificaci´o Les interrupcions podrien generar insatisfacci´o en els clients i p`erdua de confian¸ca en el sistema. Condici´o de satisfacci´o Garantir una disponibilitat del 99.9% durant les sessions de votaci´o. M`etode de validaci´o Monitoritzar la disponibilitat del sistema durant les proves. Taula 4: Fiabilitat i disponibilitat. Font: Elaboraci´o pr`opia •RNF5: Manteniment i suport N´umero Volere 7a Descripci´o S’ha de proporcionar un codi ben documentat per facilitar el manteniment i les futures actualitzacions. Justificaci´o Tenir una bona documentaci´o redueix el cost i el temps de manteniment i millores. Condici´o de satisfacci´o Proporcionar una documentaci´o actualitzada amb exemples i guies d’´us. M`etode de validaci´o Cal que tots els membres de l’equip de desenvolupament extern validin la claredat i la cobertura de la documentaci´o proporcionada. Taula 5: Manteniment i suport. Font: Elaboraci´o pr`opia 17 3.4 Riscos A continuaci´o, s’enumeren possibles riscos a l’hora de desenvolupar aquest projecte. La detecci´o proactiva dels riscos ens permetr`a implementar mesures de mitigaci´o adequades, assegurant que el projecte es mantingui dins dels terminis, pressupostos i requisits de qualitat establerts. Entre els riscos identificats, podem destacar els seg¨uents: RISC 001. Complicacions t`ecniques en la integraci´o amb ´ Ekratos •Descripci´o: Poden sorgir complicacions durant la integraci´o del sistema de votaci´o amb el sistema d’´ Ekratos, especialment si hi ha canvis inesperats en les seves API o infraestructura. •Probabilitat: Moderada. Tot i haver una comunicaci´o activa amb l’equip d’´ Ekratos, poden haver modificacions que no arribin a ser modificades. •Impacte: Una mala integraci´o pot provocar una mala experi`encia d’usuari i perdua de dades, a m´es d’enderrerir considerablement el projecte. Indicadors: Els indicadors principals que veuriem serien un augment en els errors HTTP quan el sistema accedeixi a l’API d’´ Ekratos i veuriem dades inconsistenst en el sistema. •Estrat`egies de prevenci´o: Una opci´o podria ser fer reunions peri`odiques amb l’equip d’´ Ekratos per parlar de qualsevol canvi realitzat. •Plans de mitigaci´o: Fer solucions provisionals, com modes de treball desconnectats, per assegurar el funcionament en cas de tenir problemes amb l’API. RISC 002: Vulnerabilitats de seguretat •Descripci´o: Existeix el risc de que les vulnerabilitats puguin ser explotades, aix`o podria comprometre les dades personals dels usuaris, els resultats de les votacions o el correcte funcionament del sistema. •Probabilitat: Moderada. Malgrat la implementaci´o de bones pr`actiques de seguretat, cap sistema ´es del tot immune a vulnerabilitats. •Impacte: Pot comportar una p`erdua de confian¸ca per part dels usuaris, sancions legals per incompliment de normatives de privadesa i la interrupci´o del servei. •Indicadors: Un indicador podria ser un augment dels intents d’acc´es no autoritzat registrats als logs del sistema. •Estrat`egies de prevenci´o: Es poden aplicar eines d’an`alisi de vulnerabilitats per identificar i solucionar vulnerabilitats abans que siguin explotades. •Plans de mitigaci´o: Es pot definir un pla de recuperaci´o que permeti restaurar el sistema a un estat operatiu. 18 RISC 003: Canvis en els requisits •Descripci´o: En el cas que ´ Ekratos modifiqui els requisits durant el desenvolupament del sistema de votaci´o, s’haurien de reestructurar els treballs ja realitzats, generant retards en el projecte i afectant la qualitat del producte final. •Probabilitat: Moderada. Tot i haver una planificaci´o inicial, les necessitats del client poden canviar en qualsevol moment, fent que haguem d’adaptar-nos a les nomes necessitats. •Impacte: La reestructuraci´o del projecte juntament amb afegir nous requisits pot provocar un enderriment dels temps de lliurament. •Indicadors: En aquest cas l’indicador seria la documentaci´o de canvis en els requisits per part d’´ Ekratos. •Estrat`egies de prevenci´o: La millor soluci´o seria mantenir una comunicaci´o regular amb l’equip d’´ Ekratos, amb reunions peri`odiques per estar al dia de qualsevol possiblecanvi en els requisits. •Plans de mitigaci´o: Abans d’aplicar canvis grans es poden desenvolupar prototips i fer proves de concepte, aix´ı validem la viabilitat dels nous requisits sense comprometre tot el projecte. RISC 004. Compatibilitat •Descripci´o: Pot haver problemes de compatibilitat entre el sistema de votaci´o i les diferents versions de Minecraft, o altres sistemes utilitzats per ´ Ekratos. •Probabilitat: Moderada-Alta. Pot haver alguna actualitzaci´o de Minecraft o d’altres sistemes i les difer`encies entre les versions poden generar incompatibilitats imprevistes. •Impacte: Pot provocar errors de funcionalitat en el sistema de votaci´o, afectant l’experi`encia d’usuari i la confian¸ca en el sistema. Pot provocar tamb´e un enderriment dels temps de lliurament per poder solucionar les incompatibilitats. •Indicadors: Aparici´o d’informes d’errors relacionats amb la compatibilitat a determinades funcionalitats en algunes versions de Minecraft. •Estrat`egies de prevenci´o: Tenir un control sobre les actualitzacions de Minecraft i altres sistemes que utilitzati ´ Ekratos per detectar canvis que afectin la compatibilitat. •Plans de mitigaci´o: Desenvolupar solucions provisionals o parches per garantir la continu¨ıtat del servei en les noves versions. 19 RISC 005. Qualitat del programari La pres`encia d’errors no detectats a temps pot afectar el funcionament del sistema, causant una mala experi`encia pels usuaris. •Descripci´o: La pres`encia d’errors o bugs no detectats a temps poden afectar negativament el funcionament del sistema, causant una mala experi`encia pels usuaris. •Probabilitat: Baixa. Tot i fer una revisi´o rigorosa durant el desenvolupament, en projectes amb certa complexitat t`ecnica poden haver incid`encies imprevistes. •Impacte: Aquests errors poden provocar una mala experi`encia d’usuari, decrement de confian¸ca i, fins i tot, la p`erdua de clients. •Indicadors: Alguns clars indicadors podrien ser augment en el nombre de queixes per part dels clients durant el proc´es de compra, o b´e, durant el proc´es de votaci´o. •Estrat`egies de prevenci´o: Es poden aplicar diverses opcions, una d’elles seria implementar proves unit`aries per testejar el codi, o b´e, realitzar proves d’usabilitat amb usuaris per aix´ı identificar els errors abans del llan¸cament. •Plans de mitigaci´o: La millor opci´o ´es definir un equip de resposta per corregir errors despr´es del desplegament. 20 4 An`alisi d’alternatives En aquest cap´ıtol s’analitzen les diferents alternatives tecnol`ogiques i estrat`egiques considerades durant el desenvolupament del projecte, i es justifiquen les decisions triades per garantir una bona soluci´o. 4.1 Elecci´o del model de servei Necessit`avem un model de servei que permet´es a ´ Ekratos oferir els seus serveis de votaci´o de manera accessible pels clients i sense comprometre la seguretat o la qualitat del sistema. •Alternatives considerades: – Model SaaS (Software as a Service): Proporciona serveis al n´uvol accessibles des de qualsevol dispositiu amb connexi´o a internet. ∗Punts forts: Acc´es f`acil idesde qualsevol dispositiu amb connexi´o a internet, t´e un cost inicial baix i facilita les futures actualitzacions i el seu manteniment. Menor cost inicial. ∗Punts febles: T´e certes limitacions en quant a la personalitzaci´o i customitzaci´o i, dep`en de que hi hagi acc´es a internet. – Model PaaS (Platform as a Service): ofereix una plataforma completa per al desenvolupament i desplegament d’aplicacions personalitzades. ∗Punts forts: Ofereix una millor personalitzaci´o d’aplicacions i ´es m´es flexible pel desenvolupament de solucions. ∗Punts febles: A llarg termini es pot necessitar m´es recursos i, per tant, ser m´es costosa. Tamb´e t´e una corba d’aprenentatge major per al desplegament i manteniment. •Opci´o adoptada: Es va escollir el model SaaS per la seva facilitat, pel seu menor cost inicial i perqu`e ens facilita les futures actualitzacions del sistema. Encara que el model PaaS hauria donat una major flexibilitat i ajustament, era menys atractiu a causa de la necessitat d’optimitzar costos i temps de desenvolupament. El model SaaS s’alinea m´es amb l’objectiu d’´ Ekratos de simplificar el proc´es pels usuaris, mentre que PaaS hauria requerit m´es recursos dedicats a la gesti´o de plataforma. 21 4.2 Tecnologies per al desenvolupament web Es necessitava una soluci´o per al desenvolupament de la interf´ıcie web que ens permet´es crear un sistema intu¨ıtiu, de f`acil manteniment i que no requer´ıs una gran corba d’aprenentatge. •Alternatives considerades: – Frameworks JavaScript (com Vue.js o React): frameworks moderns i potents per al desenvolupament del front-end amb funcionalitats avan¸cades. ∗Punts forts: Ens ofereixen funcionalitats avan¸cades per al desenvolupament, tenen tamb´e una gran comunitat i hi ha un bon suport per l’integraci´o. ∗Punts febles: Hi ha una corba d’aprenentatge i ´es necessita temps per dominar-los, aix`o pot portar complexitat al projecte. – Tecnologies cl`assiques (Node.js, HTML, CSS): enfocament minimalista i senzill que combina servidor i client sense necessitat d’utilitzar frameworks addicionals. ∗Punts forts: S´on una opci´o m´es senzilla i r`apida per a desenvolupar, no cal una formaci´o en noves tecnologies. ∗Punts febles: Proporciona menys flexibilitat a l’hora de crear interf´ıcies d’usuari, ´es limitant per a projectes m´es complexos. •Opci´o adoptada: Es va optar per desenvolupar l’interf´ıcie gr`afica amb els llenguatges de Node.js, HTML i CSS. Es va decidir aix`o per la seva implementaci´o m´es senzilla i perqu`e suposava menys temps de desenvolupament. Tot i que haver utilitzat els llenguatges de Vue.js i React hauria proporcionat una experi`encia m´es din`amica i potser m´es escalable a llarg termini, l’´us de tecnologies m´es cl`assiques ens ha permes un desplegament r`apid i sense necessitar una formaci´o en altres tecnolog´ıes. 22 4.3 Plataformes per al metavers Era necess`aria una plataforma immersiva i customitzable per integrar-hi el sistema de votacions d’´ Ekratos, fent possible que els usuaris votin des de la plataforma. •Alternatives considerades: – Minecraft: plataforma altament personalitzable, `ampliament coneguda i accessible. ∗Punts forts: Proporciona una gran flexibilitat i personalitzaci´o dels entorns, a m´es de ser una plataforma molt popular i amb una gran comunitat d’usuaris. El seu cost d’aprenentatge ´es m´es baix que el d’altres plataformes. ∗Punts febles: Te certes limitacions en casos molt complexes i pot semblar una plataforma ”menys seriosa”que altres. – Altres entorns virtuals (com Decentraland o Roblox): ofereixen entorns immersius, per`o amb limitacions t`ecniques i costoses integracions. ∗Punts forts: Donen grans possibilitats d’integraci´o amb funcionalitats complexes, a m´es de ser entrons immersius i moderns. ∗Punts febles: Augmenten el cost de desenvolupament, requereixen d’una especialitzaci´o pr`evia per poder treballar amb ells. •Opci´o adoptada: inalment, l’opci´o escollida va ser la d’utilitzar Minecraft. La decisi´o va ser impulsada principalment per l’empresa ´ Ekratos que per motius de m`arqueting ho van preferir, perqu`e ´es una plataforma molt popular i amb una base d’usuaris consolidada. Des d’una perspectiva t`ecnica, Minecraft ens oferia tamb´e moltes opcions de personalitzaci´o i flexibilitat a l’hora de dissenyar l’entorn virtual. L’equip de l’InLab vam optar per utilitzar la versi´o Java en comptes de la Bedrock perqu`e la versi´o Java ens permetia fer modificacions d’una manera m´es c`omoda. Per altra banda, les alternatives de Decentraland o Roblox tamb´e eren viables, per`o es va considerar que l’integraci´o seria m´es complexe i que el cost era major. 4.4 Conclusi´o Les decisions que s’han pres en aquest projecte, busquen sobretot simplificar el cost i ajustar els requisits. Tot i aix`o, s’ha de tenir en compte que en ser un projecte desenvolupat per a una altra empresa, ´ Ekratos, hi ha decisions que s’han hagut de prendre col·laborativament amb l’empresa, buscant un inter`es com´u. Aix`o inclou tant la selecci´o del model SaaS, com les tecnologies utilitzades pel desenvolupament, com l’elecci´o del videojoc de Minecraft com a plataforma per al metavers. Aquestes decisions han ajudat a ajustar el desenvolupament a les necessitats que requeria el client, assegurant que el resultat compleixi els seus objectius i requisits inicials. 23 5 Especificaci´o de requisits En aquest cap´ıtol presentem l’especificaci´o del sistema, incloent els casos d’´us, el diagrama de classes d’especificaci´o, les seves restriccions textuals i la descripci´o de les classes. 5.1 Casos d’´us Un cop analitzats els requisits funcionals i no funcionals, cal identificar i explicar els casos d’´us principals. Com podem veure a la seg¨uent figura, s’han trobat un total de sis. A continuaci´o s’expliquen cada un d’ells. Figura 1: Casos d’´us del sistema. Elaboraci´o pr`opia. 24 5.1.1 Compra de votacions Cas d’´ us CU1 - Registrar nova votaci´o Actor principal Comprador Disparador L’usuari vol adquirir el servei de votaci´o. Precondicions 1. L’usuari ha d’introduir les dades demanades (email, domini i nombre de participants). 2. El domini ha de ser ´unic i no prohibit. Escenari principal 1. L’usuari introdueix les dades necess`aries al formulari. 2. El sistema valida les dades introdu¨ıdes. 3. L’usuari selecciona el m`etode de pagament, pot ser PayPal o Stripe. 4. El sistema processa el pagament i confirma la compra. 5. El sistema avisa a l’API d’ekratos de la transacci´o, i el seu sistema ´es qui envia un correu electr`onic amb la informaci´o d’acc´es a la plataforma. Extensions 1a. Les dades introdu¨ıdes s´on incorrectes o incompletes: el sistema notifica l’error i permet correccions. 2a. El pagament falla: el sistema notifica l’error i ofereix reintentar l’operaci´o. Taula 6: Descripci´o cas d’´us CU1 (Elaboraci´o pr`opia). 25 5.2.1 Restriccions textuals Les seg¨uents restriccions asseguren la validesa del sistema: •RT1 - Els codis de descompte han de ser ´unics i no reutilitzables. •RT2 - Un codi de descompte nom´es pot ser aplicat si est`a actiu i no ha expirat. •RT3 - La data del pagament ha de ser posterior o igual a la data d’aplicaci´o del cup´o. •RT4 - Un cup´o nom´es es pot aplicar una vegada per pagament. •RT5 - Els pagaments s´on disjunts: un pagament ha de ser ´unicament de tipus PayPal o Stripe. •RT6 - Els compradors poden estar associats a m´ultiples pagaments, per`o cada pagament ha d’estar associat a un ´unic comprador. •RT7 - La opci´o d’un vot pertany a la votaci´o del mateix. •RT8 - El client que utilitza un codi es el mateix client que fa la compra. •RT9 - El preuFinal es calcula com a (preu * numParticipants) * (1 - descompte). •RT10 - numParticipants >= 1. •RT11 - 0 <descompte <1. 5.2.2 Descripci´o de les classes Per facilitar-ne la comprensi´o, el diagrama d’especificaci´o es divideix en dos blocs principals: •Votacions: Inclou les classes encarregades de representar i gestionar les votacions dins del sistema. •Entitats i pagaments: Blocs responsables de gestionar els pagaments associats a les votacions. 32 A continuaci´o, es presenta una descripci´o de les classes que formen el sistema, segons el diagrama UML anterior. Usuari En el sistema, la classe Usuari actua com la base per a representar una persona que interactua amb el sistema. Un usuari pot tenir diversos rols, depenent de la seva participaci´o dins del sistema. Els rols de Client iVotant s´on especialitzacions d’aquesta classe. El sistema ha de permetre que un usuari pugui ser client i Votant alhora, ja que una persona pot realitzar compres i participar en les votacions. Atributs clau: •El nom icorreu s´on necessaris per identificar i contactar amb l’usuari. Subclasses: •Client: Pot realitzar pagaments i comprar serveis. •Votant: Pot participar en les votacions. Permet escalabilitat del sistema, ja que els usuaris poden assumir m´ultiples rols al llarg del temps. Votaci´o La classe Votaci´o representa el proc´es principal del sistema. Aquesta classe ´es el punt de partida per a la participaci´o dels usuaris en el sistema de votaci´o. Atributs clau: •idVotaci´ o: Permet identificar la votaci´o. •data ini idata fi: Estableixen els l´ımits temporals dins els quals els usuaris poden participar en la votaci´o. •estat: Indica l’estat de la votaci´o, ´es a dir, si est`a oberta, tancada o finalitzada. Les relacions amb Opci´o iVotant garanteixen que cada votaci´o estigui formada per diverses opcions i que cada votant pugui registrar el seu vot en el sistema. La relaci´o amb Entitat mostra com aquestes estan composades per les votacions corresponents. A m´es, t´e dues relacions amb Votant per mostrar aquests dos aspectes: •Relaci´o amb els potencials votants: Inclou tots els usuaris que poden participar en la votaci´o. •Relaci´o amb els votants reals: Representa un subconjunt del conjunt anterior i nom´es inclou els votants que han em`es el seu vot. 33 Opci´o Les Opcions s´on una part clau del sistema, s´on els elements sobre els quals els votants prenen decisions. Aquestes opcions representen les respostes possibles a una votaci´o i estan associades a una votaci´o espec´ıfica. Relacions clau: •Cada Opci´o forma part d’una Votaci´o, els usuaris nom´es poden votar en les opcions disponibles dins d’una votaci´o. Entitat La classe Entitat representa el sistema de gesti´o de votacions adquirit pel client, ´es a dir, amb el sistema SaaS els clients poden adquirir una entitat. Aquesta entitat permet al client crear, gestionar i supervisar tots els processos de votaci´o que desitgin en una mateixa organitzaci´o, per`o aquestes funcionalitats es realitzen amb serveis d’´ Ekratos. Atributs clau: •El domini serveix com identificador de l’entitat, que facilita l’acc´es dins del sistema. A m´es, la relaci´o amb Votaci´o indica que una entitat pot gestionar diverses votacions, mentre que la relaci´o amb Votant implica que l’entitat pot tenir diversos usuaris participant en les votacions. Aix´ı les entitats no nom´es defineixen les votacions, sin´o que tamb´e faciliten el proc´es de participaci´o. Pagament Els Pagaments s´on necessaris per a la gesti´o econ`omica del sistema. Aquesta classe registra els pagaments realitzats pels usuaris. Les especialitzacions PagamentPaypal iPagamentStripe permeten adaptar el sistema a diferents m`etodes de pagament, permetent diverses opcions de pagament. Relacions clau: •Cada pagament est`a associat a una Compra, que a la vegada est`a associada a unClient, aix`o garanteix que les transaccions es registrin correctament i siguin atribu¨ıdes a la persona que ha realitzat el pagament. Client El Client ´es una subclasse de la classe Usuari, que es dedica a realitzar compres dins del sistema. Atributs clau: •Els atributs heretats de Usuari, com el nom i el correu, garanteixen la identificaci´o i comunicaci´o amb el client. A m´es, la relaci´o amb Entity desenvolupa en una classe anomenada Compra, que permet gestionar les transaccions realitzades. Aix`o facilita un seguiment prec´ıs de les interaccions financeres dins del sistema. 34 Compra La Compra representa una transacci´o que involucra un Client i una Entitat, establint la connexi´o entre el client que adquireix el sistema i l’organitzaci´o que gestiona les votacions. Aquesta classe recull informaci´o essencial per a gestionar i supervisar els processos d’adquisici´o dins del sistema. Atributs clau: •numParticipants (Integer): Nombre de participants que el client pot incloure en les votacions. •data ini (Date): Data d’inici de la compra, indicant quan comen¸ca el servei contractat. •data fi (Date): Data de finalitzaci´o de la compra, establint el per´ıode de validesa del servei. •preuFinal (Float): Import total de la compra, incloent-hi descomptes aplicats. Relacions clau: •Relaci´o amb Client: Cada Compra est`a associada a un ´unic client, indicant qui ha realitzat la transacci´o. •Relaci´o amb Entitat: La Compra est`a vinculada a una Entitat, representant el domini que el client ha adquirit. Permet gestionar les transaccions econ`omiques i el servei proporcionat, assegurant que els clients tinguin acc´es a les funcionalitats corresponents dins del per´ıode especificat. Cup´o El Cup´o representa un descompte que els Clients poden utilitzar per obtenir avantatges econ`omics en les seves compres. Atributs clau: •codi (String): Identificador ´unic del cup´o, que permet verificar la seva validesa i aplicaci´o. •descompte (Float): Quantitat que es descompta del preu final d’una compra. •data caducitat (Date): Data l´ımit per utilitzar el cup´o, establint la seva validesa temporal. Relacions clau: •Relaci´o amb Client: Un Cup´o pot ser utilitzat per un client, qui ´es beneficiat pel descompte en les seves transaccions. Aquesta relaci´o desenvolupa en la classe Cup´o utilitzat 35 Cup´o Utilitzat El Cup´o Utilitzat representa l’aplicaci´o d’un Cup´o per un Client en una transacci´o espec´ıfica. Aquesta classe assegura que els cupons nom´es es poden utilitzar dins dels l´ımits establerts. Atributs clau: •nom (String): Identificador del client que ha utilitzat el cup´o. •codi (String): Identificador del cup´o que ha estat utilitzat. •descompteAplicat (Float): Quantitat del descompte efectivament aplicat en la compra. Relacions clau: •Relaci´o amb Cup´o: Cada Cup´o Utilitzat est`a associat al cup´o original que va ser aplicat. •Relaci´o amb Compra: Un Cup´o Utilitzat est`a vinculat a una compra espec´ıfica, assegurant que el descompte s’apliqui correctament a la transacci´o. •Relaci´o amb Client: Permet identificar quin client ha utilitzat el cup´o en una compra concreta. Ens permet mantenir un registre detallat de com s’utilitzen els cupons en el sistema, assegurant la transpar`encia en la gesti´o dels descomptes. 36 6 Disseny del sistema Aquest apartat descriu el disseny del sistema, incloent-hi la seva arquitectura, els patrons de disseny implementats, i el disseny de la interf´ıcie gr`afica. 6.1 Arquitectura del sistema L’arquitectura del sistema es basa en el model client-servidor, on els elements clau s´on el plugin de Minecraft integrat amb un servei SaaS. Com s’ha dit, l’arquitectura del sistema es basa en el model client-servidor, que inclou diversos components essencials. En aquesta arquitectura, el Client Web ofereix una interf´ıcie gr`afica per a la interacci´o de l’usuari amb el sistema. El backend, en canvi, gestiona la l`ogica del sistema i s’encarrega de la comunicaci´o amb l’API d’´ Ekratos. A m´es, hi ha el plugin de Minecraft, que s’encarrega del processament d’esdeveniments dins del joc, enlla¸cant-lo amb la plataforma de votaci´o i assegurant la sincronitzaci´o d’esdeveniments en temps real. L’arquitectura client-servidor ´es un patr´o de disseny que distribueix les funcionalitats d’un sistema entre dos components principals: el client i el servidor. Aquest model separa les responsabilitats per millorar l’escalabilitat, la seguretat i el rendiment dels sistemes. Els protocols de comunicaci´o establerts entre el client i el servidor s´on HTTP o TCP/IP. Els components principals d’aquest model s´on: •Client: Aquest component ´es qui inicia la sol·licitud i interactua directament amb l’usuari. Pot prendre la forma tant d’una aplicaci´o m`obil com d’una interf´ıcie web. El client ´es qui sol·licita serveis o dades al servidor, les mostra a l’usuari i s’encarrega de que l’experi`encia d’usuari sigui bona. •Servidor: Aquest component ´es qui respon a les sol·licituds del client. Proporciona diferents recursos com serveis, dades o funcionalitats espec´ıfiques. Processa les peticions i retorna els resultats al client. Avantatges de l’Arquitectura Client-Servidor: L’arquitectura client-servidor ofereix diversos avantatges: •Descentralitzaci´o de responsabilitats: El client i el servidor tenen tasques separades. •Escalabilitat: Es poden afegir m´es clients o fer millores al servidor sense afectar el sistema global. •Seguretat: El servidor pot implementar mecanismes de seguretat com el control d’acc´es. •Mantenibilitat: El codi del client i el servidor es poden desenvolupar i mantenir per separat. •Interoperabilitat: El client pot interactuar amb diversos servidors. 37 Aplicaci´o en el Projecte: En aquest projecte, l’arquitectura client-servidor s’ha aplicat de la seg¨uent manera: El backend fa de servidor, aquest servidor ofereix serveis a dos tipus de clients: l’aplicaci´o web, que proporciona la interf´ıcie gr`afica a l’usuari, i el plugin de Minecraft, que gestiona els esdeveniments dins del joc. La comunicaci´o entre l’aplicaci´o web i el servidor s’ha dut a terme amb peticions HTTPS. El plugin de Minecraft, per la seva banda, envia dades i peticions al servidor, amb peticions HTTPS i mitjan¸cant WebSockets, aix`o ha permes la sincronitzaci´o d’esdeveniments en temps real. Figura 3: Diagrama d’arquitectura. Font: TFG: Creaci´o de l’entorn d’autenticaci´o i gesti´o d’usuaris al sistema de votaci´o d’Ekratos en minecraft. Aquesta arquitectura inclou els seg¨uents elements clau: •Client Web: ´ Es l’interf´ıcie gr`afica amb la qual interactuen els cliens que volen adquirir el servei de votaci´o. Les tecnologies utilitzades pel seu desenvolupament han estat: HTML, CSS, i Node.js. La seva funci´o ´es la de mostrar la informaci´o al client i gestionar les accions que aquest realitza. •Backend: ´ Es lencarregat de gestionar la l`ogica del sistema i la comunicaci´o amb l’API d’Ekratos. S’ha desenvolupat ´unicament amb el llenguatge de Node.js. ´ Es l’administrador del proc´es de les peticions que es reben del client web i del plugin de Minecraft i, a m´es, ha de gestionar les respostes pertinents. La comunicaci´o es realitza mitjan¸cant peticions HTTPS i WebSockets. En el backend es troben tamb´e les rutes per a les operacions relacionades amb el sistema de votaci´o, els pagaments i els codis de descompte. 38 •plugin de Minecraft: Un plugin de Minecraft ´es una extensi´o de programari que modifica o afegeix funcions i elements dins del joc en un servidor concret. Els plugins permeten ajustar regles dins del joc, controlar esdeveniments o integrar sistemes externs. El plugin de Minecraft ´es l’encarregat de gestionar els esdeveniments dins del joc de Minecraft. El plugin recull les dades dels esdeveniments que succeeixen dins del joc i les envia al backend, garantint aix´ı una sincronitzaci´o de les dades a temps real. 6.2 Arquitectura del Backend El backend ´es el nucli del sistema, com ja s’ha dit anteriorment, ´es l’encarregat del gestionament de la l`ogica de negoci, la comunicaci´o amb l’API d’´ Ekratos i el tractamnet de les peticions tant del client web com del plugin de Minecraft. El desenvolupament del backend est`a fet amb Node.js, s’ha aprofitat el seu entorn as´ıncron i basat en esdeveniments. Aix`o ha resultat molt ´util per tractar les peticions tant de la web com del plugin de Minecraft. El routing de Node.js ha estat fet amb Express.js [11], que ´es un framework que permet definir les rutes d’una manera senzilla. Parts principals del backend: •Voting Es tracta de les funcions per gestionar les votacions de Minecraft. S’encarrega del maneig de peticions HTTP que els usuaris poden realitzar interactuant amb el sistema i, a m´es, interactua amb la API d’´ Ekratos per enviar i validar els resultats de les votacions. •Ekratos S’encarrega de gestionar la creaci´o d’entitats, validar els cupons de descompte, i realitzar les operacions de verificaci´o de dades.. •Payments: ´ Es la part encarregada de la gesti´o de pagaments a trav´es de PayPal i Stripe, utilitzant directament l’API REST de cada una. Gestiona tamb´e els reemborsaments en cas que la compra no s’efectiu exitosament. Integraci´o amb Minecraft: El plugin de Minecraft interactua amb el backend sobretot amb peticions HTTP, aix`o ´es el que permet als usuaris participar en votacions directament des del joc. •Login El proc´es d’autenticaci´o es pot gestionar de dues maneres diferents. La primera verisi´o es la que va desenvolupar un company al seu TFG titulat: Creaci´o de l’entorn d’autenticaci´o i gesti´o d’usuaris al sistema de votaci´o d’´ Ekratos en Minecraft. Aquest treball, va fer possible que es gener´es un codi QR directament a Minecraft i aquest et portava a una web que ell havia creat per autenticar-se. Tot i que ara no fem servir aquest m`etode de la mateixa manera, ell va fer la l`ogica principal del login, ara s’ha adaptat perqu`e els usuaris puguin iniciar sessi´o directament utilitzant el token que obtenen a la plataforma d’´ Ekratos. •Votacions A trav´es de la ruta POST /vote el pluguin li envia al backend les dades de la votaci´o i ´es el backend qui interactua amb l’API d’´ Ekratos per enviar-li els resultats finals. 39 Rutes del Backend: El backend ofereix diversos punts d’acc´es per als clients, incloent el client web i el plugin. A continuaci´o es mostren algunes de les rutes principals: •GET /: Retorna un missatge per comprovar que el servidor est`a actiu. •GET /loadVoting: Carrega la configuraci´o i informaci´o inicial de la votaci´o. •GET /results: Retorna els resultats de la votaci´o. •POST /vote: Envia el resultat de la votaci´o escollit. •POST /reset: Restableix tot null els resultats de la votaci´o, ´es una funci´o de car`acter intern. •GET /cuponInfo: Valida i obt´e el descompte del codi de descompte introdu¨ıt pel client. •GET /checkEntityName: Comprova si el nom d’entitat introdu¨ıt pel client no est`a en us i si es v`alid. •GET /loginVoter: Permet l’inici de sessi´o dels votants. •POST /handleStripe: Gestiona les operacions del pagament amb Stripe. •GET /captureStripe: Captura els pagaments fets ambt Stripe. •POST /handlePaypal: Gestiona les operacions del pagament amb Paypal. •POST /capturePaypal: Captura els pagaments fets ambt Paypal. 40 6.3 Patrons de disseny utilitzats Per tal d’assegurar un codi reutilitzable i f`acil de mantenir, s’han aplicat diversos patrons de disseny, entre els quals destaquen: •Patr´o Factory: El patr´o Factory ´es un patr´o de disseny que permet crear objectes de manera flexible i encapsulada. En lloc de crear objectes directament a trav´es del constructor de la classe, el patr´o Factory utilitza una f`abrica per crear els objectes. Aquest patr´o ´es ´util quan la creaci´o d’objectes ´es complexa o dep`en de condicions, ja que permet centralitzar la l`ogica de creaci´o i evitar duplicacions de codi. Aquest patr´o s’ha fet servir per a la creaci´o dels m`etodes de pagament, permetent aix´ı diferents m`etodes de pagament sense necessitat de con`eixer els detalls de la seva implementaci´o. El client nom´es fa una sol·licitud, que s’encarrega de decidir quin tipus d’objecte crear segons les necessitats. Tot i que en el projecte no s’implementa un patr´o Factory complet amb una f`abrica centralitzada, el sistema segueix un enfocament semblant al Factory, ja que es decideix din`amicament quin objecte crear (per exemple, ‘paypalPaymentHandler‘ o ‘stripePaymentHandler‘) en funci´o de la ruta o tipus de sol·licitud. Aquest enfocament t´e diverses similituds amb el patr´o Factory: – Creaci´o d’objectes centralitzada: La l`ogica de creaci´o dels objectes es centralitza a les rutes, evitant la duplicaci´o de codi en diversos llocs. – Desacoblament de la l`ogica de creaci´o d’objectes: El client no necessita saber com es creen les inst`ancies, nom´es realitza una sol·licitud i el sistema decideix quin crear. – Facilitat d’ampliaci´o en el futur: Si en el futur es vol afegir un nou m`etode de pagament, nom´es cal crear un nou handler i actualitzar les rutes per incorporar-lo, sense haver de modificar el codi existent. Aquest enfocament encapsula la creaci´o dels objectes de pagament i segueix una estructura que permet afegir nous m`etodes de pagament en un futur, sense necessitat de modificar el codi existent, cosa que ´es una caracter´ıstica comuna en el patr´o Factory. •Patr´o Promesa: El patr´o Promesa s’utilitza per gestionar operacions as´ıncrones, permetent que les accions que poden trigar temps (com accedir a la base de dades o realitzar una crida a un servei extern) es realitzin sense bloquejar el flux de l’aplicaci´o. En lloc de bloquejar el programa mentre espera la resposta d’una operaci´o, el patr´o Promesa permet que el codi continu¨ı executant-se i que, una vegada l’operaci´o estigui completa, es gestioni el resultat. El patr´o Promesa s’utilitza per millorar l’experi`encia de l’usuari, ja que hi ha operacions (com la connexi´o amb serveis externs ) es gestionen de manera as´ıncrona. Aix`o permet a l’usuari rebre respostes immediates i continuar interactuant amb el sistema mentre espera el resultat de l’operaci´o. El codi mostrat a la figura ´es un exemple del patr´o Promesa en el meu codi, fet en Node.js. En aquest cas, el patr´o es manifesta mitjan¸cant l’´us de la 41 Descripci´o de les classes Les classes que apareixen de color vermell al diagrama anterior, s´on aquelles proporcionades per la API de Bukkit/Spigot [12], que ´es un entorn de desenvolupament per a Minecraft. Aquestes classes no han sigut creades per aquest projecte, per`o s´on necess`aries pel seu funcionament, ja que proporcionen les eines i els mecanismes necessaris per interactuar amb amb Minecraft. •Player: Representa els jugadors dins del plugin de Minecraft. Ens dona informaci´o sobre la seva ubicaci´o, el seu inventari i els elements amb els que interactua. •JavaPlugin: ´ Es una classe ”base”que defineix un plugin a l’entorn de Bukkit/Spigot. ´ Es la que ens permet inicialitzar, gestionar i registrar tots els esdeveniments dins del pluguin. •CommandExecutor: Aquesta interf´ıcie s’encarrega de la l`ogica dels comandaments personalitzats dins del pluguin. Aquesta interf´ıcie defineix com es gestionen les comandes que executen els jugadors. •Runnable: ´ Es una interf´ıcie de Java que s’utilitza per programar tasques en segon pla dins del plugin de Minecraft, utilitzant el programador intern de Bukkit/Spigot. La resta de classes del diagrama, s´on aquelles que s’han desenvolupat per tal de personalitzar al m`axim l’entorn de Minecraft i intergrar-ho amb el servei de votacions. •Plugin: Aquesta ´es la classe principal del plugin, s’encarrega de la inicialitzaci´o, configuraci´o i finalitzaci´o del sistema. Gestiona els esdeveniments del joc i delegar tasques a les altres classes, com ara a VotingDelegate iMinecraftDelegate. •VotingDelegate: ´ Es on es gestionen les votacions dins del plugin. S’encarrega de la creaci´o i tancament de sessions de votaci´o, aix´ı com el registre dels vots. •MinecraftDelegate: ´ Es qui gestiona tot l’entorn de votaci´o dins del joc. Realitza funcions com crear els espais, detectar les interaccions i actualitzar les dades que veu l’usuari. •VotingSession: Representa una sessi´o de votaci´o. Defineix els detalls de cada sessi´o, incloent les opcions disponibles i els botons associats a cada opci´o, s’encarrega tamb´e del control del proc´es de votaci´o en temps real. •Poll: Modela una votaci´o, te informaci´o com les opcions de vot, les seves descripcions i si es permet o no la selecci´o m´ultiple. Actua com a contenidor de dades per a cada proc´es de votaci´o. •PollResults: S’encarrega d’emmagatzemar i consultar els resultats de les votacions. ´ Es necess`aria per obtenir informaci´o sobre els vots i per visualitzar els resultats de les votacions. 48 •PlayerManager: Representa els jugadors dins del sistema i permet gestionar el seu estat d’autenticaci´o i participaci´o en les votacions. Aquesta classe ´es necessaria per controlar l’estat del jugador, ´es a dir si est`a autenticat o no autenticat i per saber si ja ha votat o no ha votat. •VotingExecutor: Executa accions relacionades amb les votacions, com ara carregar votacions existents o emetre vots. Fa m´es senzill l’acc´es a funcionalitats concretes del sistema. •CommandHandler: Gestiona els comandaments que pot introdu¨ır un jugador al xat del joc. Aquests comandaments permeten accions com per exemple l’inici de sessi´o al sistema . •Runner: Fa tasques que s’executen en segon pla dins del servidor. 49 7 Gesti´o del risc: Plans alternatius i obstacles ´ Es necess`aria una bona gesti´o dels riscos per assegurar que el projecte sigui exit´os. En el punt 3.4 s’han identificat i analitzat els principals riscos del projecte. A continuaci´o, es detallen aquests riscos juntament amb l’impacte que podrien tenir sobre el projecte, els m`etodes de prevenci´o que es poden fer servir, alternatives proposades i quins m`etodes de mitigaci´o seguir si arriben a oc´orrer. Risc 1: Complicacions t`ecniques en la integraci´o amb ´ Ekratos Prevenci´o: Per prevenir aquest risc ´es necessari que es revisi la documentaci´o disponible dels serveis externs, que hi hagi establer un pla d’integraci´o amb fites concretes i buscar a experts amb qui contactar en cas que hi hagi problemes amb algun dels serveis externs. Mitigaci´o: Una manera de mitigar aquest problema seria fent una soluci´o temporal que simul´es el funcionamnet correcte mente se solucionen els problemes real. Es podria prioritzar algun dels serveis per davant dels altres, i aix´ı assegurar que part de la funcionalitat es compleixi. Alternativa: Si es detecta que la integraci´o amb ´ Ekratos no ´es viable en el temps previst, es podria crear una API pr`opia que simuli les funcionalitats de l’API d’´ Ekratos, aix`o permetria continuar amb el desenvolupament sistema sense dependre. Impacte en la duraci´o: Si no es prenen mesures, aquest risc podria endarrerir el projecte fins a 2 setmanes. Amb la soluci´o temporal, es reduiria a menys d’una setmana. Risc 2: Vulnerabilitats de seguretat Prevenci´o: Una manerda de prevenir vulnerabilitats en la seguretat ´es fent auditories de seguretat amb un equip exper, aplicant millors pr`actiques en la codificaci´o de la informaci´o sensible i fent us de protocols segurs per la transmissi´o de dades, fins i tot es podrien aplicar configuracions de tallafocs espec´ıfiques per al sistema. Mitigaci´o: Un cop detecat aquest risc, algunes opcions per mitigar-ho serien posar el sistema en mode de manteniment per limitar els accessos dels clients mentre s’apliquen les correccions necess`aries. L’altre opci´o seria tenir c`opies de seguretat per poder restaurar les dades en cas de p`erdua o manipulaci´o. Alternativa: Si arriben a haver vulnerabilitats greus, es poden desactivar les funcionalitats afectades o b´e, habilitar un mode de treball offline i aix´ı evitar que l’acc´es remot sigui un risc. Impacte en la duraci´o: Si no es prenen mesures de mitigaci´o, un atac podria comportar una inactivitat del sistema durant 1-2 setmanes. En canvi, amb les accions de mitigaci´o, aquest temps d’inactivitat es podria reduir a menys de 48 hores. 50 Risc 3: Canvis en els requisits Prevenci´o: Els canvis inesperats en els requisits no es poden preveure com a tal per`o, amb una comunicaci´o constant amb l’equip ´ Ekratos es pot assegurar l’alineaci´o sobre els requisits. Tamb´e es pot establir des del principi un document amb els requisits especificats i formalitzar un proc´es d’aprovaci´o per a qualsevol canvi en aquests. Mitigaci´o: En el cas que hi hagi canvis en els requisits, ´es important prioritzar els nous requisits en funci´o de la seva import`ancia i implementar-los en futures fases de desenvolupament per tal de no interrompre l’actual. Alternativa: Davant d’un canvi important en els requisits, es podria desenvolupar la nova funcionalitat en una branca independent, aix´ı es pot desevnvolupar sense afectar tot sistema i evitanr haver de redissenyar el projecte de nou. Impacte en la duraci´o: Canvis tan grans sense gestionar poden provocar un endarreriment de fins a 3 setmanes, si es prenen les mesures de mitigaci´o aix`o podria arribar a reduir-se a nom´es 1. Risc 4: Compatibilitat Prevenci´o: Per preveure problemes en la compatibilitat s’han d’anar controlant les actualitzacions de Minecraft i d’altres eines externes utilitzades. Fer proves amb les altres versions existens i detectar possibles errors a temps. Mitigaci´o: Un cop detectats problemes de compatibilitats una manera de mitigarho seria implementant solucions provisionals per garantir la funcionalitat del sistema en les noves versions. Tamb´e es pot establir una pol´ıtica de compatibilitat limitada i seleccionar amb quines versions funcionar`a el servei. Alternativa: En cas de tenir problemes de compatibilitat amb sistemes externs, es pot implementar una capa d’abstracci´o que gestioni les difer`encies entre versions i garantir que el sistema funcioni mentre es desenvolupen les adaptacions necess`aries per a les altres versions. Impacte en la duraci´o: Els problemes de compatibilitat podrien provocar un endarreriment de fins a 2 setmanes. Aplicant els plans de mitigaci´o aix`o es podria convertir en uns 3-5 dies. 51 Risc 5: Qualitat del programari Prevenci´o: Per preveure que tot el programari ´es de qualitat es poden fer proves unit`aries i proves d’usabilitat regulars per assegurar que el codi ´es funcional i no te carencies. Que l’equip faci revisions de codi per identificar possibles errors abans del desplegament tamb´e ´es una bona opci´o. Mitigaci´o: Per mitigar possibles errors despr´es del llan¸cament, s’hauria de mantenir un equip de resposta r`apida per aplicar solucions i actualitzacions necess`aries. Alternativa: Si abans del llan¸cament es detecta una baixa qualitat del programari, es pot optar com alternativa per fer unllan¸cament gradual, ´es a dir, fer una versi´o beta per un grup limitat d’usuaris, que ens ajudi a recollir feedback i solucionar errors abans del desplegament complet. Impacte en la duraci´o: Aquest ris podria provocar un retard de fins a 3 setmanes. Si s’apliquen els m`etodes de mitigaci´o i hi ha un equip de resposta, es podrien resoldre en menys d’una setmana. Amb aquesta planificaci´o detallada de la gesti´o de riscos i les seves possibles solucions, s’intenta reduir al m`axim l’impacte negatiu en el desenvolupament del projecte i garantir que es compleixin els objectius dins dels terminis establerts. 52 8 Planificaci´o El projecte va comen¸car amb una planificaci´o inicial que servia com a guia general per al desenvolupament de les diferents fases. Tot i aix`o, al llarg del proc´es s’han produ¨ıt diversos ajustaments per tal d’adaptar-se a necessitats canviants. A continuaci´o, s’analitzen aquests canvis, la justificaci´o de les decisions adoptades i les implicacions resultants: 8.1 Canvis respecte a la planificaci´o inicial •Increment d’hores dedicades a la revisi´o i correcci´o de la mem`oria: La planificaci´o inicial estimava 20 hores per a aquesta tasca. No obstant aix`o, despr´es de l’experi`encia adquirida durant el desenvolupament, es va decidir augmentar-ne la dedicaci´o a 25 hores per garantir un contingut de qualitat. •Reducci´o de temps en tasques de desenvolupament relacionades amb el backend del SaaS: Gr`acies a l’´us de biblioteques i frameworks optimitzats, com la llibreria SweetAlert[13] per als pop-ups, es va simplificar el disseny d’interf´ıcies i es va aconseguir reduir el temps inicialment previst per a certes funcionalitats, ajustant la planificaci´o sense comprometre la qualitat. •Canvi en el calendari de lliurament d’algunes tasques: Per tal de complir amb prioritats establertes per ´ Ekratos, algunes tasques es van reordenar, especialment aquelles relacionades amb la integraci´o amb l’API d’´ Ekratos i les proves finals. 8.2 Justificaci´o dels canvis i planificaci´o definitiva Els canvis realitzats responen a: •La necessitat de garantir la qualitat del lliurament final, prioritzant la documentaci´o i les proves. •La metodologia de treball `agil, ha perm`es redistribuir les hores d’algunes tasques sense afectar l’abast ni els objectius. •Les sol·licituds espec´ıfiques del client, ´ Ekratos, que han influit en l’ordre de prioritat d’algunes funcionalitats. 8.3 Impacte en els objectius i desenvolupament del projecte Els ajustaments no han alterat els objectius generals del projecte, sin´o que han perm`es alinear-lo millor amb les necessitats del client i amb els est`andards esperats. El desenvolupament s’ha beneficiat d’una gesti´o flexible, cosa que ha perm`es abordar les desviacions en temps. 53 8.4 Impacte en els costos del projecte L’increment d’hores en algunes tasques, com la revisi´o de la mem`oria, i la reassignaci´o d’hores d’altres tasques han tingut un impacte m´ınim en els costos globals del projecte. Aix`o s’ha degut a una optimitzaci´o general del temps i l’´us de recursos sense necessitat d’augmentar significativament les hores totals dedicades. 8.5 Estat actual del projecte El projecte es troba en la fase final de proves i validaci´o, amb les principals funcionalitats ja implementades, tamb´e s’est`a finalitzant la redacci´o de la mem`oria. Aix`o indica que es compleix amb el calendari previst, amb marge suficient per abordar possibles ajustaments finals abans de l’entrega final. 54 9 Metodologia i rigor Per al desenvolupament d’aquest projecte, s’ha adoptat la metodologia `agil, un enfocament que permet adaptar-se de manera eficient als canvis i garantir que el producte final s’ajusti als requisits. Aquesta metodologia ´es especialment adequada per a projectes com aquest, on els requisits poden evolucionar al llarg del temps. Durant la carrera s’han estudiat metodologies `agils com Scrum [14] i Kanban [15], i en aquest projecte s’ha optat per una combinaci´o d’ambdues. Utilitzem un sistema de gesti´o visual per organitzar les tasques i el flux de treball, optant per Trello [16] com a eina principal per crear un taulell Kanban. Aquesta opci´o ens facilita veure quin ´es l’estat de cada tasca, ajudant-nos a prioritzar funcionalitats i a mantenir un seguiment continu del progr´es. Pel que fa a la comunicaci´o interna, s’ha optat per utilitzar Slack [17], una plataforma que promou un entorn professional i sense distraccions, facilitant aix´ı la col·laboraci´o entre els membres de l’equip. A m´es, utilitzem GitHub [18] com a sistema de control de versions per gestionar el codi de manera col·laborativa. A trav´es d’aquestes eines, el projecte es desenvolupa amb un enfocament iteratiu i incremental, amb revisi´o constant del progr´es i adaptaci´o dels objectius a mesura que avanci el treball. 55 10 Pressupost Aquest cap´ıtol t´e com a objectiu analitzar els costos associats al desenvolupament d’aquest projecte. En primer lloc, es proporcionaran els costos propis de les activitats realitzades, despr´es s’afegiran els costos dels recursos materials necessaris per al projecte, i, finalment, el resultat del c`alcul de les amortitzacions, conting`encies i imprevistos. 10.1 Cost de personal per activitat (CPA) Per determinar el cost de realitzar les activitats proposades, cal con`eixer el sou de cada membre de l’equip i la seva participaci´o en el projecte. El sou mitj`a de cada rol s’ha obtingut a partir de la p`agina Glassdoor[19]. El cost total s’ha calculat tenint en compte 220 dies laborables a l’any i 8 hores di`aries, la qual cosa implica un total de 1760 hores a l’any. S’ha afegit un 30% al sou brut per a la cotitzaci´o a la Seguretat Social. Rol Sou anual brut (€) Hores dedicades Cap del projecte 60.000 70 Desenvolupador 28.000 310 Dissenyador UI/UX 30.000 50 Arquitecte 38.000 20 Total 450 Taula 12: Costos de personal. Elaboraci´o pr`opia. A continuaci´o, es presenta el pressupost detallat per a cada tasca. L’import associat a cada tasca s’ha calculat multiplicant el nombre d’hores dedicades per cada professional pel cost per hora, incloent-hi la contribuci´o a la Seguretat Social. 56 Codi Activitat Hores dedicades (h) Cost per hora (€) Cost total (€) TRI1 Investigaci´o sobre votacions digitals i sistemes de pagament 20 15,91 318,20 TRI2 An`alisi del metavers 20 15,91 318,20 TG1 Definici´o de l’abast i contextualitzaci´o del projecte 25 34,09 852,25 TG2 Planificaci´o temporal i diagrama de Gantt 20 34,09 681,80 TD1 Disseny de l’arquitectura i creaci´o del backend del SaaS 50 15,91 795,50 TD2 Implementaci´o de les funcionalitats de pagament 40 15,91 636,40 TD3 Creaci´o de les interf´ıcies d’usuari (UI) per al SaaS 50 17,05 852,50 TD4 Disseny de l’arquitectura del servidor de Minecraft 20 21,63 432,60 TD5.1 Creaci´o del m´on de Minecraft 15 15,91 238,65 TD5.2 Creaci´o de les sales de votaci´o 15 15,91 238,65 TD5.3 Configuraci´o del servidor de Minecraft 15 15,91 238,65 TD6 Integraci´o amb l’API d’´ Ekratos 20 15,91 318,20 TD7 Proves i validaci´o del sistema 40 15,91 636,40 RM1 Documentaci´o del projecte 50 15,91 795,50 RM2 Revisi´o i correcci´o de la mem`oria 25 34,09 852,25 RM3 Preparaci´o de la defensa del TFG 25 15,91 397,75 Total 450 8.603,2 Taula 13: Costos per activitat amb hores dedicades. Elaboraci´o pr`opia. 57 El projecte permetr`a reduir l’´us d’altres recursos? Globalment, l’´us del projecte millorar`a o empitjorar`a l’empremta ecol`ogica? Com s’ha comentat anteriorment, permetr`a reduir l’´us de recursos f´ısics com paper, tinta, etc. Podem dir que sistema digital millorar`a l’empremta ecol`ogica, ja que reduir`a les emissions de gasos contaminants relacionats amb el transport de la poblaci´o. Es podrien produir escenaris que fessin augmentar l’empremta ecol`ogica del projecte? No s’ha considerat cap possible escenari con augmenti l’empremta ecol`ogica del projecte. 11.3 Dimensi´o social Que creus que t’ha aportat a nivell personal la realitzaci´o d’aquest projecte? A nivell personal, la realitzaci´o d’aquest projecte m’ha aportat moltes coses positives. M’ha donat l’oportunitat de desenvolupar habilitats en la planificaci´o de projectes i he posat en pr`actica compet`encies com el treball en equip, la comunicaci´o i el comprom´ıs. A m´es, ha estat una experi`encia que m’ha ajudat a aprnedre i creixer com a futura enginyera inform`atica. Com es resol actualment el problema que vols afrontar (estat de l’art)? En qu`e millora socialment (qualitat de vida) la teva soluci´o respecte a la existents? Aquest projecte resol sobretot els requisits de l’empresa ´ Ekratos, tot i aix`o, s’han detectat alguns aspectes socials on pot ser realment ´util. Actualment, les votacions tradicionals poden excloure certs col·lectius, com persones amb mobilitat redu¨ıda o aquelles que viuen en zones remotes. El projecte ajuda en aquests casos reduint les barreres f´ısiques, permet que m´es persones puguin participar facilitant el proc´es. Existeix una necessitat real del projecte? Realment no respon a un problema de vital import`ancia per`o permet al client facilitar el proc´es de compra dels seus serveis i dona una eina innovadora per realitzar les votacions. La realitzaci´o d’aquest projecte ha implicat reflexions significatives a nivell personal, professional o `etic de les persones que hi han intervingut? S´ı, la realitzaci´o del projecte m’ha fet reflexionar a nivell professional, m’ha fet con`eixer noves t`ecniques i posar-les en pr`actica i, a m´es, m’ha ajudat a saber cap a on vull enfocar una mica millor el meu futur professional. Qui es beneficiar`a de l’´us del projecte? Hi ha algun col·lectiu que pot veure’s perjudicat pel projecte? En quina mesura? Els principals beneficiaris d’aquest projecte seran els clients d’ekratos i l’entitat en si. Pel que fa als col·lectius perjudicats, s’ha de tenir en compte la bretxa digital, hi ha persones que encara no tenen acc´es a aquestes tecnologies, aix`o fa que no puguin beneficir-se d’aquest servei. 64 En quina mesura soluciona el projecte el problema plantejat inicialment? Com s’ha anat esmentant, projecte ha solucionat exitosament els requisits demanats pel client i s’han solucionat amb `exit tots els reptes que s’han anat trobant. Podrien produir-se escenaris que facin que el projecte sigui perjudicial per a algun segment particular de la poblaci´o? Com el projecte ´es per a una entitat i no ´es un projecte que s’hagi d’incorporar de manera global no es considera cap escenari on el projecte sigui perjudicial per part de la poblaci´o. El projecte podria crear algun tipus de depend`encia que deixes els usuaris en posici´o de debilitat? No, el projecte no genera cap tipus de denepd`encia depend`encia, l’objectiu ´es oferir una eina complement`aria per enriquir el servei que ofereix ´ Ekratos. No obstant, ´es important que hi hagi opcions alternatives per a qui no puguin accedir al sistema digital. 65 12 ` Arees legals i normatives rellevants Aquest cap´ıtol t´e com a objectiu analitzar les `arees legals i normatives que s’han de considerar per garantir que el projecte compleixi amb les regulacions vigents. 12.1 Protecci´o de dades personals •Normativa aplicable: Reglament General de Protecci´o de Dades a la Uni´o Europea [20]. •Requisits: –Obtenir el consentiment dels usuaris per a la recollida i processament de dades. –Assegurar el tractament segur i confidencial de les dades personals. –Permetre als usuaris accedir, rectificar o eliminar les seves dades. •Compliment per part del projecte: El projecte garantir`a que qualsevol dada personal recollida (com informaci´o d’usuari del servidor de Minecraft o del sistema de pagament) compleix amb la normativa GDPR. 12.2 Seguretat en els sistemes de pagament •Normativa aplicable: Directiva de Serveis de Pagament 2 a la UE [21]. •Requisits: –Implementaci´o de l’Autenticaci´o Forta de Client (SCA) per a transaccions en l´ınia. –Complir amb est`andards com PCI DSS (Payment Card Industry Data Security Standard). •Compliment per part del projecte: El sistema garantir`a transaccions segures i protegir`a dades banc`aries dels usuaris. 12.3 Drets d’autor i propietat intel·lectual •Normativa aplicable: Llei de propietat intel·lectual[22] (en l’`ambit nacional i europeu). •Requisits: –Respectar els drets d’autor de qualsevol eina o plataforma utilitzada, com ara Minecraft i APIs de tercers. –Obtenir les llic`encies necess`aries per a ´us comercial o educatiu del servidor de Minecraft. •Compliment per part del projecte: Es verificar`a que l’´us de Minecraft i altres eines est`a cobert per les llic`encies pertinents. 66 12.4 Llei de serveis digitals i accessibilitat •Normativa aplicable: Directiva sobre Accessibilitat Web i regulacions similars [23]. •Requisits: –Garantir que les interf´ıcies web i el sistema SaaS siguin accessibles per a persones amb discapacitat. •Compliment per part del projecte: Es treballar`a per implementar bones pr`actiques d’accessibilitat, com etiquetes alt per a imatges i navegaci´o amb teclat. 12.5 Normativa sobre videojocs i entorns virtuals •Normativa aplicable: Reglamentacions espec´ıfiques per a videojocs i interaccions virtuals en funci´o del pa´ıs[24]. •Compliment per part del projecte: Es garantir`a que no es vulneren lleis sobre continguts, privacitat o seguretat en un entorn virtual. 67 13 Integraci´o de coneixements El desenvolupament d’aquest projecte m’ha fet a posar en com´u els coneixements de diverses disciplines de l’enginyeria de software, reflectint els principis i t`ecniques que he apr´es durant la carrera. A continuaci´o, es detallen com s’han aplicat aquests conceptes: 13.1 Disseny i arquitectura del sistema Durant el desenvolupament del backend aix´ı com les diferents interf´ıcies d’usuari, s’han aplicat tecnologies senzilles per`o efectives com Node.js, HTML i CSS. La tria d’aquetes tecnologies va ser clau per a la comunicaci´o client i servidor, aix´ı com per a mantenir una arquitectura clara i modular. Els conceptes apr´esos a l’assignatura de ASW van ser claus per la identificaci´o de components independents i la seva integraci´o, permetent una implementaci´o cohesionada i escalable. 13.2 Desenvolupament Web i Backend En el desenvolupament del backend i les interf´ıcies d’usuari, es van aplicar tecnologies senzilles per`o efectives com Node.js, HTML i CSS. Aquesta elecci´o tecnol`ogica reflecteix els conceptes adquirits a Aplicacions i Serveis Web (ASW), que han estat essencials per assegurar una comunicaci´o eficient entre el client i el servidor. 13.3 Enginyeria de Requisits i Gesti´o La definici´o dels objectius i necessitats del projecte es va realitzar seguint els principis d’Enginyeria de Requisits (ER), on vaig aprendre a recollir, prioritzar i validar requisits funcionals i no funcionals. A m´es, l’organitzaci´o i supervisi´o del projecte s’han basat en les metodologies `agils apreses a Gesti´o de Projectes de Software (GPS), que han perm`es ajustar les tasques segons les prioritats d’´ Ekratos. 13.4 Integraci´o de Solucions Creatives Durant el desenvolupament, es van aplicar solucions innovadores, com l’elecci´o de Minecraft com a plataforma per al metavers es va basar en la seva flexibilitat i accessibilitat, reflectint una aproximaci´o pragm`atica i creativa. 13.5 Projecte i Col·laboraci´o El projecte ha actuat com una s´ıntesi pr`actica de les compet`encies adquirides a l’assignatura Projecte d’Enginyeria del Software (PES). La col·laboraci´o amb ´ Ekratos ha sigut un aspecte destacat, exigint adaptabilitat i una gesti´o rigorosa dels recursos per alinear-nos amb les seves necessitats i expectatives. 68 14 Conclusions En aquest ´ultim cap´ıtol ser`a valorada la feina realitzada durant aquest projecte i es revisar`a l’assoliment dels objectius plantejats inicialment. Tamb´e hi haur`a una valoraci´o personal sobre l’experi`encia de desenvolupar aquest projecte i es plantejaran possibles ampliacions per a futures actualitzacions. 14.1 Assoliment dels objectius Els objectius principals d’aquest projecte eren crear una plataforma SaaS que permet´es als clients d’´ Ekratos accedir als serveis de votaci´o i desenvolupar un pluguin que integr´es el sistema de votaci´o al videojoc de Minecraft. El sistema SaaS ha estat un `exit, ofereix una interf´ıcie d’usuari intu¨ıtiva, s’han integrat els sistemes de pagament i s’ha integrat correctament amb l’API d’´ Ekratos. Per tant, no nom´es s’ha simplificat el proc´es de compra del servei de votacions electr`oniques d’´ Ekratos, sin´o que tambe s’ofereix una millor experi`encia pels clients. L’implementaci´o del plugin de Minecraft ha estat un altre `exit. El pluguin permet als usuaris participar en votacions directament dins del joc, aix`o augmenta l’atractiu del servei i ajuda a ´ Ekratos a assolir el seu objectiu d’aarribar a un p´ublic m´es jove. Tot i que el projecte no ha pogut ser testat amb grans quantitats d’usuaris, s’han complert els requisits inicials establerts per l’empresa, aix´ı que podem considerar que fins el moment el projecte ha estat un `exit. 14.2 Valoraci´o personal Des del punt de vista de l’autora aquest projecte ha sigut molt enriquidor. Treballar en un projecte real, amb un client i uns requisits, ha perm`es posar en pr`actica els coneixements adquirits durant el grau. El desenvolupament del SaaS i el plugin de Minecraft ha sigut un repte t`ecnic que s’ha resolt amb solucions creatives, i ha sigut una oportunitat de treballar amb tecnologies modernes com Node.js, HTML, CSS i Java en el cas de Minecraft. Tamb´e s’ha tingut l’oportunitat de treballar en un equip amb grans professionals i companys dels quals s’ha apr`es molt, no nom´es des del punt de vista t`ecnic sin´o tamb´e sobre la gesti´o de projectes i treball en equip. 69 14.3 Futures ampliacions Encara que el sistema actual compleix amb els requisits, encara pot ser millorat o b´e ampliat en el futur: •Ampliaci´o del sistema SaaS: Es podrien afegir noves funcionalitats al SaaS, com per exemple, podr´ıa ser integrat amb la seva plataforma de gesti´o del servei de votacions, febt-ho encara m´es intuitiu i senzill pel client. •Exploraci´o d’altres metaversos: Inicialment es va plantejar adaptar les funcionalitats de minecraft a altres plataformes. Actalment nom´es esta adaptat a la versi´o Java de Minecraft, per`o existeix la versi´o Bedrock, que es amb C i seria la primera actualizaci´o a fer. Despr´es d’aix`o s’ha considerat apliar-ho m´es encara a altres platadormes, com per exemple, Roblox. •Exploraci´o d’altres metaversos: Es pot explorar la possibilitat d’integrar els serveis amb tecnologies de realitat augmentada o intel·lig`encia artificial, per buscar una millor experi`encia d’usuari i un major atractiu pels clients. Aquestes futures ampliacions podrien posicionar a ´ Ekratos com a l´ıder en el seu sector, augmentant el valor del sistema desenvolupat i consolidant la seva base de clients. 70 15 Annex 15.1 Manual d’usuari pel Plugin Minecraft El Plugin per a servidors de Minecraft d’Ekratos permet als usuaris configurar un servidor perqu`e serveixi com a entorn de votaci´o. S’associa el servidor a una votaci´o en concret i tots els usuaris que estan inclosos en el cens d’aquesta poden accedir-hi i votar. 15.1.1 Instal·laci´o de Minecraft En cas de no tenir Minecraft instal·lat, l’usuari ha de seguir el seg¨uent enlla¸c i descarregar-se el Minecraft Launcher. https://www.microsoft.com/store/productId/9PGW18NPBZV5?ocid=pdpshare Un cop iniciada sessi´o a Minecraft, cal escollir la versi´o 1.20.4, per fer-ho hem de seguir els seg¨uents pasos: 1. Anar a la pantalla Installations. 2. Seleccionar New Installation. 3. Escollir la release 1.20.4 i emplenar la resta de dades segons les prefer`encies personals. 4. Finalment, seleccionar el bot´o Create. 71 72 15.1.2 Configuraci´o del Plugin En aquest punt donem per fet que ja s’ha comprat el servei de votaci´o des del SaaS i l’usuari ha rebut el correu d’Ekratos per iniciar sessi´o, l’usuari ha creat la seva contrasenya i ha entrat al servei de configuraci´o de la votaci´o comprada d’Ekratos. Al haver fet tot aix`o l’usuari es troba amb la seg¨uent pantalla: Un cop aqu´ı s’ha de crear la nova votaci´o desitjada, a continuaci´o veureu un exemple de votaci´o per tal de que sigui m´es clara l’explicaci´o: 73 Per altra banda, es pot consultar l’´ındex de participaci´o de la votaci´o en la part superior central de la pantalla, tal i com es mostra en la figura que apareix a continuaci´o. 80 Refer`encies [1] Software as a Service (SaaS).https://en.wikipedia.org/wiki/Software_ as_a_service. Consultat el 10 de gener de 2025. [2] Facultat d’Inform`atica de Barcelona (FIB).https://www.fib.upc.edu. Consultat el 25 de setembre de 2024. [3] inLab FIB - Laboratori d’Innovaci´o i Recerca de la FIB.https://inlab.fib. upc.edu. Consultat el 25 de setembre de 2024. [4] ´ Ekratos.https://www.ekratos.com. Consultat el 25 de setembre de 2024. [5] Blockchain.https://www.blockchain.com. Consultat el 25 de setembre de 2024. [6] Minecraft.https://www.minecraft.net. Consultat el 25 de setembre de 2024. [7] Sandbox (Videojoc).https://en.wikipedia.org/wiki/Sandbox_game. Consultat el 25 de setembre de 2024. [8] PayPal.https://www.paypal.com. Consultat el 25 de setembre de 2024. [9] Stripe.https://stripe.com. Consultat el 25 de setembre de 2024. [10] James Robertson i Suzanne Robertson. Vol`ere Requirements Specification Template.https://www.volere.org. Consultat el 10 de gener de 2025. [11] Express - Node.js web application framework.https://expressjs.com/. Consultat el 10 de gener de 2025. [12] Bukkit/Spigot API Documentation.https : / / www . spigotmc . org / wiki / spigot-api/. Consultat el 10 de gener de 2025. [13] SweetAlert: Beautiful, Responsive, Customizable Popup Boxes.https://sweetalert. js.org. Consultat el 6 d’octubre de 2024. [14] Scrum Guide.https://www.scrumguides.org. Consultat el 25 de setembre de 2024. [15] Kanban.https : / / en . wikipedia . org / wiki / Kanban. Consultat el 25 de setembre de 2024. [16] Trello.https://trello.com. Consultat el 25 de setembre de 2024. [17] Slack.https://slack.com. Consultat el 25 de setembre de 2024. [18] GitHub.https://github.com. Consultat el 25 de setembre de 2024. [19] Glassdoor. Glassdoor: Accede a sueldos, rese˜nas de empresas y entrevistas. Consultat el 6 d’octubre de 2024. 2024. url:https://www.glassdoor.es/index. htm. [20] General Data Protection Regulation (GDPR).https://eur-lex.europa.eu/ eli/reg/2016/679/oj. Consultat el 5 de desembre de 2024. [21] Payment Services Directive 2 (PSD2).https://ec.europa.eu/finance/ docs/law/psd2_directive_en.pdf. Consultat el 5 de desembre de 2024. [22] Llei de Propietat Intel·lectual (Espanya).https://www.boe.es/buscar/act. php?id=BOE-A-1996-8930. Consultat el 5 de desembre de 2024. 81 [23] EN 301 549 Accessibility Requirements for ICT Products and Services.https: //www.etsi.org/deliver/etsi_en/301500_301599/301549. Consultat el 5 de desembre de 2024. [24] Legislaci´o sobre videojocs i privacitat (EUA).https://www.ftc.gov/system/ files/documents/plain-language/bus44-complaint-privacy-securityvideo-game.pdf. Consultat el 5 de desembre de 2024. 82