Aplicació per la gestió de partides, lligues i tornejos de dards
Abstract
Aquest projecte consisteix en el desenvolupament d’una aplicació web per jugar a dards de punta de ferro entre dos jugadors, en la modalitat coneguda com a 501. En aquest joc, cada participant comença amb 501 punts i ha d’anar llançant dards a una diana per anar restant puntuació fins a arribar exactament a zero. L’aplicació no substitueix el llançament físic dels dards, sinó que serveix com a eina de suport per registrar la puntuació de cada tir, portar el control de la partida i oferir una experiència visual i organitzada del seu progrés. Això permet que els jugadors es centrin en el joc mentre l’aplicació gestiona automàticament el marcador, l’historial de torns i altres elements com les estadístiques personals o la classificació en competicions. A través d’aquesta aplicació, es poden jugar partides tant localment com en línia, mantenint sempre un entorn accessible i fàcil d’utilitzar, apte per a qualsevol persona que vulgui gaudir dels dards de manera moderna i estructurada.
Full text
id192747 APLICACIÓ PER LA GESTIÓ DE PARTIDES, LLIGUES I TORNEJOS DE DARDS GERARD SERRAMIÀ ROSELL Director/a SILVIALLORENTEVIEJO(Departamentd'ArquitecturadeComputadors) Titulació GrauenEnginyeriaInformàtica(Tecnologiesdelainformació) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 15/05/2025
Resum Aquest projecte consisteix en el desenvolupament d’una aplicació web per jugar a dards de punta de ferro entre dos jugadors, en la modalitat coneguda com a 501. En aquest joc, cada participant comença amb 501 punts i ha d’anar llançant dards a una diana per anar restant puntuació fins a arribar exactament a zero. L’aplicació no substitueix el llançament físic dels dards, sinó que serveix com a eina de suport per registrar la puntuació de cada tir, portar el control de la partida i oferir una experiència visual i organitzada del seu progrés. Això permet que els jugadors es centrin en el joc mentre l’aplicació gestiona automàticament el marcador, l’historial de torns i altres elements com les estadístiques personals o la classificació en competicions. A través d’aquesta aplicació, es poden jugar partides tant localment com en línia, mantenint sempre un entorn accessible i fàcil d’utilitzar, apte per a qualsevol persona que vulgui gaudir dels dards de manera moderna i estructurada. Este proyecto consiste en el desarrollo de una aplicación web para jugar a dardos de punta de hierro entre dos jugadores, en la modalidad conocida como 501. En este juego, cada participante comienza con 501 puntos y debe ir lanzando dardos a una diana para ir restando puntuación hasta llegar exactamente a cero. La aplicación actúa como una herramienta de apoyo para registrar la puntuación de cada lanzamiento, llevar el control de la partida y ofrecer una experiencia visual y organizada de su desarrollo. Esto permite que los jugadores se centren en el juego mientras la aplicación gestiona automáticamente el marcador, el historial de turnos y otros elementos como las estadísticas personales o la clasificación en ligas. A través de esta aplicación, se pueden disputar partidas tanto localmente como en línea, manteniendo siempre un entorno accesible y fácil de utilizar, apto para cualquier persona que desee disfrutar del juego de los dardos de una forma moderna y estructurada. This project consists of the development of a web application for playing steel-tip darts between two players, using the popular 501 game mode. In this game, each player starts with 501 points and throws darts at a dartboard to reduce their score until reaching exactly zero. The application serves as a support tool to record the score of each throw, manage the progress of the match, and provide a visual and organized experience of the game. This allows players to focus on playing while the app automatically handles the scoreboard, turn history, and other features such as personal statistics or league rankings. Through this application, matches can be played either locally or online, always within an accessible and user-friendly environment, suitable for anyone who wants to enjoy darts in a modern and structured way.
Índex de continguts 1. Introducció i contextualització .................................................... 6 1.1. Introducció ............................................................................................................... 6 1.2. Context..................................................................................................................... 6 1.3. Terminologia i definicions .......................................................................................... 7 1.4. Identificació del problema ......................................................................................... 7 1.5. Actors implicats ........................................................................................................ 9 1.6. Funcionament d'una partida de dards 501 .................................................................. 9 2. Justificació ............................................................................... 12 2.1. Solucions existents ................................................................................................. 12 2.2. Proposta de solució ................................................................................................. 15 3. Abast del projecte ..................................................................... 17 3.1. Objectiu principal .................................................................................................... 17 3.2. Requisits funcionals ................................................................................................ 17 3.3. Requisits no funcionals ........................................................................................... 18 3.4. Riscos i possibles obstacles .................................................................................... 18 4. Metodologia i rigor .................................................................... 19 4.1. Metodologia ............................................................................................................ 19 4.2. Eines utilitzades ...................................................................................................... 20 5. Planificació Temporal ................................................................ 21 5.1. Recursos ................................................................................................................ 21 5.2. Descripció de les tasques ........................................................................................ 22 5.3. Resum de la planificació .......................................................................................... 25 5.4. Diagrama de Gantt .................................................................................................. 26 5.5. Gestió de riscos ...................................................................................................... 27 6. Pressupost ............................................................................... 28 6.1. Recursos humans ................................................................................................... 28 6.2. Hardware ................................................................................................................ 29 6.3. Software ................................................................................................................. 30 6.4. Costos indirectes .................................................................................................... 30 6.5. Contingències ......................................................................................................... 31 6.6. Imprevistos ............................................................................................................. 32 6.7. Pressupost final ...................................................................................................... 33 6.8. Replanificació ......................................................................................................... 33 6.9. Control de gestió ..................................................................................................... 35 7. Presa de Requisits .................................................................... 36
7.1. Presa de Requisits d'Usuari ...................................................................................... 36 7.2. Recerca i inspiració d'interfícies ............................................................................... 38 8. Disseny i implementació de l’aplicació ...................................... 41 8.1. Frontend ................................................................................................................. 43 8.2. Backend: Arquitectura i API REST ............................................................................. 52 8.3. Base de dades ........................................................................................................ 56 8.4. Backend: WebSockets Server .................................................................................. 59 8.5. Comuniacio P2P amb PeerJS ................................................................................... 64 8.6. Autenticació i Seguretat ........................................................................................... 65 9. Entorn de desplegament ........................................................... 69 9.1. Frontend – Netlify .................................................................................................... 69 9.2. Backend – Railway ................................................................................................... 69 9.3. Base de dades – Railway (PostgreSQL) ...................................................................... 70 9.4. Domini - DonDominio .............................................................................................. 70 9.5. Futur – Migració a un servidor propi .......................................................................... 71 9.6. Seguretat informàtica .............................................................................................. 71 10. Lleis i regulacions ..................................................................... 73 10.1. RGPD ..................................................................................................................... 73 10.2. LSSI-CE .................................................................................................................. 73 10.3. Llicències de programari i propietat intel·lectual ........................................................ 73 10.4. Política de cookies .................................................................................................. 73 11. Sostenibilitat i Compromís Social .............................................. 74 11.1. Dimensió ambiental ................................................................................................ 74 11.2. Dimensió econòmica .............................................................................................. 74 11.3. Dimensió social ...................................................................................................... 75 12. Integració de coneixements....................................................... 76 13. Conclusions ............................................................................. 77 13.1. Conclusió del projecte............................................................................................. 77 13.2. Principals problemes ............................................................................................... 77 13.3. Millores i funcionalitats futures ................................................................................ 77 13.4. Valoració personal .................................................................................................. 78 14. Referències .............................................................................. 79 15. Annex1 – Visualització imatges aplicació ................................... 81
Índex d’il·lustracions Il·lustració 1: Puntuació en una diana de dards. Font: Elaboració pròpia ......................... 10 Il·lustració 2: Exemple d'una partida. Font: Elaboració pròpia. ........................................ 11 Il·lustració 3: Pàgina principal Nakka. Font: Nakka [3] .................................................... 12 Il·lustració 4: Formulari de creació de partida. Font: Nakka [3] ........................................ 13 Il·lustració 5: Partida a Nakka. Font: Nakka [3] ............................................................... 13 Il·lustració 6: Metodologia Kanban. Font: Elaboració pròpia............................................ 19 Il·lustració 7: Diagrama de Gantt. Font: Elaboració pròpia. ............................................. 26 Il·lustració 8: Inspiració d’interfície evolució partida. Font: Nakka [3]. ............................. 38 Il·lustració 9: : Inspiració d’interfície, introducció de puntuacions. Font: DartCounter [4]. 38 Il·lustració 10: Inspiració d'interfície, lobby en línia. Font: DartCounter [4]. ..................... 39 Il·lustració 11: Inspiració d’interfície, disseny. Font: Chess [29]. ..................................... 39 Il·lustració 12: Arquitectura general. Font: Elaboració pròpia. ......................................... 41 Il·lustració 13: Arquitectura del frontend. Font: Elaboració pròpia. .................................. 46 Il·lustració 14: Diagrama de navegació. Font: Elaboració pròpia. ..................................... 50 Il·lustració 15: Disseny visual aplicació. Font: Elaboració pròpia. .................................... 51 Il·lustració 16: Arquitectura del backend, API REST. Font: Elaboració pròpia. ................... 53 Il·lustració 17: Diagrama Entitat Relacio (ER). Font: Elaboració pròpia. ........................... 58 Il·lustració 18: Arquitectura del backend, WebSockets. Font: Elaboració pròpia. ............. 60 Il·lustració 19: Flux de funcionament de creació de partida. Font: Elaboració pròpia. ...... 62 Il·lustració 20: Flux de funcionament d'una partida. Font: Elaboració pròpia. .................. 63 Il·lustració 21: Fluxe d'autenticacio. Font: Elaboració propia .......................................... 67 Índex de taules Taula 1: Taula resum de planificació. Font: Elaboració pròpia ........................................ 25 Taula 2: Estimació salarial per recursos humans. Font: Elaboració pròpia ...................... 28 Taula 3: Estimació salarial per tasca i rol. Font: Elaboració pròpia. ................................. 29 Taula 4: Estimació de costos per recursos material. Font: Elaboració pròpia. ................. 30 Taula 5: Estimació de costos per recursos software. Font: Elaboració pròpia. ................. 30 Taula 6: Estimació de costos indirectes. Font: Elaboració pròpia ................................... 31 Taula 7: Càlcul de costos de contingència. Font: Elaboració pròpia ............................... 31 Taula 8: Estimació de costos imprevistos. Font: Elaboració pròpia. ................................ 32 Taula 9: Pressupost final. Font: Elaboració pròpia. ........................................................ 33 Taula 10: Estimació de costos per recursos materials(2). Font: Elaboració pròpia. .......... 34 Taula 11: Pressupost final replanificat. Font: Elaboració pròpia ...................................... 34 Taula 12: Comparació de tecnologies del frontend. Font: Elaboració pròpia. .................. 44 Taula 13: Comparació de tecnologies del backend. Font: Elaboració pròpia. .................. 45 Taula 14: Comparació sistemes de bases de dades. Font: Elaboració pròpia. ................. 56
6 1. Introducció i contextualització 1.1. Introducció Aquest projecte s'emmarca dins el Treball de Fi de Grau (TFG), requisit fonamental per a la finalització del Grau en Enginyeria Informàtica (GEI) a la Universitat Politècnica de Catalunya (UPC), en l'especialitat de Tecnologies de la Informació (TI). El projecte segueix la modalitat A, on l'estudiant escull lliurement el tema sobre el qual desenvoluparà el treball. En aquest cas, el projecte s’ha centrat en la creació d'una aplicació web per a la gestió de partides, lligues i tornejos de dards, en la modalitat específica de punta d'acer. 1.2. Context Els dards són un joc amb una llarga tradició, popular tant en l'àmbit domèstic, com en espais públics, per exemple, bars i clubs socials. Històricament, han servit com a forma d'entreteniment informal, amb amics i familiars jugant tant a casa com en aquests establiments. Tot i això, també han evolucionat cap a una disciplina esportiva professional en diversos països, com Anglaterra, Alemanya o els Estats Units, amb competicions internacionals televisades i amb una audiència global. Tal com diu la Federació Catalana de Dards [1]: “S'anomena dards l'esport que es pot practicar individualment, per parelles, triplets o per equips, i que consisteix a llançar tres dards alternativament cada jugador a un objectiu circular anomenat diana que està fixat a la paret, fins a completar una puntuació determinada o assolir uns sectors determinats una sèrie de vegades també determinada, segons la variant del joc i regles amb les quals estigui jugant”. Els dards es divideixen en dues modalitats principals: • Dards de punta de plàstic (diana electrònica): En aquesta modalitat, els dards tenen una punta de plàstic, i la diana és electrònica, la qual enregistra automàticament les puntuacions dels jugadors. Aquesta modalitat és molt popular en bars i llars, on es busca sobretot la diversió. La gestió electrònica de les partides permet jugar de manera més còmoda i fins i tot en línia amb jugadors d'arreu del món, gràcies a les càmeres integrades que porten les dianes electròniques. • Dards de punta d’acer: Aquesta modalitat és la que s’utilitza principalment en competicions professionals, com les organitzades per la Professional Darts Corporation (PDC) [2]. Els dards tenen una punta d’acer, i la diana està feta de sisal, un material tradicional que es regenera després de cada impacte. Aquesta modalitat és més precisa i requereix una major habilitat per part dels jugadors. Malgrat això, el fet que les dianes no siguin electròniques comporta limitacions significatives, com la necessitat que els jugadors competeixin de manera presencial, dificultant la participació a distància.
7 1.3. Terminologia i definicions • Aplicació web: Programa accessible a través d'un navegador que permet la gestió de partides, lligues i tornejos de dards de punta d'acer. L'aplicació permet tant als Operadors com als Jugadors interactuar amb el sistema, inscriure's a competicions i registrar resultats. • Classificació: Sistema automàtic o manual que ordena els Jugadors en funció dels resultats obtinguts en les competicions. Les classificacions es poden generar tant per partides individuals com per lligues o tornejos. • Dards de punta d'acer: Modalitat en la qual els dards tenen una punta de ferro o acer, dissenyats per ser utilitzats amb dianes fetes de fibres de sisal, material conegut per la seva capacitat de regenerar-se després dels impactes. Aquesta modalitat és habitual en competicions professionals. • Diana: Objectiu circular on els jugadors llancen els dards. Conté diferents segments amb puntuacions específiques. • Lliga: Un conjunt de partides organitzades per un Operador, on els jugadors competeixen entre si durant un període de temps. Les classificacions es basen en els resultats de les partides jugades. • Operador: L’operador és l'usuari responsable de crear i gestionar les lligues, tornejos i partides dins l'aplicació. • PDC: Organització responsable de les competicions més prestigioses a escala mundial en la modalitat de dards de punta d’acer. • Partida: Una competició entre un o més jugadors amb l'objectiu d'assolir una puntuació o complir unes condicions específiques, segons les regles del joc. Les partides poden ser individuals o per equips. • Sistema de pagament: Mecanisme integrat a l'aplicació que permet als Jugadors efectuar pagaments per a inscriure's a competicions i permet als Operadors gestionar els premis o recompenses. • Torneig: Esdeveniment en el qual diversos jugadors competeixen seguint un format eliminatori o de grups, organitzat per un Operador. El guanyador és determinat segons els resultats obtinguts al llarg de les rondes. 1.4. Identificació del problema Tot i que els dards de punta d'acer són molt populars en l'àmbit professional, principalment gràcies a la PDC, aquesta modalitat presenta una limitació important: la manca d’integració tecnològica. A diferència de les dianes electròniques utilitzades en la modalitat de punta de plàstic, les dianes de sisal no incorporen sensors ni sistemes de registre automàtic de puntuació, fet que obliga els jugadors a registrar manualment les puntuacions i dificulta el joc en línia. Ara bé, si analitzem la situació amb perspectiva, la modalitat de punta d'acer també presenta un avantatge significatiu: si es vol jugar en línia, només cal una diana de sisal, tres dards i un sistema de càmeres connectades a internet. Amb una càmera enfocant la diana i una altra enfocant el jugador, es pot garantir una partida justa i sense trampes. En canvi, la modalitat de punta de plàstic requereix una infraestructura molt més complexa, ja que depèn de dianes electròniques amb pantalles integrades, sensors de
8 detecció d’impactes i, en molts casos, un sistema de connexió que limita la seva flexibilitat i accessibilitat. En aquest context, un software que permeti gestionar les partides en temps real podria ser una eina essencial per facilitar el joc en línia en qualsevol modalitat. Aquest software no només permetria portar el registre de puntuacions de manera automàtica, sinó que també podria integrar-se amb les càmeres per proporcionar una experiència de joc més fluida i transparent. Més enllà del joc en línia, la gestió de tornejos de dards de punta d'acer en bars i clubs també presenta una problemàtica: actualment, molts d’aquests esdeveniments es gestionen manualment, anotant les puntuacions en paper o administrant la competició de manera poc estructurada. Aquesta manca de digitalització pot generar errors, retardar el desenvolupament dels tornejos i dificultar-ne el seguiment. Un sistema informatitzat per gestionar tant les partides individuals com els tornejos i les lligues podria millorar significativament l’eficiència i la comoditat per a jugadors i organitzadors. Actualment, existeixen dues aplicacions web principals que aborden la gestió de partides i competicions de dards: Nakka [3] i DartCounter [4]. Tot i que ambdues ofereixen funcionalitats interessants, presenten certes limitacions que dificulten una experiència de joc òptima. La primera aplicació, Nakka, permet jugar tant en línia com gestionar tornejos i lligues. A més, ofereix la possibilitat de connectar càmeres per evitar trampes durant les partides. Ara bé, després d’analitzar-la en profunditat, es detecten diverses deficiències. L’ús de la plataforma resulta poc intuïtiu i presenta un disseny antiquat i poc amigable, fet que dificulta l’accessibilitat per a nous usuaris. A més, molts operadors i jugadors han expressat el seu descontentament amb les elevades comissions que cobra la plataforma, ja que aquestes redueixen els premis de les competicions i fan menys atractiu l’ús del seu servei. La segona aplicació, DartCounter, descoberta durant la realització d’aquest treball, ofereix la possibilitat de jugar tant en local com en línia. Aquesta plataforma està dissenyada al voltant de la venda de dianes amb un sistema integrat de càmera o sensors, que registren automàticament la puntuació de cada llançament. Això suposa un gran avantatge en termes d’automatització, però també una barrera d’accés, ja que només es pot jugar en línia amb altres usuaris si es disposa del seu hardware específic, el qual té un cost elevat (aproximadament 300-1500 € per unitat). A més, aquesta plataforma no inclou cap opció per crear tornejos o lligues, ja que està pensada principalment per a partides individuals jugades des de casa. Analitzant aquestes opcions, es pot concloure que actualment no existeix una aplicació que cobreixi totes les necessitats del joc de dards de punta d’acer de manera accessible i eficient. Per tant, es detecta una oportunitat per desenvolupar una solució més intuïtiva, moderna i econòmica, que millori l’experiència tant per als jugadors (professionals o amateurs) com per als organitzadors de competicions.
9 1.5. Actors implicats En aquest projecte en concret, hi ha diversos actors, des de la fase de plantejament del projecte, fins al desenvolupament, implementació, entrega i utilització de l’aplicació. • Desenvolupador (estudiant): Persona/es que fa el treball i s’encarrega de definir, implementar i testejar l’aplicació pel seu bon funcionament, a més a més de documentar el projecte i redactar la memòria. En aquest projecte només hi ha una persona amb aquest rol, que és Gerard Serramià Rosell. • Directora del TFG: Persona que supervisa i guia a l’estudiant perquè el projecte pugui tirar endavant. En aquest projecte, la directora és Silvia Llorente Viejo. • Jugador: Persona que juga partides fent servir l’aplicació, siguin individuals de forma local si no està registrat o bé partides en línia, tornejos o lligues si ho està. En aquest cas també té accés a les seves estadístiques personals. • Operador: Defineix les regles de les competicions, gestiona les inscripcions, busca participants, actualitza els resultats i s'encarrega de la distribució de premis o recompenses als guanyadors. 1.6. Funcionament d'una partida de dards 501 El món dels dards compta amb diferents modalitats de joc, com el Cricket, el 301, el 501, entre d’altres. El 501 és el format més estès en competicions de punta d’acer, tant a escala professional com amateur. A continuació, s'explica detalladament el funcionament d’aquesta modalitat. L'objectiu principal d'una partida d’aqueta modalitat és reduir la puntuació inicial de 501 punts a 0 exactament, utilitzant el menor nombre possible de llançaments. 1.6.1. Sistema de puntuació Cada jugador disposa de tres dards per torn. La puntuació obtinguda en un torn es calcula sumant els punts dels segments on impacten els dards. La diana està dividida en segments numerats d'1 a 20, amb una secció central interior anomenada Diana Doble i una secció central superior anomenada Diana Simple. Cada segment té diferents valors segons la zona d’impacte: • Segment senzill: Puntua el valor base del segment. • Segment doble: Puntua el doble del valor del segment. • Segment triple: Puntua el triple del valor del segment. • Diana Doble: 50 punts. • Diana Simple: 25 punts. Si el dard llençat no es clava a la diana o es clava fora d’aquests segments contarà com a 0 punts o OUT.
16 Gestió eficient de tornejos i lligues • S’ha creat un sistema que genera automàticament el quadre de competició, defineix els enfrontaments i actualitza la classificació en temps real. • Dona suport a diferents formats de tornejos i lligues, cosa que permet als organitzadors configurar regles personalitzades segons les necessitats del torneig. Reducció de costos i accessibilitat • Es garanteix que l'ús de la plataforma és més econòmic que les alternatives actuals, amb tarifes més ajustades per a l’organització de lligues i tornejos. • L'objectiu és que els premis de les competicions siguin més atractius per als jugadors, evitant comissions elevades que redueixin el valor dels premis. Perspectiva de futur: cap a una comunitat de dards A llarg termini, l’aplicació podria evolucionar cap a una comunitat digital per a jugadors de dards, on els usuaris puguin interactuar, compartir experiències i trobar competicions d’interès. • Implementar un sistema de notificacions i anuncis perquè els jugadors estiguin informats de tornejos i lligues pròximes, sigui en línia o en establiments físics. • Els bars i clubs podrien utilitzar la plataforma per promocionar els seus tornejos, facilitant la inscripció de jugadors i gestionant les competicions de manera més eficient. • Integrar un sistema de classificacions i rànquings generals, cosa que permet als jugadors seguir la seva evolució i comparar-se amb altres participants de la comunitat. Amb aquest enfocament, l’aplicació no només resol els problemes actuals de gestió de partides i tornejos, sinó que també es podria arribar a convertir en un punt de trobada per als aficionats als dards, fomentant la participació i la difusió d’aquest esport.
17 3. Abast del projecte En aquest apartat es descriu l’abast del projecte, veient els seus objectius principals, els requisits funcionals i no funcionals, així com els riscos i possibles obstacles que podrien afectar el desenvolupament. Aquestes consideracions han estat essencials per garantir que l’aplicació complís amb les expectatives inicials i pogués evolucionar cap a una versió final exitosa. 3.1. Objectiu principal L’objectiu principal d’aquest projecte ha estat desenvolupar una aplicació web funcional per a la gestió de partides, lligues i tornejos de dards de punta d'acer. Tot i que la versió inicial no pretenia ser una versió final del producte, el seu propòsit ha estat establir una estructura sòlida i funcional que superi les limitacions de les solucions actuals, oferint una interfície més intuïtiva i eficient. El resultat del projecte és una aplicació amb les funcionalitats bàsiques necessàries per a la seva implementació inicial, que podrà ser ampliada amb noves funcionalitats en el futur fins a assolir un producte competitiu al mercat. Això ha permès construir una base robusta per continuar afegint funcionalitats addicionals a mesura que es perfecciona el sistema. Fora de l’abast: la part financera, és a dir, tota la gestió de pagament, i la part legal, no es contemplen dins d’aquest projecte, ja que queda fora de les competències d'un Treball de Fi de Grau. Aquests aspectes podrien ser considerats en futures etapes del projecte, per exemple, integrant passarel·les de pagament segures. 3.2. Requisits funcionals Els requisits funcionals són les funcionalitats específiques que l’aplicació ha de proporcionar per complir amb els seus objectius. Aquests requisits inclouen: • Registre i autenticació d’usuaris (jugadors i operadors): L’aplicació ha de permetre que els jugadors i els operadors es registrin i accedeixin al sistema de manera segura. • Gestió de partides de forma local: L'aplicació ha de permetre jugar partides de forma local sense necessitat de registre, aquestes partides no quedaran registrades. • Gestió de partides en línia: L'aplicació ha de permetre crear i jugar partides en temps real entre dos jugadors. Els resultats s’han d’enregistrar automàticament en base de dades i han de ser visibles les dades en temps real, incloent-hi puntuacions i torns. A més a més, ha d’incloure un sistema de reconnexió i actualitzar les estadístiques dels jugadors en finalitzar. • Creació i gestió de lligues i tornejos: Els operadors han de poder crear i gestionar lligues i tornejos de manera senzilla, definint les regles de competició i el format. • Classificacions automàtiques i en temps real: Les classificacions de jugadors s'han d'actualitzar automàticament després de cada partida. • Estadístiques i informes: Els jugadors i operadors han de poder consultar estadístiques de rendiment i informes sobre les seves partides, lligues i tornejos.
18 3.3. Requisits no funcionals Els requisits no funcionals descriuen les característiques de rendiment i qualitat que l'aplicació ha de complir per oferir una experiència d’usuari òptima: • Usabilitat / facilitat d'ús: L’aplicació ha de ser intuïtiva i fàcil d’utilitzar, tant per als jugadors com per als operadors, amb una interfície clara i accessible. • Escalabilitat: L'aplicació ha de ser capaç de gestionar un gran volum de dades i d’usuaris, incloent-hi milers o milions de partides simultànies, així com un creixement progressiu del nombre de lligues i tornejos. • Rapidesa d'execució: Ha de garantir un rendiment ràpid, amb temps de càrrega mínims i una experiència fluida per a tots els usuaris. • Sistemes de recuperació de dades: En cas d'errors tècnics o desconnexions, l'aplicació ha de tenir la capacitat de recuperar la informació i permetre la continuació de la partida o l'esdeveniment sense pèrdua de dades. • Seguretat: És imprescindible garantir la seguretat de les dades dels usuaris, especialment en els aspectes relacionats amb la informació personal. 3.4. Riscos i possibles obstacles Durant el desenvolupament del projecte, s’han tingut en compte diversos riscos i obstacles que podrien afectar l’avanç del treball o el rendiment de l’aplicació. Els més rellevants són: • Resistència al canvi dels usuaris: Els jugadors poden ser reticents a utilitzar una nova aplicació fins que aquesta no compti amb un volum significatiu de competicions i usuaris actius. Això pot alentir l'adopció de la plataforma. • Canvi de tecnologia per falta de temps i coneixements: Un risc comú en projectes de desenvolupament és triar una tecnologia que no s’adapti al context, als recursos disponibles o al nivell de coneixement del desenvolupador. Tot i que pot ser temptador utilitzar tecnologies modernes o populars, aquestes poden introduir una complexitat innecessària si no es dominen prou bé o si no encaixen amb les necessitats específiques del projecte. • Problemes tècnics (bugs i errors): El desenvolupament, especialment en aplicacions web, pot presentar errors inesperats (bugs) que retardin el calendari inicial. Aquests problemes poden complicar la implementació de funcionalitats. • Escalabilitat tècnica: Si l’aplicació no està dissenyada adequadament per gestionar un gran volum d’usuaris o esdeveniments, el sistema pot col·lapsar quan creixi el nombre de jugadors i competicions. Això requereix una planificació tècnica acurada. • Seguretat de dades: La gestió segura de la informació personal i financera és crucial, ja que qualsevol vulnerabilitat pot comprometre la confiança dels usuaris i posar en risc el projecte.
19 4. Metodologia i rigor 4.1. Metodologia Per a la gestió d’aquest projecte, s’ha optat per la metodologia Kanban [7] a causa de la seva flexibilitat i simplicitat, ideal per a un treball individual. Aqueta metodologia facilita l'organització de les tasques mitjançant un tauler visual amb columnes que ajuden a controlar l'estat de cada tasca. Il·lustració 6: Metodologia Kanban. Font: Elaboració pròpia. S’ha fet servir Trello [8] per implementar aquest sistema. El tauler de Trello ha tingut les següents columnes: • Pendents: Ha contingut les tasques que encara no s'han començat. Aquí s’han recollit totes les activitats que havien de ser planificades i iniciades en el futur. • En curs: Ha inclòs les tasques que s’estaven duent a terme. Aquesta columna ha ajudat a veure quines tasques estan en execució per ordre de prioritats. • Finalitzades: Ha reunit les tasques que ja s'han completat. Serveix per a fer un seguiment dels progressos aconseguits i per revisar els èxits del projecte. Addicionalment, es va crear un segon tauler Kanban específic per a gestionar les subtasques derivades dels punts més grans del projecte, així com per registrar i solucionar els errors detectats durant el desenvolupament, on cada columna ha estat d’alguna part especifica com Usuaris, Partides, Lliges, etc.. Aquest tauler addicional ha permès una gestió més detallada i precisa, facilitant la resolució de problemes i contribuint a un millor seguiment del treball diari. Aquest enfocament ha permès una gestió eficaç del treball, adaptant-se a canvis i prioritats mentre es manté una visió clara del progrés del projecte.
20 4.2. Eines utilitzades Per al desenvolupament i la gestió d’aquest projecte, s’han fet servir les següents eines: • GitHub [9]: Aquesta eina s’ha utilitzat per al control de versions del codi. GitHub ha permès gestionar i seguir les modificacions del codi font de manera eficient, facilitant la recuperació de versions anteriors. • Visual Studio Code [10]: Ha estat l’entorn de desenvolupament integrat (IDE) per a programar. Visual Studio Code ofereix un ampli conjunt d’eines i extensions que faciliten la codificació, la depuració i el desenvolupament de l'aplicació. • Google Meet [11]: S’ha fet servir per fer les reunions amb la directora del projecte. • ChatGPT (OpenAI) [12]: Eina d’intel·ligència artificial utilitzada com a suport durant el desenvolupament, principalment per a tasques d’assessorament tècnic, resolució de dubtes puntuals, revisió de textos i suport en la documentació del projecte. • Trello: Aplicació per gestionar tasques segons la metodologia Kanban. Ha permès una organització clara i visual dels objectius del projecte, facilitant la gestió de tasques principals i subtasques, així com el registre dels errors trobats durant el desenvolupament. • Canva [13]: Utilitzada per crear imatges i il·lustracions específiques per a la documentació del projecte. Ha permès generar gràfics visuals i esquemes de manera senzilla i ràpida. • Microsoft Word [14]: Ha estat l’eina principal per redactar i estructurar la memòria del projecte. Word facilita la revisió, el format i l'organització efectiva del contingut textual i gràfic del document. • PgAdmin [15]: Aplicació utilitzada per gestionar, administrar i visualitzar la base de dades PostgreSQL [16] de manera còmoda i efectiva durant el desenvolupament del projecte. • Draw.io (Diagrams.net) [17]: Eina utilitzada per dissenyar els diagrames tècnics del projecte, com els diagrames de navegació i els diagrames relacionals de la base de dades, aportant claredat visual a la documentació. • Netlify [18]: Servei fet servir per desplegar l'aplicació frontend de forma ràpida i segura, facilitant les proves d’usuari i demostracions en entorns reals. • Railway [19]: Plataforma utilitzada per desplegar el backend de l'aplicació en línia, permetent proves i demostracions accessibles a través d'internet. • DonDominio [20]: Servei fet servir per registrar i gestionar el domini web propi del projecte, facilitant així la vinculació del frontend i backend sota un mateix domini personalitzat i professional. Aquesta selecció d’eines ha estat clau per assegurar un desenvolupament eficient, ordenat i àgil, així com per oferir un resultat coherent amb els objectius marcats inicialment.
21 5. Planificació Temporal La planificació temporal és fonamental per assegurar una gestió eficient de qualsevol projecte. Aquesta secció descriu les diferents fases del projecte, oferint una anàlisi detallada dels recursos necessaris, els requisits i les tasques associades a cadascuna de les etapes. S’ha fet servir la metodologia Kanban per al seguiment de les activitats i un Diagrama de Gantt [21] per representar el progrés temporal del projecte. Finalment, s’han analitzat els possibles riscos, valorant la seva probabilitat i impacte, i es plantegen mesures alternatives per mitigar-los en cas que es produeixin. La planificació inicial del projecte es va veure afectada per diversos factors personals i tècnics. Tot i així, s’ha pogut adaptar i reconduir de manera satisfactòria, obtenint un resultat coherent amb els objectius marcats. 5.1. Recursos 5.1.1. Recursos Humans • Desenvolupador: El desenvolupador, Gerard Serramià, s’ha encarregat de la implementació tècnica del projecte, incloent-hi la seva planificació, redacció de la memòria, desenvolupament de l'aplicació, assegurant el compliment dels requisits funcionals i terminis, així com la defensa davant el tribunal acadèmic. • Directora del projecte: La directora, Silvia Llorente, ha guiat l'alumne i supervisat el progrés del projecte, aportant la seva experiència per garantir el compliment dels objectius acadèmics i dels terminis establerts. • Stakeholders: El desenvolupador ha actuat com a primer tester de l’aplicació. Tanmateix, és fonamental que els stakeholders, incloent-hi els usuaris finals, hagin participat també en la fase de proves. 5.1.2. Recursos Materials • Ordinador i accessoris: Ha estat necessari un ordinador d'escriptori o portàtil amb capacitat per a la programació i execució de l'aplicació, acompanyat dels accessoris necessaris com ratolí, teclat i una o dues pantalles. • Càmeres: S’ha necessitat disposar de càmeres per verificar la connexió i la visualització, en aquest cas s’ha fet servir tant la càmera de l’ordinador portàtil, com una d’externa. 5.1.3. Recursos Software Els recursos software fets servir en aquest projecte ja han estat detalladament explicats al punt 4.2 Eines utilitzades d’aquesta mateixa memòria. Es recomana consultar aquesta secció per obtenir informació completa sobre les eines específiques i les seves funcions en el desenvolupament del projecte.
22 5.2. Descripció de les tasques Les tasques del projecte s'han dividit en quatre blocs principals per facilitar-ne la gestió i l'organització: Gestió del projecte (GP), Presa de requisits i disseny (RD), Desenvolupament del projecte (PD/D) i Finalització del projecte (F). Es va fer una planificació inicial de les tasques, però, a causa del fet que un dels riscos previstos es va acabar produint, va ser necessari refer la planificació, afegint noves tasques i modificant les hores i els terminis de les ja existents. 5.2.1. Gestió del projecte • GP01 - Contextualització i abast: Definició del context i l'abast del projecte en el seu context acadèmic. Duració estimada: 24 hores. • GP02 - Planificació temporal: Elaboració de la planificació temporal per a l'execució completa del TFG. Duració estimada: 20 hores. • GP03 - Gestió econòmica i sostenibilitat: Estimació del cost econòmic del projecte i realització d'una anàlisi de la seva sostenibilitat. Duració estimada: 20 hores. • GP04 - Integració final del document: Redacció i integració final de tots els continguts necessaris per al document del TFG, recollint els resultats de les tasques GP01, GP02 i GP03. Duració estimada: 10 hores. • GP05 - Redactar memòria: Redacció de la memòria final del projecte, la qual es farà paral·lelament amb el desenvolupament projecte fins a la seva entrega. Duració estimada: 60 hores. • GP06 - Reunions i seguiment: Reunions periòdiques amb la directora del projecte per assegurar que es compleixin els objectius establerts. Aquesta tasca es manté activa durant tota la durada del projecte. Duració estimada: 10 hores. 5.2.2. Presa de requisits i disseny Aquest bloc inclou les tasques relacionades amb l’anàlisi de les necessitats dels usuaris i el disseny tant visual com tècnic de l’aplicació. • RD01 - Presa de requisits d’usuari: Recollida de les necessitats i expectatives dels usuaris finals per definir les funcionalitats clau de l’aplicació. Duració estimada: 20 hores. • RD02 - Recerca i inspiració d’interfícies: Investigació de tendències actuals en disseny d’interfícies (UI) per inspirar-se i identificar bones pràctiques. Es revisaran altres aplicacions similars per obtenir referències i aplicar-les a l’estructura visual de l’aplicació. Duració estimada: 8 hores. • RD03 - Navegació i estructura de l’aplicació: Definició de la navegació interna de l’aplicació. Es dissenyarà l’estructura de les pantalles i les seves interaccions. Duració estimada: 20 hores. • RD04 - Disseny de la base de dades relacional: Creació de l’estructura de la base de dades, incloent-hi la definició de les taules, els camps i les relacions necessàries per gestionar la informació de manera eficient. Duració estimada: 24 hores.
23 5.2.3. Desenvolupament del projecte El desenvolupament del projecte es divideix en diverses tasques tècniques, des de la configuració de l’entorn de desenvolupament, fins a la implementació de les funcionalitats clau, passant per la integració de sistemes i proves finals. S'ha dividit en dues fases diferenciades per reflectir clarament el procés real del treball: Fase de Pre-desenvolupament (PD): Tasques inicials en les quals s’ha fet servir el framework Next.js [22] per familiaritzar-se amb aquestes tecnologies, identificar-ne les limitacions i prendre una decisió sobre l'entorn tecnològic definitiu. Fase de Desenvolupament (D): Tasques principals de desenvolupament pròpiament dites, realitzades després d’haver optat per React [23] amb Vite [24] com a entorn final. • PD01 – Instal·lació i configuració inicial de l’entorn (Next.js): Instal·lació de l'entorn inicial amb Next.js, Visual Studio Code, GitHub, i configuració preliminar de bases de dades locals amb pgAdmin per començar amb les primeres proves. Duració estimada: 10 hores. • PD02 – Desenvolupament bàsic de gestió d'usuaris (Next.js): Aprenentatge inicial de Next.js, i desenvolupament inicial d’un sistema bàsic d’usuaris per entendre la seva arquitectura. Duració estimada: 30 hores. • PD03 – Implementació inicial de partida bàsica (Next.js): Desenvolupament inicial de la mecànica bàsica del joc utilitzant Next.js, fet que va permetre detectar limitacions tècniques i prendre la decisió de migrar cap a una alternativa tecnològica més adequada. Duració estimada: 15 hores • D01 - Instal·lació de l’entorn de desenvolupament final: Instal·lació definitiva de React amb Vite, configuració de l’entorn local i configuració final de les eines necessàries per començar el desenvolupament definitiu, com ara un nou projecte a GitHub. Duració estimada: 5 hores. • D02 - Implementació de la pantalla inicial: Desenvolupament d’una pantalla inicial amb un sidebar per poder accedir a les altres pantalles, accessible sense necessitat de login, que ofereix una vista general bàsica per a tots els usuaris. Duració estimada: 20 hores. • D03 - Implementació de la gestió d'usuaris Creació d’un sistema complet de gestió d’usuaris, incloent-hi registre, autenticació i gestió de perfils. Duració estimada: 30 hores. • D04 - Implementació de la partida bàsica: Desenvolupament de la mecànica principal del joc, el sistema de gestió de partides, les regles bàsiques del joc de dards i la base de dades per emmagatzemar els resultats. Duració estimada: 50 hores. • D05 – Implementació del joc en línia: Implementació de funcionalitats en temps real utilitzant WebSockets [25] per gestionar partides en línia entre usuaris. Aquesta tasca inclou la sincronització en temps real de les jugades, l'actualització automàtica de les puntuacions, la gestió de desconnexions dels jugadors i la recuperació automàtica de partides interrompudes. A causa de la complexitat tècnica dels WebSockets, aquesta tasca ha comportat un període addicional d’aprenentatge i ajustaments tècnics. Duració estimada: 40 hores.
24 • D06 - Gestió de partides en lligues i tornejos: Expansió de la funcionalitat del joc per incloure lligues i tornejos, amb la creació d'un sistema de puntuació automàtica i la gestió de lligues i tornejos. Duració estimada: 40 hores. • D07 - Creació de perfils i pantalles per operadors: Desenvolupament de noves pantalles per a operadors en les quals es puguin gestionar lligues i tornejos. Duració estimada: 30 hores. • D08 - Millora de la Interfície d'Usuari: Millora dels elements visuals principals com botons, menús i llistats per a una experiència d'usuari millorada i una navegació més intuïtiva. Duració estimada: 20 hores. • D09 - Configuració de càmeres: Preparació dels sistemes de càmeres per enregistrar o transmetre les partides. Duració estimada: 20 hores. • D10 - Proves i correcció d’errors: Es durà a terme un període intensiu de proves que inclourà tests de funcionalitat, detecció i correcció de bugs, així com optimització del rendiment i millora del codi. Duració estimada: 20 hores. • D11 - Entorn de desplegament: Configuració i posada en marxa de l’entorn de producció, configuració del servidor, pujada de l'aplicació i la base de dades, i verificació del seu funcionament correcte. Duració estimada: 10 hores. 5.2.4. Finalització del projecte La fase final del projecte consta de dues tasques: • F01 - Revisió i correcció de la memòria: Un cop finalitzat el desenvolupament s’ha revisat i corregit la memòria elaborada durant el projecte. Duració estimada: 20 hores. • F02 - Preparació de la presentació final: S’ha preparat la presentació del TFG, que inclou els aspectes més rellevants del projecte. Duració estimada: 20 hores.
25 5.3. Resum de la planificació Tasca Hores Dependències Gestió del Projecte 144 GP01 Contextualització i abast 24 GP02 Planificació temporal 20 GP01 GP03 Gestió econòmica i sostenibilitat 20 GP02 GP04 Integració final del document 10 GP03 GP05 Redactar memòria 60 GP04 GP06 Reunions i seguiment 10 Presa de Requisits i Disseny 72 RD01 Presa de Requisits d'Usuari 20 RD02 Recerca i inspiració d'interfícies 8 RD01 RD03 Navegació i estructura de l'aplicació 20 RD01 RD04 Disseny de la base de dades relacional 24 RD01 Desenvolupament del Projecte 340 PD01 Instal·lació i configuració inicial de l’entorn (Next.js) 10 PD02 Desenvolupament bàsic de gestió d'usuaris(Next.js) 30 PD01 PD03 Implementació inicial de partida bàsica (Next.js) 15 PD02 D01 Instal·lació de l’entorn de desenvolupament final 5 D02 Implementació de la pantalla inicial 20 D01 D03 Implementació de la gestió d'usuaris 30 D02 D04 Implementació de la partida bàsica 50 D03 D05 Implementació del joc en línia 40 D04 D06 Gestió de partides en lligues i tornejos 40 D05 D07 Creació de perfils i pantalles operadors 30 D06 D08 Millora de la Interfície d'Usuari 20 D07 D09 Configuració de càmeres 20 D04 D10 Proves i correcció d'errors 20 D07 D11 Entorn de desplegament 10 D02 Finalització del Projecte 40 F01 Revisió/Correcció memòria 20 F02 Preparació de la presentació final 20 F01 Total 596 Taula 1: Taula resum de planificació. Font: Elaboració pròpia
32 6.6. Imprevistos És fonamental disposar d'una reserva per afrontar els possibles riscos que s’ha tingut en compte i evitar que tinguin un impacte significatiu en el pressupost global. En aquest cas concret, s'han identificat una sèrie de riscos amb potencial impacte econòmic, detallats a l’apartat 5.6 Gestió de riscos. Aquests imprevistos no es van tenir en compte al 100% sinó que es va fer segons el percentatge de probabilitat estimada de que succeïssin i l’impacte que tenien en el projecte. Concretament, es va aplicar el següent criteri de càlcul: • Si l’impacte és alt: S’ha reservat el 100% del valor esperat • Si l’impacte és mitjà: S’ha reservat el 50% d’aquest percentatge. • Si l’impacte és baix: S’ha estimat un 25% del percentatge assignat. Veiem en detall cada un dels riscos: • Errors de disseny de la base de dades: Un mal disseny de la base de dades podria provocar haver de redissenyar-la parcialment o totalment, fet que comportaria temps addicional per reestructurar i migrar les dades. Al ser un impacte alt i tenir una probabilitat del 60%, es va decidir reservar per aquest imprevist el 100% del 60% dels 480€ que havíem destinat a la tasca RD04 (Disseny de la base de dades relacional). Total: 288€ • Estimació incorrecta de les hores: Si les hores necessàries per a cada tasca han estat mal calculades, es podria requerir dedicar-hi més temps, la qual cosa implicaria un augment dels costos laborals. Al tenir un impacte mitja i tenir una probabilitat del 50%, es va decidir reservar per aquest imprevist el 50% del 50% de les tasques de desenvolupament D02-D08 que tenien un total de 4.400 €. Total: 1.100€ • Problemes tècnics (bugs i errors): El desenvolupament de programari sovint genera problemes tècnics i errors imprevistos que poden requerir més hores de depuració o fins i tot, reescriptura de codi. El seu impacte era baix, però amb un 90% de probabilitats, així que es va reservar el 25% del 90% de les tasques de depuració D10 amb un total de 365€. Total: 82€ • Problemes amb els recursos materials: En cas que els dispositius utilitzats es facin malbé durant el desenvolupament, s’hauran de substituir perquè són imprescindibles. Per calcular el cost, es va calcular la probabilitat que falles cada material, multiplicada pel seu preu inicial. Dispositiu % Fallada Cost inicial Cost Ordinador 2 500 € 10 € Pantalles 2 200 € * 2 8 € Ratolí 5 40 € 2 € Teclat 5 30 € 2 € Total 22 € Taula 8: Estimació de costos imprevistos. Font: Elaboració pròpia. Així doncs, el cost total per a costos imprevistos serà de 288 € + 1.100 € + 82 € + 22€ , fent un total de 1.492 €.
33 6.7. Pressupost final Tenint en compte tot l'anterior, a continuació es mostra una taula amb el resum dels costos totals. Tipus Cost Recursos humans 11,768 € Hardware 90 € Software 50 € Costos indirectes 300 € Contingències 1.832 € Imprevistos 1.492 € Total 15.532 € Taula 9: Pressupost final. Font: Elaboració pròpia. 6.8. Replanificació El projecte es va iniciar utilitzant el framework Next.js, però la manca de coneixement sobre aquesta tecnologia i la dificultat afegida haver de decidir que es podia ser renderitzat al servidor o al client, van fer que la corba d'aprenentatge fos elevada. Això va comportar la necessitat de començar el projecte de nou, aquest cop utilitzant React amb l'entorn Vite, fet que va derivar en la decisió de matricular-se a la convocatòria extraordinària i allargar el període de desenvolupament. A més, es va detectar que les hores inicialment assignades a les tasques no eren del tot ajustades, i es van haver de crear noves tasques. Aquesta situació ha requerit un revisar com això ha afectat a les partides del pressupost, diferenciant els costos entre: • Imprevistos: Si els riscos associats ja havien estat contemplats en la gestió de riscos. • Contingències: Si es tracta de despeses no previstes inicialment. 6.8.1. Recursos Humans: Es van haver d’afegir tres tasques noves: PD01, PD02 i PD03, amb un total de 55 hores. Tanmateix, es poden descomptar 5 hores de la tasca D01 i 10 hores de la D02, ja que la nova configuració de l'entorn amb Vite era més coneguda. El total net d’hores extres és, per tant, de 40 hores, equivalents a 800 €, que van destinar de la partida de contingències, ja que aquest imprevist no estava contemplat en la gestió de riscos. D’altra banda, es va comprovar que la tasca D04 (implementació de la partida bàsica) no disposava de prou hores per cobrir el desenvolupament del mode de joc en línia. Per aquest motiu, es va crear la nova tasca D05 (implementació del joc en línia), amb una durada de 40 hores (800 € addicionals). Com que aquest risc estava contemplat a la gestió de riscos, aquests 800 € es van carregar a la partida d'imprevistos.
34 6.8.2. Hardware L’augment de 80 hores de treball ha requerit un recalcul de l’amortització dels dispositius utilitzats. La fórmula aplicada ha estat: 𝐴𝑚𝑜𝑟𝑡𝑖𝑡𝑧𝑎𝑐𝑖ó = 𝐶𝑜𝑠𝑡 (€) ∗ 80 𝑉𝑖𝑑𝑎 ú𝑡𝑖𝑙 ∗ 220 ∗ 6 Dispositiu Cost Vida Útil Amortització Asus F555L 500 € 4 anys 8 € Monitor LG 200 € 5 anys 2 € Monitor Asus 200 € 5 anys 2 € Ratolí RGB Rainbow Gamming Kit 30 € 3 anys 1 € Teclat Logitech 40 € 3 anys 1 € Total 14 € Taula 10: Estimació de costos per recursos materials(2). Font: Elaboració pròpia. Aquest total de 14 €, es va agafar de la partida de contingències. 6.8.3. Software Pel que fa al software. L’únic que va augmentar va ser el compte de Railway, que és mensual, com que es van afegir 3 mesos per la matricula extraordinària es van agafar 15€ de la partida de contingències. 6.8.4. Costos Indirectes També cal recalcular els costos indirectes associats al temps addicional. Si per quatre mesos s’havien calculat 300 €, aplicant una regla de tres, per tres mesos més van ser 225 € que es van agafar de la partida de contingències. 6.8.5. Pressupost final replanificat Finalment podem veure que de la partida inicial de contingències de 1.832 € se’n van gastar 800 € de recursos humans, 14 € de hardware, 15 € de software i 225 € de costos indirectes, quedant així un total positiu de 778 €. Per la part de imprevistos, el total era de 1.492 i se’n van gastar 800€ de recursos humans, quedant un total positiu de 692€. Tipus Cost Recursos humans 13,368 € Hardware 104 € Software 65 € Costos indirectes 525 € Contingències 778 € Imprevistos 692 € Total 15.532 € Taula 11: Pressupost final replanificat. Font: Elaboració pròpia
35 6.9. Control de gestió És necessari establir mecanismes de control que permetin identificar desviacions inesperades i assegurar que es compleixin les previsions realitzades inicialment. Per tal de fer-ho, definirem uns indicadors que seran revisats i actualitzats de manera regular. Aquests indicadors inclouen: • Desviació del temps dedicat a una tasca: Aquesta mesura es calcula com a Hores estimades - Hores reals. Serveix per identificar si s'han dedicat més o menys temps del que es preveia inicialment, per a cada tasca. • Desviació de costos per tasca: S'obté a partir de la fórmula: (Hores estimades - Hores reals) * Cost per hora estimat. Aquest indicador ajuda a avaluar l'impacte econòmic de les desviacions en el temps dedicat a les tasques. • Desviació total dels costos generals: Es calcula restant el cost general real del cost general estimat: Cost general estimat – Cost general real. Permet veure si els costos generals del projecte s'ajusten a les previsions. • Desviació dels costos per imprevistos: Aquesta mesura compara el cost estimat per imprevistos amb el cost real d'aquests: Cost estimat per imprevistos – Cost real imprevistos. Ajuda a gestionar millor les reserves econòmiques destinades a imprevistos. • Desviació de les hores totals del projecte: Es calcula com a Hores estimades totals del projecte - Hores reals dedicades al projecte. Permet analitzar si el projecte avança segons el calendari previst. • Desviació de costos totals del projecte: Aquesta desviació s'obté de la resta entre el cost total estimat i el cost total real: Cost total estimat – Cost total real. Proporciona una visió general de la situació financera del projecte. Aquests indicadors permetran una gestió eficient del projecte, ajudant a identificar àrees que requereixen atenció i a prendre decisions informades per mantenir el projecte dins dels límits de temps i pressupost establerts.
36 7. Presa de Requisits Aquest apartat detalla el procés de presa de requisits, un pas fonamental per garantir que l'aplicació compleixi amb les necessitats dels usuaris. L'objectiu és identificar les funcionalitats essencials que han de formar part del desenvolupament inicial. 7.1. Presa de Requisits d'Usuari Per determinar els requisits de l'aplicació, es va dur a terme una anàlisi de necessitats basada en dues fonts principals: • Consulta amb usuaris recurrents de partides de dards, tant jugadors recreatius com professionals. • Anàlisi de plataformes de dards existents, identificant punts febles i oportunitats de millora en experiència d'usuari, funcionalitat i accessibilitat. A partir d'aquesta investigació, es van definir diferents rols d'usuari i els seus requisits específics. 7.1.1. Rols d’usuari Usuari (Jugador): • Registre, inici de sessió i gestió del perfil. • Creació i configuració de partides individuals amb opcions com puntuació inicial. • Participació en partides en línia amb sincronització en temps real. • Visualització de l'historial de partides i estadístiques personals. • Inscripció a lligues o tornejos en línia. • Visualització de resultats i calendaris de competicions. • Jugar partides programades de les competicions. Operador: • Creació i edició de tornejos i lligues. • Inici, gestió i fi de les competicions. • Gestió dels emparellaments de manera automàtica. • Revisió i ajustament de resultats, partits i classificacions. Administrador • Capacitat de poder modificar els rols dels usuaris. • Control total sobre l'aplicació.
37 7.1.2. Requisits funcionals principals Partides individuals: • Interfície senzilla i intuïtiva per facilitar el joc. • Marcadors clars, puntuació en gran per a cada jugador • Historial de torns. • Introducció senzilla de puntuacions i opció de correcció. • Diverses formes d'introduir puntuacions (teclat, botons, diana interactiva) Partides en línia: • Lobby inicial per poder triar contra qui jugar • Connexió estable amb sincronització en temps real. • Control automàtic del torn per evitar errors. • Opcions en finalitzar la partida: tornar a jugar, abandonar. • Restriccions de sortida: si s’abandona la partida un cop iniciada es donarà per perduda. • Temps de reconnexió: s’ha de permetre als jugadors recuperar la partida en cas de desconnexió temporal. Lligues i tornejos: • Crear emparellaments automàtics amb formats específics per lliga o torneig. • Classificació actualitzada en temps real • Possibilitat d’ajustar les regles i els formats de competició. 7.1.3. Requisits funcionals secundaris A llarg termini, l'aplicació podria integrar noves funcionalitats que millorin l'experiència de joc i l'organització de competicions: • Introducció a càmeres. • Opció perquè l’operador pugui revisar les partides en cas d'infracció. • Historial de partides per usuari. • Mode entrenament. • Possibilitat d'espectador en una partida en directe. • Sistema de pagaments integrat per a tornejos i lligues amb inscripció monetitzada. 7.1.4. Requisits no funcionals • Usabilitat: Interfície clara, visualment atractiva i adaptable. • Rendiment: Gestió eficient de múltiples usuaris i sincronització sense retards. • Seguretat: Protecció de dades i autenticació segura. • Escalabilitat: Capacitat de creixement i compatibilitat amb diferents dispositius.
38 7.2. Recerca i inspiració d'interfícies Per garantir una experiència d’usuari òptima i un disseny intuïtiu, es va realitzar una recerca prèvia analitzant diverses aplicacions relacionades amb els dards i altres plataformes que gestionen partides en línia. Aquesta investigació va permetre identificar bones pràctiques en la presentació de puntuacions, la gestió de partides i la navegació. 7.2.1. Inspiració d’interfícies d’altres aplicacions Per a la representació clara i senzilla de l'històric de torns, es va prendre com a referència Nakka, que destaca per la seva simplicitat en la visualització de dades. Es va tenir en compte que la informació sigui accessible d’un cop d’ull i que els jugadors puguin seguir fàcilment l’evolució de la partida. Il·lustració 8: Inspiració d’interfície evolució partida. Font: Nakka [3]. Per al sistema d’introducció de puntuacions, es va analitzar la interfície de DartCounter, que ofereix diverses opcions per introduir els punts de manera eficient i adaptable a diferents tipus de jugadors. Il·lustració 9: : Inspiració d’interfície, introducció de puntuacions. Font: DartCounter [4].
39 També es va prendre com a referència la mecànica de lobby en línia, on els jugadors poden crear una partida o unir-se a una ja existent, garantint una experiència fluida i fàcil d’utilitzar. Il·lustració 10: Inspiració d'interfície, lobby en línia. Font: DartCounter [4]. Pel que fa a l’estètica i l’elecció dels colors, es va prendre com a referència Chess [29], una aplicació per jugar a escacs en línia, tot i no ser una aplicació de dards, la seva estructura de gestió de partides en línia serveix com a referència. Chess destaca per la seva interfície simple i eficaç, per un disseny net, minimalista i intuïtiu. S’ha buscat que la interfície tingui una navegació senzilla i sigui visualment atractiva, amb botons grans i una paleta de colors que afavoreixi la comoditat visual. Il·lustració 11: Inspiració d’interfície, disseny. Font: Chess [29].
40 Aquesta investigació ha estat clau per definir una interfície clara, moderna i funcional, combinant les millors pràctiques de diverses aplicacions existents per adaptar-les a les necessitats específiques del projecte. 7.2.2. Principis de disseny adoptats A partir de l’anàlisi d’aquestes aplicacions, es van definir les següents directrius de disseny per a la nostra plataforma: Navegació senzilla i accessible: • Un menú lateral permanent amb les opcions principals per facilitar la navegació. • Una disposició dels elements clara i ordenada, evitant sobrecàrrega d'informació. Disseny optimitzat per a diferents dispositius: • Botons grans i fàcilment accessibles per garantir una bona experiència en tauletes i ordinadors. • Interfície responsive per adaptar-se a diferents pantalles i resolucions. • Estètica moderna i còmoda: • Una interfície fosca, similar a Chess, per millorar la llegibilitat i reduir la fatiga visual. • Ús de Tailwind CSS [26] per garantir coherència visual, flexibilitat i facilitat de personalització. Aquestes decisions asseguren que l’aplicació no només sigui funcional, sinó que també sigui agradable d’utilitzar, moderna i adaptable a les necessitats dels jugadors.
41 8. Disseny i implementació de l’aplicació Aquesta secció descriu l’arquitectura general de l’aplicació, la separació de responsabilitats entre capes i les tecnologies utilitzades per oferir una experiència de joc moderna, escalable i amb interacció en temps real. L'aplicació s’ha dissenyat seguint una arquitectura client-servidor, amb una clara separació entre el frontend i el backend. Ambdós es comuniquen mitjançant una API REST per a les operacions habituals, WebSockets per a la gestió en temps real de les partides i PeerJS [30] per a la transmissió de vídeo, assegurant així una experiència d'usuari fluïda i interactiva. A la figura següent es representa l'estructura de l'arquitectura: Il·lustració 12: Arquitectura general. Font: Elaboració pròpia.
48 Per implementar aquesta comunicació, s’utilitza Axios [35] ,una llibreria JavaScript basada en promeses per fer peticions HTTP des del navegador. Axios permet enviar dades al backend mitjançant mètodes com get, post, put o delete, i rebre’n les respostes de manera asíncrona. A més, s’ha definit una configuració comuna al fitxer api.js, on es configura una instància personalitzada d’Axios amb la URL base del backend i amb interceptors globals. Aquesta instància és reutilitzada per tots els serveis, i els interceptors actuen com a funcions que s’executen automàticament abans de cada petició o després de cada resposta. S’utilitzen per: • Injectar el token d’autenticació a cada petició (si n’hi ha). • Gestionar redireccions si el token ha expirat. • Registrar o modificar les respostes de l’API abans d’arribar als components. Aquesta estructura permet que totes les peticions siguin consistents i segures. Hooks personalitzats (Custom Hooks) Un hook és una funcionalitat pròpia de React que permet utilitzar característiques avançades com l’estat o els efectes secundaris dins de components funcionals, facilitant així una gestió més eficient i modular de la lògica de l’aplicació. S'han desenvolupat diversos hooks personalitzats per encapsular lògica reutilitzable i millorar la neteja del codi: • useGameEngine: Gestiona la lògica del motor de joc. • useGameSocket: Controla la interacció amb WebSockets dins del context de joc. • useAdvancedFilters: Aplica filtres avançats a llistats, com lligues o tornejos. Aquests hooks permeten simplificar la lògica dins dels components i fomentar la reutilització en diferents parts de l'aplicació. Comunicació amb el Backend La comunicació amb el backend es realitza de tres maneres: • API REST: Per operacions síncrones com autenticació, gestió de dades d'usuari, lligues o historial de partides. • WebSocket: Per funcionalitats en temps real com la sincronització de partides online. • PeerJS: Per la transmissió de vídeo en directe en les partides en línia. Les crides API passen sempre pels services, mentre que la connexió WebSocket és gestionada principalment des de l’SocketContext i reforçada per hooks especialitzats. La base de dades està completament encapsulada dins del backend, amb el frontend interactuant únicament a través dels canals establerts.
49 8.1.4. Navegació de l'aplicació Una navegació ben dissenyada es clau per oferir una experiència d'usuari fluïda, intuïtiva i segura. En aquest projecte, s'ha implementat un sistema de navegació basat en el concepte de SPA, utilitzant la llibreria React Router. React Router és una llibreria que permet definir i gestionar rutes dins d'una aplicació React de manera dinàmica, sense necessitat de recarregar la pàgina. Gràcies a aquesta eina, és possible crear una navegació estructurada, gestionar rutes protegides, redireccions, rutes dinàmiques i controlar l'accés a diferents vistes segons l'estat de l'usuari. Les rutes de l'aplicació s'han classificat segons les condicions d'accés, diferenciant entre: • Rutes públiques • Rutes nomes si l’usuari no està autenticat • Rutes nomes si l’usuari està autenticat • Rutes restringides per rol En cas que un usuari accedeixi a una ruta restringida sense permisos, es redirigeix automàticament a la pàgina de login o a un missatge d’error, segons el cas. La implementació detallada del sistema d'autenticació i la gestió de rols es descriu a l'apartat 8.5 Autenticació i Seguretat, més endavant. Un element clau per facilitar la navegació és el menú lateral anomenat Sidebar, present de forma fixa a tota l'aplicació. Aquest Sidebar permet un accés ràpid i constant a les seccions principals, adaptant les opcions visibles segons l'estat de l'usuari (autenticat o no) i permetent poder col·lapsar-la per optimitzar l’espai. Això garanteix que l'usuari sempre disposi d'una estructura clara per moure's per l'aplicació de manera eficient i segura. A continuació, es pot veure un diagrama que mostra el flux general de navegació dins de l'aplicació.
50 Il·lustració 14: Diagrama de navegació. Font: Elaboració pròpia. 8.1.5. Disseny visual i d’UX/UI Des del primer moment, el disseny de l’aplicació s’ha orientat cap a una interfície clara, moderna i coherent, prioritzant la simplicitat i l’ús d’un mode fosc per afavorir la comoditat visual durant un ús prolongat. S’ha utilitzat el framework Tailwind CSS, que ha permès definir estils de manera flexible i mantenir una línia visual uniforme a través de tota l’aplicació. Un altre aspecte fonamental ha estat la implementació d’un disseny responsiu, assegurant que l'aplicació sigui totalment funcional i accessible des de qualsevol dispositiu, ja sigui ordinador, tauleta o telèfon mòbil. Per aconseguir-ho, s’han utilitzat les utilitats de Tailwind CSS per adaptar dinàmicament la disposició dels elements i s'ha
51 dissenyat una versió específica de certes pàgines, per a pantalles petites, optimitzant l’experiència d’usuari en dispositius mòbils. A més, per millorar la comunicació entre l’aplicació i l’usuari, s’ha fet ús de notificacions tipus Toast i de modals de confirmació. Aquests elements ofereixen un feedback immediat no intrusiu, informant l’usuari sobre accions realitzades, errors o confirmacions necessàries, contribuint així a una experiència d’usuari més fluïda i controlada. A continuació es mostra una captura de pantalla de la pàgina principal, on es pot veure el disseny visual de l’aplicació, el menú lateral i l’estètica general basada en mode fosc. Per veure una visió completa de totes les pantalles i seccions implementades, es pot consultar l’Annex1, que recull exemples de les pàgines de joc, lligues, versió mòbil, i altres pantalles rellevants. Il·lustració 15: Disseny visual aplicació. Font: Elaboració pròpia.
52 8.2. Backend: Arquitectura i API REST El backend de l’aplicació ha estat desenvolupat utilitzant Node.js com a entorn d’execució i Express com a framework principal, seguint una arquitectura modular i escalable, dissenyada per gestionar de manera eficient múltiples connexions simultànies, especialment en contextos de comunicació en temps real. Paral·lelament, s'ha utilitzat Sequelize com a ORM per facilitar la interacció amb una base de dades relacional PostgreSQL, assegurant així una gestió robusta i eficient de la persistència de dades. 8.2.1. Node.js Per al desenvolupament del backend s'ha escollit Node.js, un entorn d’execució de JavaScript basat en el motor V8 de Google Chrome que permet executar codi al servidor. La seva arquitectura asíncrona i orientada a esdeveniments el fa especialment adequat per a aplicacions modernes que requereixen gestionar múltiples connexions simultànies de manera eficient, com és el cas de la comunicació en temps real mitjançant WebSockets. Les principals raons per triar Node.js han estat: • La seva capacitat per gestionar operacions d'I/O no bloquejants, es a dir, permet continuar atenent altres peticions mentre espera la resposta d’operacions com consultes a base de dades, millorant el rendiment en entorns amb molta concurrència. • La possibilitat de compartir el mateix llenguatge (JavaScript) entre frontend i backend, fet que simplifica la integració amb React/Vite i agilitza el desenvolupament. • El seu ampli ecosistema de llibreries disponibles a través de NPM, que facilita la implementació de funcionalitats diverses. • La seva escalabilitat, ideal tant per a projectes lleugers com per aplicacions més complexes. Durant la selecció de tecnologies, es van valorar altres opcions com ASP.NET (C#) [30], però es va descartar per la seva major complexitat, menor flexibilitat amb JavaScript i una arquitectura més pesada, poc adequada per a les necessitats d'aquest projecte. 8.2.2. Express Per construir l'API REST i gestionar el servidor, s'ha utilitzat Express, un framework minimalista per a Node.js. Express destaca per la seva simplicitat, flexibilitat i baix consum de recursos, permetent desenvolupar una arquitectura clara i modular sense imposar estructures rígides. Els avantatges que han motivat l'ús d'Express inclouen: • La gestió eficient de rutes i la possibilitat d'organitzar l'API de manera escalable. • El suport natiu per a middlewares, tant personalitzats com externs, que ha permès integrar funcionalitats com l'autenticació, la seguretat, la gestió d'errors i la configuració personalitzada. També s'ha fet ús de middlewares de tercers com cors per gestionar l’accés entre dominis. • La seva fàcil integració amb altres tecnologies com PostgreSQL, Sequelize i WebSockets, cobrint totes les necessitats del projecte.
53 • L'ampli suport comunitari i la compatibilitat amb nombrosos paquets disponibles a NPM. La combinació de Node.js i Express ha proporcionat una base lleugera, eficient i fàcilment extensible per al backend, assegurant un desenvolupament àgil i una integració òptima amb el frontend basat en React. 8.2.3. Estructura del backend A continuació es presenta el diagrama de l’estructura general del backend, on s’il·lustra com s’organitzen i interaccionen les diferents parts que composen el servidor de l'aplicació. Il·lustració 16: Arquitectura del backend, API REST. Font: Elaboració pròpia. Arquitectura API Rest El backend segueix un patró estructural inspirat en l’arquitectura tradicional Model-VistaControlador (MVC). En el context d'una API REST, on no es genera cap interfície visual, la "vista" es substitueix per respostes en format JSON, que són consumides pel frontend. Per aquest motiu, s’ha optat per una organització basada en la separació de Models, Controladors i Rutes, garantint una clara divisió de responsabilitats dins del sistema.
54 L'API REST desenvolupada amb Express.js, és la responsable de gestionar totes les peticions HTTP(S) provinents del frontend, seguint un flux estructurat i modular que garanteix la seguretat, la coherència i l'eficiència en el processament de les sol·licituds. Cada petició que arriba al servidor passa inicialment per una cadena de middlewares, tant globals com específics, encarregats de validar, interpretar i protegir la informació abans que la sol·licitud sigui dirigida cap a la seva ruta corresponent. Aquesta primera etapa garanteix que només les peticions correctament formades i autoritzades accedeixin a la lògica de negoci. El procés que segueix cada petició és el següent: Aplicació de Middlewares Externs • CORS Middleware: Controla l'accés entre dominis, permetent que només clients autoritzats puguin interactuar amb l'API. • Express JSON Middleware: Converteix automàticament el cos de les peticions en format JSON a objectes JavaScript, facilitant-ne la manipulació posterior. • Cookie Parser Middleware: Llegeix i interpreta les cookies enviades pel client, especialment útil per a la gestió de sessions i autenticació. Aplicació de Middlewares Propis • Authentication Middleware: Verifica la presència i validesa del token d'autenticació (JWT) en cada petició protegida, garantint que només usuaris autenticats accedeixin a determinades rutes. • Role Middleware: Comprova els permisos associats al rol de l'usuari (usuari, operador, administrador) abans de permetre l'execució de funcionalitats restringides. Gestió de Rutes (Routes) Un cop superats els middlewares, la petició es dirigeix a la Ruta corresponent segons l'endpoint sol·licitat. Cada ruta s'encarrega únicament de rebre la petició i redirigir-la cap al Controlador adequat, mantenint una estructura clara i desacoblada. Lògica de Negoci (Controllers) Els Controllers contenen la lògica principal de cada funcionalitat. Aquí es processen les dades rebudes, es realitzen les validacions necessàries i es gestionen les operacions principals de l'aplicació. Quan es requereix accés o modificació de dades persistents, els controllers interactuen amb els Models definits amb Sequelize. Accés a la Base de Dades (Models + Sequelize) Els Models representen l'estructura de les taules de la base de dades i permeten executar operacions com consultes, insercions o actualitzacions. Aquest accés es realitza mitjançant l'ORM Sequelize, que facilita la comunicació amb la base de dades relacional de manera abstracta i segura.
55 Transformació de Dades (DTOs) Abans d'enviar la resposta al client, les dades obtingudes es processen a través dels Data Transfer Objects (DTO’s). Aquesta capa s'encarrega de formatar i filtrar la informació, assegurant que només es retornin les dades necessàries, millorant la seguretat i l'eficiència en la comunicació amb el frontend. Gestió de la Resposta (Middleware ResponseHandler) Finalment, el ResponseHandler s'encarrega de gestionar totes les respostes de l'API, assegurant que segueixin un format comú amb camps com: • Succés: Camp booleà que indica si la petició ha estat correcte o no • Data: Objecte que conte les dades de resposta • Messages: Conte els missatges, ja sigui missatges d’errors o informatius. Aquest enfocament garanteix una comunicació clara i uniforme amb el client, simplificant la gestió d'errors i l'anàlisi de les respostes per part del frontend.
56 8.3. Base de dades L’aplicació utilitza una base de dades relacional per gestionar la persistència d'informació de manera estructurada i segura. Aquest model permet definir relacions clares entre entitats, assegurant la coherència i integritat referencial, a més de facilitar consultes eficients i escalables. Les necessitats principals del projecte inclouen: • La gestió d'usuaris i els seus rols. • L'enregistrament de partides, torns i resultats. • L'administració de lligues i classificacions. • El càlcul i emmagatzematge d'estadístiques per a cada jugador. Per cobrir aquests requisits, s'ha optat per utilitzar un sistema robust i escalable, capaç de gestionar volums creixents de dades i mantenir un alt rendiment. 8.3.1. PostgreSQL S’ha escollit PostgreSQL com a Sistema de Gestió de Base de Dades (SGBD) per la seva fiabilitat, potència i excel·lent suport per a estructures i relacions complexes. PostgreSQL és una solució de codi obert àmpliament reconeguda, ideal per garantir la integritat de les dades i suportar entorns amb alta concurrència. Durant el procés de selecció es van valorar altres opcions, com es mostra a continuació: Sistema Característiques Inconvenients MySQL Popular i fàcil d'utilitzar. Bon rendiment en consultes simples. Menys optimitzat per consultes complexes i alta concurrència. MongoDB Base de dades NoSQL, flexible i escalable. No és relacional, fet que hagués complicat la gestió de lligues i estadístiques. Taula 14: Comparació sistemes de bases de dades. Font: Elaboració pròpia. En la següent taula podem veure que PostgreSQL ofereix el millor equilibri entre estructura relacional, escalabilitat i rendiment, fet que el converteix en la millor opció per aquest projecte. 8.3.2. Sequelize Per facilitar la interacció entre el backend i la base de dades, s’ha utilitzat Sequelize, un ORM (Object-Relational Mapping). Aquesta eina permet gestionar la base de dades mitjançant models definits en JavaScript, evitant l'escriptura directa de consultes SQL. Els avantatges de l'ús de Sequelize són: • Simplificació de la gestió de taules: La definició de models en codi facilita la creació i manteniment de l'estructura de la base de dades. • Definició clara de relacions: Permet establir relacions 1:1, 1:N i N:M d'una manera intuïtiva i coherent amb la lògica de l'aplicació. • Facilitat per a migracions: Gestiona els canvis en l'esquema de la base de dades de forma controlada.
57 • Millora de la seguretat: Protegeix contra injeccions SQL gràcies a l'ús de consultes preparades. • Integració natural amb Node.js: Al estar desenvolupat en JavaScript, encaixa perfectament amb l'ecosistema de l'aplicació. L'ús de Sequelize ha permès mantenir una arquitectura neta i mantenible, alhora que es garanteix una comunicació eficient amb la base de dades. 8.3.3. Estructura de la base de dades El model de dades del projecte segueix una estructura relacional, dissenyada per garantir la coherència i facilitar la gestió de les entitats principals de l'aplicació. Les principals taules del model són: • Users: Gestiona la informació dels usuaris. • Games: Emmagatzema les dades de les partides. • Turns: Registra cada torn jugat. • Stats: Guarda les estadístiques dels jugadors. • Leagues: Gestiona les lligues. • League_Users: Gestiona els usuaris inscrits en una lliga i la seva classificació. • Tournaments: Gestiona els tornejos. • Tournament_Users: Gestiona els usuaris inscrits en un torneig. A continuació es mostra el diagrama entitat-relació (ER) que representa gràficament l’estructura de la base de dades i les relacions entre les taules principals del sistema.
64 8.5. Comuniacio P2P amb PeerJS Per complementar la comunicació en temps real basada en WebSockets, l’aplicació incorpora PeerJS com a solució per a connexions peer-to-peer (P2P) entre usuaris. Aquesta arquitectura resulta especialment útil per a la transmissió de dades multimèdia com l’àudio o el vídeo (per exemple, si els jugadors comparteixen imatge de càmera durant una partida), ja que evita passar tota la informació pel servidor central, reduint la latència i l’ús de recursos. PeerJS és una llibreria que simplifica la creació de connexions WebRTC entre navegadors. A diferència dels WebSockets, que mantenen una connexió centralitzada amb el servidor, WebRTC permet una comunicació directa entre clients, després d’una fase d’intercanvi de senyals (signaling). El procés general és el següent: • Creació del Peer: Cada usuari crea una instància Peer amb un identificador únic. • Intercanvi de senyals (signaling): Mitjançant el servidor PeerJS i la connexió WebSocket prèviament establerta, els usuaris s’intercanvien la informació necessària per establir una connexió directa. • Connexió P2P: Un cop establerta, la comunicació entre usuaris es realitza directament, sense passar pel backend. • Transmissió de dades: Es poden enviar fluxos de vídeo, àudio o qualsevol altre tipus d’informació en temps real. El servidor PeerJS s’ha desplegat com una instància pròpia dins la infraestructura del backend, funcionant de forma paral·lela al servidor de WebSockets. Aquest servidor actua com a intermediari únicament durant la fase d’inici de connexió (signaling), però no transmet dades un cop la connexió s’ha establert correctament. Beneficis de PeerJS: • Eficiència: La transmissió directa redueix la càrrega del servidor central. • Baixa latència: Millora la fluïdesa de les comunicacions multimèdia. • Escalabilitat: Redueix els colls d’ampolla al backend en escenaris amb molts usuaris. • Simultaneïtat: Permet establir múltiples connexions P2P independents.
65 8.6. Autenticació i Seguretat L’aplicació implementa un sistema d’autenticació basat en JSON Web Tokens (JWT) combinat amb cookies HttpOnly per garantir la seguretat i evitar vulnerabilitats com el Cross-Site Scripting (XSS) i el Robatori de tokens (Token Theft). S’ha prioritzat la seguretat en tots els processos d’autenticació, incorporant un sistema de Refresh Token, gestió de sessions, protecció de connexions WebSocket, encriptació segura de contrasenyes i mecanismes de recuperació de comptes. A continuació, es descriuen les principals mesures i fluxos de seguretat. 8.6.1. JSON Web Tokens (JWT) JWT és un estàndard d’autenticació basat en tokens que permet verificar la identitat d’un usuari de manera segura i escalable. Algunes de les seves característiques més importants són: • Autenticació sense estat (Stateless): No requereix emmagatzemar sessions al servidor, ja que el token conté la informació necessària. • Seguretat millorada amb signatura digital: Utilitza HMAC SHA256 per signar els tokens, evitant manipulacions. • Escalabilitat: permet balancejar peticions entre múltiples servidors sense sincronitzar sessions. A més, els tokens tenen un temps de vida limitat i s'invalida automàticament el seu ús un cop expiren, reforçant la seguretat. 8.6.2. Emmagatzematge del token: Cookies HttpOnly Per evitar vulnerabilitats com XSS i Token Theft, quan un usuari inicia sessió, el servidor genera els JWT i els envia el client mitjançant cookies HttpOnly. Les avantatges de fer servir cookies HttpOnly són: • Inaccessibles des de JavaScript: Protecció automàtica contra scripts maliciosos. • Manejament automàtic: El navegador s'encarrega d'incloure la cookie a cada petició al servidor, el qual valida el JWT que conte a traves del middleware d’autenticacio. • Més seguretat: El token no queda exposat al client evitant el Robatori de tokens. S’ha descartat l’ús de localStorage o sessionStorage degut al risc inherent de ser llegits en cas d'un atac XSS. 8.6.3. Flux d’autenticació en API REST i renovació de tokens L’aplicació utilitza dos tipus de tokens per gestionar la sessió: • Access Token: Té una durada curta (1 hora) i s’envia en cada petició al backend que valida que sigui correcte. • Refresh Token: Té una durada més llarga (1 dia) i serveix per obtenir un nou Access Token quan aquest caduca.
66 Mecanisme de renovació de tokens: • Quan l’Access Token caduca, la següent petició al backend retorna un error 401 Unauthorized. • L’interceptor d’api.js detecta aquest error i fa una petició al backend a un endpoint de regeneració de token, enviant el Refresh Token per obtenir un nou Access Token. • Si el Refresh Token és vàlid, el backend genera un nou Access Token i es torna a fer la petició inicial. • Si el Refresh Token ha caducat o és invàlid, l’usuari és desconnectat i redirigit al login. 8.6.4. Autenticació i Seguretat en WebSockets Per garantir la seguretat en les connexions WebSocket, igual que en l’API rest, s’utilitza un sistema de validació basat en JWT. Això impedeix que usuaris no autoritzats puguin establir connexions WebSocket sense una sessió vàlida. Quan el client intenta establir una connexió WebSocket amb el servidor, ha d’incloure l'Access Token en la petició de connexió. • El servidor WebSocket valida el token abans de permetre la connexió mitjançant el middleware d’autenticacio. • Si el token és vàlid, la connexió WebSocket s’estableix i l’usuari pot interactuar amb el servidor. • Si el token no és vàlid o ha expirat, la connexió WebSocket es rebutja i el client ha de reautenticar-se. Aquest mecanisme assegura que només els usuaris autenticats puguin utilitzar les funcionalitats en temps real i evita connexions no autoritzades o atacs malintencionats. 8.6.5. Tipus d'inici de sessió: Usuari i Google OAuth L’aplicació permet dos tipus d'inici de sessió: Inici de sessió amb Usuari i Contrasenya: • L’usuari pot registrar-se mitjançant un nom d’usuari, un correu electrònic i una contrasenya. • La contrasenya es guarda de manera segura a la base de dades mitjançant l’algorisme bcrypt [37] un algorisme de hashing especialment dissenyat per a aplicacions de seguretat. • bcrypt aplica un procés de salting i hashing iteratiu per dificultar atacs per força bruta o per diccionari. El salting afegeix un valor aleatori únic a cada contrasenya abans de fer-ne el hash, de manera que dues contrasenyes iguals generen resultats diferents. El hash resultant conté aquest salt, cosa que permet validar la contrasenya quan l’usuari inicia sessió. • Durant l’autenticació, quan l’usuari introdueix les credencials, el servidor fa servir aquest salt inclòs en el hash guardat per aplicar el mateix procés a la nova contrasenya i comparar si els resultats coincideixen. Això assegura que el sistema
67 pugui verificar correctament la identitat de l’usuari tot i que els hash siguin diferents per contrasenyes iguals. • Un cop verificades les credencials, el servidor genera un JWT (JSON Web Token) i l’envia al client dins d’una cookie HttpOnly, que no pot ser accedida des de JavaScript per evitar atacs de tipus XSS. Inici de sessió amb Google OAuth: • L’usuari pot autenticar-se mitjançant el seu compte de Google. • Un cop autenticat amb Google, aquest retorna un ID Token, que el frontend envia al servidor. • El backend valida aquest token a través de la pròpia API de Google. • Si l’email del token coincideix amb un usuari existent a la base de dades, es reutilitza aquest usuari. Si no, es crea un nou usuari automàticament, sense necessitat d’establir una contrasenya. • Finalment, el servidor genera el JWT i l’envia igualment en una cookie HttpOnly, mantenint la seguretat i consistència amb l’altre mètode d’autenticació. Ambdós fluxos comparteixen el mateix mecanisme de sessió i gestió de tokens, però la diferència principal es el procés inicial de validació de credencials. En el diagrama següent podem veure el flux que segueix l'inici de sessió i la vida dels tokens, tant si és amb Google OAuth o amb inici de sessió tradicional. Il·lustració 21: Fluxe d'autenticacio. Font: Elaboració propia 8.6.6. Recuperació i canvi de contrasenya En cas que un usuari oblidi la seva contrasenya, el sistema permet iniciar un procés de recuperació segur. Quan l'usuari sol·licita la recuperació, es genera un token aleatori associat al seu compte, amb una data de caducitat limitada. Aquest token es registra a la base de dades i s'envia per correu electrònic a l'usuari, juntament amb un enllaç per accedir al formulari de canvi de contrasenya. Si l'usuari utilitza l'enllaç dins el període de validesa del token, podrà introduir una nova contrasenya. Un cop la contrasenya es canvia
68 o el token caduca, aquest queda invalidat automàticament, evitant-ne l'ús posterior i garantint la seguretat del procés. Pel que fa al canvi de contrasenya per part d'usuaris autenticats, el sistema requereix que es validi la contrasenya actual abans de permetre definir una nova contrasenya. Aquesta nova contrasenya es xifra mitjançant l'algoritme Bcrypt, aplicant un salt únic per a cada registre, fet que reforça la protecció contra atacs de força bruta i altres intents de comprometre les credencials. 8.6.7. Eliminació d’usuaris Quan un usuari sol·licita eliminar el seu compte, el sistema duu a terme un procés d'eliminació segura de les seves dades personals. Concretament, s'esborren les dades sensibles, com la contrasenya i el correu electrònic associat al compte. A més, el nom d'usuari es reemplaça pel nom genèric "Jugador Eliminat", assegurant així que no es pugui identificar la persona original. Tot i això, per tal de mantenir la integritat i coherència de les dades històriques del sistema, especialment en partides disputades o lligues organitzades, el registre de l'usuari no s'elimina completament de la base de dades. Aquest enfocament permet preservar la traçabilitat de les interaccions i resultats dins de l'aplicació, tot garantint la protecció de la privacitat de l'usuari.
69 9. Entorn de desplegament L’aplicació està desplegada en un entorn cloud, utilitzant serveis que proporcionen una solució eficient per al desenvolupament i proves. Actualment, s’ha optat per: • Netlify: per al frontend, ja que la seva versió gratuïta és suficient per a les necessitats del projecte. • Railway: per al backend i la base de dades, ja que permet desplegar aplicacions backend i bases de dades sense costos inicials i amb un procés de configuració ràpid i senzill. Tot i això, aquestes versions inicials, són suficients per al projecte, però no per una aplicació en producció. En el futur, es podria passar a una versió de pagament de Netlify i Railway, però són opcions bastant cares, per tant, la intenció en un futur és migrar l’aplicació a un servidor propi o a una infraestructura més robusta com Amazon Web Service (AWS) [38], per millorar el control, la seguretat i la capacitat d'escalabilitat. 9.1. Frontend – Netlify El frontend, desenvolupat amb React i Vite, està desplegat a Netlify, aprofitant les seves funcionalitats de CDN global, desplegament automàtic i integració contínua amb GitHub. • Desplegament ràpid i senzill amb integració automàtica. • CDN global per millorar la velocitat de càrrega. • Certificat HTTPS automàtic amb Let's Encrypt. S’ha adquirit un domini personalitzat 9Darts, vinculat a Netlify. El certificat HTTPS s’activa automàticament mitjançant Let's Encrypt. Totes les connexions HTTP es redirigeixen a HTTPS per evitar comunicacions insegures. 9.2. Backend – Railway El backend, desenvolupat amb Node.js i Express, està desplegat a Railway, que ofereix desplegament automàtic i escalabilitat. • Desplegament fàcil i gestió de bases de dades integrada. • Variables d'entorn protegides per seguretat. • Railway proporciona connexions HTTPS, protegint les comunicacions.
70 9.3. Base de dades – Railway (PostgreSQL) Railway també allotja la base de dades PostgreSQL, cosa que permet un accés ràpid i segur. • Connexions encriptades mitjançant TLS. • Backups automàtics per protegir la informació. • Limitació d'accés només al backend de l’aplicació. 9.4. Domini - DonDominio Per aquest projecte s’ha adquirit el domini 9darts.es a través del servei DonDominio, que s'ha utilitzat tant per a la gestió de DNS com per al correu electrònic associat al projecte. A través de DonDominio s’han configurat els servidors DNS, utilitzant els següents servidors per defecte (ns1.dondominio.com, ns2.dondominio.com) A la configuració DNS s’han creat les següents entrades: CNAME • *.9darts.es → Redirigeix qualsevol subdomini no definit al domini principal allotjat a Netlify, assegurant que totes les rutes i subrutes funcionin correctament en el frontend. • api.9darts.es → Apunta al backend allotjat a Railway, mantenint el mateix domini base que el frontend i evitant problemes amb les cookies segures (HttpOnly) i les polítiques CORS. ANAME • 9darts.es → Aquesta entrada apunta directament al domini base proporcionat per Netlify. L’ús de l’ANAME permet redirigir el domini arrel (@) a una adreça IP gestionada per Netlify, assegurant una càrrega directa de la pàgina principal. A més, s’ha configurat un compte de correu electrònic associat al domini a través del propi panell de DonDominio, permetent la gestió de comunicacions oficials del projecte. Per a l’enviament de correus electrònics des de l’aplicació (per exemple, notificacions, recuperació de contrasenya, etc.), s’ha configurat un servidor SMTP amb les dades proporcionades per DonDominio. Aquesta integració permet enviar correus de manera segura i professional amb el domini propi @9darts.es.
71 9.5. Futur – Migració a un servidor propi A mesura que l’aplicació creixi, es podria considerar migrar a un entorn més robust, com per exemple AWS, per obtenir més control i escalabilitat. En un servidor propi, el certificat HTTPS ja no es gestionaria automàticament com en Netlify, per la qual cosa caldria generar un certificat SSL/TLS amb Let's Encrypt per gestionar les connexions segures i automatitzar la renovació del certificat mitjançant Certbot. Pel que fa a la gestió de variables d’entorn, mentre que Railway les administra automàticament, en un servidor propi caldria desar les credencials en fitxers variables d’entorn segures, utilitzar un gestor de secrets com AWS Secrets Manager o Vault, i evitar exposar informació delicada en el codi, establint permisos adequats. Si el frontend i el backend es despleguen en el mateix servidor, es poden millorar la seguretat i el rendiment establint les connexions internes en HTTP en lloc d’HTTPS, ja que es comunicarien dins del mateix entorn. També es pot bloquejar l’accés públic al backend, configurant-lo perquè només accepti connexions des de la mateixa aplicació i no des d’Internet, i implementar un firewall que limiti l’accés extern a la base de dades, permetent només connexions des del backend. Finalment, en un servidor propi caldria gestionar la càrrega de peticions utilitzant un balancejador de càrrega si hi ha diversos servidors, i monitoritzar l’ús de recursos per optimitzar l’escalabilitat de l’aplicació. 9.6. Seguretat informàtica El projecte ha adoptat diverses mesures de seguretat per protegir la informació dels usuaris i garantir la integritat i confidencialitat de les dades, d'acord amb les bones pràctiques habituals en el desenvolupament d'aplicacions web modernes. Les mesures implementades són les següents: • Protecció contra injeccions SQL: S'ha utilitzat l'ORM Sequelize per gestionar totes les interaccions amb la base de dades PostgreSQL. Aquest ORM evita la concatenació manual de consultes SQL i protegeix contra atacs d'injecció mitjançant parametrització automàtica de consultes. • Gestió segura de contrasenyes: Les contrasenyes es guarden de forma segura amb l’algorisme bcryptjs, que aplica salting i hashing iteratiu per dificultar atacs i garantir que cada contrasenya tingui un hash únic. Durant l’autenticació, es compara el hash generat amb el guardat, sense desencriptar la contrasenya original. • Autenticació robusta: L’autenticació es gestiona mitjançant JSON Web Tokens (JWT) emmagatzemats en cookies HttpOnly, protegint les sessions contra atacs XSS i permetent una gestió sense estat. També es contempla la futura incorporació de refresh tokens per millorar la persistència i la seguretat. • Seguretat en les comunicacions: Totes les comunicacions entre el navegador i el servidor es fan via HTTPS. El certificat SSL/TLS és proporcionat automàticament per Let's Encrypt tant a Netlify com a Railway, assegurant que les dades es transmetin de manera encriptada i protegida contra intercepcions. Railway també assegura connexions HTTPS amb TLS per a l'API REST i la base de dades.
72 • Gestió de variables sensibles: Les variables d’entorn amb informació sensible (com claus d'API o secrets JWT) es gestionen mitjançant el sistema de configuració de Railway. En un futur, amb un servidor propi, es recomana utilitzar un gestor de secrets, com AWS Secrets Manager o HashiCorp Vault. • Política CORS i SameSite: S’han definit polítiques CORS restrictives per evitar accessos no autoritzats des d’orígens desconeguts. Les cookies s’envien amb l’opció SameSite=Strict per evitar atacs CSRF, combinades amb Secure per garantir la seva transmissió només sota HTTPS.
73 10. Lleis i regulacions Durant el desenvolupament del projecte es van tenir en compte diverses lleis i normatives aplicables per tal d'assegurar-ne la legalitat i la seguretat. Concretament, les següents normatives són rellevants per al projecte: 10.1. RGPD El Reglament general de protecció de dades (RGPD) [38] és una normativa europea que regula la recollida, emmagatzematge i tractament de dades personals dels usuaris, amb l'objectiu de garantir-ne la seguretat, privacitat i drets fonamentals. Aquesta normativa requereix una gestió responsable de les dades personals, proporcionant mecanismes perquè els usuaris puguin accedir, rectificar o suprimir les seves dades. 10.2. LSSI-CE La Llei de serveis de la societat de la informació i comerç electrònic (LSSI-CE) [40] és una normativa espanyola que regula els aspectes legals dels serveis digitals oferts per mitjans electrònics. Aquesta llei obliga a proporcionar clarament informació sobre la identitat del proveïdor del servei, així com documents legals com l'avís legal, condicions d'ús i política de privacitat. 10.3. Llicències de programari i propietat intel·lectual Durant el desenvolupament del projecte s'han utilitzat llibreries i frameworks externs, especialment React, Express, Sequelize, Vite i altres dependències secundàries com Socket.io, TailwindCSS i bcryptjs. La revisió de les llicències s'ha realitzat consultant explícitament les pàgines oficials dels projectes i els seus repositoris de GitHub, confirmant que totes aquestes llibreries utilitzen la llicència MIT [41] . Aquesta llicència és molt permissiva i permet utilitzar, modificar i distribuir el programari de manera oberta i senzilla, sense restriccions significatives per a projectes personals, acadèmics o comercials. 10.4. Política de cookies L'aplicació fa servir cookies HttpOnly per gestionar la sessió de l'usuari, incrementant així la seguretat i protegint les dades personals, ja que no poden ser accedides directament per scripts des del navegador. En aquest sentit, segons la normativa de la Agencia Española de Protección de Datos [42], les cookies tècniques (com per exemple les cookies HttpOnly per la gestió de la sessió) no requereixen consentiment, només informació clara.
80 [30] PeerJS. URL: https://peerjs.com/ [31] Sequelize. URL: https://sequelize.org/ [32] Angular. URL: https://angular.dev/ [33] Vue. URL: https://vuejs.org/ [34] Create React App. URL: https://create-react-app.dev/docs/getting-started/ [35] Axios. URL: https://axios-http.com/es/docs/intro [36] ASP.NET. URL: https://dotnet.microsoft.com/es-es/learn/aspnet/what-is-aspnet [37] bcryptjs. Llicència de programari. URL: https://github.com/dcodeIO/bcrypt.js/blob/master/LICENSE [38] Amazon Web Services. URL: https://aws.amazon.com/ [39] Reglament General de Protecció de Dades (RGPD). URL: https://eurlex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32016R0679 [40] Llei de Serveis de la Societat de la Informació i Comerç Electrònic (LSSI-CE). URL: https://www.boe.es/buscar/act.php?id=BOE-A-2002-13758 [41] MIT License. URL: https://opensource.org/licenses/MIT [42] Agencia Española de Protección de Datos (AEPD). Guia sobre cookies. URL: https://www.aepd.es/sites/default/files/2020-07/guia-cookies.pdf
81 15. Annex1 – Visualització imatges aplicació Figura 1 – Pantalla d'inici amb el sidebar obert Figura 2 – Formulari d'inici de sessió amb el sidebar col·lapsat Figura 3 – Missatge d'error a l'iniciar sessió
82 Figura 4 – Formulari de registre d'usuari Figura 5 – Configuració d'una partida local Figura 6 – Pantalla de joc amb diana interactiva
83 Figura 7 – Pantalla de joc amb introducció de puntuació per botons Figura 8 – Pantalla de joc amb introducció de puntuació total Figura 9 – Mode mòbil amb diana
84 Figura 10 – Mode mòbil amb taula de torns Figura 11 – Missatge de confirmació per abandonar la partida Figura 12 – Pantalla del lobby online
85 Figura 13 – Invitació de partida online Figura 14 – Partida online amb càmeres dels jugadors Figura 15 – Estadístiques d'una partida finalitzada
86 Figura 16 – Vista de llistat de lligues amb filtres Figura 17 – Formulari de creació de lliga Figura 18 – Detall de lliga amb classificació
87 Figura 19 – Selecció de jornada en una lliga Figura 20 – Vista de tornejos amb filtres Figura 22 – Formulari de creació de torneig
88 Figura 23 – Detall del torneig amb jugadors inscrits Figura 24 – Quadre del torneig amb encreuaments Figura 25 – Perfil d’usuari amb estadístiques i partides
89 Figura 26 – Configuració del perfil d’usuari Figura 27 – Canvi de contrasenya Figura 28 – Eliminar compte