Sistema d'Informació basat en web de Gestió d'Activitats i Recursos per Operació i Sistemes de la FIB

Sistema d'Informació de Gestió d'Activitats i Recursos per Operació i Sistemes de la FIB (GAROS) Memòria Final Treball de Final de Grau - Modalitat B Especialització en Sistemes d’Informació Presentació: Entre el 27 Juny a 1 de Juliol de 2022 20 de maig de 2022 GEI Curs 21-22 Q2 Autor: Nahúm Manuel Martín Vegas Directora: Sandra Marsà Hernández Ponent: Joan Antoni Pastor Collado El més sincer agraïment a totes les persones que han col·laborat en aquest projecte per a que es dogués a terme. A la directora Sandra Marsà, al ponen Joan Antoni Pastor, als companys d’operació Elvira Pallàs iIgnasi Herranz per les seves valoracions i propostes, i a Jaume Moral per la seva ajuda en molts àmbits del projecte. 2 Resum Existeixen llocs de treball on s’ha de supervisar i vigilar diversos sistemes d’informació a la vegada i molts d’aquests sistemes no donen les facilitats per ser supervisats en grup. Això vol dir que si tenim diversos sistemes d’informació i necessitem veure canvis o avisos a cada un d’ells hem de anar canviant constantment d’entorn a entorn a revisar aquests canvis o avisos. Un mètode antiquat de rebre avisos en temps real són els correus electrònics. Per cada activitat que requereixi intervenció o coneixement rebem un correu electrònic informant d’allò i acumulant-se a la bústia. Actualment s'estilen els sistemes de «notificacions», utilitats al sistema operatiu (escriptori o mòbil) que ens avisa de forma visual i/o acústica de que tenim algun tipus d’avís. Aquests mètodes tenen l’inconvenient de que funcionen només per aplicacions instal·lades al propi sistema i no per sistemes d’informació via web. Aquest projecte ve a donar solució a aquest tipus de problema, notificar i mostra informació de diferents sistemes d’informació en un sol entorn visual que ens pugui ajudar a estar al cas de les activitats que succeeixen al lloc de treball. Un entorn clar, fàcil, dinàmic i automàtic que rebi i mostri la informació i ens notifiqui d’allò que és rellevant i ens resumeixi la informació que considerem important. A més, aquest sistema ajuda a accedir als sistemes on està connectat per fer les intervencions pertinents. L’entorn en el que el projecte està concebut és en l'àrea de Operació i Sistemes de la Facultat d’Informàtica de Barcelona (FIB), dintre de la Unitat Transversal de Gestió de l’Àmbit TIC del Campus Nord (UTGCNTIC). Utilitza eines, protocols i entorns de la universitat per conceptualitzar l’entorn visual i les comunicacions però el concepte global és fàcilment exportable a qualsevol àmbit on sigui necessari. En l’àmbit tècnic podem resumir que està concebut en un sistema Front-end i Back-end dintre de contenidors (Docker amb Linux i servidors web NGINX). Això es denomina com «Conceptualització en micro-serveis» on es separa l’entorn visual (Front-end) de l’entorn proveïdor i gestor de dades (Back-end). Son les arquitectures que es fan servir avui dia per estructurar un Sistema d’Informació per petit que sigui per a que tingui les característiques de versatilitat, seguretat, ampliabilitat i inteconnectabilitat. Més en concret tècnicament parlant, per al Front-end es fa servir Vue.js amb llenguatge JavaScript dintre d’una interfície marc de la UPC, i al Back-end es fa servir Django amb llenguatge Python. Pel que fa a les dades, es fa servir un servidor MariaDB pre-existent on s’allotja la base de dades d’aquest Sistema. Així doncs, aquest projecte formalitza i construeix un PMV[17] (Producte Mínim Viable o MVP en anglès) d’on partir i ampliar un sistema que pot ser tant gran com puguem concebre’l, ja que es pot ampliar amb moltes altres connexions a serveis i emmarcar a molts altres departaments tant dins com fora de la UPC. 3 Índex Resum 3 1. Introducció i contextualització 8 1.1 Context 8 1.1.1 Introducció 8 1.1.2 Problema 8 1.1.3 Actors implicats 8 1.2. Justificació 10 1.2.1 Situació actual 10 1.2.2 Tendència global dels SI 11 1.3. Visió del projecte 11 1.3.1 Alternatives plantejades 11 1.3.2 Visió final 12 2. Planificació del projecte 13 2.1. Abast 13 2.1.1 Objectiu general 13 2.1.2 Objectius PMV 13 2.1.3 Requisits inicials 13 2.1.3.1 Requisits funcionals 13 2.1.3.2 Requisits no funcionals 14 2.1.4 Objectius de futur 14 2.1.5 Metodologia i rigor 15 2.1.5.1 Iteracions periòdiques 15 2.1.5.2 Eines de desenvolupament 16 2.1.5.3 Alternatives descartades 16 2.1.5.4 Mètode de validació 17 2.2. Tasques i planificació temporal 18 2.2.1 Definició de tasques 18 2.2.2 Hores, dependències i recursos per tasca 19 2.2.3 Diagrama de dependències 21 2.2.4. Gantt 22 2.2.5 Riscos 24 2.3. Pressupost 25 2.3.1 Identificació i estimació de costos 25 2.3.1.1 Recursos Humans 25 2.3.1.2 Recursos materials 26 4 2.3.1.3 Amortitzacions 27 2.3.1.4 Contingències i imprevistos 28 2.3.1.5 Pressupost Final 28 2.3.2 Control de gestió 29 2.4. Sostenibilitat 30 2.4.2 Dimensió econòmica 30 2.4.3 Dimensió ambiental 30 2.4.4 Dimensió Social 30 3. Desenvolupament 31 3.1. Tecnologies, eines i coneixements aplicats 31 3.1.1 Llenguatges de programació 31 3.1.2 Soware extern i Frameworks 31 3.1.3 IDE’s, editors i eines 33 3.2. Anàlisi de requisits i especificació final 34 3.2.1 Requisits funcionals 34 3.2.2 Diagrama de casos d'ús 34 3.2.3 Requisits no funcionals 37 3.2.4 Esquema de serveis 38 3.3. Disseny de projecte 39 3.3.1 Arquitectura i components 39 3.3.1.1 Contenidors 39 3.3.1.2 Components i mòduls 43 3.3.1.3 Base de dades 46 3.3.1.4 Seguretat 51 3.3.2 Patrons i disseny 52 3.3.3 Interfície 54 3.4 Experiència d’usuari 55 3.4.1 Accés i primera vista 55 3.4.1 Calendaris 57 3.4.1 Tiquets 59 3.4.1 Préstecs 60 3.4.1 Equips 62 4. Conclusions 64 4.1 Assoliment dels objectius inicials 64 4.2 Assoliment dels objectius personals 64 4.3 Problemes o dificultats 65 4.4 Feina futura 65 5 4.5 Assoliment de les competències tècniques 65 5. Bibliografia 68 Figures Figura 1: Concepte de sprints al mètode Agile Figura 2: Concepte d’iteració a Extreme Programming (XP) Figura 3: Diagrama de dependències Figura 4: Diagrama de Gantt amb les tasques detallades a partir del 28 de març Figura 5: Diagrama de casos d’ús Figura 6: Esquema conceptual de servei Figura 7: Esquema de contenidors de Front-End Figura 8: Esquema de contenidors de Back-End Figura 9: Esquema de components i connexions entre Front-End i Back-End Figura 10: Esquema de base de dades Figura 11: Diagrama Model-Vista-Controlador Figura 12: Diagrama Aggregator Figura 13: Distribució de la interfície Figura 14: Autenticació SSOLab Figura 15: Distribució dels elements del panell Figura 16: Visual de la secció de Calendaris Figura 17: Visual de la sub-secció de tots els calendaris Figura 18: Visual de la secció de Tiquets Figura 19: Visual de la secció de Préstecs a la sub-secció de Tots Figura 20: Visual de la secció de Préstecs a la sub-secció de Canvis Figura 21: Visual de la secció d’Equips Figura 22: Visual de la secció d’Equips a la sub-secció de l’Historial 15 16 21 23 35 38 39 41 43 46 52 52 54 55 56 57 57 59 60 61 62 63 Taules Taula 1: Resum de tasques del projecte Taula 2: Costos en hores, dependències i recursos de les tasques Taula 3: Temporització del sprints i la gestió del projecte G1 Taula 4: Temporització de les tasques sobre els sprints planificats i el temps de Gestió de Projecte Gx Taula 5: Salaris dels treballadors implicats Taula 6: Costos per treballador i totals en recursos humans Taula 7: Costos de material per lloc de treball i total Taula 8: Costos amb contingències Taula 9: Costos amb imprevistos Taula 10: Costos totals Taula 11: Contingut del fitxer docker-compose.pro.yml del Front-End 18 19 22 22 25 26 27 28 28 28 39 6 Taula 12: Contingut del fitxer Dockerfile.pro del Front-End Taula 13: Contingut del fitxer docker-compose.pro.yml del Back-End Taula 14: Contingut del fitxer Dockerfile.api a la esquerra i Dockerfile.proxy a la dreta Taula 15: Taules de la base de dades per al mòdul de Préstecs Taula 16: Taules de la base de dades per al mòdul d’Equips Taula 17: Taules de la base de dades per al mòdul de Tiquets Taula 18: Taula de la base de dades per al mòdul de Calendari 40 41 42 47 48 49 50 7 1. Introducció i contextualització 1.1 Context 1.1.1 Introducció Sobre l’any 2017, el consell de govern de la UPC va prendre la decisió de re-assignar alguns departaments de les facultats i la gestió dels equipaments de la universitat[1]. Un d’aquells moviments implicava que les branques d’Operació i Sistemes de la FIB, que abans formaven part de la branca inLab FIB[2]; ara formarien part de la UTG CNTIC[3] (Unitat Transversal de Gestió de l’àmbit TIC del Campus Nord). Aquests canvis impliquen que algunes eines de gestió existents al període inLab s’han replicat per ambdós departaments o directament s'estan compartint. Tenim llavors una re-distribució de departaments amb recursos que es van escollir a un context diferent i uns criteris que no responen a la situació actual. Unes eines de treball que, si bé són funcionals, requereixen actualitzacions i adequacions als nous àmbits i requeriments distributius. 1.1.2 Problema Com es pot intuir a la introducció anterior, a Operació i Sistemes tenim un nombre considerable de sistemes d’informació on accedir per fer diferents tipus de tasques: un per inventari, un per tickets, un per documentació, quatre per sistemes operatius d’aules, un per préstecs i assignació d’aules, etc. Una amalgama de sistemes d’informació compartits amb altres departaments tots independents per diferents motius. Per tant, resulta necessari un sistema que connecti amb tots els altres sistemes d’informació, informi de canvis o alertes a algun d’ells, mostri informació organitzada de la forma més adient al lloc de treball i que enllaci aquesta informació rebuda amb la informació concreta per enviar directament a l’usuari al sistema pertinent amb la dada o registre concrete. I que també organitzi tota aquesta informació de forma personalitzada. Tot això des d’un sol entorn visual àgil, segur, ampliable i personalitzable per a cada usuari. Amb aquesta premisa resulta clar que necessitem un nou sistema de tipus Web, com marquen els temps actuals, amb una petita base de dades per guardar la informació temporal rebuda i la dels usuaris, i una interfície de comunicació amb els sistemes requerits. 1.1.3 Actors implicats Aquest treball de final de grau (TFG) es realitzarà en modalitat B i ha estat plantejat com projecte intern de la UTG CNTIC[3]. L’equip que treballarà per realitzar aquest projecte serà: ●Nahum Manuel Martín Vegas. Estudiant i desenvolupador del Projecte a mes de Personal d’Administració i Serveis (PAS) al departament Operació de la Facultat d’Informàtica de Barcelona (FIB - UPC). ●Sandra Marsà Hernández. Directora del projecte i Personal d'Administració i Serveis (PAS) al departament de Sistemes de la Facultat d’Informàtica de Barcelona (FIB - UPC). 8 ●Joan Antoni Pastor Collado, Ponent del Projecte a mes de Professor en diverses assignatures i càrrecs directius a la Facultat d’Informàtica de Barcelona (FIB - UPC). Les persones afectades pel problema són tot el personal de Sistemes i Operació. Però per aportat una solució a això caldrà la implicació de responsable d’altres departaments que facilitin l’accés a les dades que requerirà el nou sistema d’informació que es planteja en aquest projecte. Entre ells els responsables de les aplicacions de Racó[4], gestió de tickets[5], actual aplicació de projectes Redmine[6], etc. 9 Figura 2: Concepte d’iteració a Extreme Programming (XP) Font: http://www.extremeprogramming.org/ 2.1.5.2 Eines de desenvolupament Degut a la dificultat de trobar un entorn amb connexions o plug-ins amb sistemes d’informació interns de la UPC s’ha optat per fer servir un Framework Front-end[7] de programació per facilitar la implantació d’un entorn d’administració personalitzable. Per aquest cas s’ha optat per fer servir el Framework UPC webapp ui Vue 3[22] basat en Vue.js[23] amb Node.js[24] i programat amb JavaScript[25] per el Front-end on coses com taules, botons, menús, barres i etcétera ja venen definides i llestes per posar allà on es necessiti ràpidament i sense gaire programació. Per el Back-end[7] s’ha decidir fer servir un llenguatge de programació conegut als departaments de Sistemes com és Python[26]. Amb aquesta premisa s’ha escollit Django[27] com servidor Back-end que compleix amb els requeriments esmentats. Les eines de desenvolupament que es faran servir són un IDE[28] com Microso Visual Studio CODE[29] que a part de ser gratuït és un dels més utilitzats arreu del mon. A més ens permet fer servir plug-ins d’execució web local per poder veure els resultats abans de pujar els canvis al servidor. Per al control de versions i canvis es planteja fer servir GitLab[30] de UPC pel fet de què és un entorn destinat a aquest efecte i on tots els interessats poden tenir accés amb el seu compte d’usuari de la UPC. Per al control de projecte s’utilitzarà Redmine[6], què és l’actual sistema de control de projectes. 2.1.5.3 Alternatives descartades A l’hora d’escollir el Framework de Front-end[7] s’ha decidit per UPC webapp ui Vue 3[22] ja que ja porta de sèrie els colors corporatius i també es fa servir a altres aplicacions de la UPC. Les alternatives que s’havien estudiar eren AdminLTE[31], CoreUI[32] o Tabler[33] basats en Bootstrap[13], un Framework compatible amb Vue.js[23]. Tots tres poden ser perfectament vàlids si l'opció escollida mostra inconvenients per al desenvolupament. Pel que fa al Back-end[7] s’ha escollit Django[27] perquè compleix amb els requisits comentats anteriorment. A més integra totes les opcions que necessitarem per guardar les dades personals dels usuaris i la seguretat requerida. Com alternativa podem trobar Flask[34], que no te tots els complements que necessitaríem però es poden afegir de forma externa si per algun inconvenient de 16 desenvolupament no podem ser servir la opció per defecte. Altres alternatives per a Back-end com Ruby on Rails[35] o Laravel[36] incompleixen moltes més condicions de les requerides per al personal de sistemes i desenvolupament, i per això es descarten directament i no es plantegen com alternatives tot i que podrien ser perfectament funcionals. En quant a les eines de desenvolupament és més una qüestió de preferències del programador. Tot i que comptar amb un IDE que ajudi a informar de falles i errades del codi com per automatizar la previsualització local sempre és un afegit que pot aportar una velocitat de desenvolupament al projecte. IDEs alternatius a Microso Visual Studio CODE[29] hi han molts, així com programar directament amb editor de text però l’escollit és un dels més utilitzats per tots els programadors arreu del mon per qualsevol llenguatge de programació o sistema operatiu. GitLab[30] de UPC és on resideix l'actual codi de UPC webapp ui Vue 3. Per tant és el lloc ideal pel repositori del projecte. Si fos necessari es podria portar a altres repositoris externs a la UPC com GitHub[37] o GitLab[30] públic. En quant a alternatives a Redmine[6] podem trobar Microso Project[38] o Trello[39], totes dues de pagament. Però si ja es té un soware de gestió de projectes que coneix la empresa no té gaire sentit plantejar una alternativa de moment. 2.1.5.4 Mètode de validació Amb la metodologia de treball escollit podem fer avaluacions contínues dels micro-objectius de cada sprint tant amb la gent directament involucrada com amb els voluntaris dels departaments que vulguin participar de les proves de funcionament. El seguiment del projecte es durà a per les persones involucrades de forma directa: ●Nahum Manuel Martín Vegas que farà els rols de gestor de projecte, programador, analista d’interficies gràfiques i enginyer de sistemes. ●Sandra Marsà Hernández que farà els rols de Directora de projecte supervisant la feina i el compliment dels temps i objectius previstos. ●Joan Antoni Pastor Collado que farà el rol de Ponent i revisarà la documentació i l’estat del projecte periòdicament. Es marcaran reunions setmanals al final de cada sprint per revisar els objectius realitzats i plantejar els objectius del següent sprint segons la planificació o aplicant canvis si es veu oportú i necessari. 17 2.2. Tasques i planificació temporal Les tasques s’han identificat a nivell global marcant els objectius, sobretot enfocats als requisits funcionals com són les connexions amb les diferents aplicacions i serveis. Les tasques identificades amb Gx fan referència a la Gestió del Projecte, les identificades amb Px fan referència a la instal·lació i configuració del programari, les identificades amb Dx fan referència a Disseny d'interfície, i les identificades amb Cx fan referència a les diferents connexions amb els servidors o serveis que ha realitzar l’aplicatiu. 2.2.1 Definició de tasques Les tasques es nombren amb dos caràcters, un que identifica el tipus i altre que la enumera. A la taula 1 podem veure també el títol i una petita descripció de la feina que comporta cada tasca. G1 Gestió de projecte Contextualització, abast definició de funcionalitats i requisits, definició de tasques a realitzar, planificació de tasques, pla econòmic, informe de sostenibilitat i reunions amb Stakeholders. G2 Documentació de projecte Documentació del projecte durant la gestió i tots els sprints. S’estima que es faran servir 3 hores de documentació per a cada sprint i 20h a la gestió del projecte. La documentació als diferents sprints es farà paral·lelament amb les tasques a fer. G3 Reunions de control Reunions de control programades al final de cada sprint per revisar objectius complerts i possibles variacions. Cada sprint tindrà una reunió d’aproximadament 1 hora. P1 Instal·lació de contenidors de Front-end i Back-end Preparació i instal·lació dels contenidors de Front-end i Back-end per als servidors de desenvolupament dedicats. També s’habilitaràn els permisos de xarxa pertinents per poder treballar al desenvolupament. També serà el període per avaluar les versions de servidors que es faran servir al projecte. P2 Configuració de UPC webapp ui Vue 3 i Servei API Django Adaptar el Framework UPC webapp ui Vue 3 per al treball de disseny i configurar el servidor Python com API de consulta de dades de l’aplicació. P3 Preparació de l’entorn de desenvolupament, repositori i area de testing Instal·lació del programes de desenvolupament com l’IDE o creació del repositori on s'allotjaran els codis del desenvolupament. També preparar l'àrea de proves local per a una visualització més ràpida. D1 Disseny i distribució de l’entorn Front-end Disseny de tota la interfície gràfica i treball de distribució de les diferents funcions dintre del marc visual del Front-end. 18 D2 Disseny i distribució de les funcions connectades Disseny de l’entorn visual de cada funció. Estimació de 5 hores per a cada funció, a cada sprint dedicat a connectivitat. Les dependències esdevenen segons es realitza cada funció (C1, C2, C3, C4, C5) de connexió i el disseny global de l’aplicació fet a la tasca D1. C1 Connexió amb aplicació de login amb Identitat Digital UPC Connexió amb Identitat Digital de la UPC i obtenció de dades d’usuari de cara a la utilització al programari. C2 Connectar Calendaris d’Operació Connexió amb calendaris de Google Calendar i traspàs de la informació actual, així com la metodologia i nomenclatura per als calendaris compartits. C3 Connectar informació de la API de POA Connexió amb l’aplicació POA de control d’equips per a una visualització i control adients dins de l’aplicació. C4 Connectar API de Tickets Connexió amb l’aplicació de tickets i programació de les diferents tipus d’alertes que es poden obtenir a partir de les dades rebudes de la API. C5 Connectar Reserves i Préstecs per API del Racó Connexió amb l’aplicació de reserves i préstecs del Racó per a una ordenació i notificació d’alertes personalitzades, així com mecanismes de cerca i categorització. Taula 1: Resum de tasques del projecte Font: Elaboració pròpia 2.2.2 Hores, dependències i recursos per tasca A la taula 2 podem veure les hores que previsiblement necesitarà cada tasca, les seves dependències i els recursos necessaris per dur-les a terme. Cal remarcar que la tasca de documentació es farà en paral·lel amb d’altres i per aquest motiu, tot i que no tenen un punt d’inici i final continu, es poden dur a terme durant un sprint a diferents moments segons sigui convenient. La suma total d’hores és de 302 repartit en una dedicació aproximada de 4 hores diàries, unes 20 hores setmanals o per sprint. Tasc a Hores Dependènci es Recursos G1 70 - Recursos humans: Cap de projecte Recursos materials: Ordinador amb internet, Google Docs. G2 92 Tota la resta Recursos humans: Cap de projecte Recursos materials: Ordinador amb internet, Google Docs. G3 8 P1, P3, D1, D2 Recursos humans: Cap de projecte Recursos materials: Ordinador amb internet, Google Docs. 19 P1 16 G1 Recursos humans: Programador i administrador de sistemes Recursos materials: Ordinador amb xarxa, Servidor de desenvolupament, soware a instal·lar. P2 10 P1 Recursos humans: Programador Recursos materials: Ordinador amb xarxa P3 8 P2 Recursos humans: Programador Recursos materials: Ordinador amb xarxa D1 18 P3 Recursos humans: Programador i Analista d'interfícies gràfiques Recursos materials: Ordinador amb xarxa D2 20 D1, C1, C2, C3, C4, C5 Recursos humans: Programador i Analista d'interfícies gràfiques Recursos materials: Ordinador amb xarxa C1 12 P3 Recursos humans: Programador Recursos materials: Ordinador amb xarxa C2 12 P3 Recursos humans: Programador i Analista d'interfícies gràfiques. Recursos materials: Ordinador amb xarxa C3 12 P3 Recursos humans: Programador i Analista d'interfícies gràfiques Recursos materials: Ordinador amb xarxa C4 12 P3 Recursos humans: Programador i Analista d'interfícies gràfiques Recursos materials: Ordinador amb xarxa C5 12 P3 Recursos humans: Programador i Analista d'interfícies gràfiques Recursos materials: Ordinador amb xarxa Taula 2: Costos en hores, dependències i recursos de les tasques Font: Elaboració pròpia 20 2.2.3 Diagrama de dependències A la figura 3 podem veure el diagrama de dependències on els nodes en vermell són les tasques recurrents que depenen de diverses tasques i que estan repartides en diferents sprints amb nomenclatura afegida <<-Sx>> que fan referència al sprint concret on la x marca el número de sprint. La documentació de gestió del projecte es designa com <<G2-G1>>. Figura 3: Diagrama de dependències Font: Elaboració pròpia 21 2.2.4. Gantt S’han definit els sprints i hem determinat la data d’inici i acabament de cada un. També hem definit el període necessari per realitzar la gestió del projecte G1. Sprint: G1 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Dia d'inici 22/02 04/04 11/04 18/04 25/04 02/05 09/05 16/05 23/05 Dia final 01/04 08/04 15/04 22/04 29/04 06/05 13/05 20/05 27/05 Taula 3: Temporització del sprints i la gestió del projecte G1 Font: Elaboració pròpia Un cop tenim els sprints definits ja podem mostrar l’estimació de realització de cada tasca definida per a cada sprint d’acord amb les dependències i el temps que es requereix per a cada una. Moltes de les tasques de connectivitat es podrien solapar però s’estima que el grup de programació serà força reduït i per aquest motiu es defineix com un sprint per cada una de les tasques de connectivitat. La documentació s’ha de anar fent a mida que es va desenvolupant, per això la tasca G2 apareix a tots els sprints i durant la tasca de Gestió del Projecte G1. Es determina que cada tasca de connectivitat requerirà certa part d’implantació al disseny de l’aplicació, concretament el que fa referència a D2, per això s’ha repartit per a cada un dels sprints necessaris. Tasca Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 G1 G2 G3 P1 P2 P3 D1 D2 C1 C2 C3 C4 C5 Taula 4: Temporització de les tasques sobre els sprints planificats i el temps de Gestió de Projecte Gx Font: Elaboració pròpia Seguidament a la figura 3 es mostra el diagrama de Gantt més detallat a partir del 28 de març per a que els detalls es puguin veure adequadament. Del 22 de febrer al 1 de març es realitzen paral·lelament les tasques G1 i G2 tal i com es pot veure a la gràfica des del 28 de març. Les tasques que es realitzen a diferents sprints tenen la nomenclatura de la tasca seguit d’un guió i el sprint al que pertanyen. 22 Figura 4: Diagrama de Gantt amb les tasques detallades a partir del 28 de març Font: Elaboració pròpia 23 2.2.5 Riscos En quant a la base del projecte que són el Front-end[7] i el Back-end[7] els riscos que podem trobar són molt baixos. Són entorns aïllats i provats que estan dedicats per al desenvolupament, llevat d’errors de servidors o permisos de xarxa per connectar als diferents serveis no es poden trobar gaires inconvenients més. A més, les tecnologies de contenidors i el programari a utilitzar estan sobradament provats i no s’esperen incompatibilitats de cap tipus. Tot i així, si es trobessin inconvenients amb el programari escollit hi han alternatives idèntiques de sobres per canviar sense cap canvi en la planificació. Sobre les tasques de disseny i connectivitat s’ha estimat el temps per sobre perquè és conegut que difícilment les coses funcionen a la primera i l’intercanvi d’informació i errors de connectivitat sempre es trobaran. També es poden trobar diferents criteris de disseny i ser possible que es necessitin consultes dels usuaris per a trobar consens sobre el disseny. És força probable que trobem retards en la comunicació amb els diferents Stakeholders que han de participar en l’intercanvi d’informació però es té present que és possible que algunes tasques de connectivitat s'hauran de solapar a algunes hores. En tota aquesta part (cap2) trobo a faltar una reflexió de com han anat les coses, s’han fet les reunions previstes, ha hagut desviacions, quins problemes t’has trobat, etc. 24 2.3. Pressupost 2.3.1 Identificació i estimació de costos Per a cada projecte informàtic podem diferenciar dos tipus de costos generals, els materials i el humans. Per aquest projecte considerem que tenim quatre perfils de persones que han de formar part del desenvolupament del projecte: Cap de Projecte (CP), Programador (PR), Enginyer de Sistemes (ES) i Analista d’Interfícies Gràfiques (IG). Cada un d’ells participa en un període diferent del projecte amb responsabilitats ben acotades. En quant als costos materials tant físic com digital no es tindrà en compte l'amortització feta dels materials ja que es pot donar el cas que fem servir material adquirit per una altre funció o projecte previ, però sí que es reflectirà si aquest material té funcions compartides amb altres projectes o funcions per establir el cost parcial. 2.3.1.1 Recursos Humans En quant als recursos humans tenim que les persones que intervenen al projecte són: El Cap de projecte s'encarregarà de la gestió del projecte i supervisarà que els sprints i objectius s'estan assolint. El programador es dedicarà a fer tota la lògica de l’aplicació segons les indicacions esmentades a la documentació del projecte. L’administrador de sistemes participarà en la posada en marxa dels contenidors de Front-end[7] i Back-end[7] junt amb el programador que indicarà els requeriments de l’aplicació. L’analista d'interfícies gràfiques dissenyarà la distribució d’elements de l’aplicació i supervisarà la funcionalitat a nivell d’usuari dels diferents components de l’aplicació. Segons la web Glassdoor els sous base promig dels treballadors a Barcelona son: Lloc de treball Brut anual (€/any) Brut anual amb SS (€/any) Hora Bruta amb SS (€/h) Cap de projecte (CP) Project Director 65.769€ 85.500€ 41,11€ Programador (Front-end i Back-end) (PR) Full Stack Developer 36.731€ 47.750€ 22,96€ Enginyer de Sistemes (ER) Systems Engineer 43.365€ 56.375€ 27,10€ Analista d’Interficies Gràfiques (IG) Interaction Designer 48.077€ 62.500€ 30,05€ Taula 5: Salaris dels treballadors implicats Font: https://www.glassdoor.es Per a cada tasca hi han assignats alguns d’aquests treballadors i participaran en funció de les necessitats de cada tasca. També és necessari conèixer els totals de costos tant per lloc de treball com els costos totals en recursos humans. Tot això ho tenim reflexat a la següent taula: 25 Tots els serveis estaran funcionant sota la tecnologia Docker amb les funcionalitats addicionals de Docker-compose. Més en detall: ●Docker: És una tecnologia de encapsulament de soware on tenim una micro-màquina virtual que dona un servei. Normalment Docker s'emmarca en la filosofia de micro-serveis on micro-màquines virtuals s’executen per separat comunicar-se entre elles per formar un sistema global. Les avantatges dels contenidors, i Docker en aquest cas, són que es poden moure, clonar i reiniciar molt ràpidament. Son molt lleugers en quan a memoria i ben preparades es poden escalar ràpidament sense perdre servei. Un contenidor té totes les dependències de sistema operatiu incorporades, per aquest motiu és fàcilment portable a altres servidors Docker o al seu anàleg evolucionat Kubernettes[11]. Funciona a base d’imatges oficials amb un sistema operatiu Linux molt reduït amb bases de llenguatges i Frameworks bàsics. En el cas d’aquest projecte s’han fet servir imatges de Node.js, Python i NGINX. ●Node.js i Vue.js: Node es un Framework basat en Javascript que serveix com base per a altres Frameworks de més alt nivell com Vue.js. La seva característica principal és que té un gestor de paquets des de el qual podem instal·lar multitud de llibreries per al nostre projecte Javascript. Per altre banda, Vue.js és un Framework estructural que defineix unes estructures de fitxers, directoris i configuracions pròpies amb la seva pròpia llibreria de compilació. Node.js amb Vue.js te la principal avantatge de que es poden executar directament des de el directori d’arxius amb una simple comanda que aixeca un servidor web local, ideal per a desenvolupar. La estructura de Vue.js es centra principalment en el concepte de “Component” on els components s'enllacen entre ells per crear l’arbre estructural de una web. També ens permet afegir Plug-ins i llibreries per enriquir les funcionalitats del nostre projecte Vue.js. ●Django[27]: És un Framework basat en Python que dota d’una estructura de servei REST API al projecte. S’instal·la directament des dels repositoris de Python i també conté una gran varietat de Plug-ins per enriquir el seu funcionament. El concepte principal de Django son els mòduls i les “apps”, dons dintre d’una estructura Django podem tenir diferents aplicacions independents diferenciades per la adreça URL d’accés des de el client. Internament conté una estructura de directoris molt coherents i si es segueix la estructura la càrrega de mòduls és automàtica. Django també té l'avantatge de que pot connectar a una base de dades i transformar les crides a objectes (models a títol intern) a crides SQL estalviant-nos construir una crida directa a la base de dades. Tant les taules de la base de dades com les vistes de les dades s’estableixen directament sobre Django i és el propi Framework el que crea les taules a la base de dades i les rutes d’accés de la API per les visualitzacions. ●NGINX: És un dels servidors Webs més simples i versàtils que pode trobar. Ens permet tant publicar una web senzilla com redirigir tràfic entre diferents serveis. Per aquest projecte l’hem fet servir com servidor Web per al Front-End i com proxy SSL al Back-End. ●MariaDB: La pròpia universitat ens ha proporcionat accés a un servidor de bases de dades per poder encabir la base de dades d’aquest projecte. Aquest servidor és MariaDB, un servidor SQL de codi obert molt popular i fiable. Pot albergar dades relacionals, crear vistes, definir restriccions i la resta de propietats de qualsevol altre servidor SQL. ●UPC Webapp ui Vue 3: És un Framework d'interfície sobre Vue 3. És un dels nivells més alts en l’escala de programació. Dota d’un entorn preparat amb un menú lateral, una barra de títol, una secció d’usuaris, un apartat de selecció d’idioma funcional i un peu informatiu. A més 32 incorpora el Plug-in Vuex que permet guardar dades per poder fer-les servir en qualsevol punt de l’estructura web. Conté els logotips i colors corporatius de la UPC i la seva documentació conté suggerències dels Plug-ins i contingut visual recomanat. 3.1.3 IDE’s, editors i eines Les eines de desenvolupament com els IDE’s moltes vegades s’injurien perquè acaben consumint molts recursos de l’equip del desenvolupador però en els últims temps això ha deixat de ser així i han esdevingut una eina molt útil si s’ha de fer servir eines diverses i habituals. Per aquest projecte s’ha fet servir l’IDE Microso Studio Code amb Plug-ins per a GIT, Docker i Requests on des de la mateixa interfície es poden actualitzar versions al repositori[41], manegar els contenidors Docker locals i fer proves de crides a les APIs amb les que es treballa. Per a provar les versions en desenvolupament ha sigut necessari tenir instal·lat Docker a l’equip de desenvolupament, sobre tot al començament quan s’han d’establir els paràmetres dels contenidors. De forma puntual també s’han fet servir altres editors com Nano, Notepad++ o Kate segons les circumstàncies. També caldria anomenar el repositori GITLab de la UPC[41] des de on es carregaven i descarregaven les versions als diferents equips de desenvolupament i producció. 33 3.2. Anàlisi de requisits i especificació final A l’apartat de planificació del projecte havíem projectat una serie de requisits i especificacions previs que s’havien de mira d’aconseguir. Però com que tot canvia aquells requisits s’han de tornar a revisar i veure què es pot implementar i què no segons el procés del projecte. 3.2.1 Requisits funcionals Els requisits funcionals són aquells que determinen les funcions que poden fer els usuaris al sistema. A l’apartat de planificació (2.1.3.1) es projectaven una serie de requisits força generals que, una vegada està el projecte en marxa, han variat amb el temps en funció de les circumstàncies que s’han trobat en el seu desenvolupament. Els requisits funcionals en ple desenvolupament trobem que són: ●Iniciar sessió: Un usuari ha de poder iniciar sessió amb el seu usuari de la UPC i poder accedir a l’aplicació. ●Veure les dades del perfil de l’usuari: Cada usuari ha de poder veure la informació del seu perfil en la mesura en que els protocols de seguretat de la UPC ho permetin. ●Visualitzar notificacions: Un usuari ha de poder veure les notificacions d'incidències de cada mòdul per estar informat de forma immediata dels esdeveniments rellevants del lloc de treball. ●Cada unitat informativa (dada) ha de poder ser enllaçada al seu origen: Per cada dada visualitzada al sistema l’usuari ha de poder accedir al sistema d’on prové aquesta informació si el disseny així l’especifica. ●Panell (Dashboard) de resum: Tot usuari ha de poder accedir al Panell principal de l’aplicació que resumeix en una sola pàgina la informació dels diferents mòduls del sistema. ●Ordenació i cerca de dades: Tota informació rebuda ha de poder ser filtrada i ordenada per cada fragment informatiu sempre que sigui possible. 3.2.2 Diagrama de casos d'ús El diagrama de casos d'ús mostra les accions que pot realitzar un usuari dins del sistema i les relacions entre elles. Per accedir al sistema la porta d’entrada és el Panell tot i que es pot accedir a les diferents seccions per la URL. Totes les accions requereixen autenticació de la UPC per poder accedir i algunes accions depenen d’altres tal i com indica la etiqueta “includes”. 34 Figura 5: Diagrama de casos d'ús Font: Elaboració pròpia 35 El diagrama mostra els casos d’ús següents: ●Veure el Dashboard inicial: Mostra els resums dels mòduls del sistema amb petits llistats i gràfiques. Aquest cas d'ús inclou el cas de “Autenticació de la UPC” prèviament. ●Autenticació de la UPC: Mostra una pantalla d’autenticació SSOLab on hem d’introduir el nostre nom d’usuari i contrasenya, i si és la primera vegada ens demanarà permís de confiança amb l’aplicació GAROS. ●Veure Calendaris: Mostra els diferents calendaris en diferents pestanyes i la pestanya final te una visió mensual de tots els calendaris. Aquest cas d'ús inclou el cas previ de “Autenticació de la UPC”. ●Modificar Google Calendar: A sota de cada calendari tenim un botó que ens obre una pestanya nova al navegador amb Google Calendar. Aquest cas d’ús inclou el cas previ de “Veure Calendaris”. ●Veure llista de connexions a equips: Ens permet veure les connexions actives als equips dels aularis. Aquest cas d’ús inclou el cas previ de “Autenticació de la UPC”. ●Filtrar connexions: Ens permet filtrar les connexions actives mitjançant el cercador o anant a les pestanyes de pre-filtratge per edificis. Aquest cas d’ús inclou el cas previ de “Veure llista de connexions a equips”. ●Cerca Historial de connexions: Ens permet fer cerques de totes les connexions registrades encara que no estiguin actives. Aquest cas d’ús inclou el cas previ de “Autenticació de la UPC”. ●Veure llista de tiquets: Podem veure un llistat de tiquets en actiu. Aquest cas d’ús inclou el cas previ de “Autenticació de la UPC”. ●Personalitzar tiquets per equip resolutor: Podem personalitzar els tiquets que veiem activant o desactivant els equips resolutors que necessitem. Aquest cas d’ús inclou el cas previ de “Veure llista de tiquets”. ●Anar a editar tiquet al sistema origen: Per poder editar o interactuar amb un tiquet podem préme el botó d'Obrir que conté la fila informativa del tiquet. Aquest cas d’ús inclou el cas previ de “Veure llista de tiquets”. ●Veure llista de préstecs: Permet veure els préstecs vigents en llistats. Aquest cas d’ús inclou el cas previ de “Autenticació de la UPC”. ●Anar a editar préstec al sistema origen: Ens permet editar o retornar un préstec al Racó[4] mitjançant els botons d’acció que conté cada línia d’informació de tiquet. Aquest cas d’ús inclou el cas previ de “Veure llista de préstecs”. ●Marcar préstecs indefinits: Per poder marcar un préstec com indefinit només s’ha de activar el switch de la columna de indefinit que apareix a cada fila informativa de tiquet. Aquest cas d’ús inclou el cas previ de “Veure llista de préstecs”. ●Veure historial de canvis de préstecs: Podem veure l’historial de canvis de préstecs per veure quins canvis han esdevingut en els últims préstecs i fer cerques al llistat. Aquest cas d’ús inclou el cas previ de “Autenticació de la UPC”. 36 3.2.3 Requisits no funcionals El requisits no funcionals son aquells que tenen un caràcter general que no es solen referir a funcions concretes. Dels requisits no funcionals detallats en la planificació del projecte (2.1.3.2) es projectaven una serie de requisits que no han variat gaire en quant al recorregut del desenvolupament del sistema. ●El sistema ha de ser àgil i funcional per a totes les funcions que tingui. ●S’han de seguir els colors corporatius de la UPC. ●La comunicació entre serveis ha de ser directa i no ha d'haver necessitat de que l’usuari realitzi cap acció per a que la comunicació es realitzi, s’ha de mirar que les dades requerides s'actualitzin periòdicament de forma automàtica en la mesura del que sigui possible. ●El sistema no ha de interferir ni provocar cap tipus d’error a aquells serveis d’informació on es connecti. S’han de minimitzar al màxim les possibles modificacions de dades remotes. ●La informació rellevant ha de mostrar-se clarament diferenciada de la resta. ●S’han de complir tots els criteris de seguretat que marca la UPC per aquests tipus de serveis. 37 3.2.4 Esquema de serveis Al diagrama de la figura següent es poden veure a la línia inferior les fonts de dades de les que es nodreix el sistema, inclòs el servei de Google Calendar embegut de la secció de calendaris. Figura 6: Esquema conceptual de servei Font: Elaboració pròpia amb Lucidchart 38 3.3. Disseny de projecte El disseny és l’apartat clau per a que un servei esdevingui funcional, segur i escalable. És important tenir tota la concepció ben estructurada des d'un inici per poder desenvolupar de forma correcta i directa minimitzant els canvis circumstancials que poden aparèixer. 3.3.1 Arquitectura i components A aquesta secció entrarem una mica més en detall en les diferents parts que hem vist a la figura del esquema conceptual anterior. 3.3.1.1 Contenidors Tenim tres contenidors Docker en funcionament pel sistema en producció tot i que per compilar la web Vue.js cal prepara un quart que realitzarà aquesta compilació i copiarà el resultat al servidor NGINX que donarà el servei Web. A la següent figura mostrem el contenidor Node en un color diferent per indicar que després no donarà servei i serà esborrat. Figura 7: Esquema de contenidors de Front-End Font: Elaboració pròpia amb Lucidchart Podem veure un exemple d’això a un dels fitxers docker-compose que utilitzem. Concretament el “docker-compose.pro.yml” del Front-end. version: "3" services: web: container_name: garos-front build: dockerfile: Dockerfile.pro context: . volumes: - /home2/users/lcfib/garos/ssl:/etc/nginx/ssl/:ro - /home2/users/lcfib/garos/ssl/nginx-default-web.conf:/etc/nginx/conf.d/default.conf:ro - /home2/users/lcfib/garos/ssl/auth.conf.js:/public/conf/auth.conf.js:ro 39 environment: - VUE_APP_GAROS_API_SRV=${VUE_APP_GAROS_API_SRV} - VUE_APP_GAROS_API_PORT=${VUE_APP_GAROS_API_PORT} - VUE_APP_BACKEND_URL=${VUE_APP_BACKEND_URL} - VUE_APP_OIDC_CLIENT_ID=${VUE_APP_OIDC_CLIENT_ID} - VUE_APP_AUTHORITY=${VUE_APP_AUTHORITY} ports: - "147.83.41.32:80:80" - "147.83.41.32:443:443" dns: - 147.83.41.36 - 147.83.41.104 dns_search: - fib.upc.es Taula 11: Contingut del fitxer docker-compose.pro.yml del Front-End Font: Elaboració pròpia amb DBeaver Al fitxer podem veure com tenim designat el fitxer Dockerfile.pro que ens executarà la compilació i copia entre contenidors, a “volumes” podem veure com es mapejen la carpeta SSL i els arxius d’autenticació SSO. A la secció “environment” podem veure com es designen les variables d’entorn que després faran servir els contenidors a dins. I a “ports”, “dns” i “dns_search” tota la configuració de xarxa. També podem mostrar el fitxer Dockerfile.pro per veure cóm realitza aquesta operació de compilació i copia. # build environment FROM node:16-alpine as build-stage LABEL description="Garos Front-End build" WORKDIR /app COPY ./app/. . COPY .env . RUN npm install RUN npm rebuild node-sass RUN npm run build # production stage FROM nginx:stable-alpine as production-stage LABEL description="Garos Front-End" COPY --from=build-stage /app/dist /usr/share/nginx/html EXPOSE 443 CMD ["nginx", "-g", "daemon off;"] Taula 12: Contingut del fitxer Dockerfile.pro del Front-End Font: Elaboració pròpia amb DBeaver Podem veure cóm designem la imatge base del sistema (node 16-alpine, li afegim un nom descriptiu per diferenciar-ho al llistat d’imatges i contenidors en execució, realitzem operacions de còpia d’arxius, executem la descàrrega de llibreries, i executem la compilació. A l’apartat del servidor web veiem que partim d’una imatge NGINX stable-alpine, designem nom descriptiu, copiem la compilació a dins des de el contenidor anterior, obrim el port d’accés HTTS i executem el servidor web. El server API del Back-End si que manté els dos contenidors perquè el servidor NGINX només fa de pasarela SSL dins d’una xarxa virtual entre els dos contenidors. A la figura següent podem apreciar 40 com la connexió externa és per SSL però la interna és HTTP. Les connexions a les APIs de dades de la UPC també es realitzen amb protocol SSL. Figura 8: Esquema de contenidors de Back-End Font: Elaboració pròpia amb Lucidchart Podem veure la seva configuració al fitxers “docker-compose.pro.yml”, “Dockerfile.api” i “Dockerfile.proxy”. El primer de tots designa la configuració interna dels dos contenidors i la xarxa virtual interna entre els dos: version: '3.9' services: api: container_name: garos_back_api build: dockerfile: Dockerfile.api context: . command: python manage.py runserver 0.0.0.0:8000 env_file: - sql-variables.env environment: - SQL_SRV=${SQL_SRV} - SQL_PASSWORD=${SQL_PASSWORD} - OIDC_CLIENT_ID=${OIDC_CLIENT_ID} - AUTHORITY=${AUTHORITY} - BACKEND_URL=${BACKEND_URL} - FRONTEND_URL=${FRONTEND_URL} - OIDC_SERVER_TYPE=${OIDC_SERVER_TYPE} - SOA_PASS=${SOA_PASS} - GN6_PASS=${GN6_PASS} dns: - 147.83.41.36 - 147.83.41.104 dns_search: - fib.upc.es networks: back: ipv4_address: 172.88.0.10 proxy: container_name: garos_back_proxy 41 Mòdul d’Equips api_connexiousuari: Copia tal qual les dades provinents de POA amb claus foranes per a la ubicació i l’usuari. Cal remarcar que totes aquestes dades venen juntes des de l’aplicació POA i al Back-End es distribueixen en les tres classes. Queden registrats els moments de Login i Logout, el sistema operatiu (so) fet servir, l’usuari que ha accedit i la seva ubicació. Aquestes dos últimes dades són claus foranes. Cada terna dateTimeLogin, usuari i ubicació és única. Cada connexió nova rebuda crea una entrada nova però cada connexió que desapareix estableix la variable dateTimeLogout al temps actual i ho guarda a la base de dades. api_ubicacio: Cada ubicació és única i ve identificada amb la seva denominació. És possible que en un futur aquesta classe es pugui arribar a ampliar. Cada ubicació és única i conforma la seva clau primària. Cada ubicació nova que arriba crea una nova entrada i és permanent a la base de dades api_usuari: Cada connexió es produeix per un usuari i POA proveeix del seu nom i cognoms. Per cada usuari es guarda el nom d’usuari del sistema, el seu nom personal i els seus cognoms. Cada nom d’usuari és únic i conforma la la pròpia clau primària. Cada nou usuari nou que arriba es crea una nova entrada i és permanent a la base de dades. Taula 16: Taules de la base de dades per al mòdul d’Equips Font: Elaboració pròpia amb DBeaver 48 Mòdul de Tiquets api_tiquet: Copia gran part de la informació rebuda de cada tiquet, queden fora de la taula el contingut i altres dades no rellevants per la informació que es requereix. Per cada tiquet es guarda el codi, l’assumpte, el nom del client d’on prové el tiquet (aplicació origen), el codi del client (codi d’aplicació origen), a qui ha sigut assignat el tiquet si existeix assignació, el nom de la persona o departament assignat, la data de creació del tiquet, el codi de l’equip que ha de resoldre el tiquet, el nom de l’equip resolutor, el nom descriptiu de l’estat del tiquet (no guarda el seu codi), el nom descriptiu de la seva prioritat (no guarda el seu codi), el nom d’usuari del sol·licitant del tiquet, el nom de l’usuari sol·licitant i el nom descriptiu de la urgència (no el seu codi) Cada Tiquet ve identificat amb una id que és clau primària. Quan un nou tiquet apareix es crea una nova entrada i quan desapareix de la llista rebuda també s’elimina la entrada de la taula. Recordem que només fa de caché d’informació. api_perfil: Cada usuari que entra al sistema té una sèrie d’equips resolutors visualitzables per defecte i altres equips que pot veure de forma opcional. Per habilitar i deshabilitar la visualització de cada equip es guarden en aquest perfil on cada usuari pot personalitzar la seva visualització en funció dels tiquets que necessita veure. Cada perfil guarda un text que representa un objecte en format JSON qué llista els equips resolutors visibles. Cada perfil ve identificat amb un usuari que és clau primària. Taula 17: Taules de la base de dades per al mòdul de Tiquets Font: Elaboració pròpia amb DBeaver 49 Mòdul de Calendaris api_examen: A fi de poder veure les notificacions dels exàmens pendents del dia l’aplicació carrega la informació de les reserves realitzades prèviament filtrades. Cada reserva nova crea una entrada nova i cada reserva desapareguda elimina la entrada, recordem que només fa de caché. Per cada examen es guarda el codi de reserva, la descripció de la reserva, el títol de la reserva, l’assignatura de l'examen, les aules que farà servir, la hora inicial, la hora final, el tipus de reserva, els comentaris afegits, si requereix entorn segur o no, si l’USB estarà disponible, el sistema operatiu que farà servir (imatge), el tipus d’usuari que entrarà als equips, els accessos permesos a webs (acces_url), si es podrà accedir a home_dades, i observacions afegides. Cada examen queda identificat amb una id independentment del codi que proporciona i que forma la clau primària. Es té previst fer servir aquesta informació en un futur, per això es guarda informació ara innecessària. Taula 18: Taula de la base de dades per al mòdul de Calendari Font: Elaboració pròpia amb DBeaver 50 3.3.1.4 Seguretat En qüestions de seguretat és important dir que ha sigut el procés més complicat ja que quasi bé cada font de dades té el seu mètode d’autenticació o registre d’usuari. Aquí detallem els mètodes d’autenticació i les seves particularitats i justificacions: ●SSOLab Pre: Per tal de tenir un usuari autenticat al sistema cal tenir un sistema d’autenticació de la UPC. Aquest servei d’autenticació és una versió provisional que serà el futur mètode SSO de la UPC però encara està en desenvolupament. Com és el mateix cas d’aquesta aplicació i també està connectat al sistema d’autenticació SSO actual de la UPC ja ens serveix com mètode d’autenticació del servei, i en un futur la transició serà més ràpida. ●Api UPC: Per a la API de la UPC hi han diversos àmbits d’autenticació però el que nosaltres requirim és el públic. Aquest mètode només requereix un registre del sistema dins del servei API per poder fer crides. El registre en qüestió ens proporciona un Client_ID que hem de donar en cada crida a la API. ●SOAP - GN6: El sistema d’autenticació per recollir dades dels tiquets conté una pasarel·la SOA d’autenticació prèvia, per aquest motiu calen dos usuaris i dos contrasenyes per fer la crida. El mètode de sol·licitud de dades no és un Request convencional com es fa entre Front-End i Back-End o entre Back-end i API UPC sino que es requereix una libreria de client SOAP per a Python anomenada SUDS. ●Google: De cara a poder accedir als calendaris de Google hi han dos vies, una és registrar l’aplicació a Google Cloud per fer crides directament a la API de Calendar i una altre és embebir directament un frame de Google Calendar a la web. Es va triar la segona opció perquè no es requeria tractament de les dades i simplificava enormement el desenvolupament del mòdul. ●SSL: Tan per la connexió entre el navegador de l’usuari i la web de GAROS com entre el navegador i la API de GAROS la seguretat de la comunicació és SSL amb un certificat proporcionat per la UPC. Ambdós tenen el mateix certificat ja que treballen amb el mateix domini garos.fib.upc.edu. També existeix seguretat SSL entre el Back-End i la API de la UPC, aquesta última amb el seu propi certificat. 51 3.3.2 Patrons i disseny Si mirem el esquema global podem apreciar que és semblant, però no encertat, al concepte del patró Model-Vista-Controlador però amb interfícies API en la comunicació entre la Vista (Front-End) i el Controlador (Back-end) i comunicació SQL entre el controlador (Back-End) i el Model de base de dades (MariaDB). Aquest mateix patró l’hem pogut estudiar a l’assignatura de PROP on es tracten directament aquestes qüestions. Figura 11: Diagrama Model-Vista-Controlador Font: Platzi.com Però en l’esquema de micro-serveis considerat està definit el patró de Aggregator amb una capa de visualització i base de dades pròpia com el mencionat anteriorment. El patró Aggregator es caracteritza per ser un consumidor de dades API per fer anàlisi, visualització, càlculs, etc. És precisament el que fa el nostre Back-End però amb un Model i Vista afegits. Figura 12: Diagrama Aggregator Font: https://refactorizando.com/arquitectura-de-microservicios/ 52 Estrictament parlant i seguint la filosofia de micro-serveis aquest projecte hauria d’haver implementat els dos patrons per separat, un contenidor Python només per recollir dades dels proveïdors informació de la UPC i enviar-les al servidor Django[27]. I el contenidor amb Django[27] que faria només les funcions de API per consulta i modificació de dades de la base de dades. Però com que el model Aggregator simple té poques fonts d’informació i encaixen directament amb els mòduls, i aprofitant que la API ja funciona amb el llenguatge que fa servir, hem decidit fer els dos patrons en un de sol. Potser en un futur cap la possibilitat de diferenciar el dos patrons i separar en dos contenidors aquestes tasques. 53 3.3.3 Interfície El disseny d’una bona interfície intuïtiva, agradable i fàcil és clau per l’èxit d’un sistema que fa servir una persona física i per això s’ha posat molta cura de que la distribució, l'accessibilitat, la coherència i la facilitat d’ús estigui dins el medi d’interacció amb l’usuari. Presentem a continuació una captura de pantalla d’una pàgina inicial per mostrar els camps generals de la interfície. Aquesta interfície ve donada pel Framework de la UPC Webapp Vue 3 que s’ha fet servir de base per la interfície. A la barra superior podem veure d’esquerra a dreta el logotip de la UPC, seguit de una icona per minimitzar el menú lateral, El títol del sistema “GAROS”, una icona informativa que conté un enllaç a la web de https://www.fib.upc.edu/ca/la-fib/serveis-tic/cataleg-de-serveis, una icona per escollir el l’idioma del sistema, i un accés al nostre perfil d’usuari autenticat. A la barra lateral esquerra podem veure el menú on trobem les seccions de Panell, Calendaris, Tiquets, Préstecs i Equips. A la seva dreta tindrem el contingut de cada una de les seccions (mòduls), i a la part de sota (peu) tenim una barra que ens indica la propietat “© UPC Universitat Politècnica de Catalunya · BarcelonaTech”, un enllaç de contacte que ens informa que podem contactar amb ATIC en cas d'incidències, un enllaç d'accessibilitat que ens porta a la web https://www.upc.edu/ca/avis-legal/accessibilitat, i un últim enllaç d’avís legal que ens porta a la web https://www.upc.edu/ca/avis-legal. Figura 13: Distribució de la interfície Font: Elaboració pròpia Els continguts de cada mòdul i del panell es detallen a la secció “Experiència d’usuari”. 54 3.4 Experiència d’usuari És important que cada usuari experimenti el sistema de forma còmoda, informativa, útil i que s’adapti a les seves necessitats. També és important que augmenti el rendiment del treballador facilitant la feina diària i avisar només de la informació rellevant sense perdre tota la informació útil. 3.4.1 Accés i primera vista De primeres, si introduïm l’adreça de garos.fib.upc.edu ens ha de mostrar la pantalla d’autenticació en la qual s’ha d'introduir el nom d’usuari i contrasenya de la UPC. Certament no és igual que la pantalla de Login habitual de la UPC però ja hem mencionat anteriorment que aquest mètode d’autenticació està en desenvolupament i que serà el que acabi donant servei a la UPC. Figura 14: Autenticació SSOLab Font: Elaboració pròpia Un cop autenticats entrarem directament a la secció del Panell que ens mostrarà un resum dels diferents mòduls de l’aplicació. 55 Figura 15: Distribució dels elements del panell Font: Elaboració pròpia Al Panell podem veure a la part superior una gràfica de barres que ens indica el nombre d’hores que porta un equip en marxa. Concretament, quantes hores està un usuari logejat. Això és útil de cara a saber si algun usuari s’ha deixat l’equip encès i quantes persones hi han treballant a les aules. Les connexions inferiors a quatre hores con mostrades en verd i les de més de quatre són mostrades en vermell. A la part inferior tenim el resum de la resta de mòduls. El primer és un llistat resumit dels tiquets on els tiquets amb equip resolutor “Dispatcher” es mostren en vermell. Això és perquè són tiquets que s’han de redirigir a altres departaments i són la feina més urgent. El segon és un gràfic de barra vertical dels préstecs actuals i les quantitats de cada tipus on el blau són el nombre de préstecs indefinits, els verds són el nombre de préstecs pendents d’entregar a temps, i el vermell són els préstecs caducats pendents d’entregar. Aquest últim grup són els urgents i que s’han de reclamar a la persona que es va registrar el préstec. Per últim veiem un resum de tots els calendaris que fa servir Operació i sistemes on cada calendari està representat en un color diferent. Al menú lateral esquerra podem veure que les diferents seccions que representen els mòduls tenen indicatius en vermell. Aquests indicatius marquen la informació rellevant que hi ha a cada mòdul. Per exemple: A la gràfica de connexions veiem que hi ha una connexió en vermell i al menú lateral la secció d’equips porta un número 1 en vermell. La secció de préstecs al menú porta un número 8 que indica el nombre de préstecs caducats pendents de reclamar. A la secció de tiquets apareixen el nombre de tiquets de tipus “Dispatcher”. I als calendaris indica el nombre de reserves d’exàmens que queden el dia d’avui. 56 3.4.1 Calendaris A la secció de Calendaris inicialment podem veure els tres calendaris embeguts dels aularis A5, B5 i C6 dins de la primera pestanya “Exàmens”. A la segona pestanya “Departaments i esdeveniments” trobem els calendaris de “Presentacions i esdeveniments”, “Recursos Humans” i “Esdeveniments Sistemes”. Figura 16: Visual de la secció de Calendaris Font: Elaboració pròpia A la última pestanya podem trobar tots els calendaris en una visió mensual per poder tenir una perspectiva temporal de totes les activitats. 57 4. Conclusions A data del redactat d’aquesta memòria i havent complert quasi bé tots els objectius funcionals de l’aplicació queda repassar la feina feta i treure conclusions de tot el procés de planificació i desenvolupament del projecte. 4.1 Assoliment dels objectius inicials Si bé no tots els objectius planificats han resultat complerts cal dir que la majoria amplia s’han aconseguit. Tenim un sistema que recapta informació d’altres sistemes d’informació, ordena i resumeix les dades rebudes, avisa a l’usuari de la informació rellevant i guarda informació addicional per completar el servei. A més, proporciona una interfície clara, àgil, que s’actualitza automàticament i que compleix amb els requeriments modulars planejats des d’un inici.: Préstecs, tiquets, calendaris, connexions a equips i resum global. A més el projecte s’ha dut a terme dintre d’un marge de temps raonable tot i els inconvenients trobats i retards. La concepció del sistema és quasi bé la inicial i va en consonància amb la resta de sistemes d'informació nous que s'estan creant a la UPC avui dia. De vuit setmanes planificades totals el projecte ha trigat deu en tenir tots els mòduls en funcionament, tot i que sempre poden sortir correccions que formen part de la fase de manteniment continu. En quant a les hores i personal dedicats al projecte tenim que: ●Pel departament de Sistemes la Sandra Marsà ens reporta 10 hores en: creació d’un nou servidor, backups, instal.lació dockers, parches, etc. ●Jaume Moral en el suport de connexió i recollida de dades de les fonts de la UPC ens reporta unes 5 hores de feina. ●Per part d’un servidor les hores dedicades al projecte sobrepassen de molt les estimades, fins i tot es podien arribar a duplicar. Al punt de “Problemes i dificultats” podem trobar les causes de l’augment d’hores dedicades. 4.2 Assoliment dels objectius personals A nivell personal crec que el projecte ha suposat un gran esforç en quant a dedicació i aprenentatge però el resultat ha sigut molt satisfactori. Crec que aquest projecte té la capacitat d’escalar amb més serveis connectats i assumir mes càrrega de serveis propi, és a dir, no provinent d’altres sistemes d’informació. El fet de fer servir una plataforma estàndard de la UPC ha facilitat la feina en certa mesura per què algunes decisions de disseny ja venen suggerides i no s’ha tingut la necessitat d’experimentar. Veig GAROS com un projecte de futur que pot esdevenir la pedra angular del servei de Operació de la FIB i part de la de Sistemes; i potser també d’altres departaments de la UPC en un futur. 64 4.3 Problemes o dificultats Com tot projecte no ha estat exempt de dificultats, le més destacables han sigut la formació en els Frameworks i els sistemes d’autenticació. Aquest últim ha sigut força farragós per què implicava altres departaments i calia que dediquessin temps al meu projecte per esbrinar alguns errors o mostrar-me el seu funcionament. La cerca d'informació i recursos a internet ha sigut clau per resoldre la majoria de problemes i mancances de formació, i moltes vegades ha sigut clau en la presa de decisions veure conceptes o mètodes fets de diferents formes. També ens hem trobat que alguns continguts no tenien prou documentació i s’ha hagut de trucar i parlar amb persones que han tocat el tema. Altres vegades els procediments no estaven prou clars i s’ha tingut que investigar i realitzar proves de funcionament. Una dificultat trobada força incòmoda era l’ordinador de la UPC destinat a ser l’equip de desenvolupament que per ser massa antic i no tenir suficient memòria suposar una veritable desesperació quan s’havien de posar en marxa els contenidors o realitzar la compilació. Per sort es va canviar a temps per un portàtil amb més potència i memòria que podia realitzar tota la feina de forma sobrada. 4.4 Feina futura GAROS està pensat per ser la pedra angular de tota la informació que que requereix un usuari d’Operació a la FIB i per la part de Sistemes relacionat amb aquest. Com podem llegir a un apartat anterior “Objectius de futur” queden moltes funcionalitats i ampliacions per ficar dins del sistema. És més, a mida que avançava el projecte han sortit algunes de noves que es poden plantejar en un futur. Unes de les qüestions més útils es poder realitzar estadístiques d'ús i activitats en tots els mòduls del sistema com veure quins equips o aules són les més utilitzades dins i fora d’horari, analitzar el grau de morositat als préstecs, el grau de presencialitat i utilització de l’equipament, etc. Aquests anàlisi estadístics poden ser molt útils de cara a la presa de decisions, el que s’anomena Intel·ligència Empresarial[43] o Bussiness Inteligence (BI) en anglès. El fet de fer servir un Framework estès a la UPC facilita el fet de que qualsevol persona que domini Vue i Django[27] sigui capaç de fer-se càrrec del manteniment i ampliació del sistema. S’ha tingut en compte de que totes les variables i funcions tinguin noms autodescriptius per facilitar la navegació pel codi a fi de facilitar l’accés a qualsevol nou programador futur. També està pensat fer un manual tècnic per al programador per el cas en que es vulgui exportar el sistema a altres departaments anàlegs. 4.5 Assoliment de les competències tècniques Les competències tècniques són uns requeriments mínims per demostrar l’assoliment formatiu de la universitat i com s’ha aplicat al projecte de final de grau. Mirarem de resumir les influències formatives sobre cada una de les competències del projecte. 65 CSI2.1: Demostrar comprensión y aplicar los principios y las técnicas de gestión de calidad y de innovación tecnológica en las organizaciones. [Un poco] S’ha tingut cura de la metodologia, els temps d’execució, la seguretat corporativa i l'eficiència en tots els aspectes, tant en temps com en diners guardant sempre la qualitat promesa. CSI2.2: Concebir, desplegar, organizar y gestionar sistemas y servicios informáticos, en contextos empresariales o institucionales, para mejorar sus procesos de negocio, responsabilizarse y liderar su puesta en marcha, y su mejora continua; y valorar su impacto económico y social. [En profunditat] Queda clar que un sistema que facilita la resposta dels serveis i agilitza la rebuda d’informació rellevant sempre és benvingut a qualsevol entorn de treball. Aquest era l’objectiu i s’ha complert com s’esperava. S’ha planificar, organitzat, gestionat i desenvolupat un sistema que millora la eficiència en l’entorn laboral a més de rebaixar l'estrès als llocs de treball al reduir la preocupació constant de la informació rellevant. CSI2.3: Demostrar conocimiento y capacidad de aplicación de los sistemas de extracción y de gestión del conocimiento. [Bastante] Haver aconseguit connectar i comunicar sistemes d’informació diversos en una sola plataforma informativa que analitza, organitza i cataloga totes les dades es mostra suficient per considerar la competència com acomplerta. CSI3.1: Demostrar comprensión de los principios de la evaluación de riesgos y aplicarlos correctamente en la elaboración y la ejecución de planes de actuación. [Bastante] S’han complert les planificacions del projecte dintre dels terminis i pressupostos determinats fins a cert punt, ja que s’havia previst un cost addicional del 10% i finalment ha sigut del 20% només en l’àmbit temporal. Llevat dels endarreriments puntuals les previsions inicials han anat força a temps assolint quasi bé tots els objectius a nivell general. CSI4.1: Participar activamente en la especificación de los sistemas de información y de comunicación. [Bastante] L'especificació inicial és clau i al ser un projecte personal per la UPC ha sigut quasi bé completament pròpia. CSI4.3: Administrar bases de datos (CES1.6). [Un poco] Si bé l’àmbit de bases de dades pròpies no ha sigut massa extens, el accedir a diverses fonts d’informació podria veure’s com interaccions amb altres bases de dades. CSI3.3: Evaluar ofertas tecnológicas para el desarrollo de sistemas de información y gestión. [Bastante] 66 Pel que fa a l’estudi d’alternatives cal comentar que s’han mirat propostes alternatives en quant a Frameworks de desenvolupament tot i que des de un inici la suggerència de la UPC ha sigut la més encertada. No s’ha trobat cap sistema concret que pogués fer la feina d’aquest mateix sistema amb fonts d’informació tan particulars i pròpies com hi han a la UPC. CSI3.4: Desarrollar soluciones de negocio mediante la implantación y la integración de hardware y soware. [Bastante] El fet de determinar la divisió contenidors, la diferenciació hardware de la base de dades i l’estructura comunicativa interna i externa del sistema pot demostrar aquesta competència. CSI3.5: Proponer y coordinar cambios para mejorar la explotación del sistema y de las aplicaciones. [En profunditat] El propi fet de proposar un sistema d’informació per agilitzar el treball esdevé en si una millora per a l'explotació del sistema i la resta d’aplicacions dels llocs de treballs implicats. CSI1: Demostrar comprensión y aplicar los principios y las prácticas de las organizaciones, de manera que puedan ejercer como enlace entre las comunidades técnica y de gestión de una organización, y participar activamente en la formación de los usuarios. [Bastante] El fet de facilitar i agilitzar els serveis del lloc de treball implica una agilització dels procediments laborals. Aquestes millores s’han provat amb els usuaris finals els que han donat la seva opinió en tot moment i han ajudat a millorar el sistema. CSI4.2: Participar activamente en el diseño, la implementación y el mantenimiento de los sistemas de información y de comunicación. [En profunditat] Com ja hem comentat es un projecte propi per a la UPC i tot el disseny i implementació han sigut pròpies. A més, també s’espera que faci el manteniment de tot el sistema d’informació mentre hi sigui al lloc de treball. 67 5. Bibliografia [1] Creació de la Unitat Transversal de Gestió de l’àmbit TIC, 2017. [online], Barcelona : Consell de Govern de la Universitat Politècnica de Catalunya, Disponible: https://www.upc.edu/normatives/ca/documents/consell-de-govern/11-29-aprovacio-de-la-creacio-utg-a mbit-tic.pdf [2] inLab FIB. inLab FIB [online], [Accedit 1 Març 2022]. Disponible: https://inlab.fib.upc.edu/ [3] CATALUNYA, UPC, Unitat Transversal de Gestió de l'Àmbit TIC Campus Nord (UTG CNTIC). Unitat Transversal de Gestió de l'Àmbit TIC Campus Nord [online]. [Accedit 1 Març 2022]. Disponible: https://utgcntic.upc.edu/ca/la-utg [4] Racó de la FIB. Raco.fib.upc.edu [online], [Accedit 1 Març 2022]. Disponible: https://raco.fib.upc.edu [5] eATIC Atenció als usuaris. Gn6.upc.edu [online], [Accedit 1 Març 2022]. Disponible: https://gn6.upc.edu [6] Redmine, 2006. Redmine.org [online], [Accedit 1 Març 2022]. Disponible: https://www.redmine.org/ [7] Front end y back end - Wikipedia, la enciclopedia libre. Es.wikipedia.org [online], [Accedit 1 Març 2022]. Disponible: https://es.wikipedia.org/wiki/Front_end_y_back_end [8] Lambert, N., 2016. Microservicios: rompiendo el soware monolítico. [online] Computerworld.es. [Accedit 1 Març 2022]. Disponible: https://www.computerworld.es/innovacion/microservicios-rompiendo-el-soware-monolitico [9] Group, I., 2021. ¿Cómo evolucionará la adopción de tecnologías emergentes en 2022?. [online] Ituser.es. [Accedit 1 Març 2022]. Disponible: https://www.ituser.es/estrategias-digitales/2021/12/como-evolucionara-la-adopcion-de-tecnologias-em ergentes-en-2022 [10] Empowering App Development for Developers | Docker. Docker [online], [Accedit 1 Març 2022]. Disponible: https://www.docker.com/ [11] Production-Grade Container Orchestration. Kubernetes [online], Disponible: https://kubernetes.io [12] Charts.js | Open source HTML5 charts for your website. [online], Disponible: https://www.chartjs.org/ [13] MARK OTTO, AND BOOTSTRAP CONTRIBUTORS, Bootstrap. Getbootstrap.com [online]. [Accedit 1 Març 2022]. Disponible: https://getbootstrap.com/ [14] What is Vuex? | Vuex. [online], Disponible: https://vuex.vuejs.org/ [15] A Vue 3 UI Framework | Element Plus. [online], Disponible: https://element-plus.org/ [16] Information Technology Infrastructure Library (ITIL) - Wikipedia.es. [online], Disponible: https://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library [17] Producte mínim viable - Viquipèdia, l'enciclopèdia lliure, 2022. Ca.wikipedia.org [online], [Accedit 1 Març 2022]. Disponible: https://ca.wikipedia.org/wiki/Producte_m%C3%ADnim_viable [18] CATALUNYA, UPC, Identitat Digital UPC. - Universitat Politècnica de Catalunya. Identitat Digital UPC [online]. [Accedit 1 Març 2022]. Disponible: https://www.upc.edu/identitatdigital/ca [19] Booked – Simply Powerful Scheduling. Bookedscheduler.com [online], [Accedit 1 Març 2022]. Disponible: https://www.bookedscheduler.com/ [20] Metodologia àgil - Viquipèdia, l'enciclopèdia lliure, 2022. Ca.wikipedia.org [online], [Accedit 1 Març 2022]. Disponible: https://ca.wikipedia.org/wiki/Metodologia_%C3%A0gil [21] Extreme Programming: A Gentle Introduction. Extremeprogramming.org [online], [Accedit 1 Març 2022]. Disponible: http://www.extremeprogramming.org/ 68 [22] UPC webapp ui Vue 3. gitlab.upc.edu [online], [Accedit 1 Març 2022]. Disponible: https://gitlab.upc.edu/f1/upc-webapp-ui-vue3 [23] Vue.js - The Progressive JavaScript Framework | Vue.js. Vuejs.org [online], [Accedit 1 Març 2022]. Disponible: https://vuejs.org/ [24] Node.js. Node.js [online], [Accedit 1 Març 2022]. Disponible: https://nodejs.org [25] JavaScript - Viquipèdia, l'enciclopèdia lliure. Ca.wikipedia.org [online], [Accedit 1 Març 2022]. Disponible: https://ca.wikipedia.org/wiki/JavaScript [26] Welcome to Python.org. Python.org [online], [Accedit 1 Març 2022]. [Accedit 1 Març 2022]. Disponible: https://www.python.org/ [27] The web Framework for perfectionists with deadlines | Django. Djangoproject.com [online], [Accedit 1 Març 2022]. Disponible: https://www.djangoproject.com/ [28] Entorn integrat de desenvolupament - Viquipèdia, l'enciclopèdia lliure. Ca.wikipedia.org [online], [Accedit 1 Març 2022]. Disponible: https://ca.wikipedia.org/wiki/Entorn_integrat_de_desenvolupament [29] Visual Studio Code - Code Editing. Redefined. Code.visualstudio.com [online], [Accedit 1 Març 2022]. Disponible: https://code.visualstudio.com/ [30] Iterate faster, innovate together | GitLab. gitlab.com [online], [Accedit 1 Març 2022]. Disponible: https://about.gitlab.com/ [31] Free Bootstrap Admin Template - AdminLTE.IO. AdminLTE.IO [online], [Accedit 1 Març 2022]. Disponible: https://adminlte.io/ [32] Bootstrap Admin & Dashboard Template · CoreUI. Coreui.io [online], [Accedit 1 Març 2022]. Disponible: https://coreui.io/ [33] Premium dashboard template with responsive and high quality UI. Tabler.io [online], [Accedit 1 Març 2022]. Disponible: https://tabler.io/ [34] Welcome to Flask — Flask Documentation (2.0.x). Flask.palletsprojects.com [online], [Accedit 1 Març 2022]. Disponible: https://flask.palletsprojects.com [35] Ruby on Rails. Ruby on Rails [online], [Accedit 1 Març 2022]. Disponible: https://rubyonrails.org/ [36] Laravel - The PHP Framework For Web Artisans. Laravel.com [online], [Accedit 1 Març 2022]. Disponible: https://laravel.com/ [37] GitHub: Where the world builds soware. GitHub [online], [Accedit 1 Març 2022]. Disponible: https://github.com/ [38] Soware de administración de proyectos | Microso Project. Microso.com [online], [Accedit 1 Març 2022]. Disponible: https://www.microso.com/es-es/microso-365/project/project-management-soware [39] Trello. Trello.com [online], [Accedit 1 Març 2022]. Disponible: https://trello.com/ [40] Cloud Computing Services - Amazon Web Services (AWS). Amazon Web Services, Inc. [online], Disponible: https://aws.amazon.com [41] nahum.manuel.martin / GAROS · Gitlab. [online], Disponible: https://gitlab.upc.edu/nahum.manuel.martin/garos [42] DBeaver Community | Free Universal Database Tool. [online], Disponible: https://dbeaver.io/ [43] Intel·ligència empresarial - Viquipèdia, l’enciclopèdia lliure. [online], Disponible: https://ca.wikipedia.org/wiki/Intel%C2%B7lig%C3%A8ncia_empresarial 69