Tema 44 · Documental, GIS, qualitat i arquitectura

Solucions de gestió documental i arxiu electrònic

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Solucions de gestió documental i arxiu electrònic.

1. DMS, ECM i altres sigles

La gestió documental és la disciplina que s'ocupa de la planificació, la creació, la captura, l'ús, l'organització, el tractament i l'avaluació dels documents generats o rebuts per un organisme en l'exercici de les seves funcions (ISO 15489). Un SGD (Sistema de Gestió Documental) és l'aplicació que la implementa: no un repositori de fitxers, sinó el sistema que manté cada document lligat al seu productor, al seu procediment i al seu règim de conservació.

Aquesta formulació és la que apareix literalment a l'examen quan es demana quina proposta correspon a una solució de gestió documental, i és la resposta correcta: no ho són ni l'aplicació web de publicació de contingut (això és un CMS, Content Management System), ni una tecnologia que captura i emmagatzema sense preservar.

Diferència principal entre DMS i ECM —pregunta literal—: el DMS se centra en la gestió de documents individuals (versions, metadades, cerca, flux d'aprovació), mentre que l'ECM és un enfocament més ampli que abasta TOT el contingut empresarial de qualsevol tipus i format, integrant la captura, la gestió, l'emmagatzematge, la preservació i el lliurament al llarg de tot el cicle de vida i en connexió amb els processos de negoci. El DMS és, per tant, un component de l'ECM.

Les cinc funcions clàssiques de l'ECM (AIIM, Association for Information and Image Management): Capturar, Gestionar, Emmagatzemar, Preservar i Lliurar.

2. Funcionalitats d'un sistema de gestió documental

• Captura: digitalització amb OCR (Optical Character Recognition), importació massiva, captura des del correu, formularis i integració amb el registre d'entrada.
• Emmagatzematge amb metadades i quadre de classificació (→ apartat 2.2).
• Control de versions i historial de canvis.
• Cerca: per metadades i a text complet (indexació).
• Control d'accés granular i permisos heretats de l'expedient.
• Fluxos de treball (workflow) d'elaboració, revisió, aprovació i signatura.
• Signatura electrònica i segellat de temps.
• Retenció i disposició: polítiques de conservació i eliminació.
• Auditoria: la pista d'auditoria ha de ser inalterable i capturar i emmagatzemar automàticament quina acció s'ha dut a terme, quin usuari la inicia i a quina hora — és un requeriment habitual en la contractació d'aquestes eines. Implica directament dues dimensions de seguretat de l'ENS (tema de l'ENS): l'autenticitat (qui actua) i la traçabilitat (què i quan); no la integritat, que protegeix el contingut, ni la disponibilitat, que és l'accés.
• Integració amb la tramitació, el registre i el portasignatures.

Productes del mercat: Alfresco (codi obert), Nuxeo, OpenText (Content Suite i Documentum), Microsoft SharePoint, IBM FileNet, M-Files, OpenKM. Per a arxiu de preservació: Archivematica, iARXIU (AOC, Administració Oberta de Catalunya), Preservica.

Pregunta habitual: quina de les següents és una solució de gestió documental? La trampa que ha caigut és colar una suite ofimàtica —LibreOffice, Microsoft Office— entre gestors documentals: l'ofimàtica crea documents individuals, no els gestiona.

2.1 El cicle de vida del document i les edats de l'arxiu

Un document no «s'arxiva» al final: entra al sistema i hi recorre una seqüència de processos que la NTI de Política de gestió de documents electrònics enumera, i que tota administració ha de descriure a la seva política de gestió documental:

captura → registre → classificació → descripció → accés → traçabilitat → qualificació → conservació → transferència → destrucció

• La captura és l'entrada del document al sistema: se li assigna un identificador únic i les metadades mínimes obligatòries que el lliguen al seu autor i al context en què es va produir. És quan un fitxer passa a ser un document del sistema.
• El registre és l'assentament d'entrada o de sortida, i no és el mateix que la captura: registrar deixa constància fefaent de la recepció o la tramesa; capturar incorpora el document al sistema. Molts documents es capturen sense registrar-se mai —els que genera la mateixa tramitació—, i per això les metadades de registre només s'omplen soles en els documents lligats a l'assentament (→ apartat 4.1).
• La qualificació és la decisió arxivística: quant es conserva cada sèrie i què se'n fa després. No la pren qui tramita, sinó l'òrgan d'avaluació documental (→ apartats 2.2 i 6).
• La transferència és el pas d'una fase d'arxiu a la següent, amb canvi de custòdia; la destrucció només és possible amb una taula d'avaluació aprovada.

Les edats del document. L'arxivística ordena el recorregut en fases segons l'ús que es fa del document, i el model és el mateix en electrònic que en paper: el que canvia és que la transferència ja no mou caixes, sinó custòdia i metadades.

Les quatre classes són les del Reial decret 1708/2011 (Sistema d'Arxius de l'Administració General de l'Estat), on l'arxiu intermedi és l'Arxiu General de l'Administració. No tots els sistemes en tenen quatre: a Catalunya el recorregut habitual és gestió → central → històric (→ apartat 6). En electrònic, l'arxiu electrònic únic de la Llei 39/2015, art. 17 cobreix les fases posteriors al tancament del procediment.

2.2 Quadre de classificació, sèries documentals i calendari de conservació

Un sistema documental no s'organitza per carpetes ni per organigrama, sinó amb uns instruments que la ISO 15489 dona per necessaris i que no s'han de confondre entre ells:

• El quadre de classificació és l'estructura jeràrquica que ordena tota la documentació d'un organisme per funcions i activitats. Es fa funcional, i no orgànic, precisament perquè les funcions duren i les unitats es reorganitzen: un quadre orgànic caldria refer-lo a cada canvi d'organigrama. Cada branca acaba en una sèrie documental.
• La sèrie documental és el conjunt de documents produïts per un mateix òrgan en l'exercici d'una mateixa activitat i sotmesos al mateix tràmit: «llicències d'obres menors», «queixes per soroll», «cessió d'horts urbans». No és un document ni un expedient: és el tipus al qual pertanyen tots els expedients iguals, i és la unitat sobre la qual es decideix tot el que ve després. Per això l'anàlisi es fa sèrie a sèrie i mai expedient a expedient.
• El calendari de conservació —que es concreta en les taules d'avaluació documental— diu, per a cada sèrie, quant de temps es conserva la documentació, en quina fase, quin és el destí final (conservació permanent o eliminació) i en quines condicions s'hi accedeix.
• El catàleg de tipologies documentals descriu la forma del document —informe, acta, resolució, notificació—, que és una altra cosa que la funció que el genera.

La confusió que cal tenir resolta: el quadre de classificació diu on va cada document i el calendari de conservació quant dura i com acaba — dos instruments diferents sobre la mateixa sèrie, i cap dels dos és el catàleg de tipologies.

I la cadena, en ordre creixent — document → expedient → sèrie documental → quadre de classificació: un document és una unitat d'informació amb context propi; un expedient, el conjunt ordenat de documents d'un procediment (→ apartat 3); una sèrie, el conjunt de tots els expedients d'un mateix tràmit; el quadre, el mapa de totes les sèries de l'organisme.

3. El document i l'expedient electrònics

Document administratiu electrònic (Llei 39/2015, art. 26) — requisits de validesa:

a) contenir informació de qualsevol naturalesa arxivada en un suport electrònic segons un format determinat susceptible d'identificació i tractament diferenciat; b) disposar de les dades d'identificació que permetin la seva individualització, sens perjudici de la seva possible incorporació a un expedient electrònic; c) incorporar una referència temporal del moment en què han estat emesos.

Els documents emesos per les administracions han d'estar signats electrònicament. No requereixen signatura els emesos amb caràcter merament informatiu ni els que no formin part d'un expedient.

Expedient electrònic (Llei 39/2015, art. 70) — conjunt ordenat de documents i actuacions que serveixen d'antecedent i fonament a la resolució administrativa, així com les diligències encaminades a executar-la. Té format electrònic i es forma mitjançant la incorporació ordenada dels documents, amb un índex numerat i, quan es remet, complet, foliat, autentificat i acompanyat d'un índex així mateix autentificat, i amb una còpia electrònica certificada de la resolució.

No forma part de l'expedient la informació de caràcter auxiliar o de suport —aplicacions, fitxers i bases de dades informàtiques, notes, esborranys, opinions, resums, comunicacions i informes interns o entre òrgans— ni els judicis de valor, llevat que es tracti d'informes preceptius o facultatius sol·licitats abans de la resolució. → tema comú 17.

Còpies autèntiques (Llei 39/2015, art. 27) i digitalització: la còpia electrònica d'un document en paper requereix digitalització i la incorporació de la metadata que n'acredita la condició de còpia. Les còpies autèntiques d'una administració són vàlides davant qualsevol altra.

Arxiu electrònic únic (Llei 39/2015, art. 17): cada administració ha de mantenir un arxiu electrònic únic dels documents que corresponguin a procediments finalitzats, en un format que permeti garantir l'autenticitat, la integritat i la conservació, així com la consulta amb independència del temps transcorregut, amb aplicació de les mesures de seguretat de l'ENS.

4. Interoperabilitat i normes tècniques

L'ENI es desplega en les NTI (Normes Tècniques d'Interoperabilitat), que són d'aplicació obligatòria:

• NTI de Document Electrònic: components (contingut, metadades mínimes obligatòries, signatures) i format d'intercanvi ENI-XML (basat en XML, eXtensible Markup Language). Metadades mínimes: identificador, òrgan, data de captura, origen (ciutadà o administració), estat d'elaboració (original, còpia autèntica, còpia electrònica…), tipus documental i nom del format.
• NTI d'Expedient Electrònic: documents, metadades i índex ENI-XML signat. L'índex pot ser provisional abans del tancament i pot referenciar documents de més d'un expedient.
• NTI de Digitalització de documents: requisits d'imatge i de signatura de la còpia.
• NTI de Política de gestió de documents electrònics: cada administració ha de tenir la seva política de gestió documental.
• NTI de Procediments de còpia autèntica i conversió, Catàleg d'estàndards, SICRES 4 (Sistema d'Informació Comuna de Registres d'Entrada i Sortida: model de dades per a l'intercanvi d'assentaments registrals) i Reutilització de recursos d'informació.

Integració entre sistemes: per connectar l'arxiu electrònic amb la resta d'aplicacions d'administració electrònica —passarel·la d'interoperabilitat amb l'AOC, registre d'entrada i sortida, e-notificació, e-signatura, contractació—, l'estàndard que cal establir, per senzillesa de protocol i efectivitat de la interconnexió middleware, és una API (Application Programming Interface) REST (Representational State Transfer): la capa de serveis de cada sistema exposa crides a accions concretes, sense una interfase corporativa única. No s'ha de confondre amb CORBA (Common Object Request Broker Architecture), middleware obsolet, ni amb ETL (Extract, Transform, Load), per a càrregues massives de dades, ni amb SNMP (Simple Network Management Protocol), per a monitoratge de xarxa.

4.1 Metadades: qui determina cada característica

Els expedients electrònics conformats al gestor documental tenen les seves pròpies metadades, repartides en grups que no es determinen igual:

• Les metadades de registre —les que deixa l'assentament registral: número, data, oficina— només s'emplenen de manera automàtica en els documents lligats a aquest assentament, no en tots els de l'expedient.
• Les metadades de gestió, característiques de cada procediment, no tenen un esquema únic per a tot l'organisme: la forma en què s'han d'informar és la que determini l'anàlisi documental de la sèrie documental corresponent, feta pel servei d'arxiu en construir el quadre de classificació (→ apartat 6).
• L'identificador únic de l'expedient es genera automàticament en crear-lo i l'identifica en tot el sistema; no se substitueix pel de cap tràmit concret.

Aquest repartiment és el que cal complir per satisfer el MGDE (Model de Gestió de Documents i Expedients Electrònics): quin grup de metadades s'omple sol, quin el fixa l'anàlisi de cada sèrie i quin queda fix un cop generat, no és el mateix.

El Model tecnològic del MGDE defineix la relació entre els components tecnològics del sistema —el repositori d'objectes documentals, les interfícies per interactuar-hi, el framework de serveis documentals— i els requisits que han de complir. És funcional i agnòstic de producte: no identifica proveïdors, ni llenguatges de programació, ni requisits tècnics concrets.

4.2 Esquemes de metadades i normes de descripció

Una cosa són les metadades mínimes obligatòries —les que exigeix la NTI de Document Electrònic, que és el mínim per interoperar— i una altra un esquema de metadades, que és el catàleg complet d'elements que una organització manté al llarg de tot el cicle de vida:

• e-EMGDE (Esquema de Metadades per a la Gestió del Document Electrònic): l'esquema de referència de l'Administració espanyola, que acompanya la NTI de Política de gestió de documents electrònics. Agrupa els elements en tres blocs: els obligatoris per les NTI de document i d'expedient, els complementaris mínims —necessaris per transferir documents i expedients entre repositoris amb canvi de custòdia— i els complementaris recomanats. La versió vigent és la 3.0, del desembre del 2023.
• Dublin Core: esquema genèric i curt de descripció de recursos, pensat per localitzar-los, no per gestionar-ne el cicle de vida ni acreditar-ne el valor probatori.
• PREMIS: esquema específic de metadades de preservació (→ apartat 5).

La descripció arxivística és una altra cosa: descriu fons i sèries per a la consulta, no cada document per tramitar-lo.

Normes internacionals: ISO 15489 (gestió de documents), ISO 30300/30301 (sistemes de gestió per als documents), ISO 14721 (OAIS, Open Archival Information System) —model de referència d'un sistema obert d'arxiu d'informació, amb els seus paquets SIP (submissió), AIP (arxiu) i DIP (Dissemination Information Package, difusió)— i ISAD (International Standard Archival Description) (G), per a la descripció arxivística.

5. Preservació digital

El problema: garantir que un document sigui llegible, íntegre i autèntic d'aquí a trenta anys, quan els formats, els suports i els algorismes de signatura hagin canviat.

Estratègies:

• Migració de formats a formats estables, oberts i normalitzats: PDF/A per a documents, TIFF (Tagged Image File Format) per a imatges i XML per a dades.
• Emulació de l'entorn original.
• Redundància i verificació d'integritat mitjançant resums criptogràfics (hash) i comprovació periòdica.
• Resegellat de temps i signatures longeves: formats AdES amb perfil de llarg termini —CAdES-A / XAdES-A / PAdES-LTA (LTA: Long-Term Archive)— que incorporen segells de temps encadenats i la informació de validació, de manera que la signatura continua sent verificable quan els certificats han caducat o els algorismes s'han quedat curts.
• Metadades de preservació: PREMIS (Preservation Metadata: Implementation Strategies).
• Custòdia distribuïda i còpies en ubicacions separades.

A Catalunya: iARXIU del Consorci AOC és el servei de preservació digital per a les administracions catalanes.

6. Gestió documental a l'Ajuntament de Barcelona

• Arxiu electrònic municipal: l'estructura on s'emmagatzemen i conserven tots els documents i expedients electrònics de l'activitat municipal. Aquesta és la definició que apareix a l'examen.
• AIDA (Administració Integral de Documents i Arxius): el sistema municipal de gestió documental, amb els quatre instruments de l'apartat 2.2 aplicats a Barcelona: el quadre de classificació (funcional), el mètode de descripció, el calendari de conservació i accés i el catàleg de tipologies documentals.
• Sistema Municipal d'Arxius: Arxiu Municipal Contemporani, Arxiu Històric de la Ciutat, arxius de districte i arxius centrals de sector.
• Comissió Municipal d'Avaluació i Accés a la Documentació: òrgan que aprova les taules d'avaluació documental, que determinen què es conserva permanentment i què es pot eliminar i quan. Cap document públic no es pot destruir sense una taula d'avaluació aprovada.
• Integració: GPA (Gestió de Procediments Administratius, tramitació), registre, portasignatures i seu electrònica → tema 4.
• BCNROC (Barcelona, Repositori Obert de Coneixement): repositori obert, per a la difusió dels documents públics municipals.

Marc normatiu català: Llei 10/2001, d'arxius i gestió de documents (modificada per la Llei 20/2015), que regula el Sistema d'Arxius de Catalunya i la CNAATD (Comissió Nacional d'Accés, Avaluació i Tria Documental).

7. Accés i protecció de dades

• Dret d'accés a la informació pública (Llei 19/2013, art. 12 i Llei 19/2014) → tema comú 18: els documents són accessibles amb els límits taxats.
• Protecció de dades (RGPD): els documents contenen dades personals; cal base de licitud, limitació del termini de conservació i control d'accés. L'excepció d'arxiu en interès públic (RGPD, art. 5.1.e i RGPD, art. 89) permet conservar més enllà del termini ordinari amb garanties adequades.
• Seguretat: l'ENS classifica la informació i imposa mesures de protecció, traçabilitat i còpies de seguretat.
• Transparència vs privadesa: l'Llei 19/2013, art. 15 obliga a ponderar l'interès públic en la divulgació i els drets dels afectats, i preveu la dissociació de les dades com a solució.
• Accés de les persones interessades: les persones usuàries podran recuperar sempre els documents que necessitin, sempre que s'identifiquin, i de cada accés en quedarà traçabilitat —el mateix registre d'auditoria de l'apartat 2.

Claus d'examen

• DMS és un component de l'ECM, no a l'inrevés: si la pregunta demana el terme més ampli, és sempre l'ECM.
• Una pista d'auditoria inalterable que registra usuari, acció i hora és autenticitat + traçabilitat de l'ENS —no integritat ni disponibilitat (TS-TIC 2018, p. 8).
• El contingut de les metadades de gestió d'un expedient el fixa l'anàlisi documental de la sèrie documental corresponent, sèrie a sèrie —no una llista fixa per a tot l'organisme—; les metadades de registre només s'omplen soles en els documents de l'assentament registral, i l'identificador únic de l'expedient, un cop generat, no se substitueix pel de cap tràmit (TS-TIC 2021, p. 24; TS-TIC 2023, p. 17).
• La integració entre sistemes d'administració electrònica es fa amb API REST: ETL és per a càrregues massives de dades i CORBA és middleware obsolet, no estàndards d'integració actuals (TS-TIC 2018, p. 9).
• Recuperar sempre els propis documents identificant-se, amb accés traçat (TS-TIC 2023, p. 19).
• Quan es demana què és una solució de gestió documental, la correcta és la definició de la disciplina —planificació, creació, captura, ús, organització, tractament i avaluació dels documents d'un organisme—, no la d'un CMS de publicació web ni la d'una eina que captura i emmagatzema sense preservar (TS-TIC 2023, p. 26).

Per recordar

• DMS = documents; ECM = TOT el contingut de l'organització i tot el seu cicle de vida. El DMS és un component de l'ECM.
• Cinc funcions de l'ECM: capturar, gestionar, emmagatzemar, preservar i lliurar.
• Cicle de vida (NTI de Política de gestió): captura → registre → classificació → descripció → accés → traçabilitat → qualificació → conservació → transferència → destrucció. Edats de l'arxiu: gestió → central → intermedi → històric; capturar no és registrar.
• Quadre de classificació = on va cada document, funcional (per funcions, no per organigrama). Calendari de conservació / taula d'avaluació = quant dura i com acaba, sèrie a sèrie. La sèrie documental és el conjunt de tots els expedients d'un mateix tràmit: document → expedient → sèrie → quadre.
• e-EMGDE és l'esquema de metadades de referència (tres blocs: obligatoris, complementaris mínims per a la transferència amb canvi de custòdia i complementaris recomanats); les metadades mínimes obligatòries de la NTI només són el mínim per interoperar.
• Document electrònic (Llei 39/2015, art. 26): informació en suport electrònic + dades d'identificació + referència temporal, i signatura si l'emet l'Administració.
• Expedient electrònic (Llei 39/2015, art. 70): índex numerat i autentificat, còpia certificada de la resolució, i la informació auxiliar i els judicis de valor NO en formen part.
• Arxiu electrònic únic (Llei 39/2015, art. 17): per a procediments finalitzats, garantint autenticitat, integritat i conservació amb independència del temps transcorregut.
• Les NTI de l'ENI fixen les metadades mínimes obligatòries i el format ENI-XML. Les metadades de registre s'omplen soles; les de gestió les fixa l'anàlisi de la sèrie documental corresponent (MGDE).
• La integració entre sistemes d'administració electrònica es fa amb API REST, no amb ETL ni CORBA.
• OAIS (ISO 14721): SIP → AIP → DIP. Preservació amb PDF/A, hash, resegellat de temps i signatures AdES de llarg termini.
• A Barcelona: AIDA (quadre de classificació funcional, calendari de conservació) i la Comissió d'Avaluació; cap document es destrueix sense taula d'avaluació aprovada.

Tema 45 · Documental, GIS, qualitat i arquitectura

Serveis digitals geogràfics

Enunciat oficial. Serveis digitals geogràfics: definició, funcions i tipus d'informació. INSPIRE, IDE, OGC.

1. Conceptes bàsics

Un servei digital geogràfic és el servei que una administració presta per la xarxa i que té la posició al territori com a element central: veure un mapa, cercar una adreça, consultar què hi ha en un punt, descarregar una capa o saber quines dades existeixen. Perquè existeixi calen sempre tres peces —dades amb coordenades, un SIG que les gestioni i un servei web estàndard que les publiqui— i és aquesta última la que el converteix en un servei interoperable i no en un mapa que només es pot mirar. El servei digital al ciutadà en general —seu electrònica, identificació, notificacions— es desenvolupa a administració electrònica i serveis digitals; aquí només interessa el que la posició hi afegeix.

SIG (Sistema d'Informació Geogràfica), en anglès GIS (Geographic Information System): sistema per capturar, emmagatzemar, gestionar, analitzar i representar informació referenciada geogràficament.

Dada geoespacial: la que té associada una posició a la superfície terrestre. Té dues components: geomètrica (on) i temàtica o alfanumèrica (què).

Els cinc components d'un SIG: maquinari, programari, dades, persones i mètodes/procediments.

Funcions d'un SIG: entrada i captura de dades, gestió i emmagatzematge, anàlisi espacial (superposició, proximitat, xarxes, interpolació), consulta, i sortida i visualització (mapes, informes).

1.1 Tipus d'informació geogràfica

Tres eixos diferents es confonen amb facilitat, i val la pena separar-los abans de res: el tipus d'informació (què representa la dada), el model de dades (com es representa, apartat 2) i el format de fitxer (com es desa, apartat 4). Un mateix carrer pot ser dada de referència, estar en model vectorial i venir en un GeoPackage.

Pel contingut, la LISIGE classifica la informació geogràfica en dues famílies, seguint la mateixa lògica que els annexos d'INSPIRE:

• Informació geogràfica de referència (annex I de la llei): la cartografia bàsica sobre la qual es recolza tota la resta —marc geodèsic, unitats administratives, adreces, noms geogràfics, parcel·les cadastrals, xarxes de transport, hidrografia, altimetria i ortoimatges—. No és de cap sector concret: la produeix i la manté un organisme cartogràfic perquè tothom hi encaixi el que és seu. L'annex I de la LISIGE recull el contingut dels annexos I i II d'INSPIRE junts, i per això l'elevació i les ortoimatges, que a la directiva són de l'annex II, aquí ja són dades de referència.
• Dades temàtiques: les que se superposen a les de referència per desenvolupar-ne un aspecte o afegir-hi informació sectorial. La llei encara les separa en fonamentals (annex II) i generals (annex III).

Per la naturalesa del fenomen: objectes discrets amb límits nets —una parcel·la, un fanal, un tram de carrer— davant de camps continus, que tenen un valor a tot arreu —l'altitud, la temperatura, el nivell de soroll—. És aquesta distinció, i no el format del fitxer, la que decideix si convé el model vectorial o el ràster.

Per la dimensió i el temps: dades 2D, 2,5D (una sola cota per posició, com un model digital del terreny), 3D (edificis, subsòl, núvols de punts) i sèries temporals o lectures de sensors en temps real.

2. Models de dades geogràfiques

Hi ha dues maneres de representar digitalment la informació geoespacial, i la tria no és una qüestió de gust sinó del fenomen que es vol descriure: el model vectorial dibuixa objectes amb límits, i el model ràster omple l'espai amb una malla de valors.

Topologia: relacions espacials entre elements —adjacència, connectivitat i inclusió— independents de les coordenades. És el que permet dir que dues parcel·les són veïnes o que un carrer connecta amb un altre.

Model TIN (Triangulated Irregular Network): representació de superfícies contínues per triangles; alternativa vectorial al ràster per al relleu.

3. Sistemes de referència i projeccions

Unes coordenades no volen dir res si no es diu sobre què estan mesurades, i les dues coses que cal dir són diferents. El sistema de referència geodèsic (el datum) fixa l'origen i l'orientació del sistema, és a dir, quina figura de la Terra i quin ancoratge s'han pres; la projecció és l'operació posterior que passa la superfície corba a un pla per poder-la dibuixar i mesurar en metres. ETRS89 és un datum i UTM és una projecció: no són alternatives entre si, sinó dues capes de la mateixa resposta, i confondre-les és una trampa d'examen habitual.

• Sistema de referència geodèsic: a Espanya, ETRS89 (European Terrestrial Reference System 1989; obligatori pel RD (Reial Decret) 1071/2007) per a la península i Balears, i REGCAN95 per a Canàries. WGS84 (World Geodetic System 1984) és el sistema del GPS (Global Positioning System), pràcticament coincident.
• Projecció: UTM (Universal Transverse Mercator; fusos 29, 30 i 31; Catalunya és al fus 31 nord). Codi EPSG (European Petroleum Survey Group, l'organització que va numerar aquests sistemes): EPSG:25831 (ETRS89/UTM 31N) per a Catalunya; EPSG:4326 és WGS84 en coordenades geogràfiques; EPSG:3857 és la projecció Web Mercator que fan servir els serveis de mapes web.
• L'ED (European Datum) és la sèrie europea de datums anterior; l'ED50 (European Datum 1950) és el que ETRS89 va substituir a Espanya, i encara apareix en cartografia antiga, de manera que una capa mal etiquetada pot sortir desplaçada més de cent metres.
• Tota projecció deforma: no es poden conservar simultàniament àrees, angles i distàncies.
• Escala, resolució i georeferenciació.

4. Formats

Vectorials: SHP (Shapefile) —format de facto d'ESRI (Environmental Systems Research Institute), en realitat un conjunt de fitxers—, GeoJSON (l'estàndard obert basat en JSON (JavaScript Object Notation), molt usat al web i a les API (Application Programming Interface)), GML (Geography Markup Language, estàndard OGC en XML, eXtensible Markup Language), KML (Keyhole Markup Language) / KMZ (Keyhole Markup Zipped, un KML comprimit; Google Earth), GPKG (Geo + Package, és a dir, GeoPackage) —contenidor SQLite obert, recomanat com a substitut modern del shapefile—, DWG (drawing en anglès) i DXF (Drawing eXchange Format), formats de CAD (Computer-Aided Design), TopoJSON, FlatGeobuf.

Ràster: GeoTIFF, JPEG2000, ECW (Enhanced Compression Wavelet), MrSID, COG (Cloud Optimized GeoTIFF), NetCDF i HDF (Hierarchical Data Format) per a dades científiques multidimensionals.

Núvols de punts: LAS (làser) i LAZ (LASzip, la compressió sense pèrdua d'un LAS): dades LiDAR.

Bases de dades espacials: PostGIS (extensió de PostgreSQL, la referència de codi obert), Oracle Spatial, SQL Server Spatial (SQL: Structured Query Language), SpatiaLite, MongoDB amb índexs geoespacials.

Compte amb la trampa que ha aparegut en un examen: GeoJSON SÍ que és un format geogràfic; el que no ho és, en aquell enunciat, era MKV (Matroska Video, un contenidor de vídeo).

5. Estàndards OGC

L'OGC (Open Geospatial Consortium) és el consorci que defineix els estàndards d'interoperabilitat geoespacial. Els que cauen:

La distinció que més es pregunta: WMS lliura una IMATGE; WFS lliura les DADES vectorials. Si l'usuari ha de poder consultar atributs, mesurar o descarregar geometries, cal WFS; si només ha de veure el mapa, WMS o WMTS.

Metadades: ISO 19115 (metadades geogràfiques), ISO 19139 (implementació XML), ISO 19119 (serveis) i el NEM (Núcleo Español de Metadatos).

6. INSPIRE i les IDE

6.1 La directiva INSPIRE

INSPIRE — Directiva 2007/2/CE (CE, de Comunitat Europea) del Parlament Europeu i del Consell, per la qual s'estableix una infraestructura d'informació espacial a la Comunitat Europea (INSPIRE).

És la directiva europea que regula la interoperabilitat de les dades geogràfiques. Aquesta és la resposta literal a l'examen.

Objectiu: crear una infraestructura d'informació espacial europea que permeti compartir informació geogràfica del sector públic entre administracions i posar-la a disposició del públic, amb finalitat inicial de política ambiental.

Transposició a Espanya: LISIGE (Llei 14/2010, sobre les Infraestructures i els Serveis d'Informació Geogràfica a Espanya).

Els cinc principis d'INSPIRE:

1. Les dades s'han de recollir una sola vegada i mantenir-se al nivell on això es faci de manera més efectiva.
2. Ha de ser possible combinar informació espacial contínua de diferents fonts i compartir-la entre usuaris i aplicacions.
3. La informació recollida a un nivell de l'Administració ha de poder compartir-se amb tots els altres nivells.
4. La informació geogràfica necessària per a una bona governança ha d'estar disponible en condicions que no restringeixin el seu ús generalitzat.
5. Ha de ser fàcil descobrir quina informació hi ha disponible, avaluar-ne la idoneïtat i conèixer-ne les condicions d'ús.

Els tres annexos amb els temes de dades:

• Annex I (referència): sistemes de coordenades, quadrícules geogràfiques, noms geogràfics, unitats administratives, adreces, parcel·les cadastrals, xarxes de transport, hidrografia, espais protegits.
• Annex II: elevació, cobertura terrestre, ortoimatges, geologia.
• Annex III (temàtics, 21 temes): unitats estadístiques, edificis, sòl, ús del sòl, salut humana i seguretat, serveis d'utilitat pública i estatals, instal·lacions de seguiment ambiental, instal·lacions de producció i industrials, instal·lacions agrícoles i d'aqüicultura, distribució de la població, zones de gestió i restricció, zones de risc natural, condicions atmosfèriques, característiques meteorològiques i oceanogràfiques, regions marines, regions biogeogràfiques, hàbitats i biòtops, distribució de les espècies, recursos energètics i recursos minerals.

Components obligatoris: metadades, interoperabilitat de conjunts i serveis, serveis de xarxa, mesures d'ús compartit i coordinació i seguiment.

Els cinc serveis de xarxa d'INSPIRE: descobriment (CSW), visualització (WMS/WMTS), descàrrega (WFS/WCS/Atom), transformació (canvi de sistema de coordenades i d'esquema) i invocació de serveis.

6.2 Infraestructura de Dades Espacials (IDE)

IDE: conjunt de tecnologies, polítiques, estàndards, dades i recursos humans necessaris per adquirir, processar, distribuir, usar, mantenir i preservar informació espacial, permetent-ne el descobriment, l'accés i l'ús a través d'internet mitjançant serveis estàndard.

Components: dades i metadades · serveis (descobriment, visualització, descàrrega) · estàndards (OGC, ISO) · polítiques i acords de compartició · usuaris i organització.

Nivells: INSPIRE (europeu), IDEE (Infraestructura de Datos Espaciales de España, coordinada pel Consell Directiu de la IDEE i l'IGN (Institut Geogràfic Nacional)), IDEC (Infraestructura de Dades Espacials de Catalunya, coordinada per l'ICGC (Institut Cartogràfic i Geològic de Catalunya)), i les IDE locals.

7. Serveis geogràfics al món local i a Barcelona

Usos municipals: planejament urbanístic i qualificació del sòl, cadastre i gestió tributària de l'IBI (Impost sobre Béns Immobles), llicències d'obres i d'activitats, mobilitat i trànsit, xarxes de serveis (aigua, clavegueram, enllumenat, semàfors), medi ambient (arbrat, soroll, qualitat de l'aire), serveis socials i equipaments, emergències i protecció civil, guia de carrers i numeració postal, i anàlisi territorial per a la presa de decisions.

A Barcelona:

• Geoportal / CartoBCN: portal de descàrrega de cartografia municipal.
• GeoBCN: llibreria de geocomponents JavaScript (amb paquet per a Angular) que l'Ajuntament posa a disposició de les persones desenvolupadores per incrustar la cartografia oficial —mapa, cercador d'adreces, parcel·les, capes WMS— a pàgines web pròpies; és la que fan servir el Plànol BCN, el Portal d'Informació Urbanística i centenars de pàgines municipals. Inclou també un servei RESTful de geocodificació.
• Guia de carrers i visor de planejament urbanístic.
• Open Data BCN publica capes en GeoJSON i SHP i ofereix serveis WMS/WFS → tema 33.
• Sentilo com a plataforma de sensors amb component geogràfica.
• Col·laboració amb l'ICGC, l'IGN i la Direcció General del Cadastre.

Programari:

• QGIS (Quantum Geographic Information System): aplicació d'escriptori de codi obert i programari lliure per gestionar informació geogràfica. No cal registrar-ne l'ús ni pagar cap llicència, tampoc si l'utilitza l'Administració pública. Gestiona tant dades vectorials com ràster, i és extensible mitjançant Python (consola i connectors). Suporta, entre d'altres, els formats KML, GeoJSON, Shapefile i GeoPackage.
• ArcGIS, gvSIG, GeoServer i MapServer (servidors de mapes, codi obert), PostGIS, OpenLayers i Leaflet (visors web), GDAL (Geospatial Data Abstraction Library) i OGR (OpenGIS Reference Implementation, la implementació de referència per a dades vectorials): la biblioteca de conversió de formats geoespacials, MapLibre.

8. Geolocalització i serveis de mapes per a la ciutadania

Geoportal i visor no són el mateix. El geoportal és la porta d'entrada d'una IDE: hi conviuen el catàleg de metadades, la cerca, la descàrrega i la documentació dels serveis. El visor és només l'aplicació que pinta capes sobre un mapa al navegador. Un visor sense catàleg darrere no converteix una col·lecció de capes en una infraestructura.

Geocodificació: conversió d'una adreça, un topònim o una cruïlla en unes coordenades. La geocodificació inversa fa el camí contrari i, donades unes coordenades, retorna l'adreça o la unitat administrativa que hi correspon. És el motor del cercador d'adreces de qualsevol visor municipal i el que permet assignar automàticament una incidència ciutadana al seu districte.

Càlcul de rutes i àrees d'influència (isòcrones, isodistàncies): funcionen sobre una xarxa de transport topològicament connectada, no sobre un dibuix de carrers. És l'exemple més clar de per què la topologia no és un adorn del model vectorial.

Posicionament del dispositiu:

• GNSS (Global Navigation Satellite System) és el terme genèric del posicionament per satèl·lit. El GPS només és la constel·lació dels Estats Units i conviu amb Galileo (Unió Europea), la russa i la xinesa; dir «GPS» per a qualsevol posicionament és un abús de llenguatge que convé no arrossegar a l'examen.
• Al mòbil, la posició del satèl·lit es completa amb xarxes Wi-Fi, cel·les de telefonia i sensors inercials, i el navegador l'ofereix a les pàgines web amb una API de geolocalització que exigeix el consentiment explícit de qui l'utilitza.

La ubicació d'una persona és una dada personal quan permet identificar-la, i un recorregut ho és gairebé sempre: un servei que registri posicions necessita base jurídica, minimització i, si només cal l'estadística, agregació o anonimització abans de publicar-la — RGPD.

Claus d'examen

• QGIS és programari lliure i no cal registrar-se enlloc per fer-lo servir, ni tan sols a l'Administració pública: no hi ha llicència que pagar. La trampa és donar per fals el que sí és cert (que gestiona vectorial i ràster, que és extensible amb Python, que suporta KML/GeoJSON/Shapefile/GeoPackage) i deixar passar l'afirmació sobre el registre, que és la falsa (TS-TIC 2021, específic p. 81).
• GeoBCN, no «BCN Plus» ni «CartoLib», és el nom de la llibreria de geocomponents amb què l'Ajuntament de Barcelona dona eines als desenvolupadors; la fan servir el Plànol BCN i el Portal d'Informació Urbanística (TS-TIC 2021, pràctica p. 3, supòsit 4).
• El tribunal fabrica sistemes de referència que no existeixen: «ED 55», «ETRS 50» i «ETRS 132» surten com a distractors barrejant una sigla real amb un any o un número que no designen res. Els dos que existeixen són ETRS89, l'oficial, i ED50, el datum antic que ETRS89 va substituir (TS-TIC 2018, específic p. 81; TS-TIC 2021, pràctica p. 4, supòsit 4). En aquesta segona pregunta l'enunciat demana la «projecció» i el que respon és el datum: llegeix les opcions abans de fiar-te del mot.
• Del model ràster es pregunta la definició, i els distractors són el model vectorial i el GML. «Punt, línia i polígon» i «el segment de recta definit per dos punts» descriuen el vectorial; «extensió d'XML definida per l'OGC» descriu el GML, que és un format i no un model (TS-TIC 2023, específic p. 2).
• Format obert vol dir sense propietari que en controli l'especificació. De les quatre opcions del 2018, l'obert és el GeoPackage; el shapefile és d'ESRI, i els altres dos són els formats natius de MicroStation (Bentley) i d'AutoCAD (Autodesk) (TS-TIC 2018, específic p. 2).

Per recordar

• Vectorial = punts, línies i polígons, per a objectes discrets; ràster = matriu de cel·les, per a fenòmens continus.
• Topologia = adjacència, connectivitat i inclusió; és pròpia del model vectorial.
• WMS lliura una imatge; WFS lliura les dades vectorials; WCS, el ràster original; CSW, el catàleg de metadades.
• INSPIRE = Directiva 2007/2/CE, la que regula la interoperabilitat de les dades geogràfiques a Europa; a Espanya, LISIGE (Llei 14/2010).
• Tres annexos d'INSPIRE i cinc serveis de xarxa: descobriment, visualització, descàrrega, transformació i invocació.
• Primer principi d'INSPIRE: recollir la dada una sola vegada i mantenir-la on sigui més efectiu.
• IDE = dades + serveis + estàndards + polítiques + persones. A Catalunya, IDEC (ICGC); a Espanya, IDEE (IGN).
• ETRS89 és el sistema de referència oficial a Espanya; Catalunya és al fus UTM 31N (EPSG:25831). ETRS89 és el datum i UTM la projecció: no són alternatives, van juntes.
• GeoJSON i GeoPackage són formats geogràfics oberts; el shapefile és el format clàssic de facto.
• Tipus d'informació, model de dades i format són tres eixos distints. La LISIGE separa la informació de referència (annex I) de les dades temàtiques (annexos II i III), i el seu annex I recull junts els annexos I i II d'INSPIRE: per això l'altimetria i les ortoimatges hi són dades de referència.
• GNSS és el terme genèric del posicionament per satèl·lit; el GPS només és la constel·lació nord-americana, al costat de Galileo i de les altres.

Tema 46 · Documental, GIS, qualitat i arquitectura

Gestió de la Qualitat del Programari

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Gestió de la Qualitat del Programari.

1. Concepte

Qualitat del programari: grau en què un producte de programari satisfà els requisits establerts i les necessitats i expectatives implícites dels seus usuaris.

Dues vessants:

• Qualitat del producte: característiques del programari en si (funcionalitat, rendiment, seguretat, mantenibilitat…).
• Qualitat del procés: com es construeix. La qualitat dels productes i serveis està altament influïda per la qualitat dels processos que els produeixen — aquest és el principi que fonamenta els models de maduresa.

Definició de la Gestió de la Qualitat del Programari (SQM, Software Quality Management): conjunt d'activitats sistemàtiques i planificades, aplicades al llarg de tot el cicle de vida, destinades a assegurar que tant el procés de desenvolupament com el producte resultant compleixen els requisits de qualitat establerts. Comprèn la planificació de la qualitat, l'assegurament de la qualitat (SQA, Software Quality Assurance), el control de la qualitat (SQC, Software Quality Control) i la millora.

Assegurament vs control — la distinció clau:

2. Què forma part i què no de la gestió de la qualitat

Activitats pròpies: planificació de la qualitat i pla de qualitat; definició d'estàndards i de criteris d'acceptació; revisions i inspeccions; proves en tots els nivells; anàlisi estàtica; mesura amb mètriques de producte i de procés; auditories; gestió de defectes; gestió de la configuració; i millora contínua.

NO forma part de la gestió de la qualitat del programari l'estimació de costos i terminis del projecte, la negociació contractual ni la gestió de recursos humans: són activitats de direcció de projectes → temes 9 i 7. Aquesta és la distractora habitual de la pregunta «quina activitat NO forma part de la gestió de la qualitat del programari».

Caixa blanca i caixa negra, com a dues maneres de dissenyar les proves de control de qualitat: la caixa negra es basa en l'especificació, sense conèixer el codi intern; la caixa blanca analitza el funcionament intern del codi. Es desenvolupen a fons a → tema 49 (Disseny i realització de proves de programari); aquí n'hi ha prou amb la distinció.

3. Aspectes fonamentals al llarg del cicle de vida

Per garantir la qualitat del programari cal incorporar activitats de qualitat en TOTES les fases, des dels requisits fins al manteniment, i no només mitjançant proves al final. En concret:

1. Requisits clars, complets, verificables i traçables: la majoria de defectes cars neixen aquí.
2. Disseny i arquitectura amb atributs de qualitat explícits.
3. Estàndards de codificació i revisions de codi sistemàtiques.
4. Proves automatitzades integrades al pipeline de CI → tema 41.
5. Gestió de la configuració i control de versions.
6. Mesura contínua amb mètriques objectives.
7. Manteniment planificat i control del deute tècnic.

Cost de la correcció: el cost d'esmenar un defecte creix exponencialment com més tard es detecta. Un error de requisits detectat en producció pot costar entre 10 i 100 vegades més que si s'hagués detectat a l'anàlisi. Prevenció millor que inspecció, i inspecció millor que correcció.

4. Normes de qualitat del producte

ISO/IEC 25000 (SQuaRE)

La IEC (International Electrotechnical Commission) i la ISO publiquen conjuntament aquesta família de normes, que substitueix la ISO/IEC 9126. La més citada és la ISO/IEC 25010, que defineix el model de qualitat del producte. La edició de 2011 —la que fan servir gairebé tots els temaris i manuals— el descriu amb vuit característiques:

Adequació funcional és la característica que mesura fins a quin punt el programari fa el que li demanen els requisits i les especificacions, i és la que es pregunta per la seva definició. No s'ha de confondre amb la portabilitat (operar en diferents plataformes), la mantenibilitat (facilitat de modificar-lo) ni la fiabilitat/seguretat (robustesa i protecció del codi).

La ISO/IEC 25012 defineix el model de qualitat de les dades → tema 31.

ISO/IEC 25010:2023: la revisió que en té nou

La ISO/IEC 25010:2023 substitueix l'edició de 2011 i passa de vuit a nou característiques. Si en un examen la compta surt diferent, és per això:

La distinció que compta: Security és protecció davant l'atac —confidencialitat, integritat, no-repudi—; Safety és protecció davant el dany, i entra perquè el programari governa cotxes, dispositius mèdics i indústria.

Aquest tema desenvolupa les vuit de 2011 perquè és el vocabulari dels enunciats i dels manuals d'oposició, i nomena les nou de 2023 perquè és l'edició vigent.

Altres

ISO/IEC 12207 (processos del cicle de vida del programari), ISO/IEC 15288 (sistemes), ISO/IEC 29119 (proves de programari) → tema 49, ISO 9001 (sistema de gestió de la qualitat) → tema 13.

ISO/IEC 14764: tipus de manteniment

Desenvolupa el procés de manteniment de la ISO/IEC 12207. Defineix quatre tipus de manteniment del programari, segons si esmenen un defecte o milloren el sistema:

La confusió habitual és preventiva ↔ correctiva: la preventiva actua abans que hi hagi errada; la correctiva, després.

5. Models de maduresa

CMMI

Capability Maturity Model Integration — model de millora de processos desenvolupat originalment per l'SEI (Software Engineering Institute) de la Universitat Carnegie Mellon, avui gestionat per l'ISACA (Information Systems Audit and Control Association).

Afirmacions certes sobre CMMI —el que es pregunta—:

• És un model de maduresa de PROCESSOS, no una metodologia de desenvolupament ni una norma certificable com la ISO.
• No és prescriptiu: descriu QUÈ cal aconseguir —les àrees de procés i els seus objectius— però no diu COM implementar-ho; cada organització tria el seu propi mètode per arribar-hi.
• Té dues representacions: per etapes (nivells de maduresa de tota l'organització, de l'1 al 5) i contínua (nivells de capacitat per àrea de procés).
• Serveix per avaluar i millorar la capacitat dels processos, i les avaluacions formals es diuen appraisals (mètode SCAMPI (Standard CMMI Appraisal Method for Process Improvement), avui MDD, el Method Definition Document).
• És compatible i complementari amb els enfocaments àgils: no s'hi oposa.
• Existeixen versions per a diferents àmbits: CMMI-DEV (desenvolupament), CMMI-SVC (serveis) i CMMI-ACQ (Acquisition, adquisició).

Els cinc nivells de maduresa (representació per etapes):

Els errors habituals a les preguntes: dir que CMMI és una norma ISO o una certificació de producte; dir que té quatre o sis nivells; o afirmar que és incompatible amb l'agilisme.

Altres models: ISO/IEC 33000 (successora de la 15504 / SPICE, Software Process Improvement and Capability dEtermination), TMMi (maduresa de proves), ITIL (Information Technology Infrastructure Library) i COBIT (Control Objectives for Information and Related Technology) per a serveis i govern.

6. Tècniques i eines

Revisions estàtiques (sense executar el codi): inspeccions formals de Fagan, revisions per parells (peer review), recorreguts (walkthroughs) i revisions de codi integrades al flux de treball (pull requests). Són molt eficaces: detecten defectes que les proves no troben, especialment de disseny i de mantenibilitat.

Anàlisi estàtica automatitzada (SAST, Static Application Security Testing): SonarQube, PMD (Programming Mistake Detector), Checkstyle, SpotBugs, ESLint, Semgrep, Coverity. Detecten defectes, males pràctiques, vulnerabilitats i codi duplicat, i mesuren la complexitat ciclomàtica i la cobertura.

SonarQube és, d'aquestes, l'eina enfocada únicament en la inspecció contínua de la qualitat del codi: a diferència de Jenkins o GitLab CI/CD —orquestradors del pipeline de CI/CD → tema 41— o de Maven —eina de construcció (build) i gestió de dependències—, no executa ni orquestra el pipeline: s'hi integra com un pas més.

Anàlisi de composició (SCA, Software Composition Analysis) i SBOM (Software Bill of Materials) per a les dependències de tercers → tema 41.

Signatura d'artefactes (Sigstore/cosign) i procedència verificable (SLSA, Supply-chain Levels for Software Artifacts): permeten verificar qui va signar la imatge o el paquet i sobre quin digest, i aporten atestacions sobre com es va construir. No ho garanteixen per si soles: cal una política de verificació i admissió que les comprovi abans de desplegar, i que els controls anteriors —SAST, SCA, SBOM— hagin deixat la seva pròpia atestació. Sense aquesta política, l'artefacte va signat però ningú no ho mira.

Mètriques de producte:

• Complexitat ciclomàtica (McCabe): nombre de camins independents; per damunt de 10-15 per funció, s'ha de refactoritzar.
• Cobertura de codi: percentatge de línies, branques o condicions executades per les proves. La cobertura alta no garanteix qualitat, però la baixa sí que indica risc.
• Densitat de defectes (defectes per KLOC (Kilo Lines of Code) o per punt de funció).
• Deute tècnic i relació de deute.
• Acoblament i cohesió: es busca baix acoblament i alta cohesió.
• Punts de funció i COCOMO (Constructive Cost Model) per a l'estimació.

Mètriques de procés: temps de lliurament, taxa de fallides dels canvis, temps de resolució de defectes, DORA (DevOps Research and Assessment) → tema 41.

7. Pràctiques de construcció

• Estàndards de codificació i format automàtic (linters i formatadors).
• Principis de disseny: SOLID (Single-Responsibility, Open-Closed, Liskov-Substitution, Interface-Segregation, Dependency-Inversion), DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), YAGNI (You Ain't Gonna Need It), separació de responsabilitats, llei de Demeter.
• Refactorització contínua i control del deute tècnic: el deute assumit conscientment i registrat és gestionable; l'assumit per descuit, no.
• Desenvolupament guiat per proves (TDD, Test-Driven Development): escriure la prova que falla abans que el codi (roig → verd → refactoritzar). És la resposta correcta quan es pregunta pel primer pas per implementar una funcionalitat nova en un entorn de qualitat: escriure la prova que en defineix el comportament esperat.
• BDD (Behaviour-Driven Development) amb escenaris Given-When-Then (Cucumber, Gherkin).
• Programació en parella i mob programming.
• Definició d'Acabat que inclogui els criteris de qualitat → tema 12.
• Documentació viva: la que es genera del codi i es manté amb ell.
• Accessibilitat i seguretat com a atributs de qualitat de primera classe, no com a revisió final.

8. Al sector públic

• La Definició d'Acabat dels contractes de desenvolupament ha d'incloure els requisits municipals no negociables: accessibilitat WCAG (Web Content Accessibility Guidelines) 2.1 AA (RD, Reial Decret, 1112/2018), ENS, protecció de dades, documentació, codi obert i reversibilitat, segons la Mesura de digitalització oberta i els Barcelona Digital Standards → tema 12.
• Els plecs han d'exigir criteris de qualitat mesurables (cobertura mínima, absència de vulnerabilitats crítiques, llindars de SonarQube) i preveure'n la verificació abans de l'acceptació.
• Mètrica v3 aporta la interfície d'assegurament de la qualitat transversal a tots els seus processos → tema 1.
• La recepció i acceptació del contracte és el moment jurídic en què es verifiquen aquests criteris (LCSP).

Claus d'examen

• Els quatre tipus de manteniment (ISO/IEC 14764) es donen com un supòsit amb quatre accions per aparellar. La trampa és preventiva vs. correctiva: «detectar i corregir una disfunció latent abans que sigui una errada» és preventiva; «solucionar un error ja reportat» és correctiva (TS-TIC 2018 pràctica, supòsit 4).
• SonarQube s'ha preguntat per exclusió: entre Gitlab, Jenkins, Maven i SonarQube, només SonarQube està enfocat únicament en la inspecció de la qualitat del codi; els altres tres orquestren CI/CD o construeixen (TS-TIC 2023 pràctica, supòsit 4).
• Caixa blanca = codi; caixa negra = especificació. La distractora és dir que la caixa blanca «es basa en el punt de vista de l'usuari»: és justament al revés (TS-TIC 2025 pràctica, supòsit 3).
• Preguntat què és fonamental per garantir la qualitat al llarg del cicle de vida, la resposta del tribunal és definir clarament els requisits abans de començar el desenvolupament — el punt 1 del §3, no la formulació general de «activitats de qualitat a totes les fases», que no és cap de les opcions (TS-TIC 2025 específic, p. 26).

Per recordar

• Assegurament = processos, preventiu; control = productes, detectiu.
• La gestió de la qualitat NO inclou estimar costos i terminis ni gestionar recursos: això és direcció de projectes.
• El que és fonamental és incorporar qualitat a totes les fases, no només provar al final. El cost de corregir creix exponencialment amb el temps.
• ISO/IEC 25010:2011: vuit característiques — adequació funcional, eficiència d'acompliment, compatibilitat, usabilitat, fiabilitat, seguretat, mantenibilitat i portabilitat. La revisió de 2023 en té nou: hi afegeix Safety i rebateja usabilitat com Interaction Capability i portabilitat com Flexibility.
• CMMI és un model de maduresa de PROCESSOS, amb cinc nivells (inicial, gestionat, definit, gestionat quantitativament, en optimització), dues representacions i compatible amb l'agilisme.
• Complexitat ciclomàtica alta i acoblament alt són senyals d'alerta; es busca baix acoblament i alta cohesió.
• Davant una funcionalitat nova en un entorn amb cultura de qualitat, el primer pas és escriure la prova (TDD).
• Manteniment (ISO/IEC 14764), quatre tipus: correctiva (esmena l'errada ja reportada), preventiva (corregeix abans que hi hagi errada), adaptativa (segueix un canvi extern) i perfectiva/evolutiva (afegeix o millora funcionalitat).
• SonarQube inspecciona la qualitat del codi; no orquestra CI/CD (Jenkins, GitLab CI/CD) ni construeix (Maven).
• Caixa negra = especificació, sense mirar el codi; caixa blanca = estructura interna del codi.

Tema 47 · Documental, GIS, qualitat i arquitectura

Desenvolupament d'aplicacions natives al núvol

Elaboració pròpia: la font és de pagament i no es reprodueix

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. Desenvolupament d'aplicacions natives al núvol.

1. Definició

Cloud native (definició de la CNCF, Cloud Native Computing Foundation): les tècniques natives al núvol permeten a les organitzacions construir i executar aplicacions escalables en entorns moderns i dinàmics com ara núvols públics, privats i híbrids. Exemples d'aquest enfocament són els contenidors, les malles de serveis, els microserveis, la infraestructura immutable i les API declaratives. Aquestes tècniques permeten sistemes desacoblats que són resilients, gestionables i observables. Combinades amb una automatització robusta, permeten als enginyers fer canvis d'alt impacte de manera freqüent i predictible amb un esforç mínim.

Natiu al núvol ≠ al núvol. Traslladar una aplicació monolítica a una màquina virtual d'un proveïdor (lift and shift) és estar al núvol, però no és natiu al núvol: no n'aprofita l'elasticitat ni els serveis gestionats.

Característica essencial d'una aplicació nativa al núvol: està dissenyada per ser escalable elàsticament i resilient, amb components desacoblats i sense estat, desplegats en contenidors i gestionats de manera automatitzada i declarativa. Els seus trets:

• Modularitat: microserveis o components desacoblats.
• Sense estat (stateless): l'estat viu fora del procés (base de dades, cau, magatzem d'objectes), de manera que qualsevol instància pot atendre qualsevol petició i es pot destruir i recrear lliurement.
• Empaquetament en contenidors i execució orquestrada.
• Escalat horitzontal automàtic segons la demanda.
• Resiliència dissenyada: assumeix que els components fallaran.
• Automatització completa del desplegament i de l'operació.
• Observabilitat integrada des del disseny.
• API declaratives i infraestructura com a codi.

2. Els dotze factors

Metodologia The Twelve-Factor App (Heroku), la referència per construir aplicacions natives al núvol:

1. Codi base únic amb seguiment de versions i múltiples desplegaments.
2. Dependències declarades i aïllades explícitament.
3. Configuració a l'entorn, mai al codi.
4. Serveis de suport (backing services) tractats com a recursos connectables.
5. Construir, alliberar, executar: etapes estrictament separades.
6. Processos d'execució sense estat i sense compartir res.
7. Vinculació de ports: el servei s'exporta pel seu propi port.
8. Concurrència mitjançant el model de processos: escalar afegint processos.
9. Descartabilitat: arrencada ràpida i aturada elegant.
10. Paritat entre desenvolupament i producció: entorns tan semblants com sigui possible.
11. Registres (logs) com a flux d'esdeveniments cap a la sortida estàndard, no com a fitxers gestionats per l'aplicació.
12. Processos d'administració executats com a processos puntuals.

S'hi afegeixen sovint tres factors més, centrats en el desenvolupament:

13. API primer: es dissenya i es documenta el contracte de l'API (OpenAPI) abans d'implementar-la, de manera que altres equips o serveis consumidors poden desenvolupar-hi en paral·lel contra un contracte estable.
14. Telemetria: instrumentar l'aplicació des del disseny, no afegir-la a posteriori.
15. Autenticació i autorització: cada servei verifica identitat i permisos explícitament, sense assumir que la xarxa interna ja és de confiança.

3. Els pilars tecnològics

3.1 Contenidors i orquestració

Docker/OCI (Open Container Initiative) per empaquetar i Kubernetes per orquestrar → tema 41.

3.2 Microserveis

Descomposició en serveis petits, autònoms i desplegables per separat → tema 48.

3.3 Infraestructura immutable i infraestructura com a codi

Infraestructura immutable: els components no es modifiquen un cop desplegats; per canviar-los es construeix una instància nova a partir de la imatge actualitzada i es reemplaça l'antiga. Elimina la deriva de configuració, fa els desplegaments reproduïbles, simplifica el retorn i millora la seguretat.

IaC: la infraestructura es declara en fitxers versionats (Terraform/OpenTofu, Pulumi, Crossplane). Aquest és el concepte d'infraestructura que s'implementa habitualment en una aplicació natiu-núvol i que s'ha preguntat a l'examen.

3.4 Automatització i CI/CD

Pipeline complet fins a producció, amb GitOps com a model dominant → tema 41.

3.5 Serverless i FaaS

FaaS (Function as a Service): el proveïdor executa funcions en resposta a esdeveniments; no hi ha servidors a gestionar, l'escalat és automàtic —fins a zero— i es paga per execució i temps de còmput. AWS (Amazon Web Services) Lambda, Azure Functions, Google Cloud Functions, Knative, OpenFaaS.

Limitacions: arrencada en fred (cold start), límits de temps d'execució i de memòria, dificultat de depuració, i bloqueig de proveïdor elevat.

3.6 Malla de serveis (service mesh)

Capa d'infraestructura que gestiona la comunicació entre serveis: encaminament, balanceig, reintents, tallacircuits, mTLS, autorització i telemetria, sense tocar el codi de l'aplicació. Istio, Linkerd, Consul Connect.

3.7 Observabilitat

Mètriques, registres i traces amb OpenTelemetry → tema 23.

4. Patrons de disseny natius al núvol

Persistència: poliglota —cada servei tria el magatzem que li convé—, base de dades per servei, i patrons per a la consistència distribuïda: saga, transactional outbox, CQRS (Command Query Responsibility Segregation) i event sourcing → tema 48.

5. Beneficis i costos

Beneficis: elasticitat i pagament per ús, resiliència, velocitat de lliurament, escalabilitat independent per component, aprofitament de serveis gestionats (bases de dades, cues, IA (intel·ligència artificial)) i portabilitat si es fa sobre estàndards oberts.

Costos i riscos:

• Complexitat operativa molt superior: cal maduresa en observabilitat, automatització i seguretat.
• Cost econòmic descontrolat si no hi ha FinOps → tema 27.
• Bloqueig de proveïdor quan s'usen serveis propietaris; es mitiga amb Kubernetes, OpenTelemetry i estàndards oberts.
• Superfície d'atac més gran: més components, més xarxa, més secrets.
• No sempre val la pena: per a una aplicació petita i estable, un monòlit ben fet és millor.

6. Seguretat: els 4C

Model de seguretat natiu al núvol en quatre capes concèntriques: Cloud → Cluster → Container → Code.

• Núvol: configuració segura del compte, xarxes, IAM (Identity and Access Management), xifratge en repòs.
• Clúster: RBAC (Role-Based Access Control), NetworkPolicies, admissió de polítiques, actualització.
• Contenidor: imatges mínimes, sense root, escaneig i signatura, secrets fora de la imatge.
• Codi: SAST (Static Application Security Testing), SCA (Software Composition Analysis), gestió de dependències, TLS (Transport Layer Security), validació d'entrada.

Zero Trust (NIST SP (Special Publication) 800-207): no es confia en cap component per la seva ubicació de xarxa; cada petició s'autentica i s'autoritza. A l'entorn natiu al núvol es materialitza en mTLS entre serveis i identitats de càrrega de treball: SPIFFE (Secure Production Identity Framework For Everyone) i SPIRE (SPIFFE Runtime Environment).

7. Al sector públic

• Portabilitat i reversibilitat com a requisit contractual (LCSP i Mesura de digitalització oberta): Kubernetes i els estàndards oberts són la millor defensa contra el bloqueig.
• Sobirania de les dades i ubicació del tractament → tema 60.
• ENS: la categorització del sistema determina les mesures; l'ús de serveis de núvol exigeix el compliment del perfil de compliment específic per a serveis al núvol del CCN (Centre Criptològic Nacional) i la conformitat del proveïdor.
• Protecció de dades: transferències internacionals, encarregat del tractament i contracte de l'RGPD, art. 28.
• FinOps i el pas de CAPEX (Capital Expenditure, despesa d'inversió) a OPEX (Operating Expenditure, despesa operativa), amb l'impacte pressupostari del canvi de capítol → tema 27.

Claus d'examen

• La característica essencial que més es pregunta és l'escalat i la recuperació automàtics: davant quatre opcions, les altres tres neguen sempre algun tret cloud native (servidor físic, no escala, només Windows) (TS-TIC 2025 específic, p. 50; TS-TIC 2025 pràctica, s3-p8).
• El paradigma arquitectònic típic són els microserveis, mai el monolític ni el client-servidor tradicional (TS-TIC 2025 pràctica, s3-p9).
• Infraestructura immutable = es reemplacen els servidors, no es modifiquen. El parany és colar-hi «es modifiquen manualment» com a distractor (TS-TIC 2025 pràctica, s3-p10).
• IaC és el concepte que fa idèntics i automatitzats els entorns de desenvolupament, proves i producció; ni el serverless ni un patró de comunicació com l'EDA (Event-Driven Architecture) ho són (TS-TIC 2025 pràctica, s3-p6).
• Ansible és l'eina de referència per a «desplegament i configuració de tota mena d'infraestructura a partir de codi»: YAML és un format, Bash un llenguatge d'ús general i kubectl només val per a Kubernetes (TS-TIC 2023 pràctica, s4-p2).

Per recordar

• Natiu al núvol ≠ al núvol: el lift and shift no ho és.
• Característiques essencials: desacoblament, sense estat, contenidors, escalat elàstic automàtic, resiliència, automatització i observabilitat.
• Dotze factors: configuració a l'entorn, processos sense estat, logs com a flux, separació build/release/run, descartabilitat.
• Infraestructura immutable: no es modifica, es reemplaça; elimina la deriva de configuració. Es declara amb IaC.
• Serverless/FaaS: escala fins a zero, es paga per execució; problemes d'arrencada en fred i bloqueig de proveïdor.
• Patrons de resiliència: tallacircuits, reintent amb retrocés, mampara, degradació elegant, limitació de ritme.
• Seguretat 4C: Cloud, Cluster, Container, Code, amb Zero Trust i mTLS.
• El paradigma arquitectònic habitual de les aplicacions natives al núvol són els microserveis.

Tema 48 · Documental, GIS, qualitat i arquitectura

Disseny d'una arquitectura de microserveis

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Disseny d'una Arquitectura de Microserveis.

1. La idea central

Microserveis: estil arquitectònic que estructura una aplicació com un conjunt de serveis petits, autònoms i desplegables de manera independent, cadascun organitzat al voltant d'una capacitat de negoci, amb la seva pròpia base de dades i comunicats mitjançant API (Application Programming Interface, interfície de programació d'aplicacions) lleugeres.

La idea central que impulsa l'arquitectura de microserveis és descompondre l'aplicació en serveis autònoms i desplegables de manera independent, alineats amb capacitats de negoci, per poder desenvolupar-los, escalar-los, desplegar-los i evolucionar-los per separat. La independència de desplegament és el que ho justifica tot: si per posar en producció un canvi d'un servei cal desplegar-ne uns altres, no són microserveis.

Característiques essencials:

1. Independència de desplegament: cada servei es desplega sense coordinació amb els altres.
2. Alineació amb capacitats de negoci (context delimitat del Domain-Driven Design).
3. Descentralització de les dades: cada servei posseeix la seva base de dades; cap altre servei no hi accedeix directament.
4. Comunicació per API ben definides, mai per base de dades compartida.
5. Autonomia dels equips: un equip petit posseeix el servei extrem a extrem.
6. Heterogeneïtat tecnològica possible (persistència poliglota, llenguatges diferents).
7. Disseny per a la fallida: assumeix que la xarxa i els altres serveis fallaran.
8. Automatització de la construcció, prova i desplegament.

Aquestes vuit són les respostes correctes quan es pregunta «quina característica és essencial en una arquitectura de microserveis». La base de dades compartida és exactament el contrari: és l'error més comú i converteix el conjunt en un monòlit distribuït, que combina els inconvenients de tots dos móns.

Microservei ≠ funció sense servidor. Un microservei és un procés de llarga durada que l'equip propietari desplega, escala i opera, amb el seu estat persistent i el seu cicle de vida; una funció (FaaS) és codi efímer i sense estat que el proveïdor arrenca en resposta a un esdeveniment, escala fins a zero i factura per execució. Una funció pot implementar un microservei, però ni la granularitat ni qui n'opera el temps d'execució són les mateixes → tema 47.

2. Monòlit, SOA i microserveis

Monòlit vol dir una sola unitat de desplegament: tot el codi es construeix, es prova i es posa en producció alhora, sobre una base de dades única. No vol dir codi desordenat. El monòlit modular conserva aquesta unitat de desplegament però hi imposa mòduls amb frontera explícita que només es parlen per interfícies internes: el domini queda partit sense pagar la xarxa. Per tant la diferència entre monòlit i monòlit modular és la qualitat de les fronteres internes, i la que separa el monòlit modular dels microserveis és si les peces es poden desplegar per separat — no la qualitat del codi.

Quan un monòlit és millor: aplicacions petites, equips reduïts, domini poc conegut i requisits estables. El patró recomanat és començar amb un monòlit ben modularitzat (monolith first) i extreure serveis quan els límits del domini siguin clars i el dolor justifiqui el cost.

SOA — arquitectura orientada a serveis:

Avantatge principal: la reutilització de serveis i la interoperabilitat entre sistemes heterogenis: exposar funcionalitat com a serveis estàndard, independents de la plataforma, que diverses aplicacions poden consumir sense duplicar la lògica. En derivar-ne una conseqüència: com totes les aplicacions accedeixen a la mateixa dada a través del mateix servei, en lloc que cadascuna en mantingui una còpia pròpia, SOA facilita la integració entre aplicacions diferents i en millora la coherència de les dades entre múltiples aplicacions.

La interfície d'un servei: el contracte entre el proveïdor i el consumidor del servei — què ofereix (operacions, dades d'entrada i de sortida) sense exposar-ne la implementació interna. En SOA aquest contracte és el WSDL (Web Services Description Language, llenguatge de descripció de serveis web); en REST, l'OpenAPI.

Protocol habitual per a la comunicació entre serveis en SOA: SOAP (Simple Object Access Protocol), sobre XML (eXtensible Markup Language, llenguatge de marcatge extensible) i normalment HTTP (HyperText Transfer Protocol, protocol de transferència d'hipertext), amb els seus contractes WSDL i l'ecosistema WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction) i UDDI (Universal Description, Discovery and Integration) com a registre. És la resposta a la pregunta d'examen. Als microserveis, en canvi, el protocol dominant és REST sobre HTTP amb JSON (JavaScript Object Notation).

REST (Representational State Transfer, transferència d'estat representacional) vs SOAP — la característica que els distingeix:

Mètodes HTTP estàndard: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, CONNECT. UPDATE no és un mètode HTTP —l'actualització es fa amb PUT (substitució completa) o PATCH (parcial)—. Al tribunal li agrada aquest tipus de pregunta —quin verb NO és un mètode estàndard de HTTP, amb un verb plausible que no ho és (DOWNLOAD, TS-TIC 2025)— però aquesta és del tema d'Internet, arquitectura i protocols, no d'aquest.

Nivells de maduresa REST (model de Richardson): 0 un únic URI i POST · 1 recursos · 2 verbs HTTP i codis d'estat · 3 HATEOAS (Hypermedia As The Engine Of Application State, hipermèdia).

3. Components d'una arquitectura de microserveis

3.1 API Gateway

Funció principal: actuar com a punt d'entrada únic per als clients, encaminant les peticions als microserveis corresponents i concentrant les funcions transversals —autenticació i autorització, limitació de ritme, terminació TLS (Transport Layer Security, seguretat de la capa de transport), transformació de protocol i de format, agregació de respostes, cau, versionat i telemetria—, de manera que els clients no hagin de conèixer la topologia interna ni cada servei hagi d'implementar aquestes funcions.

API Manager: va més enllà de la passarel·la. És la plataforma de gestió del cicle de vida complet de les API: disseny i publicació, catàleg i portal per als desenvolupadors, registre i alta de consumidors amb les seves claus, polítiques de seguretat i de quota, versionat i desactivació, analítica d'ús i, si escau, monetització. La passarel·la n'és el component d'execució en temps real; l'API Manager és el govern. Per als consumidors, això es tradueix en el que permet als usuaris i a les aplicacions consumir serveis, interconnectar mòduls i aplicacions, i facilitar l'accés al backend, afavorint-ne la reutilització; per a qui l'opera, és el que controla l'accés a les API i n'aplica les polítiques de seguretat. Productes: Kong, Apigee, WSO2 API Manager, Azure API Management, AWS (Amazon Web Services) API Gateway, Gravitee, 3scale.

Seguretat de les API REST — les opcions correctes: OAuth 2.0 amb OpenID Connect i tokens JWT (JSON Web Token) signats, amb àmbits (scopes) i temps de vida curt; mTLS entre serveis; claus d'API només per a identificació d'aplicacions, mai com a única autenticació; limitació de ritme i quotes; validació estricta d'entrada; HTTPS (HyperText Transfer Protocol Secure, protocol de transferència d'hipertext segur) obligatori; i seguir l'OWASP (Open Web Application Security Project) API Security Top 10, encapçalat per l'autorització a nivell d'objecte trencada i l'autenticació trencada —els dos primers riscos de la llista, i els que expliquen per què l'autorització s'ha de comprovar a cada servei i no només a la passarel·la—.

3.2 Descobriment de serveis i configuració

Les instàncies neixen, moren i canvien d'adreça contínuament, així que les adreces no es poden escriure ni al codi ni a un fitxer. El descobriment de serveis ho resol amb un registre de serveis: la base de dades de quines instàncies de cada servei hi ha vives i on són (Consul, etcd, Eureka, el DNS (Domain Name System, sistema de noms de domini) intern de Kubernetes).

• Com s'hi donen d'alta: per autoregistre —la instància s'inscriu en arrencar i es dona de baixa en parar— o per registre de tercers, quan ho fa per ella un component extern, típicament l'orquestrador. En tots dos casos és la prova de salut periòdica la que retira la instància que ha deixat de respondre.
• Com el consulta qui truca: en el descobriment del costat client el consumidor demana la llista al registre i tria ell mateix la instància; en el descobriment del costat servidor truca sempre una adreça estable i és un intermediari —passarel·la, balancejador o el Service de Kubernetes— qui resol i encamina.

Balanceig de càrrega: repartir les peticions entre les instàncies vives, amb la llista que surt del registre. El que canvia és on es decideix — al client (la biblioteca del consumidor), a la infraestructura (un balancejador de capa 4, per adreça i port, o de capa 7, per URI, capçalera o versió de l'API) o al costat, en un sidecar adjunt a cada instància. Criteris de repartiment: cíclic (round robin), menys connexions actives, per pes i per resum de la clau (hashing) quan cal enganxar un client a una instància.

Configuració centralitzada i externalitzada (ConfigMaps, Consul KV (Key-Value, clau-valor), Spring Cloud Config): viu a l'entorn i no a la imatge, de manera que la mateixa imatge es promociona entre entorns sense reconstruir-la.

3.3 Comunicació

• Síncrona: REST i gRPC (HTTP/2 + Protocol Buffers, alt rendiment, contracte fort). Simple, però acobla temporalment els serveis.
• Asíncrona: missatgeria (RabbitMQ) i flux d'esdeveniments (Kafka). Desacobla en el temps, absorbeix pics i millora la resiliència; a canvi, complica el raonament i la traçabilitat.
• EDA (Event-Driven Architecture, arquitectura orientada a esdeveniments): els serveis publiquen fets i altres hi reaccionen.

Patró de conversa: petició-resposta —un consumidor n'espera la resposta— davant publicació-subscripció —el productor emet un fet i no sap qui l'escolta—. El primer acobla; el segon no.

Passarel·la ≠ malla de serveis. L'API Gateway governa el trànsit nord-sud, el que entra de fora cap als serveis; la malla de serveis governa l'est-oest, el que els serveis es fan entre ells, amb un sidecar per instància i sense tocar el codi → tema 47.

3.4 Dades

Base de dades per servei: cada servei posseeix el seu esquema i és l'únic que hi escriu i el llegeix; els altres hi arriben només per la seva API. És el que permet desplegar i escalar un servei sense tocar-ne cap altre, i el preu és que una operació que travessa diversos serveis ja no és una transacció. La persistència poliglota —que cada servei triï el tipus de magatzem que s'ajusta a les seves dades— n'és la conseqüència directa, i es desplega al tema 32.

Consistència eventual, no ACID. Una transacció ACID dona atomicitat i aïllament dins d'una base de dades; entre serveis caldria un commit en dues fases (2PC), que no s'usa als microserveis perquè bloqueja recursos i fa que la disponibilitat del conjunt sigui la del participant més lent. El que se n'obté a canvi és consistència eventual: durant una finestra de temps cada servei pot veure una dada diferent, i acaben convergint. Dissenyar per a microserveis és acceptar aquesta finestra i fer-la explícita al negoci, no dissimular-la.

• Patró Saga: transacció distribuïda com a seqüència de transaccions locals amb compensacions. Les compensacions desfan l'efecte de les anteriors amb una operació de negoci —abonar el càrrec—, no amb un rollback, perquè cada transacció local ja s'ha confirmat.
• Transactional outbox per publicar esdeveniments de manera fiable: l'esdeveniment s'escriu a la mateixa transacció local que la dada, i un procés a part el publica després.
• CQRS (Command Query Responsibility Segregation, segregació de responsabilitat entre comandes i consultes): separar el model d'escriptura del de lectura. Event sourcing és un patró diferent i independent: emmagatzemar la seqüència d'esdeveniments com a font de veritat en lloc de l'estat final.
• API composition i CQRS per a consultes que travessen serveis: la primera pregunta a cada servei i ajunta les respostes; la segona manté una vista de lectura ja ajuntada.

Coreografia ≠ orquestració, i val tant per a la saga com per a qualsevol composició de serveis:

3.5 Resiliència i observabilitat

Als microserveis la xarxa forma part del disseny: una crida remota pot arribar tard, no arribar o arribar duplicada, i la fallada d'un servei no pot arrossegar la dels altres. Els patrons de resiliència són la resposta, i com que el tribunal els contraposa, el que cal saber de cadascun és quin problema resol ell i no els altres:

Qui els implementa: o bé el codi de l'aplicació amb una biblioteca (Resilience4j, Polly), o bé la infraestructura amb un sidecar, que aplica les mateixes polítiques sense tocar el servei → tema 47.

Observabilitat: sense traçat distribuït amb propagació de context —un identificador de correlació que viatja amb la petició per tots els serveis que travessa— un error no es pot seguir fins a l'origen. Què és una traça i quina plataforma ho recull, al tema 23.

4. Disseny: com trobar els límits

• Domain-Driven Design: contextos delimitats (bounded contexts), llenguatge ubic i mapes de context. Un microservei sol correspondre a un context delimitat.
• Descomposició per capacitat de negoci, no per capa tècnica. Un servei «de base de dades» o «de lògica» és un antipatró.
• Acoblament feble i cohesió alta: dins d'un servei, tot allò que canvia junt; entre serveis, com menys se sàpiguen l'un de l'altre, millor. Es trenca de tres maneres i totes tenen nom — acoblament de dades (dos serveis comparteixen taula), acoblament temporal (el consumidor no pot avançar si el proveïdor no respon ara mateix) i acoblament de desplegament (s'han de publicar alhora)—. La prova és senzilla: si un canvi obliga a tocar i desplegar més d'un servei, la frontera està mal posada.
• Llei de Conway: l'arquitectura del sistema reprodueix l'estructura de comunicació de l'organització. La maniobra Conway inversa consisteix a organitzar els equips segons l'arquitectura desitjada.
• Mida: no hi ha una regla; el criteri és que un equip petit el pugui posseir i entendre, i que es pugui reescriure en poques setmanes.
• Estrangulador (strangler fig): patró per migrar un monòlit gradualment, interceptant funcionalitat i redirigint-la als serveis nous fins que el monòlit desapareix.

5. Costos

Els microserveis no són gratuïts. El que es guanya en independència es paga en:

• Complexitat distribuïda: xarxa poc fiable, latència, consistència eventual.
• Operació: cal orquestració, observabilitat, CI/CD, gestió de secrets i de configuració madurs.
• Proves: les proves d'integració extremes són difícils; calen contractes de consumidor (consumer-driven contracts, Pact).
• Depuració: sense traçat distribuït, un error és impossible de seguir.
• Governança: versionat i compatibilitat de les API, evitar canvis trencadors.
• Cost d'infraestructura superior.

Antipatrons: monòlit distribuït (serveis que s'han de desplegar junts), base de dades compartida, microserveis anèmics que només fan CRUD (Create, Read, Update, Delete), ESB (Enterprise Service Bus, bus de serveis empresarial) als microserveis (bus intel·ligent), nanoserveis (granularitat excessiva) i comunicació síncrona en cadena (un error a la punta cau tota la cadena).

6. Al sector públic

• L'arquitectura de microserveis encaixa amb la reutilització (Llei 40/2015, art. 158) i amb l'exposició de serveis a altres administracions.
• Interoperabilitat (ENI): les API han de complir els estàndards del catàleg i, quan afecten l'intercanvi entre administracions, els models de dades de les NTI (Normes Tècniques d'Interoperabilitat).
• Contractació: cal definir la propietat de les API i del codi, i la reversibilitat (LCSP, Mesura de digitalització oberta).
• Seguretat: l'ENS exigeix control d'accés, traçabilitat i protecció de les comunicacions; mTLS i OAuth 2.0 en són la implementació habitual.
• Realisme: la major part de la tramitació administrativa viu en plataformes corporatives (a Barcelona, el GPA, Gestor de Procediments Administratius); els microserveis són adequats per als serveis digitals nous i d'alt trànsit, no per reescriure-ho tot.

Claus d'examen

• API Gateway ≠ API Manager: la passarel·la és el component d'execució que encamina peticions en temps real; l'API Manager és la plataforma que en governa el cicle de vida complet —catàleg, claus, quotes, analítica—. El tribunal ha preguntat pels dos per separat (TS-TIC 2018, p. 19; TS-TIC 2023 específic, p. 20; TS-TIC 2023 pràctica, s4-p5; TS-TIC 2025 pràctica, s3-p16).
• UPDATE no és un mètode HTTP. El truc del tribunal és preguntar quin verb NO ho és i colar-hi un de plausible que tampoc ho és; ha caigut amb DOWNLOAD (TS-TIC 2025 específic, p. 70), però aquesta pregunta és del tema d'Internet, arquitectura i protocols.
• SOA no és microserveis: SOA sol anar amb SOAP/WSDL; microserveis, amb REST/JSON. Confondre'ls fa fallar la pregunta del protocol habitual (TS-TIC 2018, p. 1; TS-TIC 2025 pràctica, s3-p18).
• Base de dades compartida = monòlit distribuït. És el parany més repetit: sembla arquitectura de microserveis però trenca l'autonomia de dades per servei.
• El 2PC no s'usa als microserveis; la consistència entre serveis es resol amb el patró Saga (transaccions locals amb compensacions), no amb transaccions distribuïdes clàssiques.

Per recordar

• La idea central és la independència de desplegament de serveis alineats amb capacitats de negoci.
• Cada servei té la seva base de dades; la base de dades compartida genera un monòlit distribuït.
• SOA: avantatge = reutilització i interoperabilitat; protocol habitual = SOAP (amb WSDL). Microserveis: REST/JSON i gRPC.
• REST és un estil arquitectònic orientat a recursos i sense estat; SOAP és un protocol XML amb contracte WSDL.
• UPDATE no és un mètode HTTP: s'usa PUT o PATCH.
• API Gateway = punt d'entrada únic i funcions transversals en temps d'execució; API Manager = govern del cicle de vida complet de les API.
• Saga substitueix les transaccions distribuïdes amb transaccions locals i compensacions; el 2PC no s'usa. Entre serveis hi ha consistència eventual, no ACID.
• Coreografia = cada servei reacciona a esdeveniments; orquestració = un coordinador dona ordres.
• Descobriment: del costat client tria el consumidor amb la llista del registre; del costat servidor tria un intermediari darrere d'una adreça estable.
• Reintent insisteix, tallacircuits desisteix, mampara aïlla recursos i temps d'espera és el que fa possibles els altres tres.
• Comença amb un monòlit modular i extreu serveis quan els límits siguin clars.
• Antipatrons: monòlit distribuït, base de dades compartida, nanoserveis, cadenes síncrones.

Tema 49 · Documental, GIS, qualitat i arquitectura

Disseny i realització de proves de programari

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Disseny i realització de proves de programari.

1. Propòsit de les proves

Propòsit principal de les proves dins del cicle de vida del desenvolupament: verificar que el programari compleix els requisits especificats i detectar defectes abans que arribin a producció, proporcionant informació objectiva sobre la qualitat del producte per donar suport a la presa de decisions.

Tres matisos que es pregunten:

• Les proves no demostren l'absència de defectes: només en demostren la presència (Dijkstra). L'exhaustivitat és impossible.
• Les proves no milloren la qualitat per si soles: la revelen. La qualitat es construeix, no es prova.
• Serveixen també per reduir el risc i per donar confiança per desplegar.

Els set principis de les proves (ISTQB, International Software Testing Qualifications Board):

1. Les proves mostren la presència de defectes, no la seva absència.
2. Les proves exhaustives són impossibles.
3. Provar aviat (early testing), també anomenat desplaçament a l'esquerra (shift-left), estalvia temps i diners: el cost de corregir un defecte creix com més tard es detecta, i provar des de l'inici —revisar l'especificació, escriure proves abans o durant la implementació— surt més barat que provar només al final.
4. Agrupació de defectes: un nombre reduït de mòduls conté la majoria dels defectes (Pareto).
5. Paradoxa del pesticida: repetir sempre les mateixes proves deixa de trobar defectes nous; cal revisar-les i ampliar-les.
6. Les proves depenen del context.
7. La falàcia de l'absència d'errors: un sistema sense defectes coneguts pot ser igualment inservible si no cobreix les necessitats de l'usuari.

Verificació vs validació: verificació = estem construint el producte correctament? (compleix l'especificació); validació = estem construint el producte correcte? (satisfà la necessitat real).

Error → defecte → fallida: una persona comet un error, que introdueix un defecte al codi, que en executar-se pot provocar una fallida del sistema.

2. Nivells de prova

Proves d'acceptació d'usuari (UAT — User Acceptance Testing): les executen els usuaris finals o els representants del negoci en un entorn semblant al de producció, amb dades i escenaris reals, per validar que el sistema satisfà les seves necessitats i que estan disposats a acceptar-lo. No busquen defectes tècnics: busquen adequació a l'ús. Variants: prova alfa (a les instal·lacions del desenvolupador), prova beta (a l'entorn de l'usuari), prova d'acceptació operativa (còpies, recuperació, manteniment), prova d'acceptació contractual i normativa.

Estratègies d'integració: big bang, descendent (top-down) amb stubs, ascendent (bottom-up) amb controladors (drivers), sandvitx i incremental contínua (CI).

Dobles de prova: dummy, stub, spy, mock i fake.

3. Tipus de prova

3.1 Funcionals

Verifiquen què fa el sistema: proves de requisits, de casos d'ús, de regles de negoci, de fluxos i de dades.

3.2 No funcionals

Verifiquen com de bé ho fa:

• Rendiment: càrrega, estrès, resistència (soak), pic (spike), escalabilitat i volum → tema 21. Un informe de prova de càrrega (per exemple, l'informe agregat de JMeter) es llegeix comparant mitjana i mediana —si són properes, el rendiment és estable; si la mediana queda molt per sota de la mitjana, uns quants temps molt alts la distorsionen— i mirant la desviació estàndard: com més baixa, més consistent és el servei sota càrrega.
• Seguretat: anàlisi estàtica (SAST, Static Application Security Testing), dinàmica (DAST, Dynamic Application Security Testing), anàlisi de composició (SCA, Software Composition Analysis), proves de penetració (pen test) i anàlisi de vulnerabilitats.
• Usabilitat i accessibilitat (WCAG (Web Content Accessibility Guidelines) 2.1 AA, obligatòria al sector públic pel RD (Reial Decret) 1112/2018): eines automàtiques (axe, WAVE, Lighthouse) i proves amb usuaris i amb productes de suport (lectors de pantalla).
• Compatibilitat: navegadors, dispositius, sistemes operatius, resolucions.
• Fiabilitat, recuperació i tolerància a fallides.
• Portabilitat, mantenibilitat i instal·lació.
• Internacionalització i localització.

3.3 Proves de canvis

Totes es fan al voltant d'un canvi, i el tribunal les contraposa per la pregunta a la qual responen: la confirmació respon s'ha arreglat allò?, la regressió he trencat res? i la de fum arrenca, si més no?.

• Proves de confirmació (retest): tornar a executar la prova que va fallar, un cop corregit el defecte, per comprovar que la correcció funciona. Miren el defecte corregit, no la resta del sistema.
• Proves de regressió: s'executen per assegurar que els canvis o correccions introduïts al codi no han provocat errors nous en funcionalitats que ja funcionaven correctament. Aquesta és la definició literal que es pregunta, i la correcta és sempre «regressió».
• Són les candidates naturals a l'automatització, perquè es repeteixen a cada canvi.
• Regressió completa vs selecció de regressió basada en l'anàlisi d'impacte.
• Una prova de fum (smoke test) és una bateria mínima i ràpida de les funcions crítiques, feta abans de provar de debò, que verifica que el sistema arrenca i que va el que és essencial; serveix per decidir si val la pena continuar provant. És l'exemple típic de criteri d'entrada: no busca defectes, comprova que la versió és provable.
• La prova de sanitat (sanity test) és una comprovació ràpida i focalitzada d'una àrea concreta després d'un canvi menor, a mig camí entre la de fum i la regressió completa.

4. Tècniques de disseny de casos de prova

La diferència que es pregunta: la caixa blanca dissenya els casos analitzant el funcionament intern del codi —camins, condicions, complexitat—; la caixa negra, a partir de l'especificació externa, sense conèixer el codi. No es distingeixen per la fase en què s'apliquen —totes dues serveixen a qualsevol fase—, i la distractora habitual inverteix les dues definicions.

4.1 Caixa negra (basades en l'especificació)

La caixa negra dissenya els casos a partir de l'especificació i del comportament esperat, sense mirar com està escrit el codi per dins. Serveix a qualsevol nivell de prova i no cal accés al codi font.

• Particions d'equivalència: dividir el domini d'entrada en classes que es comporten igual i provar-ne un representant de cadascuna. Estalvia proves redundants.
• Anàlisi de valors límit: provar els extrems de cada partició i els seus veïns immediats. És on es concentren els defectes. La diferència amb l'anterior és quin representant es tria: la partició en tria un qualsevol; els valors límit trien justament els de la vora —les dues es fan servir juntes, i el tribunal les contraposa.
• Taules de decisió: combinacions de condicions i accions.
• Transició d'estats: per a sistemes amb estats i esdeveniments.
• Casos d'ús i parells (pairwise) per reduir l'explosió combinatòria.

4.2 Caixa blanca (basades en l'estructura)

La caixa blanca dissenya els casos a partir de l'estructura interna del codi i en mesura la cobertura assolida; exigeix accés al codi font i és sobretot de nivell unitari. La contraposició amb la caixa negra és especificació contra codi, no «usuari contra tècnic».

• Cobertura de sentències, de decisions/branques, de condicions, de condicions múltiples i MC/DC (obligatòria en programari crític).
• Cobertura de camins i complexitat ciclomàtica com a fita del nombre de camins.

4.3 Basades en l'experiència

Predicció d'errors (error guessing), proves exploratòries i proves basades en llistes de verificació.

5. Automatització

Piràmide de proves (Mike Cohn): molts casos unitaris a la base, menys d'integració/servei al mig i molt pocs d'extrem a extrem (E2E) al cim. Les d'a dalt són lentes, fràgils i cares; les de baix, ràpides i barates.

Antipatró del con de gelat: la piràmide invertida —molts E2E i poques unitàries— que produeix una bateria lenta, inestable i inútil.

Proves inestables (flaky): passen o fallen sense canvis al codi. Destrueixen la confiança a la bateria: cal aïllar-les i corregir-les immediatament, no reexecutar-les fins que passin.

Eines: JUnit, pytest, NUnit, Jest (unitàries); Testcontainers, WireMock, Pact (integració i contractes); Selenium, Cypress, Playwright (E2E web); Appium, Espresso, XCUITest (mòbil); REST (REpresentational State Transfer) Assured, Postman/Newman, Karate (API, Application Programming Interface); JMeter, k6, Gatling (rendiment); OWASP (Open Worldwide Application Security Project) ZAP (Zed Attack Proxy), Burp (seguretat); SonarQube (estàtica).

Integració al pipeline: unitàries i estàtiques a cada commit; integració i contractes a cada fusió; E2E i rendiment abans del pas a preproducció → tema 41.

5.1 Desenvolupament guiat per proves (TDD)

TDD (Test-Driven Development, desenvolupament guiat per proves): tècnica en què s'escriu la prova d'un requisit abans que el codi que l'implementa. Cicle roig → verd → refactor, que es repeteix per a cada requisit:

1. Roig: triar un requisit i escriure'n una prova, que ha de fallar perquè encara no hi ha implementació.
2. Verd: escriure la implementació mínima que fa passar la prova, sense preocupar-se encara del disseny.
3. Refactor: millorar l'estructura del codi (eliminar duplicació, aclarir noms) mantenint totes les proves en verd.

El primer pas del cicle és sempre escriure la prova, no el codi: és la inversió respecte al desenvolupament tradicional i el que distingeix el TDD d'«escriure proves després».

6. Gestió i entorns

Pla de proves (IEEE 829 / ISO/IEC (International Electrotechnical Commission) 29119): abast, estratègia, nivells i tipus, criteris d'entrada i de sortida, entorns, dades, riscos, recursos, calendari i entregables.

• Criteris d'entrada: quan es pot començar a provar (codi desplegat, prova de fum superada).
• Criteris de sortida: quan es pot deixar de provar (cobertura assolida, cap defecte crític obert, casos executats).

Gestió de defectes: registre amb passos per reproduir, resultat esperat i obtingut, entorn, gravetat (impacte tècnic) i prioritat (urgència de negoci) —no són el mateix—, i el seu cicle de vida (obert → assignat → resolt → verificat → tancat / rebutjat / duplicat / ajornat).

Entorns: desenvolupament, integració, QA (Quality Assurance, assegurament de la qualitat)/proves, preproducció (com més semblant a producció, millor) i producció.

Dades de prova: aquest és un punt crític al sector públic. No es poden fer servir dades personals reals en entorns de prova sense una base de licitud i garanties: el principi de limitació de la finalitat del RGPD, art. 5 ho impedeix. Solucions: generació sintètica, anonimització o pseudonimització robusta, i subconjunts mínims. Si excepcionalment s'usen dades reals, cal la mateixa protecció que a producció.

6.1 El procés de prova i els seus productes

Provar no és només executar: és una seqüència d'activitats que acompanya tot el projecte. Planificació → seguiment i control → anàlisi (què s'ha de provar) → disseny (com es provarà) → implementació (preparar el material i l'entorn) → execució → tancament (informe, lliçons apreses i arxiu del material). No són estrictament seqüencials: en un context àgil s'encavalquen i es repeteixen a cada iteració.

Els productes de treball tenen noms que es confonen:

• Condició de prova: allò que s'ha de comprovar —un requisit, una regla de negoci, un risc—. Diu què.
• Cas de prova: entrades, precondicions i resultat esperat que exerciten una condició. Diu amb quines dades i què ha de passar.
• Procediment de prova: la seqüència ordenada de casos i els passos per executar-los.
• Informe de proves: què s'ha executat, què ha passat i quins defectes queden oberts. És el que sosté la decisió de desplegar.

L'estratègia de proves és el criteri general amb què s'aborda tot això, i es tria segons el context: analítica (es prioritza pel risc o pels requisits), metòdica (una llista de verificació estàndard, sempre la mateixa), conforme a la norma o al procés, i reactiva (es dissenya mentre s'executa, com a les proves exploratòries).

7. Al sector públic

• Les proves d'accessibilitat són obligatòries i s'han de documentar a la declaració d'accessibilitat (RD 1112/2018).
• Les proves de seguretat formen part dels requisits de l'ENS, que exigeix anàlisi de vulnerabilitats i, segons la categoria, proves de penetració abans del pas a producció.
• La validació i proves del servei d'ITIL (Information Technology Infrastructure Library) v3 és el procés que dona la confiança que l'entrega lliurarà el valor esperat → tema 19. Els seus quatre subprocessos són definició de models de prova, adquisició de components per a la versió, proves de la versió i proves d'acceptació del servei.
• L'acceptació formal del contracte (LCSP) és el moment jurídic en què es verifiquen els criteris; els plecs han de definir-los de manera mesurable (cobertura mínima, absència de vulnerabilitats crítiques, compliment WCAG).
• Les UAT les han de fer les unitats usuàries municipals, no el proveïdor.

Claus d'examen

• La definició literal de regressió cau així: «els canvis o correccions al codi no han provocat errors nous en funcionalitats que ja funcionaven». Encara que el redactat variï, si parla de repetir una prova després d'un canvi per comprovar que no s'ha trencat res, és regressió (TS-TIC 2023 específic, p. 65; TS-TIC 2025 específic, p. 52).
• El cicle TDD comença en roig: es tria un requisit i s'escriu la prova abans que el codi. La confusió és posar «escriure la implementació» com a primer pas (TS-TIC 2025 pràctica, s3-p23).
• Davant d'una eina lliure per a proves de validació d'usuari, la resposta és una eina d'automatització de navegador (Selenium), no una de build (Maven) ni d'anàlisi estàtica (SonarQube) (TS-TIC 2023 pràctica, s4-p11).
• Per interpretar un informe de prova de càrrega, compara mitjana i mediana: si són pràcticament iguals, el rendiment és estable des de l'inici, no inestable (TS-TIC 2021 pràctica, s4-p16).
• Els subprocessos de «Validació i proves del servei» d'ITIL v3 parlen d'adquisició de components, no d'adquisició de recursos de màquina, que és la distractora habitual (TS-TIC 2018 específic, p. 87).

Per recordar

• Les proves mostren la presència de defectes, no l'absència; les exhaustives són impossibles; provar aviat (shift-left); paradoxa del pesticida.
• TDD: cicle roig → verd → refactor. Es comença escrivint la prova, no el codi.
• Verificació = construir bé el producte; validació = construir el producte correcte.
• Nivells: unitàries → integració → sistema → acceptació.
• Les tres proves posteriors a un canvi, per la pregunta que responen: confirmació = s'ha arreglat allò?; regressió = he trencat res? —és la candidata principal a l'automatització—; fum = arrenca, si més no?.
• Condició de prova = què s'ha de comprovar; cas de prova = amb quines dades i quin és el resultat esperat.
• UAT = les fan els usuaris finals, en entorn i dades realistes, per validar l'adequació a l'ús.
• Valors límit: on es concentren els defectes.
• Piràmide de proves: moltes unitàries, poques E2E. El con de gelat és l'antipatró.
• Gravetat ≠ prioritat.
• No es poden usar dades personals reals en proves sense base de licitud i garanties: sintètiques o anonimitzades.

Tema 50 · Documental, GIS, qualitat i arquitectura

Tècnica de sistemes SAP BASIS i S/4HANA

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Tècnica de sistemes SAP BASIS i S4/HANA.

1. Què és SAP BASIS

SAP BASIS (Business Application Software Integrated Solution; avui SAP NetWeaver Application Server i, a S/4HANA, SAP Application Server ABAP) és la capa tècnica intermèdia de SAP: el conjunt de components que permet que les aplicacions de negoci s'executin amb independència del sistema operatiu i de la base de dades. El llenguatge de programació propi de SAP és ABAP (Advanced Business Application Programming), amb què s'escriu tant el nucli estàndard com les extensions pròpies de cada client.

Funcions de l'administrador BASIS: instal·lació i actualització del sistema, gestió de mandants, transports, usuaris i autoritzacions, planificació de treballs de fons, monitoratge i rendiment (tuning), còpies de seguretat i recuperació, alta disponibilitat, connexions RFC (Remote Function Call) i interfícies, i aplicació de pedaços i notes SAP.

Fins on arriba aquest tema. Aquí es tracta la capa tècnica: què hi ha sota els mòduls i qui l'administra. Els mòduls funcionals que hi corren a sobre tenen tema propi —comptabilitat i pressupost FI/EA-PS —EA (Enterprise Add-on) per al PS (Public Sector)— → tema 36, gestió tributària TRM (Tax and Revenue Management) → tema 37, recursos humans HCM → tema 38— i el concepte general d'ERP es desenvolupa al tema 42.

2. Arquitectura

Model de tres capes: presentació (SAP GUI, Graphical User Interface, navegador, Fiori) → aplicació (servidors d'aplicació) → base de dades.

Components d'una instància SAP:

Mandant (client): unitat organitzativa i tècnica que separa completament les dades. Un mateix sistema pot tenir diversos mandants (per exemple, 100 personalització, 200 proves, 300 formació).

Paisatge de sistemes (landscape): DEV (Development) → QAS (Quality Assurance System) → PRD (Production).

Sistema de correcció i transport (CTS, Correction and Transport System): tot canvi de personalització o de desenvolupament es registra en una ordre de transport que es promou de DEV a QAS i a PRD. En alliberar l'ordre a DEV els objectes s'exporten, s'importen a QAS i queden encuats cap a PRD. Cap canvi es fa directament a producció.

Transaccions d'administració i transport: SE01/SE09/SE10 (Transport Organizer, creació i alliberament d'ordres), STMS (Transport Management System, cua i importació de transports), SPRO (SAP Project Reference Object, personalització: obre la guia d'implementació), SM59 (RFC Destinations, destinacions RFC), SICK (Installation Check, comprovació de la instal·lació), SPAM i SAINT (Support Package Manager i SAP Add-On Installation Tool, pedaços i complements) i SUM (Software Update Manager, actualitzacions i migracions).

3. SAP Solution Manager

Propòsit principal: plataforma centralitzada de gestió del cicle de vida complet de les solucions SAP (ALM, Application Lifecycle Management): dona suport a la implantació, l'operació, el manteniment, la millora contínua i el monitoratge de tot el paisatge SAP.

Funcions: documentació de processos de negoci, gestió de projectes d'implantació, gestió de canvis i de transports (ChaRM), gestió d'incidents i de peticions (ITSM, Information Technology Service Management, integrat), monitoratge tècnic i de negoci, gestió de proves, descobriment del paisatge (LMDB, Landscape Management Database), aplicació de pedaços i notes, anàlisi de causa arrel i gestió de la migració a S/4HANA (Readiness Check).

No és un mòdul de negoci, ni una base de dades, ni una eina de desenvolupament: és gestió del cicle de vida.

El manteniment estàndard de Solution Manager 7.2 acaba el 2027, alhora que el de SAP ERP 6.0. El relleu és SAP Cloud ALM per als escenaris al núvol i SAP Focused Run per al monitoratge de paisatges grans; el relleu no és equivalent funció a funció, i escenaris com ChaRM o la gestió de proves s'han de replantejar.

4. SAP HANA

SAP HANA (HANA: High-performance ANalytic Appliance) és: la base de dades in-memory, columnar i multimodel de SAP, que és alhora plataforma d'aplicacions.

Enfront d'un motor SQL (Structured Query Language) clàssic com Oracle o SQL Server, el que la distingeix és on viuen les dades i com s'organitzen, no la disponibilitat ni l'escalabilitat, que qualsevol d'aquells motors també ofereix:

• Emmagatzematge principal en memòria (in-memory): les dades resideixen a la RAM (Random Access Memory), no al disc; el disc s'usa per a persistència i recuperació. Això elimina el coll d'ampolla d'entrada/sortida i multiplica la velocitat de consultes i transaccions. Un disc d'estat sòlid no és memòria: per ràpid que sigui, segueix sent disc.
• Emmagatzematge columnar com a model principal: les dades s'organitzen per columnes en lloc de per files, cosa que permet compressió molt elevada, lectures analítiques molt més ràpides i operacions d'agregació sobre milions de files sense índexs addicionals.
• Processament OLTP (Online Transaction Processing) i OLAP (Online Analytical Processing) sobre les mateixes taules (HTAP, Hybrid Transactional/Analytical Processing): desapareix la necessitat de mantenir taules agregades, índexs secundaris i un magatzem de dades separat per a l'anàlisi bàsica. Aquesta és la conseqüència de negoci més important.
• Paral·lelisme massiu aprofitant tots els nuclis, i push-down del càlcul a la base de dades (el «codi va a les dades», no a l'inrevés).
• Multimodel: relacional, documental (JSON, JavaScript Object Notation), espacial, grafs, cerca de text i aprenentatge automàtic integrats al mateix motor.

Persistència: savepoints periòdics i registre de transaccions (redo log) al disc garanteixen la durabilitat malgrat treballar en memòria.

Emmagatzematge per files vs per columnes: HANA permet totes dues; per columnes és el predeterminat i el recomanat per a la immensa majoria de taules.

5. SAP S/4HANA

Què és: la suite ERP (Enterprise Resource Planning) de nova generació de SAP, successora de SAP ERP (ECC 6.0) (ECC: ERP Central Component), construïda exclusivament sobre SAP HANA i amb una simplificació radical del model de dades.

Novetats principals:

Opcions de desplegament: on-premise, núvol privat (RISE with SAP) i núvol públic (S/4HANA Cloud, amb un abast estandarditzat i menys extensibilitat).

Camins de migració:

1. Nova implantació (greenfield): es reimplanta des de zero, redissenyant els processos. Neteja el deute però és el més costós.
2. Conversió del sistema (brownfield): es converteix el sistema existent conservant dades i personalització. Menys disruptiu, arrossega el deute.
3. Transformació selectiva del paisatge (bluefield): es migra selectivament el que interessa.

Eines: SAP Readiness Check, Simplification List (llista de canvis funcionals obligatoris), Custom Code Migration (anàlisi del codi ABAP propi), SUM/DMO (Database Migration Option, actualització i migració de base de dades en un sol pas) i SAP Activate com a metodologia.

Calendari crític: el manteniment estàndard de SAP ERP 6.0 finalitza el 2027 per als enhancement packages 6, 7 i 8 —els anteriors ja hi van sortir abans—, amb manteniment estès opcional fins al 2030 a canvi d'un recàrrec sobre la quota. SAP hi ha afegit després una opció de transició fins al 2033 reservada a clients que passen al model de subscripció al núvol. Cap de les tres allarga el producte indefinidament: la migració a S/4HANA és una obligació planificable, no una opció, per a les administracions que hi tenen la gestió econòmica.

6. Usuaris i autoritzacions

El control d'accés de SAP té dos nivells que no s'han de confondre: qui entra (el registre mestre d'usuari) i què pot fer un cop dins (les autoritzacions). Els dos són per mandant: el mateix nom d'usuari en dos mandants del mateix sistema són dos usuaris diferents, amb rols diferents.

El registre mestre d'usuari es manté amb SU01 (User Maintenance) i porta les dades d'accés, el grup, la validesa i els rols. Cada usuari té un tipus, i la diferència entre ells és de les que es pregunten:

Com es concedeix un permís. La peça mínima és l'objecte d'autorització: una agrupació de fins a deu camps que representa una comprovació. Els valors permesos per a aquests camps s'agrupen en un rol, que es manté amb PFCG (Profile Generator); en generar el rol el sistema en construeix el perfil. Assignar el rol no basta: fins que no es fa la comparació d'usuari el perfil no entra al registre mestre i l'usuari no té l'autorització. Els rols poden ser simples, compostos (agrupen rols simples) i derivats (hereten d'un rol pare i només canvien les restriccions organitzatives).

Quan un usuari rep un «sense autorització», el primer lloc on es mira és SU53, que ensenya l'última comprovació d'autorització que ha fallat i amb quins valors.

Els riscos clàssics, que són els que apareixen en una auditoria:

• El perfil SAP_ALL dona el sistema sencer. No hi ha cap motiu perquè estigui assignat de manera permanent a producció.
• Els usuaris estàndard —SAP*, DDIC, EARLYWATCH— es creen a la instal·lació amb contrasenyes públiques i documentades: s'han de canviar i bloquejar.
• La segregació de funcions: qui comptabilitza no paga, qui crea el proveïdor no aprova la factura. És un requisit de control intern, i el model de rols és on es materialitza.

Traçabilitat: el registre d'auditoria de seguretat enregistra accessos, intents fallits i accions crítiques. Es configurava amb SM19 i es llegia amb SM20; des de NetWeaver 7.50 les transaccions vigents són RSAU_CONFIG i RSAU_READ_LOG.

7. Monitoratge i rendiment

Un sistema SAP es vigila per capes, i el primer pas d'una anàlisi és decidir de quina capa és el coll d'ampolla —aplicació, base de dades o sistema operatiu— abans d'entrar al detall. Mirar-ho al revés és l'error habitual: es fa tuning de la base de dades quan el que falta és memòria a la màquina.

Estat del sistema (capa d'aplicació): SM50 (Work Process Overview, els processos de treball d'una instància) i SM66 (Global Work Process Overview, els de totes les instàncies alhora, que és la vista per a un paisatge distribuït); SM12 (bloquejos), SM13 (actualitzacions pendents o cancel·lades), SM21 (registre del sistema), ST22 (bolcats ABAP) i SM37 (treballs de fons).

Rendiment: la parella que cal distingir és ST03 (Workload Monitor: temps de resposta i càrrega per tipus de tasca —diàleg, fons, RFC, actualització—, la mesura de referència de com va el sistema per a qui l'usa) i ST06 (Operating System Monitor: la màquina —processador, memòria, intercanvi, disc i xarxa—). Per baixar un esglaó hi ha monitors específics de les memòries intermèdies de SAP, de la base de dades i de la traça de sentències SQL.

Base de dades i còpies: DB02 (Tables and Indexes Monitor: creixement, espai i índexs) i DB12 (registres de còpia de seguretat: si l'última va acabar bé).

Alertes i monitoratge centralitzat: el CCMS (Computing Center Management System) recull mètriques amb llindars i les presenta com a alertes a RZ20. Per damunt, SAP Solution Manager hi afegeix el monitoratge de tot el paisatge i l'informe periòdic EarlyWatch Alert, i SAP Focused Run i SAP Cloud ALM fan el mateix per a paisatges grans i per al núvol. La base de dades HANA té la seva pròpia consola, el SAP HANA Cockpit.

8. SAP BTP i l'ecosistema

SAP Business Technology Platform (BTP): la plataforma de núvol de SAP per a extensió, integració, dades i IA (Intel·ligència Artificial). Components: SAP Integration Suite (successora de PI (Process Integration) i PO (Process Orchestration)), SAP Build (low-code → tema 40), SAP Datasphere i SAP Analytics Cloud (dades i analítica), ABAP Environment (ABAP al núvol) i serveis d'IA.

Altres: SAP Fiori Launchpad, SAP Gateway (serveis OData), SAP Cloud ALM (successora de Solution Manager per a entorns al núvol), SAP Signavio (process mining).

9. Consideracions per al sector públic

• Dimensionament de memòria: HANA exigeix molta RAM certificada, i el factor de compressió depèn de les dades de cada instal·lació, de manera que la mida no s'estima a ull sinó amb les eines de dimensionament de SAP. El cost d'infraestructura és un factor determinant en la decisió entre local i núvol; la sala on s'allotja el maquinari és matèria del CPD (Centre de Procés de Dades) → tema 55.
• Alta disponibilitat i recuperació: HANA System Replication i clústers; els objectius RPO (Recovery Point Objective) i RTO (Recovery Time Objective) s'han de fixar segons la criticitat del servei → tema 58.
• ENS: categorització del sistema, control d'accés, segregació de funcions, traçabilitat i còpies. El model d'autoritzacions de SAP és una peça central del compliment.
• RGPD: SAP tracta dades personals massives (HCM, Human Capital Management, padró, tributs); calen control d'accés per objecte d'autorització, registre d'activitats, terminis de conservació i bloqueig i esborrat de dades (SAP ILM, Information Lifecycle Management).
• Contractació i dependència: la migració a S/4HANA i a RISE implica decisions de llarg abast sobre sobirania de les dades i bloqueig de proveïdor; la Mesura de digitalització oberta obliga a valorar-ho.
• Migració de dades: la qualitat de les dades mestres determina l'èxit → tema 31.

Claus d'examen

• A HANA la memòria hi és sempre; el columnar l'acompanya, però no la substitueix. El mateix tret cau dues vegades i amb dues redaccions diferents de la correcta: a TS-TIC 2025 pràctica (s4-p024) és «emmagatzematge de dades en memòria principal (RAM) per accelerar consultes i transaccions», sense esmentar columnes; a TS-TIC 2025 específic (p. 59) és «emmagatzemar dades en memòria (in-memory database) i el seu model de columna», les dues coses juntes. La regla que en surt: descarta tota opció que no parli de memòria, i entre les que en parlen tria la que hi sumi el columnar si l'hi sumen.
• El parany de HANA és el disc ràpid. Les distractores hi posen SSD (Solid State Drive), fitxers de text plans i taules per files amb accés seqüencial (TS-TIC 2025 pràctica, s4-p024). Un SSD segueix sent disc. I les que ofereixen «alta disponibilitat i escalabilitat» o «suport a múltiples llenguatges» (TS-TIC 2025 específic, p. 59) fallen per un altre motiu: Oracle i SQL Server també les tenen, així que no distingeixen res.
• SAP Solution Manager no és una base de dades ni un mòdul de negoci: el propòsit que cau és «monitorització i gestió de sistemes SAP», el nucli de l'ALM (TS-TIC 2023, p. 82). Les distractores hi confonen desenvolupament d'aplicacions, implementació de HANA o informes financers.
• ABAP és el llenguatge de SAP, no d'un altre fabricant (Navision, Microsoft Dynamics, Oracle són les distractores habituals): és el llenguatge complementari de desenvolupament sobre l'estàndard SAP (TM-TIC 2021-OP, p22; examen d'una altra categoria, no compta per aquest temari però la trampa és la mateixa).

Per recordar

• BASIS és la capa tècnica de SAP: instal·lació, mandants, transports, usuaris i autoritzacions, treballs de fons, rendiment i còpies.
• Paisatge DEV → QAS → PRD amb ordres de transport; cap canvi directe a producció.
• SAP Solution Manager = gestió del cicle de vida complet de la solució (ALM): implantació, canvis, incidents, monitoratge i migració.
• SAP HANA: in-memory i columnar, amb compressió alta i OLTP i OLAP sobre les mateixes taules. Aquesta és la diferència essencial amb Oracle o SQL Server. Un SSD no és memòria.
• La durabilitat de HANA es garanteix amb savepoints i registre de transaccions al disc.
• S/4HANA: Universal Journal (ACDOCA) unifica FI i CO; Business Partner únic; interfície Fiori; analítica incrustada; principi de clean core.
• Migració: greenfield, brownfield i bluefield.
• Autoritzacions: objecte d'autorització → rol (PFCG) → perfil → usuari, i el permís no és efectiu fins a la comparació d'usuari. SAP_ALL no viu a producció.
• Monitoratge: SM50 és d'una instància i SM66 de totes; ST03 mesura la càrrega de treball i ST06 la màquina.
• Fi de manteniment de SAP ERP 6.0: 2027 (EhP 6, 7 i 8), estès fins al 2030 i, en el model de subscripció, fins al 2033. És l'única data d'aquest tema que cal saber; la resta de versions i noms de producte, situa'ls, no els memoritzis.