Desenvolupament de cua d'espera de peticions web
Full text
id193336 DESENVOLUPAMENT DE CUA D'ESPERA DE PETICIONS WEB MARC RODRIGUEZ MARTIN Director/a VÍCTORFERRUSOLAIJORDÀ(CONSORCIPERALANORMALITZACIOLINGUISTICA.CCT.) Ponent:CARLESFARRETOST(Departamentd'EnginyeriadeServeisiSistemesd'Informació) Titulació GrauenEnginyeriaInformàtica(EnginyeriadelSoftware) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 23/01/2025
1. Context......................................................................................................................................................3 1.1 Introducció.......................................................................................................................................3 1.2 Definicions.......................................................................................................................................3 1.3 Problema a resoldre.......................................................................................................................4 1.4 Actors implicats..............................................................................................................................4 2. Justificació............................................................................................................................................... 6 2.1 Estudis previs..................................................................................................................................6 2.2 Justificació......................................................................................................................................7 3. Abast..........................................................................................................................................................9 3.1 Objectius i subobjectius................................................................................................................9 3.2 Requisits.......................................................................................................................................... 9 3.3 Obstacles i riscos potencials.....................................................................................................10 4. Metodologia i rigor................................................................................................................................12 4.1 Metodología..................................................................................................................................12 4.2 Validació........................................................................................................................................ 14 5. Planificació inicial..................................................................................................................................15 5.1 Descripció de les tasques.......................................................................................................... 15 5.1.1 Introducció.................................................................................................................................15 5.1.2 Tasques......................................................................................................................................15 5.1.3 Recursos.................................................................................................................................... 17 5.2 Taula i Gantt..................................................................................................................................19 5.2.1 Taula de tasques.......................................................................................................................19 5.2.2 Diagrama de Gantt................................................................................................................... 20 5.3 Gestió del risc: Plans alternatius i obstacles..........................................................................21 5.3.1 Introducció.................................................................................................................................21 5.3.2 Inexperiència en les tecnologies necessàries.....................................................................21 5.3.3 Calendari tancat........................................................................................................................22 5.4 Pressupost....................................................................................................................................23 5.4.1 Identificació dels costos......................................................................................................... 23 5.4.2 Costos de personal per activitat............................................................................................23 5.4.3 Costos generals........................................................................................................................25 5.4.4 Contingències i imprevistos................................................................................................... 26 5.4.5 Control de gestió.......................................................................................................................27 6. Informe de sostenibilitat......................................................................................................................28 6.1 Autoavaluació...............................................................................................................................28 6.2 Dimensió econòmica.................................................................................................................. 29 6.3 Dimensió Ambiental....................................................................................................................29
6.4 Dimensió Social............................................................................................................................30 7. Cua d’espera de peticions web...........................................................................................................31 7.1 Introducció.................................................................................................................................... 31 7.2 Vista lógica....................................................................................................................................31 7.3 Arquitectura...................................................................................................................................34 7.4 Serveis AWS..................................................................................................................................35 7.5 Plantilles Amazon Cloudformation...........................................................................................38 7.6 Documentació API pública.........................................................................................................44 7.7 API privada....................................................................................................................................46 7.8 Diagrames de seqüència............................................................................................................48 7.9 Modificacions i implementació.................................................................................................52 7.10 Proves i validació.......................................................................................................................59 7.11 Possibles millores......................................................................................................................60 7.12 Conclusió.................................................................................................................................... 60 8. Aplicació Web........................................................................................................................................ 60 8.1 Introducció.................................................................................................................................... 60 8.2 Arquitectura...................................................................................................................................61 8.3 Disseny extern..............................................................................................................................61 8.4 Disseny intern...............................................................................................................................63 11.5 Proves i validació.......................................................................................................................64 8.6 Conclusió.......................................................................................................................................65 9. Identificació de lleis i regulacions......................................................................................................66 10. Resultat final del projecte..................................................................................................................67 10.1 Planificació final.........................................................................................................................67 10.2 Pressupost final.........................................................................................................................68 11. Conclusions.........................................................................................................................................70 11.1 Reflexió........................................................................................................................................70 11.2 Competencies............................................................................................................................70 12. Referències.......................................................................................................................................... 72 1
1. Context 1.1 Introducció Aquest projecte, “Desenvolupament d’una cua d’espera de peticions web”, es tracta del treball de fi de grau de la Facultat d’Informàtica de Barcelona (FIB). Aquest projecte té com a objectiu posar en pràctica els coneixements i habilitats adquirides durant la carrera, i específicament l’especialitat escollida, en aquest cas la d’enginyeria del software. Aquest treball està fet en modalitat B, i per tant en col·laboració amb una empresa externa. Aquesta empresa és el Consorci per a la Normalització Lingüística (CPNL), una institució formada per la Generalitat de Catalunya que té com a objectiu facilitar i promoure l’ús del català a la població adulta de Catalunya mitjançant cursos adreçats, tant a la ciutadania en general, com a col·lectius concrets. A través d’aquests cursos es fomenta l’ensenyament, la igualtat d’oportunitats, la cohesió social i l’ús professional, disponibilitat i oferta en català per promoure-hi l’ús i la qualitat de la llengua catalana. A raó de la gran quantitat d’usuaris, entre alumnes i professors, que té el CPNL, és important tenir un sistema que gestioni de manera eficient aquest volum d’usuaris. Aquest projecte tracta de solucionar aquest problema amb una cua d’espera de peticions web que actuï quan un gran volum d’usuaris vulguin accedir simultàniament a un mateix servei. Protegint els sistemes i millorant l’experiència d’usuari amb la informació necessària. 1.2 Definicions ● CNL: Centre de Normalització Lingüística. Els CNL són centres d'ensenyament de català que poden englobar altres centres. Sol haver-hi només un per comarca. ● SLC: Servei Local de Català. Els SLC són punts de servei d’ensenyament de català que són a dins d’una xarxa d’un CNL. ● OC: Oficina de Català. Els OC són, com els SLC, punts de servei d’ensenyament de català que formen part d’una xarxa d’un CNL. Aquestes oficines tenen un tamany menor que els SLC. 2
● ADP: Administració Digital i Processos. Fa referència a la unitat dins del Servei TIC del CPNL. Aquesta unitat s'encarrega d'entendre les necessitats del negoci, conèixer els seus processos i estratègies i de traduir-les en solucions tecnològiques òptimes i eficients. 1.3 Problema a resoldre El Consorci per a la Normalització Lingüística[1] actualment té una estructura de 22 centres de normalització lingüística i disposa de més de 140 punts de servei entre els diversos SLC i OC. Això es tradueix en milers d’usuaris que han de gestionar els diferents serveis informàtics del CPNL a l’hora de fer els diversos tràmits com inscripcions, proves de nivell i diferents tipus de sol·licituds. Tenint en compte el gran volum d’usuaris que poden tenir els diferents serveis de l’empresa en un moment determinat, és important tenir un sistema que reguli el flux dels usuaris de manera ordenada per, d’una banda, protegir i dimensionar els sistemes, i per l’altra banda garantir una bona experiència d’usuari, donant suficient informació i evitant caigudes del servei. D’aquesta manera, la solució pretén donar aquestes garanties amb una cua d’espera virtual que redirigeixi als usuaris a una altra pàgina on estiguin informats de la seva posició, el seu temps d’espera aproximat i la seva posició a la cua. 1.4 Actors implicats ● Treballadors: Tots els treballadors del CPNL que poden accedir a qualsevol tràmit poden passar per alguna cua d’espera en algun moment determinat. Poden ser professors, directius, administratius… ● Alumnes: Els alumnes del CPNL poden passar per una cua d’espera en algun moment dels seus tràmits. ● Unitat ADP del Consorci: La unitat dels Serveis TIC del CPNL més interessada en aquest projecte, que un cop finalitzat, el podrà integrar el podrà integrar amb les seves estructures. 3
● Desenvolupador: L’autor del mateix projecte. 4
2. Justificació 2.1 Estudis previs Actualment, el sistema utilitzat al Consorci per gestionar el flux de peticions web és Queue-it[2], una empresa que ofereix una solució per controlar el tràfic al teu lloc web durant esdeveniments de gran demanda. El seu servei principal és una cua virtual que s’implementa per evitar que un lloc web col·lapsi quan intenten accedir un gran nombre d’usuaris simultàniament. Aquest servei es pot desplegar durant un període de temps definit on es preveu un gran volum d’usuaris, com per exemple, l’obertura d’inscripcions. El servei de Queue-it col·loca els usuaris a una cua virtual de manera que accedeixen al lloc web de manera ordenada i esglaonada, evitant una sobrecàrrega del sistema i millorant l'experiència d’usuari, proporcionant informació com el seu lloc a la cua i el temps d’espera aproximat. Les principals característiques que ofereix queue-it són: ● Cua virtual: Quan el tràfic supera la capacitat del lloc, els usuaris són redirigits a una cua virtual. Els usuaris reben una posició en la cua, temps aproximat d’espera i altres informacions per estar informats en tot moment. ● Distribució justa: Queue-it s’assegura que l’entrada al lloc web sigui justa, gestionant l’accés per ordre d’arribada i així evitant que bots o usuaris amb connexions més ràpides accedeixin injustament. ● Monitoratge en temps real: Els administradors poden controlar el trànsit, ajustar diferents paràmetres, veure estadístiques en temps reals… Tot això, facilita una gestió més eficient del lloc web. ● Integració fàcil: Es pot integrar fàcilment mitjançant els recursos proporcionats sense necessitat de reestructurar la infraestructura existent amb APIs i documentació per diferents llenguatges com JavaScript o .NET. 5
● Solució escalable: És capaç d’adaptar-se a un gran nombre d’usuaris, des dels milers, fins als milions. Figura 1: Exemple de cua d’espera de Queue-it. Font: [2] 2.2 Justificació Com s’ha vist a l’apartat anterior, el servei que proporciona Queue-it és molt atractiu i eficient. El principal problema del servei de Queue-it és el preu. La llicència anual de Queue-it més barata costa prop dels 20.000 €[3] i cobreix un màxim d’un milió d’usuaris redirigits a una cua d’espera al mes. És per aquest motiu que desenvolupar una cua pròpia que faci una funció similar, sense arribar a totes les característiques que ofereix Queue-it, és un projecte que tindria un impacte econòmicament positiu al CPNL. Aquesta cua seria desenvolupada amb tecnologia Amazon Web Services, seguint la seva implementació inicial[4]. Amazon dona una estimació dels següents preus[5] de la seva implementació d’una cua d’espera: ● Cost diari sense cap esdeveniment: $11 6
● Cost d’un esdeveniment amb 50.000 usuaris a una cua d’espera durant 2 hores: $94 ● Cost d’un esdeveniment amb 100.000 usuaris a una cua d’espera durant 2 hores: $348 7
5. Planificació inicial 5.1 Descripció de les tasques 5.1.1 Introducció La duració d’aquest projecte és d’aproximadament 4 mesos. Des del 19 de setembre de 2024 fins al 17 de gener de 2025. Les tasques estan dividides en 3 grups: Gestió del projecte, desenvolupament i documentació i comunicació. Dins de l’apartat de desenvolupament s’han agrupat les tasques en blocs. Per cada tasca s’ha assignat un codi i la quantitat d’hores estimades per facilitar la planificació del projecte, a més d’una explicació de cada tasca. 5.1.2 Tasques ➔ Gestió de projecte: ➔ GP1 - Contextualització i abast: S’elabora un document que contextualitza i descriu l’abast del projecte (20 hores). ➔ GP2 - Planificació: S’elabora un document que descriu les tasques del projecte, les hores dedicades, els recursos i la gestió de riscos (20 hores). ➔ GP3 - Pressupost i sostenibilitat: S’elabora un document amb l’estimació del pressupost del projecte i una part inicial de l’informe de sostenibilitat (20 hores). ➔ GP4 - Integració final del document: S’elabora un document que integra i millora a través del feedback els continguts de totes les parts de la gestió del projecte (20 hores). ● Desenvolupament: 14
I - Incepció: ➔ I1 - Preparació de l’entorn: Descarregar tots els programes necessaris per a la gestió, disseny i programació del projecte (5 hores). ➔ I2 - Determinar la càrrega del sistema: Determinar la manera de mesurar la càrrega al sistema per configurar la cua d’espera (15 hores). EP - Creació entorn de proves ➔ EP1 - Backend: Crear una backend per l’entorn de proves (20 hores). ➔ EP2 - Frontend: Crear un frontend per l’entorn de proves (20 hores). ➔ EP3 - Base de dades: Crear una base de dades per l’entorn de proves (10 hores). CA - Cua AWS[8] ➔ CA1 - Estudiar arquitectura: Estudiar l’arquitectura, proporcionada per AWS, per la cua d’espera virtual (20 hores). ➔ CA2 - Desplegar cua de proves: Configurar i desplegar la cua de proves, proporcionada per AWS, a l’entorn de proves per familiaritzar-se amb el seu funcionament (20 hores). ➔ CA3 - Desplegar stack principal: Configurar i desplegar el stack principal de la solució a AWS CloudFormation. Requerit per la funcionalitat principal de la cua (20 hores). ➔ CA4 - Desplegar stack d’autoritzacions: Configurar i desplegar el stack d’autoritzacions a AWS Cloudformation. Dissenyat per verificar els tokens assignats a la cua d’espera (15 hores). ➔ CA5 - Desplegar OpenID stack: Configurar i desplegar l’OpenID stack a AWS CloudFormation. Per assegurar-nos de la identitat dels usuaris i augmentar la seguretat al nostre lloc web (15 hores). 15
➔ CA6 - Desplegar stack d'estratègia d’entrada: Configurar i desplegar el stack d'estratègia d’entrada. Per determinar l'estratègia d’entrada dels usuaris a la cua i configurar la seva capacitat (15 hores). ➔ CA7 - Customització de la pàgina d’espera: Personalitzar l’estil visual de la cua d’espera per compartir un aspecte uniforme amb el lloc web (10 hores). ● Documentació i comunicació: ➔ DC1 - Seguiment: S’apunten els esdeveniments que es vagin realitzant per tal de portar un seguiment i incloure-ho a la documentació. Aquesta tasca es realitzarà contínuament i és per això que no té una durada específica. ➔ DC2 - Redacció de memòria i repàs: Es dedicarà temps a l’elaboració de la documentació relativa al desenvolupament i millorant les parts prèviament escrites (70 hores). ➔ DC3 - Comunicació: Es duran a terme reunions amb el tutor del projecte per fer un seguiment del projecte i resoldre dubtes (20 hores). 5.1.3 Recursos Recursos humans: ● [CP] Cap del projecte ● [AS] Analista de Software ● [DS] Desenvolupador de Software ● [DU] Dissenyador UI/UX ● [T] Tester ● [PP] Ponent del projecte ● [TE] Tutor de l’empresa ● [CADP] Cap de la unitat ADP de l’empresa 16
● [TGEP] Tutor de GEP Recursos físics: Seran necessaris per a totes les tasques del projecte. ● Espai de treball ● Ordinador portàtil ● Ratolí Recursos de software: ● [VSC] Visual Studio Code ● [GIT] Github ● [GW] Google Workspace ● [GC] Google Chrome ● [AWS] Amazon Web Services ● [SQLS] SQL Server ● [TA] Taiga 17
5.2 Taula i Gantt 5.2.1 Taula de tasques Codi Tasca Duració (h) Dependències Recursos GP Gestió del projecte 80 - GP1 Contextualització i abast 20 - CP, TGEP, GW, GC GP2 Planificació 20 GP1 CP, GW, GC GP3 Pressupost i sostenibilitat 20 GP2 CP, GW, GC GP4 Integració final del document 20 GP3 CP, GW, GC I Incepció 20 - I1 Preparació de l’entorn 5 - DS, GC, VSC, GIT, AWS I2 Determinar la càrrega del sistema 15 - AS, GW, GC EP Creació entorn de proves 50 - EP1 Backend 20 I1 DS, GC, VSC, GIT EP2 Frontend 20 I1 DS, GC, VSC, GIT EP3 Base de dades 10 EP1 DS, GC, VSC, GIT, PSQL CA Cua AWS 115 - CA1 Estudiar arquitectura 20 - AS, GC CA2 Desplegar cua de proves 20 I, EP, CA1 DS, T, GC, VSC, AWS CA3 Desplegar stack principal 20 CA2 DS, T, GC, VSC, GIT, AWS CA4 Desplegar stack d’autoritzacions 15 CA3 DS, T, GC, VSC, GIT, AWS CA5 Desplegar OpenID stack 15 CA4 DS, T, GC, VSC, GIT, AWS CA6 Desplegar stack d'estratègia d’entrada 15 CA5 DS, T, GC, VSC, GIT, AWS CA7 Customització de la pàgina d’espera 10 CA3 DU, T, GC, VSC, GIT, AWS DC Documentació i comunicació 90 DC1 Seguiment - - CP, GW, TA DC2 Redacció de memòria i repàs 70 - CP, TE, CAPD, TGEP, GW DC3 Comunicació 20 - CP, TE, CAPD, TGEP, GW Total 355 Taula 1: Hores de dedicació, dependències i recursos per a cada tasca. Font: Elaboració pròpia 18
5.2.2 Diagrama de Gantt Per fer el diagrama de Gantt s’ha tingut en compte l’inici del projecte (19 de setembre), el final del projecte (17 de gener) i s’ha decidit definir una mitjana de 4 hores diàries, mitja jornada, de dilluns a dissabte. Arribant a les 24 hores de dedicació setmanals. Per realitzar aquest diagrama s’ha utilitzat el software GanttProject[9]. Figura 3: Diagrama de Gantt. Font: Elaboració pròpia. 19
5.3 Gestió del risc: Plans alternatius i obstacles 5.3.1 Introducció Com ja s’ha esmentat anteriorment, un projecte com aquest no està exempt de riscos i obstacles que puguin dificultar la seva progressió. A continuació s’ha creat una taula amb els possibles riscos que ens podem trobar, la seva probabilitat i la quantitat d’hores aproximades que poden requerir. Risc Probabilitat Hores aproximades Inexperiència en les tecnologies necessàries Alta 40 Calendari tancat Mitja 20 Errors d’implementació Mitja 30 Taula 2: Probabilitat i hores aproximades per cada risc. Font: Elaboració pròpia 5.3.2 Inexperiència en les tecnologies necessàries En començar aquest projecte, no es té experiència en les tecnologies que s’utilitzaran, particularment Amazon Web Services. S’han afegit tasques per estudiar i aprendre aquestes tecnologies, però és probable que la poca experiència pugui endarrerir el desenvolupament del projecte. Les tasques afectades d’aquest risc són principalment les que tenen a veure amb la cua (CA). El pla alternatiu per aquest risc serà dedicar-hi més hores a l’estudi de les tecnologies mencionades. Amazon Web Services, al ser una plataforma molt popular per desenvolupadors i utilitzada mundialment, per tant es farà ús de la gran quantitat de documentació i cursos online gratuits per resoldre els dubtes i problemes que es poden arribar a tindre i com a conseqüència, endarrerir les altres tasques. 20
5.3.3 Calendari tancat Aquest projecte té una data d’entrega definida i, per tant, és una possibilitat que no es pugui completar en el temps donat. Aquest risc afecta a totes les tasques, ja que, si s’endarrereix el progrés d’alguna tasca, les altres tasques també s’endarreriran com a conseqüència. Doncs, com a pla alternatiu d’aquest risc, es portarà un seguiment de les tasques comparativament amb el diagrama de Gantt que s’ha planificat prèviament. Si s’acaba detectant un endarreriment, es procurarà de treballar més hores a la setmana per tal de portar el projecte al dia. Com a últim recurs, en cas que encara dedicant-hi més hores no es puguin arribar a completar totes les tasques del projecte, es retallarà l’abast del projecte, restant-li les tasques de personalització visual (EP2, CA7) al no afectar al funcionament de la cua i les tasques dels stacks que no tenen un comportament crític dins la cua (CA4, CA5). 5.3.4 Errors d’implementació Un problema comú a la programació i el desenvolupament són els errors d’implementació. Aquest és un possible risc que pot endarrerir el progrés del projecte. Especialment, quan es fa ús de noves tecnologies en les quals no es tenen experiència. Per tant, serà important testejar el codi sovint i fer ús del control de versions de Git per minimitzar l’impacte d’aquests errors. Aquest risc pot afectar a totes les tasques de desenvolupament (EP1-3, CA2-7). Davant d’aquests errors d’implementació s’hauran de dedicar inevitablement més hores setmanals per completar les tasques afectades a temps. 21
5.4 Pressupost 5.4.1 Identificació dels costos Un cop planificat el projecte, definint les tasques i el calendari a seguir, es continua amb l’elaboració del pressupost. El primer pas per calcular el cost total del projecte serà determinar el cost total del diferents rols del projecte. Les estimacions del salari brut de cada rol s’han obtingut de la pàgina web Glassdoor[10]. Rol Salari/hora (brut) [€] Salari/hora + Seguretat Social (*1,3) [€] [CP] Cap de projecte 24,27 31,55 [AS] Analista de Software 18,44 23,98 [DS] Desenvolupador de software 17,22 22,38 [DU ]Dissenyador UX/UI 18,36 23,87 [T] Tester 11,45 14,88 Taula 3: Cost per hora de cada membre de l’equip. Font: Elaboració pròpia 5.4.2 Costos de personal per activitat Un cop definit el cost per hora de cada integrant, basant-se en la taula de tasques de la planificació temporal. Es pot definir el cost de cada tasca i, conseqüentment, el cost total de les tasques del projecte.. S’ha elaborat la següent taula que desglossa el cost del personal per activitat. 22
Codi Duració (h) Hores Cost [€] CP AS DS DU T GP 80 80 2.524,00 GP1 20 20 631,00 GP2 20 20 631,00 GP3 20 20 631,00 GP4 20 20 631,00 I 20 15 5 471,60 I1 5 5 111,90 I2 15 15 359,70 EP 50 50 1.119,00 EP1 20 20 447,60 EP2 20 20 447,60 EP3 10 10 223,80 CA 115 15 60 10 35 2.462,00 CA1 20 15 5 434,10 CA2 20 15 5 410,10 CA3 20 15 5 410,10 CA4 15 10 5 298,20 CA5 15 10 5 298,20 CA6 15 10 5 298,20 CA7 10 10 5 313,10 DC 90 90 2.839,50 DC1 - DC2 70 70 2.208,50 DC3 20 20 631,00 Total 9.416,10 Taula 4: Cost del recursos humans per tasca. Font: Elaboració pròpia 23
7. Cua d’espera de peticions web 7.1 Introducció L’objectiu d’aquesta cua és el de regular les sol·licituds dels usuaris al nostre lloc web, durant esdeveniments de gran tràfic, de manera justa i satisfactòria pels usuaris. Creant un prototip fàcilment modificable i escalable per tal de veure la seva viabilitat. Per tal, d’aconseguir aquests objectius farem servir els serveis d’Amazon Web Services. El principal motiu d’utilitzar aquesta plataforma és que aquests serveis ens proporcionaran una infraestructura robusta al núvol, a més que al CPNL ja fa servir actualment els serveis d’AWS i, per tant, estan familiaritzats amb el seu funcionament. En el cas d’aquesta cua, AWS ens dona una solució en forma de plantilla inicial que implementa la infraestructura necessària per una sala d’espera virtual per regular el tràfic. 7.2 Vista lógica Els elements d’aquesta vista representen els tipus i la terminologia de la solució. Figura 4: Vista lògica de l’arquitectura. Font [17] 30
Pàgina web Aquest tipus representa la pàgina web que està sent protegida per la sala d’espera virtual. Comptador Aquest tipus representa la posició numerica del final de la cua, o el que és el mateix, el nombre total de persones que són o han passat per la sala d’espera. Esdeveniment Aquest tipus representa un esdeveniment únic per a un lloc web que requereix protecció contra un excés d'usuaris concurrents. L'esdeveniment associa el lloc web, la cua de la sala d'espera, les claus criptogràfiques i els comptadors numèrics que s'utilitzen per avançar els usuaris a través de la sala d'espera. Sala d’espera Aquest tipus representa la cua d’espera d’usuaris que esperen per entrar al lloc web. La sala d’espera està formada per un conjunt ordenat de peticions, cadascuna amb una posició única a la cua. La posició a la cua i la posició en atenció determinen quan un nou usuari pot accedir de nou a la pàgina web. Posició en atenció Aquest tipus representa la posició a la cua més alta que té accés per continuar cap al lloc web. Totes les peticions amb una posició de cua igual o menor a aquest valor poden sortir de la cua i accedir al lloc web. Clau pública Aquest tipus representa la JSON Web Key pública que és generada per aquesta instal·lació de la sala d’espera. La clau pública és utilitzada per verificar signatures de JSON Web Tokens que s’assignen des de la sala d’espera virtual. Clau privada Aquest tipus representa la JSON Web key privada que és generada per aquesta instal·lació de la sala d’espera. La clau privada és utilitzada per assignar JSON Web Tokens per autoritzar la sortida de la sala d’espera. 31
Petició Aquest tipus representa una petició feta pel client per entrar a la cua de la sala virtual. La petició és monitoritzada durant el seu pas per la sala d’espera. La petició està relacionada amb la posició a la cua, la qual pot ser inferior o superior a la posició en atenció. La petició també pot estar relacionada amb un token d’accés en forma de JWT. Token d’accés Aquest tipus representa un JSON Web Token assignat per la sala d’espera per guanyar accés al lloc web o interactuar amb les API protegides del lloc. Posició a la cua Aquest tipus representa una posició numèrica d’una petició de la cua de la sala d’espera. Una posició a la cua inferior a la posició en atenció permet sortir de la sala d’espera i accedir al lloc web de nou. Estat de la sessió Aquest tipus representa l’estat d’una petició. És un estat complementari utilitzat per monitoritzar un JSON Web Token després de ser assignat. Aquest estat s’utilitza per comprovar si un token ha estat utilitzat, l’usuari ha marxat de la sala o el token a expirat. 32
7.3 Arquitectura A la següent imatge es pot veure l’arquitectura completa d’aquesta solució: Figura 5: Informació general de l’arquitectura. Font: [4]. 1. Distribució d’Amazon Cloudfront per proporcionar crides d’API públiques al client. 2. API pública per processar peticions de la cua desde la sala virtual, seguir les posicions de la cua i validar els tokens d’accés a la pàgina web. 3. Una Simple Queue Service (SQS) d’Amazon per regular el tràfic a les funcions del servei Lambda que processen els missatges de la cua. 4. API privada per funcions administratives. 5. Funcions de Lambda per validar i processar les peticions i respostes de les API. 6. Amazon Virtual Private Cloud (VPC) per allotjar les funcions de Lambda que interactuen directament amb Elasticache, permetre la comunicació entre els diferents serveis de la solució i connectar amb els endpoints de Cloudfront. 7. Una regla de Amazon Cloudwatch que invoca una funció de Lambda que periòdicament envia actualitzacions d’estat. 8. Taulas d’Amazon DynamoDB per guardar els tokens, posició a la cua i el número de persones a les que s’estan servint. 9. AWS Secrets Manager per guardar claus per operacions amb tokens i altra informació sensible. 33
10. (Opcional) Component d’autorització consistent d’un rol d’AWS Identity and access Management (IAM) i una funció d’autorització de Lambda. 11. (Opcional) Amazon Simple Notification Service (SNS), Cloudwatch i funcions Lambda per l’ús d'estratègies d’entrada. 12. (Opcional) Connector d’OpenID amb una API Gateway i funcions de Lambda per proveir autenticació d’usuaris al lloc web del client. 13. (Opcional) Distribució Cloudform amb un bucket S3 d’Amazon per la mostra de la web de la sala d’espera. 7.4 Serveis AWS Tal com s’ha observat a l’apartat anterior, aquesta arquitectura fa ús de diversos serveis d’Amazon Web Services. A continuació hi ha un desglossament de cadascun dels serveis utilitzats: ● Amazon CloudFormation Amazon CloudFormation és un servei que permet crear i gestionar recursos AWS de manera automàtica mitjançant plantilles de codi. Aquestes plantilles es defineixen en format YAML o JSON i permeten descriure recursos d’una estructura. En el cas de la cua d’espera, aquest servei juntament amb aquestes plantilles permetrà desplegar l’arquitectura mostrada anteriorment de manera automàtica i modular. Això permet evitar errors humans en la configuració de la infraestructura, tenir una arquitectura escalable i controlada. ● API Gateway API Gateway és un servei que permet crear, publicar i gestionar API a gran escala. API Gateway actua com a "porta d'entrada" entre les aplicacions externes (com a aplicacions mòbils o web) i els serveis que es troben al núvol, permetent als desenvolupadors exposar de manera segura les funcionalitats del backend a través de RESTful APIs, WebSocket APIs o APIs basades en HTTP. En el cas de la cua d’espera utilitzarem aquest servei per les dues API. Principalment la pública la farem servir per crides relacionades amb les posicions de la cua i verificar JSON Web Tokens, i la privada per autenticar els JSON Web Tokens. 34
Aquest servei també ens permetrà gestionar un gran nombre de crides d’API simultàniament, el que serà important si tenim pensat tindre un gran volum d’usuaris entrar i sortint de la cua en un curt període de temps. ● Amazon Simple Queue Service (SQS) Amazon SQS és un servei que facilita l’enviament, la recepció i emmagatzematge de missatges entre serveis. Ofereix cues escalables per emmagatzemar i processar missatges entre sistemes de manera fiable. Té una utilitat a la cua gestionant l’entrada ordenada d’usuaris, emmagatzemant les sol·licituds dels usuaris i invocant la funció Lambda que processa els missatges de la cua per lots en comptes de fer-ho individualment. ● AWS Lambda El servei AWS Lambda permet executar codi sense necessitat de gestionar servidors. Es dispara automàticament en resposta a esdeveniments com la recepció d’un missatge en una cua. La seva utilitat rau en la capacitat d'executar codi de manera eficient i només quan sigui necessari, reduint costos operatius i millorant l'escalabilitat de l'aplicació. Aquest servei valida i processa i valida crides de l’API privada i pública i és de gran utilitat per aquesta solució per la seva gran escalabilitat, eficiencia i costos. Tres punts vitals per una aplicació que gestiona un gran nombre de sol·licituds. ● Amazon VPC (Virtual Private Cloud) Amazon VPC (Virtual Private Cloud) és un servei que permet crear una xarxa virtual privada dins de l'entorn d'AWS. Aquesta xarxa ofereix control total sobre l'entorn de xarxa, incloent-hi configuracions d'IP, subxarxes, taules de rutes i passarel·les de xarxa. AWS VPC garanteix la seguretat i l'aïllament dels recursos desplegats, permetent connectivitat segura amb Internet, altres serveis d'AWS o xarxes locals mitjançant VPN o AWS Direct Connect. Aquest servei permet establir una connexió segura entre les funcions de Lambda i altres serveis de la solució. ● Amazon CloudWatch 35
Amazon CloudWatch és un servei de monitoratge i observabilitat que recull i analitza mètriques, registres i esdeveniments dels recursos i aplicacions d'AWS. Proporciona visualitzacions en temps real, alertes i accions automatitzades per ajudar a mantenir l'estabilitat, l'optimització del rendiment i la gestió dels costos. Amazon CloudWatch permet invocar a funcions Lambda per monitoritzar l’estat de la cua periòdicament, de de un panell de control per exemple. Aquest servei també ens permet habilitar notificacions quan la cua estigui en un estat crític que requereixi la nostra atenció. De la mateixa manera que es pot fer servir per implementar una estrategia d’entrada on la posició en atenció s’actualitza periòdicament. ● Amazon DynamoDB Amazon DynamoDB és un servei de base de dades NoSQL completament gestionat i altament escalable, dissenyat per oferir un rendiment ràpid amb una latència baixa consistent. Aquest servei permet emmagatzemar tokens, posicions a la cua i la posició en atenció a distintes taules. ● AWS Secrets Manager AWS Secrets Manager és un servei gestionat que ajuda a protegir secrets com ara credencials de bases de dades, claus d'API i altres dades sensibles. Proporciona emmagatzematge segur, rotació automàtica de secrets i accés controlat mitjançant permisos integrats amb AWS Identity and Access Management (IAM). Aquest servei és d’utilitat per guardar tokens i altres dades sensibles, mantenint la nostra infraestructura segura. ● AWS Identity and Access Management (IAM) AWS IAM (Identity and Access Management) és un servei que permet gestionar de manera segura l'accés als recursos d'AWS. Amb IAM, pots crear i administrar usuaris, grups i rols, definir polítiques d'accés granulars i controlar qui pot fer què dins de la infraestructura AWS. 36
Aquest servei és d’especial utilitat per gestionar l’accés a certes parts de la nostra infraestructura. Concretament, a l’API privada que gestiona l’assignació de tokens i el comptador de la posició d’atenció que regula el flux de la cua d’espera. ● Amazon Simple Notification Service (SNS) Amazon SNS (Simple Notification Service) és un servei de missatgeria gestionat que facilita l'enviament de notificacions en temps real a través de diferents canals com SMS, correu electrònic, o publicació en temes (tòpics) que altres serveis poden subscriure. És altament escalable i dissenyat per integrar-se fàcilment amb altres serveis d'AWS. Amb aquest servei és possible enviar notificacions als usuaris en cas que arribi el seu torn per avançar a la cua. Tot i que, a aquesta, solució, està integrat amb el servei Lambda per implementar la estrategia d’entrada MaxSize, que incrementa la posició en atenció basat en el nombre màxim de transaccions que s’ha definit. ● Amazon Simple Storage Service (S3) Amazon S3 (Simple Storage Service) és un servei d'emmagatzematge d'objectes altament escalable, segur i durador, dissenyat per guardar qualsevol tipus de dades, com fitxers, imatges, vídeos o registres. S3 ofereix opcions d'accés flexible, controls de seguretat avançats i integració amb altres serveis d'AWS. Aquest servei es farà servir per depositar el codi font de la cua un cop s’hagi modificat. Des d’aquest servei s’extreu la URL per desplegar les plantilles que es crearan a CloudFormation. 7.5 Plantilles Amazon Cloudformation Per tal de desplegar l’arquitectura, a AWS trobem les plantilles de Cloudformation. Aquestes descriuen la infraestructura i els recursos que es volen gestionar a AWS mitjançant el servei CloudFormation.Aquestes plantilles es defineixen en format YAML o JSON i actuen com a fulls de ruta per desplegar i configurar els serveis AWS de manera automàtica i modular. 37
Unset Unset Unset Una plantilla de CloudFormation consta de diverses seccions que defineixen els recursos i les configuracions necessàries per a la infraestructura. Aquestes són algunes de les seccions més rellevants d’aquest tipus de fitxers: 1. Versió del format Especifica la versió del format de l’arxiu que s’està tractant. "AWSTemplateFormatVersion": "2010-09-09" 2. Descripció Descripció de la plantilla per documentar la seva finalitat "Description": "(SO0166) Virtual Waiting Room on AWS %%VERSION%%", 3. Paràmetres Defineix valors d’entrada que els usuaris poden proporcionar quan es crea un conjunt de recursos (pila). Aquests paràmetres poden ser personalitzables, com noms de recursos, tipus d’instància, regions, etc. "Parameters": { "EventId": { "Description": "Unique ID for this instance of the waiting room", "Type": "String", "MinLength": 1, "ConstraintDescription": "Please enter a value for this field." 4. Mappings Permet definir dades estàtiques que es poden utilitzar en altres parts de la plantilla, com ara regions o configuracions específiques 38
Unset Unset "Mappings": { "SourceCode": { "General": { "S3Bucket": "%%BUCKET_NAME%%", "KeyPrefix": "%%SOLUTION_NAME%%/%%VERSION%%" } 5. Outputs Proporciona informació sobre els recursos creats, com URL d'accés, identificadors, etc. Això és útil per compartir valors amb altres conjunts de recursos (pila) o per visualitzar informació important. "Outputs": { "PublicApiInvokeURL": { "Value": { "Fn::Sub": [ "https://${CloudFrontDomainName}", { "CloudFrontDomainName": { "Fn::GetAtt": [ "PublicApiCloudFront", "DomainName" ] } L’arquitectura d’aquesta solució està dividida en 5 plantilles: ● virtual-waiting-room-on-aws.template Aquesta plantilla desplega la funcionalitat principal de la cua. Incloent les API públiques i privades i serveis del núvol per crear els esdeveniments de la sala d’espera. Conté els següents paràmetres de personalització: Parametre Per defecte Descripció Event ID Sample ID unic per aquesta instancia de la sala virtual d’espera 39
vii. Response body: { "serving_num": INTEGER } viii. Status codes: 200: Success 400: Invalid event ID 4. /num_active_tokens i. Descripció: Retorna el nombre de tokens actius. Un token actiu té un atribut exp que és posterior a l’hora actual. ii. Autorització: IAM iii. Mètode: GET iv. Tipus de contingut: application/json v. Paràmetres query: event_id vi. Request body: NONE Response body: { "active_tokens": INTEGER } vii. Status codes: 200: Success 404: Invalid event ID 5. /reset_initial_state i. Descripció: Aquesta API reinicia els comptadors interns a zero i esborra i després torna a crear la taula de DynamoDB utilitzada per l’API. ii. Autorització: IAM iii. Mètode: POST iv. Tipus de contingut: application/json v. Paràmetres query: event_id vi. Request body: { "event_id": EVENT_ID } Response body: { "message": "Counters reset. DynamoDB table recreated." } vii. Status codes: 200: Success 400: Invalid event ID 6. /update_session i. Descripció: Aquesta API canvia l’estat d’un token assignat. ii. Autorització: IAM iii. Mètode: POST iv. Tipus de contingut: application/json v. Paràmetres query: NONE vi. Request body: { "event_id": EVENT_ID, "request_id": REQUEST_ID, "status": INTEGER (1 = completed, -1 = abandoned) } vii. Response body: NONE viii. Status codes: 200: Success 400: Invalid event ID or request ID 404: Request ID doesn't exist or status already set 46
7.8 Diagrames de seqüència El següent diagrama mostra els primers passos d’un usuari quan entra a la sala d’espera i obté una posició a la cua. Figura 6: Diagrama de seqüència entrar a la sala d’espera. Font [17] 47
El següent diagrama mostra els passos per obtenir la posició de l’usuari fent servir l’ID rebut pel diagrama anterior. Figura 6: Diagrama de seqüència obtenir posició. Font [17] 48
El següent diagrama mostra els passos, que sovint es repeteixen en un interval, per rebre la posició d’atenció de la cua d’espera. Figura 7: Diagrama de seqüència posició d’atenció. Font [17] 49
El següent diagrama mostra els pasos per obtenir un JSON Web Token de l’API pública un cop la posició d’atenció ha superat la posició de l’usuari a la cua. Figura 8: Diagrama de seqüència obtenir token. Font [17] 50
El següent diagrama segueix els pasos utilitzats amb l’API Gateway authorizer. Figura 9: Diagrama de seqüència API Gateway. Font [17] 7.9 Modificacions i implementació Tot i que les plantilles de CloudFormation permeten un cert grau de personalització modificant els paràmetres, a l’hora d’implementar la nostra solució no s’han desplegat les plantilles a Amazon Cloudformation directament, sinó que s’ha treballat des del repositori del codi font de la infraestructura per fer les modificacions necessàries i després crear les plantilles amb el codi modificat, fer un desplegament a un bucket d’Amazon S3 i per últim desplegar-ho a Amazon Cloudformation. Les principals modificacions del codi han estat a la plantilla virtual-waiting-room-on-aws-sample. Aquesta és la plantilla que proporciona una mostra de 51
Unset l’aplicació web de la cua. La primera modificació ha estat sobre l’estètica de l’aplicació web. Aquestes modificacions s’han fet intentant semblar la web del propi CPNL, donant-li un tó vermell i afegint el logo. Com es pot veure a la pàgina de benvinguda. Figura 10: Sala d’espera, benvinguda. Font Elaboració pròpia Un cop fem clic al botó de reservar passem a la següent pàgina on trobem la sala d’espera amb diferents components que donen informació a l’usuari. La posició, nombre d’usuaris sent atinguts i mida de la sala d’espera, s’obtenen mitjançant crides a l’API pública. L’últim component, el temps aproximat de sortida, funciona de manera que calcula una regressió lineal que estima quant de temps falta per arribar al capdavant de la cua amb agafant mostres anteriors que va actualitzant. updateExitExtrapolation() { // update the sample and estimate from the timer const now = new Date().getTime(); // create a new sample with the position and timestamp const item = [this.queuePosition, now]; // add to the end this.samples.push(item); // trim the older samples from the front if needed while (this.samples.length > MAX_SAMPLES) { 52
this.samples.shift(); } // create the fit function from the samples const fitFunction = linearRegressionLine(linearRegression(this.samples)); // estimate the exit timestamp for the user's line position const estimate = Number.parseInt(fitFunction(this.myPosition)); if (!isNaN(estimate)) { this.estimatedExitTimestamp = estimate; // create the human-readable this.remainingTime = moment().to(new Date(this.estimatedExitTimestamp)); } else { this.estimatedExitTimestamp = 0; } } 53
Figura 11: Sala d’espera. Font Elaboració pròpia Un cop arriba el torn de l’usuari per avançar a la cua, se li desbloqueja el botó per avançar i arriba a la pàgina de sortida segura. A aquesta pàgina s’informa a l’usuari de l’estat del seu token i un cop el verifica pot sortir de la sala d’espera virtual. S’ha afegit un atribut que informa de que el token ha estat validat correctament, a través d’aquesta validació, debloqueja el botó i permet sortir de la cua i anar al lloc web desitjat. La integració amb el lloc web s’ha fet mitjançant redireccions HTTP 302, de la mateixa manera que ho fan servir al servei queue-it. 54
Figura 12: Sistema de sortida segura. Font Elaboració pròpia Aquesta mateixa plantilla també inclou un panell de control per gestionar la nostra cua. Aquest panell requereix d’un usuari IAM que s’ha de configurar al nostre compte d’AWS i enllaçar a través del servei IAM a la cua d’espera. Un cop tinguem l’usuari IAM, tindrem l’access key i la secret access key per connectar-nos i modificar els atributs del panell de control. 55
Unset Figura 18: Flux de navegació d’aplicació web. Font Elaboració pròpia 8.4 Disseny intern Per tal de desenvolupar l’aplicació web s’ha fet servir el framework .NET i el llenguatge C#. Aquesta aplicació web consta de diversos components: Els controladors, RegisterController i LoginController, reben les dades dels formularis, tracten les dades i comuniquen amb la base de dades. En el cas de RegisterController, verifica la validesa del model, encripta la contrasenya amb BCrypt i desa les dades a la taula Users. En el cas de Login Controller, busca l’usuari a la base de dades pel seu correu i compara la contrasenya introduïda amb la que apareix a la base de dades. En tots dos casos es redirigeix cap a l’inici. Les views són responsables de generar el contingut HTML que es mostra a l’usuari. Alguns exemples són la pàgina d’inici i els formularis de registre i inici sessió. Els models són classes que descriuen l’estructura de les dades i les seves propietats, com per exemple la classe User. using System.ComponentModel.DataAnnotations; namespace TFG_Web.Models { public class User { 62
Unset [Key] public int Id { get; set; } [Required] [MaxLength(100)] public string Email { get; set; } [Required] [MaxLength(255)] public string PasswordHash { get; set; } } } I finalment tenim la classe ApplicationDBContext que és el component principal de la capa de dades i connecta l’aplicació amb la base de dades SQL server. using Microsoft.EntityFrameworkCore; using TFG_Web.Models; namespace TFG_Web.Data { public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } public DbSet<User> Users { get; set; } } } 11.5 Proves i validació Per tal de testejar el lloc web, s’han desenvolupat tests unitaris per comprovar que la base de dades no tingui cap error i assegurar un bon funcionament de les seves funcionalitats. 63
A part dels tests unitaris, també s’ha testejat manualment el lloc web per tal d’assegurar una bona experiència d’usuari i el bon funcionament del recorregut des de la pàgina principal fins a la cua d’espera. 8.6 Conclusió Aquest lloc web, que imita la estética del CPNL, serveix com a demostració d’un cas d'ús de la cua d’espera, on els usuaris han de passar obligatòriament per la cua d’espera abans de poder introduir les seves dades. En un hipotètic cas en el que tinguéssim un gran flux d’usuaris que volguessin registrar-se la cua actuaria com a mecanisme de regulació i protecció, garantint una experiència d’usuari controlada i evitant possibles saturacions. 64
9. Identificació de lleis i regulacions Es pot afirmar que aquest projecte no vulnera cap llei ni regulació. Observant els components principals del projecte, l’entorn web de proves i la cua d’espera, no hi ha cap funcionalitat que pugui vulnerar la seguretat dels usuaris ni comprometre les seves dades. L’entorn web de proves no recull ni processa dades reals de cap usuari, ja que només és un entorn on verificar el funcionament de la cua d’espera i, per tant, tots els usuaris afegits no seran reals. El lloc web tampoc tindrà problemes de vulnerabilitats, ja que no estarà obert al públic. Respecte a la cua d’espera, tampoc recull cap dada de l’usuari, es limita a redirigir i informar els usuaris de la seva posició a dins la cua. La cua tampoc tindrà cap problema de vulnerabilitats perquè estarà protegida per la infraestructura d’AWS, que compleix amb els estàndards de seguretat necessaris. 65
10. Resultat final del projecte En aquest apartat es pot veure com ha acabat el projecte. Durant la duració 10.1 Planificació final En aquest apartat tenim la planificació final del projecte. La gran majoria d’apartats han sortit a més hores de les que estaven planejades. El motiu d’aquest increment hores ha estat la revalorització de les tasques, a més que s’han afegit noves tasques. Això va ser degut a fer una planificació inicial massa optimista, un cop afegides les noves tasques i recalculades les prèvies, tenim un total d’hores de 470, sense comptar riscos i obstacles. L’única fase del desenvolupament que no augmenta en hores és la fase d’incepció, ja que s’ha eliminat una tasca relacionada amb determinar la càrrega del sistema. El motiu per eliminar aquesta tasca és que la càrrega del sistema depèn completament de la web on implementem la cua, per tant, en un projecte on no s’afegeix la cua a un entorn real, no té sentit fer aquesta tasca. Codi Tasca Duració (h) Dependències Recursos GP Gestió del projecte 80 - GP1 Contextualització i abast 20 - CP, TGEP, GW, GC GP2 Planificació 20 GP1 CP, GW, GC GP3 Pressupost i sostenibilitat 20 GP2 CP, GW, GC GP4 Integració final del document 20 GP3 CP, GW, GC I Incepció 10 - I1 Preparació de l’entorn 10 - DS, GC, VSC, GIT, AWS EP Creació entorn de proves 90 - EP1 Frontend 40 I DS, GC, VSC, GIT EP2 Base de dades 30 I DS, GC, VSC, GIT, SQLS EP3 Testejar entorn de proves 20 EP1 DS, GC, VSC, GIT CA Cua AWS 200 - CA1 Estudiar arquitectura 30 - AS, GC CA2 Desplegar cua de prova 40 I, CA1 DS, T, GC, VSC, AWS CA3 Configuració stack d’autoritzacions 15 CA2 DS, T, GC, VSC, GIT, AWS 66
CA4 Configurar stack d'estratègia d’entrada 15 CA2 DS, T, GC, VSC, GIT, AWS CA5 Customització de la pàgina d’espera 40 CA1 DU, T, GC, VSC, GIT, AWS CA6 Desplegar cua principal 40 CA3, CA4, CA5 DS, T, GC, VSC, GIT, AWS CA7 Testejar la cua d’espera 20 CA2, CA6 DU, T, GC, VSC, GIT, AWS DC Documentació i comunicació 90 DC1 Seguiment - - CP, GW, TA DC2 Redacció de memòria i repàs 70 - CP, TE, CAPD, TGEP, GW DC3 Comunicació 20 - CP, TE, CAPD, TGEP, GW Total 470 Taula 15: Taula de tasques final Font: Elaboració pròpia 10.2 Pressupost final De la mateixa manera que amb la taula de tasques, el pressupost ha augmentat per pràcticament totes les tasques excepte per l’incepció. Codi Duració (h) Hores Cost [€] CP AS DS DU T GP 80 80 2.524,00 GP1 20 20 631,00 GP2 20 20 631,00 GP3 20 20 631,00 GP4 20 20 631,00 I 10 10 223,80 I1 10 10 223,80 EP 90 50 20 20 1.894,00 EP1 40 20 20 925,00 EP2 30 30 671,40 EP3 20 20 297,60 CA 200 30 130 20 20 4.403,80 67
CA1 30 30 719,40 CA2 40 40 895,20 CA3 15 15 335,70 CA4 15 15 335,70 CA5 40 20 20 925,00 CA6 40 40 895,20 CA7 20 20 297,60 DC 90 90 2.839,50 DC1 - DC2 70 70 2.208,50 DC3 20 20 631,00 Total 11.885,10 Taula 16: Cost humà final Font: Elaboració pròpia Un cop recalculat el pressupost final, tenim que la diferència entre el pressupost inicial (13.773,53) i el final (16.242,53) ha estat de 2.469€. Un augment del 17,92%. Aquesta desviació és bastant elevada, tot i així, és coherent amb la quantitat d’hores i amb la quantitat d’hores afegides. Amb l’experiència d’aquest projecte, es podria aproximar un pressupost més proper a la realitat en un futur projecte. Costos Cost [€] Costos de personal per activitat 11.885,10 Costos generals 1.049,96 Contingències 1.293,27 Imprevistos 2.014,20 Total 16.242,53 Taula 17: Pressupost final Font: Elaboració pròpia 68
11. Conclusions 11.1 Reflexió A aquest projecte s’ha pogut desenvolupar i implementar una solució de cua d’espera de peticions web per gestionar grans volums de tràfic web basada en els serveis d’Amazon Web Services. Aquesta solució s’ha construït amb un enfocament escalable, modular i amb una alta capacitat per a la personalització i adaptabilitat, complint d’aquesta manera els nostres principals objectius i oferint una alternativa al servei de Queue-it. Gràcies a l’ús dels serveis d’AWS, la infraestructura és robusta i fàcilment escalable depenent del trànsit esperat. Les plantilles són flexibles i permeten tant una personalització superficial fent ús dels paràmetres d’entrada com una personalització més profunda mitjançant el codi font de la solució. De la mateixa manera, el lloc web compleix amb els objectius de mostrar la fàcil integració d’aquesta cua a una aplicació web qualsevol mitjançant redireccions i garantir un recorregut satisfactori des de la web fins a la cua i retornar. En conclusió, el projecte ha validat amb èxit la viabilitat d’aquesta infraestructura basada en AWS, demostrant que és una solució escalable, adaptable i fàcilment personalitzable per a diversos casos d’ús. A més, ofereix una alternativa robusta i competitiva al servei de Queue-it, amb la capacitat d’ajustar-se a necessitats específiques i d’evolucionar per incorporar millores futures. 11.2 Competencies CES1.1: Desenvolupar, mantenir i avaluar sistemes i serveis software complexos i/o crítics. [En profunditat] Pel desenvolupament d’aquest projecte s’ha seguit un enfocament clàssic amb uns requisits i objectius clars. Durant el desenvolupament s’han efectuat els ajustaments necessaris per resoldre els possibles obstacles o desviacions i s’han desenvolupat tests per tal de mantenir un control de qualitat sobre el software. 69
CES1.2: Donar solució a problemes d'integració en funció de les estratègies, dels estàndards i de les tecnologies disponibles. [En profunditat] Durant el desenvolupament del projecte s’han hagut d’afrontar reptes per integrar diferentes parts. Per exemple, a la pàgina web s’ha hagut d’implementar una base de dades SQL server i també s’ha hagut d’integrar la cua d’espera amb la pàgina web per tal que pugui absorbir el tràfic. Per tant, s’han hagut de buscar solucions per aquests problemes d’integració. CES1.3: Identificar, avaluar i gestionar els riscos potencials associats a la construcció de software que es poguessin presentar. [En profunditat] Durant la fase inicial del projecte es va dur a terme un anàlisi exhaustiu per identificar els possibles riscos i obstacles que podrien afectar a la planificació. Aquesta planificació ens ha ajudat a minimitzar els riscos i assegurar la construcció del software CES1.4: Desenvolupar, mantenir i avaluar serveis i aplicacions distribuïdes amb suport de xarxa. [En profunditat] Per la part de la cua d’espera, s’ha hagut de treballar amb molts serveis diferents d’AWS. Tots serveis basats en el núvol i amb necessitat de comunicar-se entre sí de manera segura i eficient. CES1.5: Especificar, dissenyar, implementar i avaluar bases de dades. [Una mica] Per la part de l’aplicació web s’ha empleat una base de dades SQL server que s’ha hagut d’integrar amb els formularis de la pròpia pàgina web per generar usuaris amb diferents atributs i requeriments. CES1.7: Controlar la qualitat i dissenyar proves en la producció de software. [En profunditat] Per tal de comprovar la qualitat del software s’han hagut de passar tests unitaris per validar les funcionalitats dels sistema tant per la part de la cua d’espera com per l’aplicació web. I de la mateixa manera s’han hagut de testejar manualment les interfícies per assegurar el seu correcte funcionament i accessibilitat pels usuaris. CES2.1: Definir i gestionar els requisits d'un sistema software. [En profunditat] Des de la planificació inicial es van recopilar una serie de requisits que el projecte havia de complir per ser satisfactori. D’aquests requisits han sortit les bases del treball i els objectius i han ajudat a assolir el projecte. 70
12. Referències [1] “CPNL”. Visitat el 19 de setembre de 2024: https://www.cpnl.cat/ [2] “Queue-it”. Visitat el 21 de setembre de 2024: https://queue-it.com/ [3] “Queue-it: Virtual Waiting Room - Digital Marketplace”. Visitat el 23 de setembre de 2024: https://www.applytosupply.digitalmarketplace.service.gov.uk/g-cloud/services/347629176609 675 [4] “Sala de espera virtual de AWS | Soluciones de AWS”. Visitat el 23 de setembre de 2024: https://aws.amazon.com/es/solutions/implementations/virtual-waiting-room-on-aws/ [5] “Cost - Virtual Waiting Room on AWS”. Visitat el 23 de setembre de 2024: https://docs.aws.amazon.com/solutions/latest/virtual-waiting-room-on-aws/cost.html [6] “The 5-min Kanban module overview - Tutorials and Guides - Taiga Community”. Visitat el 24 de setembre de 2024: https://community.taiga.io/t/the-5-min-kanban-module-overview/122 [7] “GitHub”. Visitat el 24 de setembre de 2024: https://github.com/ [8] “Absorb large bursts of traffic to your website with the Virtual Waiting Room on AWS” Room ”. Visitat el 30 de Setembre de 2024: https://docs.aws.amazon.com/solutions/latest/virtual-waiting-room-on-aws/welcome.html [9] “GanttProject”. Visitat l’1 d’Octubre de 2024: https://www.ganttproject.biz/ [10] “Sueldos de la empresa | Glassdoor”. Visitat el 7 d’Octubre de 2024: https://www.glassdoor.es/Sueldos/index.htm 71