Opcions d'impressió

Mida
Compacta · 9 pt Normal · 10,5 pt Gran · 12,5 pt
Els meus apunts
No imprimir-los Incloure'ls a cada paràgraf

El navegador numera les pàgines des del seu propi quadre d'imprimir: activa-ho allà si les vols.

Els requadres grisos només surten si deixes marcada la casella «Gràfics de fons» del quadre d'imprimir.

opos

Temari específic · Tècnic/a Superior en Tecnologies de la Informació i la Comunicació

Ajuntament de Barcelona
Grup de titulació
Grup A, subgrup A1
Què conté
Temari específic
Temes
73
Imprès el
2026-10-19

Tema 1

Planificació estratègica TIC

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

Enunciat oficial. Planificació estratègica TIC. Pla director de sistemes d'informació. Anàlisi de necessitats organitzatives.


1. Què és la planificació estratègica de SI/TI

SI (Sistemes d'Informació) i TI (Tecnologies de la Informació), sovint agrupats com a TIC (Tecnologies de la Informació i la Comunicació).

Finalitat: alinear els sistemes i les tecnologies de la informació amb els objectius i l'estratègia de l'organització, decidint quines inversions TIC s'han de fer, en quin ordre i amb quins recursos, per un horitzó típic de 3 a 5 anys.

No és un pla de compres ni un catàleg de projectes: és la traducció de l'estratègia de negoci en una cartera de sistemes, dades, infraestructures, capacitats i governança.

Direcció per objectius (DPO), que és com aquesta traducció baixa a les persones: els objectius s'acorden entre qui dirigeix i qui executa, no s'imposen. Els seus passos són assegurar que la missió, la visió i els valors estan comunicats i compresos, acordar la metodologia per fixar els objectius i controlar-los, i donar retroalimentació sobre el seu assoliment. Emetre instruccions i ordres concretes dins d'un marc d'actuació limitat és el contrari: és direcció per instruccions, i és la distractora habitual.

Beneficis que se solen enunciar (i que els exàmens fan triar):

No és un benefici de la planificació estratègica «garantir que tots els projectes s'executin en termini», «eliminar el risc» ni «reduir el pressupost TIC»: aquestes són les respostes falses habituals.

Nivells de planificació: estratègica (què i per què, 3-5 anys, alta direcció) → tàctica (com i amb què, 1-2 anys, direcció TIC) → operativa (dia a dia, caps de servei).


2. Marcs de referència

El procés PSI de Mètrica v3

Activitats, en ordre: inici del pla; definició i catàleg de requisits; estudi de la informació rellevant; identificació de requisits (processos i necessitats d'informació); estudi dels sistemes d'informació actuals; disseny del model de sistemes d'informació; definició de l'arquitectura tecnològica; definició del pla d'acció; i, com a darrer pas, la revisió i aprovació del Pla de Sistemes d'Informació.

La convocatòria i el pla de treball són del principi; l'aprovació, del final.


3. El PDSI (Pla Director de Sistemes d'Informació)

PDSI: sigla del Pla Director de Sistemes d'Informació.

El mateix instrument, quatre noms. L'enunciat oficial d'aquest tema el diu pla director de sistemes d'informació, però la sigla més estesa avui a les administracions espanyoles és PETIC (Pla Estratègic de Tecnologies de la Informació i la Comunicació) —el Govern Basc aprova el seu PETIC 2021-2024 amb aquest nom—, i també se'l troba com PETI (Pla Estratègic de Tecnologies de la Informació, sense la comunicació) o PESI (Pla Estratègic de Sistemes d'Informació). No són instruments diferents: són el mateix document. PDSI i PETIC designen la mateixa cosa i qualsevol de les dues sigles pot aparèixer a l'enunciat d'una pregunta.

Definició: document que recull el diagnòstic de la situació actual, el model objectiu de sistemes, dades, infraestructures i organització TIC, i el full de ruta (cartera de projectes prioritzada, calendari, pressupost i indicadors) per passar d'un a l'altre.

Contingut típic:

  1. Marc estratègic: la missió (la raó de ser i actuar de l'organització), la visió (on vol estar en el futur) i els valors —que li donen personalitat pròpia i han de ser compartits, mai imposats— de l'organització; drivers i restriccions.
  2. Diagnòstic (as-is, la situació actual): mapa d'aplicacions, dades, infraestructures, organització TIC, processos, despesa, nivell de maduresa, deute tècnic.
  3. Anàlisi de necessitats i requisits de les àrees.
  4. Model objectiu (to-be, la situació desitjada): arquitectura de negoci, dades, aplicacions i tecnologia.
  5. Anàlisi de bretxes (gap analysis): distància entre l'as-is i el to-be.
  6. Cartera de projectes prioritzada amb criteris explícits.
  7. Full de ruta (roadmap): fases, dependències, calendari, quick wins.
  8. Model de govern: òrgans de decisió, comitès, rols, gestió de la demanda.
  9. Pla econòmic: CAPEX (Capital Expenditure, inversió) i OPEX (Operating Expenditure, despesa corrent), TCO (Total Cost of Ownership, cost total de propietat), model de contractació.
  10. Riscos, gestió del canvi i quadre de comandament amb KPI (Key Performance Indicator, indicador clau de rendiment).

Del diagnòstic al model objectiu del PDSIDues fotografies i la distància que hi ha entre elles. L'anàlisi de bretxes no és un pas del pla: és el que el pla ha de tancar.Diagnòstic (as-is)situació actualModel objectiu (to-be)situació desitjadaanàlisi de bretxes (gap analysis)

Cicle de vida: normalment quadriennal, amb revisió anual i actualització de la cartera.

Factors crítics d'èxit: patrocini de l'alta direcció, participació de les àrees usuàries, realisme pressupostari, governança clara i seguiment amb indicadors. La causa de fracàs més citada és la desconnexió entre el pla i el pressupost real.


4. L'anàlisi de necessitats organitzatives

4.1 Diagnosi estratègica

La diagnosi contesta dues preguntes diferents: on és l'organització respecte del seu entorn, que és el que mira el DAFO, i què sap fer, que és el que mira el mapa de capacitats. La primera dona el relat del pla; la segona, la columna vertebral sobre la qual es prioritza la cartera de projectes.

DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats; en anglès SWOT, Strengths, Weaknesses, Opportunities, Threats): classifica cada circumstància per dos eixos alhora, mai per un de sol — l'origen (intern de l'organització o extern del seu entorn) i el signe (negatiu o positiu). Del creuament surten les quatre caselles:

Negatiu Positiu
Intern Debilitat — mancança pròpia: deute tècnic, dificultats de coordinació entre àrees, plantilla TIC insuficient Fortalesa — capacitat pròpia: expertesa acumulada del personal en un sistema, infraestructura consolidada
Extern Amenaça — factor de l'entorn que perjudica: normativa reguladora canviant, obsolescència d'un producte, dependència d'un proveïdor únic Oportunitat — factor de l'entorn que afavoreix: maduració de l'administració electrònica, fons europeus, aparició d'un estàndard obert

La matriu CAME (Corregir, Afrontar, Mantenir, Explotar) deriva l'acció del DAFO: Corregir debilitats, Afrontar amenaces, Mantenir fortaleses, Explotar oportunitats. El DAFO diu on s'és; el CAME, què es fa.

Les altres eines de la diagnosi:

Un diagrama de Gantt no és una tècnica de diagnosi ni serveix per entendre l'estratègia de negoci: és una eina de programació temporal de projectes. Apareix com a distractor precisament per això.

4.2 Anàlisi de processos

4.3 Priorització de la inversió


5. La planificació estratègica TIC al sector públic i a l'Ajuntament


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 2

La Transformació Digital i l'impacte en les organitzacions

Enunciat oficial. La Transformació Digital i l'impacte en les organitzacions.


1. Concepte i graus de digitalització

Transformació digital és el canvi profund del model de funcionament d'una organització —processos, cultura, relació amb els usuaris i model de servei— possibilitat per les tecnologies digitals. La tecnologia n'és l'habilitador, no la finalitat, i el canvi impacta alhora en el nivell estratègic, el funcional, l'organitzatiu i el dels serveis.

1.1 Els tres graus

Cal distingir-los: la resposta falsa descriu la transformació digital com un simple trasllat dels processos al món digital «sense canvis significatius».

Què fa Exemple municipal
Digitització (digitization) passa informació analògica a format digital escanejar l'expedient en paper
Digitalització (digitalization) fa servir la tecnologia per executar el procés existent tramitar el mateix procediment per la seu electrònica
Transformació digital redissenya el model de servei i l'organització eliminar el tràmit perquè l'Administració ja té les dades

Els tres graus de la digitalització, per profunditat del canviL'eix creix cap a la dreta: cada grau canvia més coses que l'anterior. Sobre la línia, què canvia; sota, un exemple.Digititzaciócanvia el suportDigitalitzaciócanvia el canal del procésTransformació digitalcanvia el model de servei,l'estructura i la culturapaper → fitxerfinestreta → seu electrònicael tràmit desapareixprofunditat del canvi en l'organització

La relació és de contingut, no d'oposició: la digitalització —l'adopció de TIC (Tecnologies de la Informació i la Comunicació)— és una activitat continguda dins dels projectes de transformació digital, no un sinònim seu ni una cosa que només afecti els processos interns.

1.2 L'impacte en les tecnologies i els sistemes

La transformació digital no consisteix a afegir tecnologia sobre els sistemes existents. Exigeix proporcionar una base tècnica estable i adequada per als objectius a curt i a llarg termini i obrir-se a estàndards oberts i interoperables: desacoblament, API (Application Programming Interface, interfície de programació d'aplicacions), núvol, dades com a actiu, i una manera diferent de construir programari. Les distractores són tres: mantenir la segmentació dels equips de tecnologia, fer solucions a mida sense pensar en el manteniment i deixar que el departament tecnològic lideri sol la transformació.


2. Dimensions i palanques del canvi

Sis dimensions habituals:

  1. Estratègia i model de servei — proposta de valor digital, canals, personalització, proactivitat.
  2. Persones i cultura — competències digitals, lideratge, autonomia dels equips, tolerància a l'error.
  3. Processos — simplificació, automatització, extrem a extrem, només una vegada.
  4. Tecnologia — núvol, interfícies obertes, microserveis, plataformes, ciberseguretat.
  5. Dades — govern de la dada, analítica, intel·ligència artificial, decisions basades en evidència.
  6. Ecosistema — col·laboració amb altres administracions, empreses i ciutadania.

Tecnologies habilitadores: social, mobilitat, núvol i internet de les coses; i les posteriors: IA (Intel·ligència Artificial), cadena de blocs i bessó digital. Cada una té el seu tema: aquí són palanques, no matèria.

El bessó digital és la rèplica virtual d'un actiu, procés o sistema físic alimentada amb dades en temps real que permet simular, predir i optimitzar el comportament de l'original: a escala urbana, assajar decisions abans d'executar-les.


3. L'impacte en les organitzacions

3.1 Estructura, rols i cultura

L'automatització no treu les persones del servei: allibera les activitats programables perquè es dediquin a les que no ho són.

3.2 La gestió del canvi

És el factor de fracàs més freqüent. Les causes es repeteixen: confondre la transformació amb la compra de tecnologia, delegar-la al departament tecnològic, la resistència de les estructures que perden competències, la manca de competències internes i l'abast excessiu sense victòries visibles.

Models de referència:

Palanques: comunicació interna i externa, formació de l'equip humà, revisió de la relació de llocs de treball, noves fórmules de contractació i una governança que legitimi i prioritzi el projecte.

Riscos: bretxa digital, dependència de proveïdor, pèrdua de sobirania sobre les dades, biaix algorítmic, superfície d'atac més gran i obsolescència de competències.


4. Com es mesura

Una transformació sense mesura és una declaració d'intencions. Tres instruments:

L'Ajuntament de Barcelona en té de propis i públics: l'enquesta de serveis municipals, anual, que mesura l'ús de canals i xarxes socials —el 2020, entre persones de 18 a 74 anys, la més emprada era WhatsApp i la segona, Instagram, per davant de Facebook i Twitter—, i els estudis periòdics de bretxa digital.


5. La transformació digital al sector públic

5.1 Què la distingeix del sector privat

La motivació no és la competitivitat sinó el millor servei a la ciutadania, l'eficiència, la transparència i la inclusió. I quatre restriccions que una empresa no té:

Per això és ètica per obligació: garantir la governança de les dades i la transparència en l'ús de la intel·ligència artificial no és un extra, és la condició per fer-la. Els contraris —algoritmes propietaris opacs, decisions automatitzades sense supervisió humana, velocitat per damunt de la qualitat— són les distractores.

5.2 Principis del servei públic digital

El com —seu electrònica, registre, notificació, expedient— és matèria del tema d'administració electrònica; aquí interessa què li passa a l'organització quan els adopta.

5.3 Marc europeu i estatal

5.4 La ciutat intel·ligent

La UNE (Una Norma Espanyola) 178104 —sistemes integrals de gestió de la ciutat intel·ligent, del CTN (Comitè Tècnic de Normalització) 178— fixa els requisits d'interoperabilitat de la Plataforma de Ciutat Intel·ligent.

L'objectiu del trànsit cap a ciutat intel·ligent, segons la norma, és ser més sostenibles i eficients i millorar la qualitat de vida de la ciutadania mitjançant l'ús de la tecnologia. No «ser més modernes», ni «quadrar el pressupost», ni «millorar la consciència política»: aquestes són les distractores.

La plataforma capacita la ciutat per operar les seves infraestructures, prendre decisions basades en dades i coordinar els serveis urbans. El que no n'és una capacitat és dependre d'una única empresa proveïdora: la norma persegueix el contrari.


6. La bretxa digital

6.1 Concepte i dimensions

Bretxa digital (o escletxa digital) és la desigualtat en l'accés, l'ús i l'aprofitament de les tecnologies digitals entre grups de població. Té tres capes que no es tanquen alhora: accés (connexió i dispositiu), ús i competències i aprofitament (benefici real). Tancar la primera fa emergir les altres dues.

Aquí la bretxa interessa com a palanca i fre del canvi de model: qui no té accés, ús o competències queda fora del servei digital per defecte. El mecanisme jurídic que ho garanteix —el dret a triar el canal (Llei 39/2015, art. 14), l'assistència en l'ús de mitjans electrònics (art. 12) i el funcionari habilitat— el desenvolupa Administració electrònica i serveis digitals; transformar-se sense desplegar aquesta assistència és excloure.

6.2 Barcelona: de l'estudi del 2016 al del 2020

6.3 Els perfils de digitalització

L'estudi del 2020 agrupa la ciutadania en quatre perfils de digitalització —avançat, mitjà, bàsic i baix— combinant equipament i usos:

Conèixer aquesta composició és el pas previ a qualsevol procés participatiu: diu a qui deixa fora l'eina que es tria.


7. El model de Barcelona

7.1 El Pla Barcelona Ciutat Digital

Aprovat en mesura de govern el 2016, amb l'horitzó 2017-2020. S'organitza en tres eixos estratègics, un per destinatari:

Eix A qui s'adreça
Transformació digital el govern i la ciutat
Innovació digital les empreses i les entitats socials
Apoderament digital la ciutadania

7.2 La mesura de govern per a la digitalització oberta

La mesura de digitalització oberta (2017) concreta com es fa. Objectius: arquitectura oberta, obertura de la contractació pública, model de serveis centrat en la persona usuària i sobirania tecnològica i de les dades —les dels serveis públics són un bé comú i el codi fet amb diner públic es publica—. El programari lliure hi és preferent, no excepcional: dir que la mesura promou el propietari és la distractora directa. S'hi afegeixen el desenvolupament àgil, amb equips orientats al servei, i la contractació responsable: clàusules socials, ètiques i de reversibilitat, i entrada de petites i mitjanes empreses locals.

Instruments: els estàndards de serveis digitals —criteris de disseny, construcció i manteniment: equips multidisciplinaris, mètodes àgils, codi i estàndards oberts, seguretat i privacitat, i accessibilitat—, el codi de pràctiques tecnològiques i el pla de migració a codi obert.

Aquests instruments, publicats en obert i reutilitzables per altres ciutats, són el que l'Ajuntament anomena els Estàndards Ètics Digitals. «Ètics» no és un codi deontològic: el que hi ha és una guia amb criteris per crear, gestionar i oferir serveis digitals de manera àgil i oberta, i l'ètica és el resultat de com es construeix el servei. I «estàndards» no és una norma tècnica certificable: és material amb llicència lliure, sense compliment obligat fora de l'Ajuntament.

7.3 L'Estratègia d'impuls dels serveis digitals

Mesura de govern del 2018. El seu propòsit és accelerar el procés de digitalització de serveis i equilibrar l'esforç de transformació amb una major consecució de valor al servei públic —no «eliminar el paper», ni «derivar l'atenció al portal web», ni reduir-se a la interoperabilitat—.

Es desplega en un decàleg de principis per adaptar-se a la Llei 39/2015: els del § 5.2 més mitjans digitals personals, interoperabilitat i eficiència.

Les directrius de disseny, desenvolupament i manteniment que en surten, i que cauen com a llista amb un intrús, són: adreçat a la ciutadania, serveis integrats i integrals i claredat en objectius i recursos. L'intrús és el principi d'eficiència: pertany al decàleg d'adaptació a la Llei 39/2015 —reduir els recursos dedicats a burocràcia sense valor afegit—, que mira el cost intern de l'Administració, no el disseny del servei.

El seu component central és la Plataforma de Serveis Digitals, una arquitectura d'abast integral, sobre aquests fonaments:

7.4 Plataformes i canals municipals

Cada peça té la seva funció, i l'examen les creua:

La comunicació digital municipal es basa en quatre eixos: la informació de servei (temps, trànsit, tràmits, horaris, emergències), la informació sobre les iniciatives municipals i l'acció de govern (mesures, plans, ordenances, pressupostos), l'atenció ciutadana (peticions, suggeriments, queixes) i la participació. Els canals —web i xarxes socials— són el mitjà, no un eix.

7.5 El programari lliure

Les quatre llibertats essencials de la Free Software Foundation. Un programa és programari lliure si els usuaris tenen:

Fixa't en la llibertat 0: és executar, no modificar —modificar és la 1—. I no són llibertats essencials «vendre el programa», «tenir suport tècnic gratuït», «que sigui gratuït» ni «garantir que no es pugui usar amb fins comercials»: el programari lliure no és el mateix que gratuït i no restringeix l'ús comercial.

GNU (GNU's Not Unix) és el projecte de Richard Stallman per oferir un sistema operatiu complet, compatible amb Unix i 100 % programari lliure. D'aquí surten la GPL (General Public License) i el copyleft: mètode general per convertir en lliure un programa i aconseguir que qualsevol derivat mantingui la condició de lliure. Les llicències permissives com Apache 2.0 no imposen la reciprocitat.

Avantatges per a una administració: independència de proveïdor, escrutini públic de la seguretat, foment de la indústria local i reutilització. El que no fa és eliminar els costos de migració —dades, formació, integració—: la distractora clàssica.

Programari de codi tancat o propietari: s'adquireix un dret d'ús (llicència), no la propietat ni el dret a modificar-lo o redistribuir-lo, i aquest dret no inclou l'accés públic al codi font. Té limitacions d'ús i no obliga a contractar suport.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 3

Prospecció de solucions TIC: casos de negoci

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

Enunciat oficial. Prospecció de solucions TIC: Casos de negoci.


1. La prospecció de solucions

Prospecció és el procés d'identificar, analitzar i comparar les alternatives disponibles al mercat —o construïbles internament— per cobrir una necessitat, abans de comprometre la inversió.

Etapes:

  1. Definició de la necessitat i dels requisits (funcionals i no funcionals), amb els criteris d'acceptació.
  2. Estudi de mercat i exploració d'experiències d'altres administracions i de catàlegs de solucions reutilitzables (§1.2).
  3. Identificació d'alternatives: fer (desenvolupament propi), comprar (producte comercial), reutilitzar (solució d'una altra administració), subscriure (SaaS), externalitzar (servei gestionat), o no fer res (l'alternativa base sempre s'ha d'avaluar).
  4. Consultes preliminars del mercat.
  5. Anàlisi de viabilitat: tècnica, econòmica, operativa, legal i temporal.
  6. Avaluació comparativa amb criteris ponderats i prova de concepte (PoC) o pilot.
  7. Cas de negoci i decisió.

Anàlisi de viabilitat d'una solució TIC (Tecnologies de la Informació i la Comunicació) — les dimensions que s'han preguntat:

Abans de prendre la decisió final és necessari avaluar diverses alternatives amb criteris objectius i comprovar-ne la viabilitat; no n'hi ha prou amb l'anàlisi de requisits ni amb el pressupost del proveïdor.

Mètodes de valoració d'alternatives: matriu de decisió ponderada, AHP (Analytic Hierarchy Process), anàlisi multicriteri, RFI (Request for Information) / RFP (Request for Proposal) amb bancs de proves.

1.1 Build vs buy: els criteris de comparació

La decisió build vs buy —construir o comprar— no es resol pel preu de compra, sinó comparant les alternatives amb els mateixos criteris ponderats i el mateix horitzó temporal:

Criteri Què s'hi mira
Ajust funcional quant cobreix el producte de sèrie i quanta personalització caldrà; una personalització alta destrueix l'avantatge de comprar
Cost total el TCO de cada alternativa, no el preu de la llicència ni el cost del primer any
Termini comprar sol lliurar abans; construir triga, però pot arribar on el mercat no arriba
Capacitats internes si no hi ha equip per mantenir el que es construeix, «fer» és una decisió que caduca
Diferenciació el que dona avantatge propi es construeix; el que és una commodity es compra
Risc i dependència maduresa i solvència del proveïdor, comunitat, reversibilitat i portabilitat de les dades
Encaix legal protecció de dades, accessibilitat, ENS / ENI i règim de propietat del codi

Els dos extrems rarament guanyen sols: a la pràctica s'imposen les opcions intermèdies —reutilitzar una solució d'una altra administració, subscriure un SaaS o estendre un producte comercial amb desenvolupament propi acotat—, i totes s'han de valorar amb la mateixa graella.

1.2 Estudis de mercat i benchmarking tecnològic

L'estudi de mercat és la fotografia de què ofereix el mercat avui: quins proveïdors hi ha, quines solucions, en quines forquilles de preu i amb quines condicions. Al sector públic té a més un ús taxat: justificar el pressupost base de licitació amb dades objectives. Estimar-lo grosso modo confiant que la competència ja el corregirà a la baixa no és admissible: el preu es justifica abans de licitar.

Els instruments:

El benchmarking tecnològic és el pas següent: comparar sistemàticament les alternatives —o la pròpia situació— contra unes referències, amb criteris homogenis i mesurables. Es distingeix de la vigilància tecnològica, que capta informació de l'entorn de manera contínua però no ordena alternatives concretes (→ tema 28). El benchmarking dona el quadre comparatiu ponderat; quan la diferència no es pot resoldre sobre paper, es tanca amb una PoC o un pilot.

1.3 Sobirania tecnològica i bloqueig del proveïdor

La sobirania tecnològica és l'adopció de mesures orientades a reduir el bloqueig tecnològic (vendor lock-in): la dependència d'un únic proveïdor, format o tecnologia propietària que deixa l'organització sense capacitat real de decidir sobre l'evolució dels seus sistemes.

No és la llibertat de decidir quina marca o producte es compra, ni la identificació de les millors solucions abans d'adquirir-les —això segon és la prospecció mateixa, i és la trampa que hi posa el tribunal (§Claus d'examen).

Les mesures que la materialitzen en una prospecció:

És una línia declarada del Pla Barcelona Ciutat Digital, que vincula la sobirania tecnològica al programari lliure, als estàndards oberts i a un model de contractació que no depengui d'un sol proveïdor.


2. El cas de negoci (business case)

Definició (PMBOK) (Project Management Body of Knowledge): document que recull l'estudi de viabilitat econòmica documentat que s'utilitza per establir la validesa dels beneficis d'un component encara no prou definit i que és el fonament per autoritzar més activitats de direcció del projecte. Justifica per què cal fer la inversió.

Contingut:

  1. Necessitat de negoci i problema o oportunitat.
  2. Anàlisi de la situació i alineació estratègica.
  3. Alternatives considerades, inclosa la de no fer res.
  4. Solució recomanada i abast d'alt nivell.
  5. Anàlisi econòmica: costos —CAPEX (Capital Expenditure) / OPEX (Operating Expenditure), TCO—, beneficis (tangibles i intangibles), indicadors financers, període d'anàlisi.
  6. Beneficis esperats i com es mesuraran (indicadors, línia base, responsable de la realització).
  7. Riscos i supòsits.
  8. Full de ruta i recursos necessaris.
  9. Recomanació i govern de la decisió.

Aspectes no financers: el cas de negoci no es limita als aspectes econòmic-financers. Ha d'incorporar també els no financers —d'imatge, estratègics, de risc, socials— i, sempre que sigui possible, intentar reduir-los a una valoració econòmica per poder-los comparar amb la resta dins la mateixa anàlisi; no n'hi ha prou amb ignorar-los ni amb donar-los per no quantificables.

El cas de negoci es manté viu: es revisa a les portes de fase (stage gates) i al tancament, on es contrasta el benefici realitzat amb el promès (gestió de la realització de beneficis).

Acta de constitució (project charter) ≠ cas de negoci: el cas de negoci justifica la inversió i és previ; l'acta autoritza el projecte i nomena el director. Tots dos són documents de negoci al PMBOK, juntament amb el pla de gestió de beneficis.


3. Anàlisi econòmica

Indicador Què és Regla de decisió
TCO (Total Cost of Ownership) cost total de propietat al llarg de tot el cicle de vida: adquisició, implantació, llicències, operació, suport, formació, energia, migració i retirada comparar alternatives amb el mateix horitzó temporal
ROI (Return On Investment) (benefici net − inversió) / inversió com més alt, millor; no té en compte el temps
VAN (Valor Actual Net) / NPV (Net Present Value) suma dels fluxos de caixa descomptats menys la inversió inicial VAN > 0 → el projecte crea valor
TIR (Taxa Interna de Retorn) / IRR (Internal Rate of Return) taxa de descompte que fa el VAN = 0 TIR > cost de capital → acceptable
Payback temps que triga la inversió a recuperar-se com més curt, millor; ignora el que passa després
Cost-efectivitat cost per unitat de resultat quan el benefici no es pot monetitzar típic al sector públic (cost per tràmit, per usuari atès)

CAPEX vs OPEX: la compra d'infraestructura és CAPEX (inversió amortitzable); el núvol i les subscripcions són OPEX (despesa corrent). El pas a núvol converteix CAPEX en OPEX, cosa que canvia el tractament pressupostari i el capítol del pressupost afectat.

Costos ocults que s'obliden i que els exàmens pregunten: migració de dades, integracions, formació, gestió del canvi, sortida del proveïdor i costos de sortida de dades (egress) al núvol.


4. La contractació pública com a marc

Al sector públic, la prospecció s'ha de fer sense vulnerar els principis de la LCSP (Llei de Contractes del Sector Públic, Llei 9/2017): llibertat d'accés a les licitacions, publicitat i transparència, no discriminació i igualtat de tracte, i eficient utilització dels fons destinada a la realització d'obres i a l'adquisició de béns i serveis mitjançant l'exigència de la definició prèvia de les necessitats a satisfer.

4.1 Consultes preliminars del mercat (LCSP, art. 115)

Definició literal: els òrgans de contractació poden realitzar estudis de mercat i dirigir consultes als operadors econòmics que estiguessin actius en aquest amb la finalitat de preparar correctament la licitació i informar els esmentats operadors econòmics sobre els seus plans i sobre els requisits que exigiran per concórrer al procediment.

Regles:

4.2 CPI (Compra Pública d'Innovació)

El concepte de compra pública d'innovació i les seves dues modalitats —CPP (Compra Pública Precomercial) i CPTI (Compra Pública de Tecnologia Innovadora)— es desenvolupen al tema 28. El que correspon a la prospecció és on encaixa cadascuna dins la LCSP:

4.3 El valor estimat del contracte (VEC)

El VEC (Valor Estimat del Contracte) és la xifra que decideix quin procediment s'ha de seguir i si el contracte està subjecte a regulació harmonitzada, i per això es pregunta amb números. Dues regles, totes dues a l'art. 101 de la LCSP, i totes dues contraintuïtives:

Un manteniment de tres anys prorrogable dos amb un VEC d'1.243.000 € vol dir 1.243.000 € sense IVA i cobrint els cinc anys (TS-TIC 2021, pràctica, s3-p14). Les opcions que hi afegeixen l'IVA o que el limiten als tres anys inicials són les dues trampes de la pregunta.

I al càlcul cal comptar-hi, com a mínim, els costos laborals, els d'execució material, les despeses generals d'estructura i el benefici industrial.

4.4 Racionalització tècnica: l'acord marc

Acord marc (LCSP, art. 219-222): instrument de racionalització tècnica de la contractació pel qual un o diversos òrgans de contractació fixen, en un únic procés, les condicions comunes —en particular preus i, si escau, quantitats— a què s'hauran d'ajustar els contractes que se'n derivin mentre l'acord estigui vigent. La seva durada màxima és de 4 anys, salvat excepció justificada; la dels contractes derivats és independent.

Si l'acord es va concloure amb una sola empresa, els contractes derivats s'adjudiquen directament en els termes ja fixats. Si es va concloure amb diverses, l'adjudicació pot fer-se sense nova licitació —si el plec de l'acord ho preveu i deixa totes les condicions definides— o amb una nova licitació restringida a les empreses que en són part.

El que no fa un acord marc:

4.5 Documentació administrativa i vinculació de l'oferta

Documentació acreditativa dels requisits previs (LCSP, art. 140): les empreses licitadores no aporten, d'entrada, la documentació completa de solvència. N'hi ha prou amb una declaració responsable, ajustada al formulari DEUC (Document Europeu Únic de Contractació), en què manifesten que compleixen els requisits de solvència econòmica, financera i tècnica exigits i que no estan incurses en prohibició de contractar. Només a l'empresa que ha presentat la millor oferta se li requereix, abans de l'adjudicació, la documentació acreditativa d'aquesta solvència, en un termini de 10 dies hàbils des de la recepció del requeriment (LCSP, art. 150.2).

La presentació de l'oferta vincula (LCSP, art. 139.1): presentar-la suposa l'acceptació incondicionada del contingut dels plecs, sense reserva. Un cop l'oferta resulta adjudicatària, tant els plecs com el contingut de la pròpia oferta —incloses les millores ofertes encara que no fossin objecte de valoració— passen a formar part del contracte: l'empresa no es pot desdir del que va oferir només perquè no va ser puntuat.

4.6 Contractació pública socialment responsable

L'Ajuntament de Barcelona incorpora a la compra pública municipal objectius de justícia social, sostenibilitat ambiental i codi ètic. El Decret d'Alcaldia de contractació pública sostenible (2017) dona validesa jurídica a la Guia de contractació pública social i a la Guia de contractació pública ambiental municipals.

Fase d'introducció de les mesures socials: la LCSP permet introduir-les indistintament, no exclusivament d'una manera:

Quota de reserva de discapacitat: l'article 42 del RDLeg (Reial Decret Legislatiu) 1/2013 —text refós de la Llei general de drets de les persones amb discapacitat i de la seva inclusió social— obliga les empreses de 50 o més treballadors a acreditar que, com a mínim, el 2 % de la seva plantilla té reconeguda una discapacitat.

4.7 Bones pràctiques en la compra pública TIC


5. Vigilància tecnològica i innovació

Hype Cycle de GartnerNo hi ha números darrere d'aquesta forma ni marques als eixos: anomena cinc llocs pels quals passa una tecnologia, en ordre. L'altiplà final queda per sota del pic.TempsExpectativesInnovation triggerPeak of inflated expectationsTrough of disillusionmentSlope of enlightenmentPlateau of productivity


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 4

Administració electrònica i serveis digitals

Enunciat oficial. Administració electrònica i serveis digitals: regulació de la relació electrònica amb les administracions públiques i del funcionament electrònic del sector públic, d'acord amb la Llei 39/2015, del procediment administratiu comú, i en la Llei 40/2015, de règim jurídic del sector públic.

Aquest tema comparteix matèria amb el tema 17 del bloc comú, que conté el desenvolupament complet de drets, expedient electrònic i model municipal. Aquí s'hi afegeix el que és específic de la vessant tècnica i municipal.


1. Els dos eixos normatius

Llei 39/2015 — relació amb la ciutadania Llei 40/2015 — funcionament intern i entre administracions
Regula capacitat d'obrar, representació, registres d'apoderaments, identificació i signatura dels interessats, drets, registre electrònic, notificacions, documents i còpies, arxiu electrònic únic, expedient electrònic seu electrònica, portal d'internet, actuació administrativa automatitzada, sistemes de signatura dels òrgans, intercanvi de dades en entorns tancats, reutilització de sistemes i aplicacions, relacions interadministratives
Articles clau 9–12, 13–14, 16, 26–27, 40–46, 53, 70 3, 38–46, 155–158

El desplegament reglamentari és el RD 203/2021, que concreta el Punt d'Accés General electrònic, les seus electròniques i seus associades, el directori d'aplicacions per a la reutilització, el registre electrònic general, les oficines d'assistència en matèria de registres, l'expedient, el document, les còpies autèntiques i l'arxiu electrònic únic.

La Llei 40/2015 és la llei de règim jurídic del sector públic, i d'aquest règim el tema en pren només la part electrònica: el funcionament del sector públic per mitjans electrònics —seu, signatura dels òrgans, actuació automatitzada, arxiu— i les relacions electròniques entre administracions —transmissió de dades, esquemes nacionals, reutilització d'aplicacions—. La resta del règim jurídic (òrgans, competència, delegació, convenis, sector públic institucional, responsabilitat patrimonial) no és matèria d'aquest tema. La mateixa llei fixa com a principi de tota relació interadministrativa la cooperació, la col·laboració i la coordinació (Llei 40/2015, art. 3): els serveis digitals integrats es construeixen entre administracions autònomes que col·laboren, no per centralització imposada ni per jerarquia.

1.1 Seu, portal, punt d'accés general i carpeta ciutadana

No són sinònims, i el tribunal els creua. Es distingeixen per qui n'és titular i quina garantia jurídica ofereixen:

Espai Què és Garantia
Seu electrònica (Llei 40/2015, art. 38) adreça electrònica disponible per a la ciutadania a través de xarxes de telecomunicacions, la titularitat de la qual correspon a una administració pública o als seus organismes en l'exercici de les seves competències el titular respon de la integritat, la veracitat i l'actualització de la informació i els serveis; és on es fan els tràmits i es consulten els expedients amb plena seguretat tecnològica i jurídica
Seu electrònica associada (RD 203/2021, art. 10) seu creada per raons tècniques o organitzatives sota una altra seu té la consideració de seu a tots els efectes
Portal d'internet (Llei 40/2015, art. 39) punt d'accés electrònic d'una administració que permet accedir a la informació publicada i, si escau, a la seu informa; no té la garantia jurídica reforçada de la seu
Punt d'Accés General electrònic (RD 203/2021, art. 7) la seu que concentra l'entrada al conjunt de serveis, tràmits i informació d'una administració i dels seus organismes cada administració té el seu; quan la pregunta contraposa el punt d'accés general a la seu d'un ajuntament, el que es demana és l'element d'abast general, no el municipal. També és on s'han de posar a disposició les notificacions
Carpeta ciutadana l'espai personal i autenticat de dins la seu on cada persona veu els seus expedients, notificacions i dades exigeix identificar-se amb un mitjà admès; no depèn ni d'estar empadronat ni de ser contribuent

2. Principis bàsics de l'administració electrònica

Els que es pregunten com a «principi bàsic»:


3. Els col·lectius obligats a relacionar-se electrònicament

Llei 39/2015, art. 14 — pregunta recurrent, sovint en negatiu («quins no estan obligats»):

Estan obligats en tot cas: les persones jurídiques; les entitats sense personalitat jurídica; els qui exerceixin una activitat professional per a la qual es requereixi col·legiació obligatòria, en els tràmits propis d'aquesta activitat (amb notaris i registradors expressament inclosos); els qui representin un interessat obligat; i els empleats públics per als tràmits que facin per raó de la seva condició.

No estan obligades les persones físiques que actuen a títol particular: poden triar el canal i canviar-lo en qualsevol moment. Reglamentàriament es pot establir l'obligació per a col·lectius de persones físiques que, per la seva capacitat econòmica, tècnica o dedicació professional, tinguin acreditat l'accés i disponibilitat dels mitjans.

Si un obligat presenta en paper, l'Administració li requereix l'esmena mitjançant presentació electrònica i la data de presentació vàlida és la de l'esmena (Llei 39/2015, art. 68.4).

El deure d'assistència és de l'Administració, no un dret que la ciutadania hagi d'exercir. L'art. 12 de la Llei 39/2015 no recomana: les administracions «hauran de garantir» que les persones interessades es puguin relacionar amb elles per mitjans electrònics, i per això han de posar a disposició els canals d'accés, els sistemes i les aplicacions que calguin. Poder triar el paper serveix de poc si ningú no ajuda a fer el tràmit electrònic: aquí és on la bretxa digital deixa de ser un problema de model i es converteix en una garantia jurídica exigible, que es concreta en tres peces —el dret a triar el canal (art. 14), l'assistència en l'ús de mitjans electrònics a les oficines de registre, i el funcionari habilitat que identifica i signa per qui no disposa dels mitjans, amb el seu consentiment exprés—. La conseqüència pràctica: si una persona amb dret a ser assistida no té els mitjans, la seva identificació o signatura pot ser vàlidament feta per un funcionari habilitat, no per «qualsevol» funcionari ni per una signatura presencial substitutòria.


4. Registre electrònic, apoderaments i notificació

Moment en què es practica una notificació electrònicaNo accedir-hi no evita la notificació: passats deu dies naturals es dona per rebutjada, amb els mateixos efectes que si s'hagués llegit.S'accedeix al contingut?Notificació posada adisposició a la seu electrònicaPracticada en elmoment de l'accésRebutjadaels mateixos efectesque practicadaSíNo, en 10 dies naturals


5. Identificació, signatura i actuació automatitzada


6. Interoperabilitat i reutilització

La base legal està a la Llei 40/2015: les administracions es transmeten les dades que necessiten per exercir les seves competències, sense demanar-les a la persona interessada (Llei 40/2015, art. 155); ho fan complint els dos esquemes nacionals, l'ENI i l'ENS (Llei 40/2015, art. 156) —el requisit tècnic que garanteix alhora seguretat i interoperabilitat, i que exigeix estàndards oberts, no formats tancats ni sistemes aïllats—; i poden fer-ho també per intercanvi electrònic de dades en entorns tancats de comunicació (Llei 40/2015, art. 44), on els documents circulen entre òrgans d'una mateixa administració o entre administracions que hi han convingut les condicions, amb validesa d'original.


7. La seguretat: l'ENS

L'ENS és el marc obligatori de seguretat de l'administració electrònica: categorització dels sistemes, anàlisi de riscos, declaració i política de seguretat, mesures de seguretat de l'annex II i auditoria. → tema 66, que s'estudia sencer perquè apareix als quatre àmbits funcionals.


8. Els serveis digitals de l'Ajuntament de Barcelona


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 5

Gestió de projectes (PMBOK v7): enfocament orientat al valor i adaptació al context

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Enfocament orientat al valor i adaptació al context (tailoring).

Avís d'edicions. El PMBOK (Project Management Body of Knowledge) és la guia de fonaments de la direcció de projectes del PMI (Project Management Institute). El programa oficial diu PMBOK v7, però bona part de les preguntes d'exàmens anteriors estan redactades sobre PMBOK v6 (grups de processos i àrees de coneixement). Cal saber les dues: la v7 per als principis i dominis, la v6 per a la terminologia de processos, entrades, eines i sortides.


1. Conceptes bàsics (comuns a v6 i v7)

El vocabulari d'aquest apartat no canvia entre la v6 i la v7, i és el que més s'ha preguntat. La clau és que projecte, programa i portafoli són tres nivells d'agrupació del treball, i la PMO no n'és cap: és l'estructura que els dona suport. El que separa els tres primers és què obliga a estar junt —res, en el projecte; la relació entre els components, en el programa; l'objectiu estratègic, en el portafoli—.


2. PMBOK v7: el canvi de paradigma

La setena edició (2021) abandona l'estructura de 49 processos en 5 grups i 10 àrees de coneixement i passa a un model basat en:

El focus passa del lliurament de l'entregable al lliurament de valor, i de l'orientació a processos a l'orientació a resultats.

2.1 Els 12 principis

  1. Ser un administrador diligent, respectuós i atent (stewardship).
  2. Crear un entorn de col·laboració de l'equip del projecte.
  3. Involucrar-se efectivament amb els interessats.
  4. Enfocar-se en el valor.
  5. Reconèixer, avaluar i respondre a les interaccions del sistema (pensament sistèmic).
  6. Demostrar comportaments de lideratge.
  7. Adaptar (tailoring) en funció del context.
  8. Incorporar la qualitat als processos i als entregables.
  9. Navegar en la complexitat.
  10. Optimitzar les respostes als riscos.
  11. Adoptar l'adaptabilitat i la resiliència.
  12. Permetre el canvi per assolir l'estat futur previst.

2.2 Els 8 dominis d'acompliment

Un domini d'acompliment és un grup d'activitats del projecte que la v7 tracta com una àrea de resultats: diu què cal aconseguir, no quin procés cal executar. La diferència amb la v6 no és de noms: els dominis no són fases ni grups de processos i no van l'un darrere l'altre. Els vuit operen alhora durant tot el projecte i s'influeixen entre si —una resposta a la incertesa canvia la planificació, i un canvi de planificació arriba al lliurament—. Un domini tampoc no és una àrea de coneixement: n'hi ha vuit i no deu, i no hi ha correspondència d'un a un.

Domini De què respon On es desenvolupa
Interessats (Stakeholders) relació de treball productiva amb els interessats i el seu acord amb els objectius interessades i comunicació
Equip (Team) propietat compartida, equip d'alt rendiment i lideratge distribuït entre els seus membres lideratge, equip i recursos
Enfocament de desenvolupament i cicle de vida enfocament coherent amb els entregables i cicle de vida que facilita la retroalimentació enfocaments i cicle de vida
Planificació avanç organitzat i coordinat, amb abast, cronograma, cost, recursos i qualitat integrats en un sol pla que s'actualitza planificació integrada
Treball del projecte acompliment eficient, processos apropiats a l'entorn, recursos i adquisicions ben gestionats i millora contínua gestió del treball
Lliurament (Delivery) entregables acceptats pels interessats que produeixen el valor previst i contribueixen als objectius de negoci aquest tema, apartat 3
Mesurament comprensió fiable de l'estat, dades utilitzables per decidir i accions oportunes rendiment, riscos i tancament
Incertesa consciència de l'entorn, anticipació d'amenaces i oportunitats i lliurament sense impactes greus per imprevistos rendiment, riscos i tancament

El domini «Lliurament» és el que enganxa amb la resta d'aquest tema, i el que més es confon amb «Treball del projecte». La distinció és neta: «Treball del projecte» respon de com es fa la feina; «Lliurament», de què s'obté i de si serveix —requisits, abast, qualitat i criteris d'acceptació convertits en resultats que algú accepta—. El vocabulari de la v6 amagava aquesta frontera, perquè allà tot cabia dins d'«execució».


3. L'enfocament orientat al valor

Sistema de lliurament de valor (value delivery system): conjunt d'activitats estratègiques —portafolis, programes, projectes, productes i operacions— orientades a construir, sostenir i avançar l'organització. El projecte no és un fi: és un component d'aquest sistema.

El sistema funciona amb informació que circula en els dos sentits. Cap avall, l'estratègia de l'organització fixa els objectius, el portafoli hi selecciona i prioritza la inversió, i els programes i projectes produeixen entregables que passen a operacions, que és on el valor es realitza de manera sostinguda. Cap amunt, l'acompliment i els beneficis realment obtinguts tornen a la direcció, que amb això reajusta l'estratègia i la cartera. La primera meitat d'aquest recorregut —com es decideix què entra al portafoli— es desenvolupa a planificació estratègica TIC.

Definicions que cauen:

Implicacions pràctiques: prioritzar per valor —WSJF (Weighted Shortest Job First) o MoSCoW—, lliurar de manera incremental per obtenir valor abans, mesurar resultats i no només compliment de cronograma, i cancel·lar un projecte que ja no aporta valor —una decisió correcta, no un fracàs.

Governança: el patrocinador (sponsor) és responsable del cas de negoci i de la realització dels beneficis; el director de projecte ho és del lliurament.


4. L'adaptació (tailoring)

Definició: l'adaptació deliberada de l'enfocament, la governança i els processos de direcció del projecte per fer-los més adequats a l'entorn donat i al treball a realitzar.

Per què s'adapta:

Què es pot adaptar: el cicle de vida i l'enfocament de desenvolupament, els processos (afegir, eliminar, combinar, ajustar la freqüència o el rigor), la governança (comitès, portes de fase, nivells d'aprovació), les persones (rols i estructura de l'equip), les eines, els mètodes i els artefactes (quins documents es fan i amb quin detall).

El que NO s'ha d'adaptar mai: els requisits legals, contractuals i normatius, ni els estàndards de seguretat obligatoris. En una administració pública això vol dir que la traçabilitat de l'expedient, la contractació, la protecció de dades i l'ENS (Esquema Nacional de Seguretat) no són negociables.

Procés d'adaptació (PMBOK v7):

  1. Seleccionar l'enfocament de desenvolupament inicial (predictiu, adaptatiu o híbrid).
  2. Adaptar-lo a l'organització: cultura, capacitats, maduresa, PMO, marc regulador.
  3. Adaptar-lo al projecte: mida, criticitat, durada, equip, grau d'incertesa i innovació, restriccions.
  4. Implementar la millora contínua: revisar l'adaptació a les retrospectives i ajustar-la.

El procés d'adaptació (tailoring) del PMBOK v7Quatre passos, i el quart torna sobre els altres tres: cada retrospectiva pot canviar l'enfocament, l'adaptació a l'organització o l'adaptació al projecte.1. Enfocament inicial4. Millora contínua2. Adaptar a l'organització3. Adaptar al projecteRevisió a les retrospectives

Factors que orienten l'adaptació: grau d'incertesa dels requisits, estabilitat de l'entorn, criticitat i risc, mida de l'equip i distribució geogràfica, maduresa organitzativa, exigències regulatòries i experiència prèvia amb tecnologies similars.


5. Nocions de PMBOK v6 que continuen caient

Cinc grups de processos — inici, planificació, execució, seguiment i control, tancament. Són grups de processos, no fases del projecte.

Deu àrees de coneixement: integració, abast, cronograma, costos, qualitat, recursos, comunicacions, riscos, adquisicions i interessats.

Documents de negoci del projecte: el cas de negoci i el pla de gestió de beneficis, tots dos anteriors al projecte i responsabilitat del patrocinador.

Acta de constitució del projecte (project charter): document emès per l'iniciador o patrocinador que autoritza formalment l'existència del projecte i confereix al director l'autoritat per aplicar-hi recursos. En surt del procés Desenvolupar l'acta de constitució, dins del grup d'inici i de l'àrea d'integració.

Els APO (Actius dels Processos de l'Organització) i els FAE (Factors Ambientals de l'Empresa): les dues entrades presents a gairebé tots els processos. Els APO són interns (plantilles, lliçons apreses, procediments); els FAE poden ser interns o externs (cultura, estructura, normativa, condicions de mercat).


Claus d'examen

Per recordar

Tema 6

Gestió de projectes (PMBOK v7): gestió d'interessades i comunicació estratègica

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Gestió d'interessades i comunicació estratègica.

Avís d'edicions. El PMBOK (Project Management Body of Knowledge) és la guia de fonaments de la direcció de projectes del PMI (Project Management Institute). El temari diu v7, però gairebé totes les preguntes que han caigut estan redactades sobre la v6: àrees de coneixement, processos i grups de processos. A la v7 aquesta matèria és el domini d'acompliment «Interessats» i no hi ha ni processos ni grups. Cal saber les dues i saber quina és quina: la v7 per als resultats esperats, la v6 per al vocabulari que es pregunta.


1. Qui és un interessat

1.1 La definició

Interessat (stakeholder): individu, grup o organització que pot afectar, veure's afectat o percebre's afectat per una decisió, activitat o resultat d'un projecte, programa o portafoli.

Els tres verbs hi són tots tres, i cadascun tanca una porta:

Tres precisions que els exàmens exploten:

1.2 Interessat, client, usuari i patrocinador no són el mateix

Tot són interessats, però no fan la mateixa cosa, i aquí és on es guanyen o es perden les preguntes de supòsit pràctic.

Figura Què fa que no faci cap altre
Patrocinador o espònsor (sponsor) proporciona recursos i suport, és la figura rellevant en l'aprovació de l'abast i de l'acta de constitució, i és responsable de l'èxit del projecte
Client qui encarrega i rep el resultat; accepta els entregables
Usuari qui farà servir el producte cada dia; sovint no és qui el paga
Director del projecte l'assigna l'organització executora per assolir els objectius; elabora els plans i el cronograma
Equip del projecte fa la feina; → Lideratge, equip i gestió de recursos
PMO (Project Management Office) estandarditza els processos de govern del projecte; no és qui aprova l'abast

La confusió clàssica: «interessat» no vol dir «qui hi guanya diners». Els adjudicataris d'una licitació són interessats, però també ho són els departaments que no hi cobren res.

1.3 Què aporta un interessat i què no li toca

Els interessats ajuden a determinar els requisits, les restriccions i els supòsits del projecte, i els entregables del producte. Aquesta és la seva aportació i és la que es pregunta.

El que no és seu:

I la conseqüència operativa, que ha caigut dues vegades amb el mateix format: els requisits i l'abast els determinen tots els interessats, no un sol directiu ni l'empresa adjudicatària. L'adjudicatari executa el que els departaments han demanat; la figura que té el paper rellevant en l'aprovació formal de l'abast de cada projecte conceptualitzat és l'espònsor o patrocinador, no el director del projecte ni l'equip.

Per què importa identificar-los tots. Un interessat que apareix tard porta requisits que arriben tard, i un requisit que arriba tard és una sol·licitud de canvi. Quan un projecte va bé en tot menys en el nombre de canvis, la causa més probable segons la guia no és falta de supervisió ni de recursos: és que no s'han identificat tots els implicats.


2. Els processos de la v6 i el domini de la v7

L'àrea de coneixement Gestió dels Interessats del Projecte de la v6 té quatre processos, un per grup de processos, i cadascun deixa un artefacte diferent. Saber quin artefacte surt de quin procés és la pregunta més repetida del tema.

Els processos d'interessats al llarg del projecteA cada fase del projecte, el procés d'interessats que hi correspon i la sortida que en surt. El cicle es repeteix periòdicament al llarg de tot el projecte.IniciPlanificacióExecucióSeguiment i controlProcésSortidaIdentificar elsinteressatsPlanificarl'involucramentGestionarl'involucramentMonitorarl'involucramentRegistre d'interessatsPla d'involucraciódels interessatsSol·licituds de canviInformació del'acomplimentes repeteix periòdicament al llarg de tot el projecte

Identificar els interessats és un dels dos únics processos del grup d'inici; l'altre és Desenvolupar l'acta de constitució del projecte. Es fa al principi i es repeteix periòdicament, perquè la comunitat d'interessats canvia.

A la v7 no hi ha ni àrees ni processos: hi ha el domini d'acompliment «Interessats», i el que es demana són resultats: una relació de treball productiva amb els interessats, el seu acord amb els objectius del projecte, i que creixin els interessats que hi donen suport mentre disminueixen els que s'hi oposen.

2.1 Registre, pla i matriu: quin document diu què

Els tres es confonen a propòsit a les opcions de resposta.

Si la pregunta demana on es troba el mètode de comunicació preferit d'una persona interessada, la resposta és el pla d'involucració, no el registre ni la matriu.

2.2 Gestionar i monitorar l'involucrament

Gestionar l'involucrament dels interessats és el procés de comunicar-se i treballar amb els interessats per satisfer les seves necessitats i expectatives, abordar els incidents i fomentar la participació adequada. El benefici clau és que permet al director del projecte incrementar el suport i minimitzar la resistència. Es porta a terme al llarg de tot el projecte, no en una fase concreta.

Eines: habilitats interpersonals i d'equip (gestió de conflictes, consciència cultural, negociació, observació i conversa, consciència política), habilitats de comunicació i regles bàsiques del terreny (ground rules).

Monitorar l'involucrament vigila les relacions i ajusta les estratègies quan deixen de funcionar.

2.3 Tendències i bones pràctiques

La v6 recull com a bones pràctiques, i han caigut com a tals:

Limitar el conjunt d'interessats als imprescindibles no és una bona pràctica: és la contrària.


3. Anàlisi i classificació dels interessats

3.1 Les graelles

Matriu poder/interès (Johnson i Scholes) — la més preguntada:

Interès baix Interès alt
Poder alt Mantenir satisfet Gestionar de prop (manage closely)
Poder baix Monitorar (esforç mínim) Mantenir informat

Altres graelles amb la mateixa lògica de dos eixos: poder/influència i influència/impacte. El cub d'interessats és la versió tridimensional (poder, interès i influència).

Model de prominència (salience) de Mitchell, Agle i Wood: classifica per poder, legitimitat i urgència. Qui té un sol atribut és latent, qui en té dos és expectant, i qui té els tres és definitiu i s'atén primer.

Direcció de la influència: cap amunt (alta direcció), cap avall (equip), cap enfora (grups externs, com la ciutadania o els proveïdors) i cap als costats (altres directors de projecte).

El mapa d'interessats és la representació visual del resultat de qualsevol d'aquestes anàlisis, i s'actualitza quan s'amplien els col·lectius identificats.

3.2 La matriu d'avaluació de l'involucrament

Compara el nivell actual (C, current) amb el desitjat (D, desired) per a cada interessat, en cinc nivells:

Desconeixedor (unaware) → Reticent (resistant) → Neutral → De suport (supportive) → Líder (leading)

La distància entre C i D és la bretxa, i és el que dispara les accions del pla d'involucració.


4. La comunicació al projecte

L'àrea de Gestió de les Comunicacions de la v6 té tres processos: Planificar la gestió de les comunicacions (planificació), Gestionar les comunicacions (execució) i Monitorar les comunicacions (seguiment i control). Compte amb la simetria: interessats en té quatre i comunicacions en té tres, perquè la comunicació no té procés d'inici.

4.1 El pla de gestió de les comunicacions

Ha de respondre, per a cada necessitat d'informació: qui la necessita, quina informació, quan i amb quina freqüència, en quin format, per quin canal, qui la produeix, qui l'autoritza i qui la rep. Inclou també el glossari, els fluxos d'escalada, les restriccions legals o de confidencialitat i el mètode d'actualització del pla.

La primera acció en preparar un pla de comunicació és definir el públic objectiu: sense saber a qui es parla no es pot decidir ni el contingut ni el canal ni la freqüència. Un estudi de mercat, contactar amb empreses de formació o enviar correus són activitats posteriors o directament alienes al pla.

4.2 Nombre de canals de comunicació

Fórmula: n(n−1)/2, on n és el nombre de persones. Amb 10 persones hi ha 45 canals; amb 11, 55. Passar de n a n+1 afegeix n canals nous.

4.3 Dimensions, mètodes i model

4.4 Les cinc C de la comunicació escrita

Qualitats que ha de tenir un document del projecte: correcta (gramàtica i ortografia), concisa (sense paraules sobreres), clara (propòsit i expressió adreçats a qui llegirà), coherent (flux lògic d'idees) i controlada (control del flux de paraules i idees, amb ajudes visuals i resums).


5. La comunicació estratègica

5.1 Què ha de fer una estratègia de comunicació, i què no

Ha de fer-ho des del principi i de manera contínua:

I el que no ha de fer, que és el que s'ha preguntat: posposar-se fins a la posada en producció. Comunicar només quan el sistema ja funciona deixa els interessats fora de tot el cicle de vida, converteix cada expectativa no satisfeta en un canvi tardà i destrueix la relació de treball que el domini «Interessats» demana com a resultat.

5.2 Segmentar l'audiència

El missatge s'adapta a qui el rep: el comitè de direcció vol impacte, risc i decisió; l'equip vol detall; la ciutadania vol claredat i servei.

I la comunicació i la formació d'un sistema es planifiquen pels grups que l'utilitzaran majoritàriament, no per qui el paga ni per qui el dirigeix. En una contractació per lots amb dos sistemes, cada lot té els seus destinataris propis: el sistema de tramitació interna es comunica i es forma als departaments de l'Ajuntament que hi tramiten, i el portal de licitadors, a les empreses proveïdores. Confondre els dos és la forma habitual de la pregunta.

5.3 Expectatives, satisfacció i línies base

La gestió d'expectatives comença el primer dia: es documenten supòsits i restriccions, s'acorda què no inclou l'abast i es renegocia explícitament quan alguna cosa canvia. → El tema de BRM (Business Relationship Management) desenvolupa la relació continuada amb l'usuari intern; aquí, l'expectativa dins d'un projecte, que té principi i final.

Complir les línies base no és el mateix que satisfer l'interessat. Un projecte pot estar dins de l'abast, el cronograma i el cost acordats i tenir el client descontent: això vol dir que l'expectativa i la línia base no coincideixen, i és un problema de comunicació, no de mesura. Quan passa —per exemple, quan hi ha relleu de direcció del projecte i l'òrgan de govern es queixa tot i que els indicadors són bons—, el primer que cal fer és reunir-se amb el client per entendre què espera. Recalcular línies base o renegociar el contracte abans de saber-ho és actuar sense diagnòstic.

Les mesures de l'avanç i els informes d'acompliment del treball, amb el valor guanyat, són del tema de rendiment, riscos i tancament; les línies base d'abast, cronograma i cost, del de planificació integrada.


6. L'interessat al sector públic

L'interessat públic té dues propietats que no té el privat: no s'escull i, a més, vota.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 7

Gestió de projectes (PMBOK v7): lideratge, equip i gestió de recursos

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Lideratge, equip i gestió de recursos.

Avís d'edicions. El PMBOK (Project Management Body of Knowledge) és la guia de fonaments de la direcció de projectes del PMI (Project Management Institute). El temari diu v7, però gairebé totes les preguntes que han caigut estan redactades sobre la v6: àrees de coneixement, processos i grups de processos —els de la taula de la secció 2—. A la v7 aquesta matèria és el domini d'acompliment «Equip», sense processos ni grups. Cal saber les dues: la v7 per als resultats esperats, la v6 per al vocabulari que es pregunta.


1. El domini d'acompliment «Equip»

Resultats esperats: propietat compartida, equip d'alt rendiment, i que tots els membres demostrin lideratge i altres competències rellevants.

Cultura d'equip: transparència, integritat, respecte, discurs positiu, suport, coratge i celebració de l'èxit. Es materialitza en les regles bàsiques del terreny (ground rules), acordades per l'equip i no imposades.


2. Els sis processos de recursos (v6)

Procés Grup Sortida principal
Planificar la gestió de recursos Planificació Pla de gestió de recursos, acta de constitució de l'equip (team charter)
Estimar els recursos de les activitats Planificació requisits de recursos, estructura de desglossament de recursos (RBS, Resource Breakdown Structure)
Adquirir recursos Execució assignacions de recursos físics i de l'equip, calendaris de recursos
Desenvolupar l'equip Execució avaluacions de l'acompliment de l'equip
Dirigir l'equip Execució sol·licituds de canvi
Controlar els recursos Seguiment i control informació d'acompliment del treball

Desenvolupar l'equip millora competències, interacció i ambient. Dirigir l'equip fa seguiment de l'acompliment, dona retroalimentació, resol incidents i gestiona canvis. Aquesta distinció es pregunta.

L'àrea cobreix dos tipus de recursos —els de l'equip (persones) i els físics o materials (equipament, instal·lacions, infraestructura, subministraments)—, però cada procés té el seu abast: desenvolupar i dirigir l'equip són de les persones, i controlar els recursos és el dedicat als físics i materials: compara el consum real amb el planificat, detecta escassetats, excedents o retards de subministrament, i corregeix les desviacions; el seguiment de l'acompliment de les persones el fa, en canvi, dirigir l'equip.

Acta de constitució de l'equip (team charter): document que estableix els valors, acords i pautes operatives de l'equip: valors compartits, pautes de comunicació, criteris i processos de presa de decisions, procés per resoldre conflictes, pautes per a les reunions i acords de l'equip. El crea l'equip, no el director en solitari.

Quan la composició de l'equip canvia —sortides, baixes inesperades o membres que passen a altres iniciatives sense substitució— el document que cal revisar és el pla de gestió de recursos: és on consten les necessitats de personal, i actualitzar-lo és el pas previ per decidir com es cobreix el buit i es continua el projecte amb la resta de l'equip.


3. Assignació de responsabilitats

Matriu d'assignació de responsabilitats (RAM, Responsibility Assignment Matrix), en la seva forma més coneguda la matriu RACI (Responsible, Accountable, Consulted, Informed):

Lletra Significat Regla
R — Responsible qui executa la tasca pot haver-hi més d'un
A — Accountable qui respon del resultat i aprova només un per tasca, sempre
C — Consulted a qui es consulta abans de decidir (comunicació bidireccional) pot haver-n'hi diversos
I — Informed a qui es manté informat del resultat (comunicació unidireccional) pot haver-n'hi diversos

La pregunta clàssica: quin rol està concentrat en una única persona? L'Accountable (A). Variants del model: RASCI (Responsible, Accountable, Support, Consulted, Informed), que afegeix la S — Support, qui aporta recursos i col·labora activament en l'execució i la posada en marxa sense ser-ne responsable ni haver-ne de respondre —no es confon amb la C, que només és consultada—; RACI-VS (Verify, Sign-off) i CAIRO (Consulted, Accountable, Informed, Responsible, Omitted — afegeix l'Out of the loop).

En un contracte, qui signa l'acceptació no és qui executa. A la RACI d'un contracte de desenvolupament, el cap de projecte del proveïdor respon dels informes de seguiment i de la gestió dels riscos, i ha d'estar informat dels plans de proves, però la conformitat última d'un lliurable la dona qui el valida: el client, el patrocinador o les persones usuàries, per mitjà del procés Validar l'Abast. Això és la regla d'aquest contracte, no una prohibició general del model: R i A són funcions diferents i poden recaure en la mateixa persona —dins d'un mateix equip sovint hi recauen—. El que la separació contractual impedeix és que l'A de l'execució sigui també l'A de l'acceptació, i confondre-les és la distractora habitual.

Altres formats: organigrama jeràrquic, estructura de desglossament de l'organització (OBS, Organizational Breakdown Structure), estructura de desglossament de recursos (RBS), descripcions de rols en format text i l'histograma de recursos: gràfic de barres que mostra la quantitat de recursos —persones o hores— emprats en cada període de temps; serveix per detectar sobreassignacions i anivellar la càrrega de treball.


4. Lideratge

Lideratge ≠ direcció (management): la direcció s'ocupa de fer les coses de manera correcta amb l'autoritat posicional (planificar, organitzar, controlar); el lideratge s'ocupa de fer les coses correctes guiant, motivant i influint mitjançant relacions.

Estils de lideratge:

Poder del director de projecte (French i Raven, ampliat al PMBOK): posicional o formal, de recompensa, coercitiu o de penalització, expert, referent o carismàtic, informacional, relacional, situacional, de pressió, basat en la culpa, persuasiu, evitatiu i ingratiatori. Els més efectius en projectes solen ser l'expert i el referent; el coercitiu és el menys recomanable.

Intel·ligència emocional (Goleman): autoconsciència, autoregulació, motivació, empatia i habilitats socials. És la competència més citada per predir l'èxit del director de projecte.

El triangle del talent del PMI: gestió de projectes tècnica, lideratge i gestió estratègica i de negoci (des de 2023 reformulat com ways of working, power skills i business acumen).


5. Desenvolupament de l'equip

5.1 Model de Tuckman

Formació (forming) → Turbulència (storming) → Normalització (norming) → Acompliment (performing) → Dissolució (adjourning).

Les fases no són irreversibles: un canvi de membres pot retornar l'equip a storming.

Model de TuckmanCinc fases en seqüència. No són irreversibles: un canvi de membres pot fer tornar l'equip a la turbulència.AdjourningFormingNormingPerformingStormingun canvi de membres pot tornar l'equip a storming

5.2 Teories de la motivació

Teoria Idea central
Maslow jerarquia de necessitats: fisiològiques, seguretat, socials/afiliació, estima/reconeixement, autorealització
Herzberg factors d'higiene (salari, condicions, supervisió, polítiques) eviten la insatisfacció però no motiven; els motivadors (assoliment, reconeixement, responsabilitat, creixement) sí
McGregor teoria X (les persones eviten el treball, cal control) vs teoria Y (les persones s'automotiven i busquen responsabilitat)
McClelland necessitats d'assoliment, poder i afiliació
Vroom (expectativa) motivació = expectativa × instrumentalitat × valència
Ouchi (teoria Z) ocupació estable, participació i responsabilitat col·lectiva

5.3 Altres eines


6. Gestió de conflictes

Les cinc tècniques (Thomas-Kilmann, tal com les recull el PMBOK), de menys a més desitjable:

Tècnica Descripció Resultat
Retirar / Eludir (withdraw/avoid) retirar-se de la situació o ajornar-la perdre-perdre; només vàlid si el tema és menor o cal temps
Suavitzar / Acomodar (smooth/accommodate) emfatitzar els punts d'acord i cedir en la pròpia posició per mantenir l'harmonia perdre-guanyar
Consensuar / Conciliar (compromise/reconcile) buscar solucions que aportin cert grau de satisfacció a totes les parts; totes cedeixen alguna cosa perdre-perdre parcial
Forçar / Dirigir (force/direct) imposar el propi punt de vista a costa dels altres guanyar-perdre; útil en emergències
Col·laborar / Resoldre el problema (collaborate/problem solve) incorporar múltiples punts de vista i perspectives, amb actitud col·laborativa i diàleg obert, per arribar a un consens i compromís reals guanyar-guanyar; és la tècnica preferida i la que dona solucions duradores

La pregunta típica: la tècnica que incorpora múltiples punts de vista i condueix al consens i al compromís és col·laborar / resoldre el problema. No la confonguis amb consensuar, on totes les parts cedeixen i ningú no queda plenament satisfet.

Rejilla de Thomas-KilmannAssertivitat contra cooperació. Sense marques als eixos: el que compta són les direccions, no els números.AssertivitatCooperacióSuavitzar / acomodarCol·laborar / resoldre el problemaConsensuar / conciliarRetirar / eludirForçar / dirigir

Font dels conflictes en projectes, per ordre de freqüència segons els estudis clàssics: cronogrames, prioritats, recursos, opinions tècniques, procediments administratius, cost i, en darrer lloc, personalitats.

Negociació: habilitat interpersonal per arribar a acords entre parts amb interessos diferents (abast, cost, prioritats, assignació de recursos). Es distingeix, com en la gestió de conflictes, entre una negociació distributiva (guanyar-perdre: es reparteix un pastís fix) i una negociació integrativa o col·laborativa (guanyar-guanyar: s'amplia el que hi ha a repartir buscant l'interès de totes dues parts), que és la que el PMBOK recomana com a preferent, en línia amb la tècnica de col·laborar / resoldre el problema vista més amunt.


7. Reconduir el rendiment d'una persona

Seqüència recomanada quan un membre de l'equip no rendeix o té una manera de treballar inadequada:

  1. Conversa privada i directa, amb fets concrets i no judicis de valor.
  2. Retroalimentació sobre l'impacte de la conducta en l'equip i el projecte.
  3. Acord d'un pla de millora amb objectius mesurables i termini.
  4. Suport: formació, mentoring, aparellament (pairing).
  5. Seguiment i reconeixement de la millora.
  6. Només si no hi ha millora, escalada al responsable funcional i, si escau, reassignació.

El registre també es pregunta, no només la seqüència. Situada en les dimensions de la comunicació —que desenvolupa tic/pmbok-interesadas-y-comunicacion—, aquesta primera conversa és informal i verbal: informal perquè no és un acte de projecte ni deixa constància documental, i verbal perquè el to i la resposta de l'altre són la meitat del que s'hi juga. Deixar-ho per escrit el primer dia, encara que sigui un correu privat, formalitza l'incident i el converteix en expedient abans d'haver intentat resoldre'l; la constància escrita arriba quan s'acorda el pla de millora (pas 3), no abans.

L'error habitual —i la resposta falsa dels exàmens— és començar per l'escalada, la sanció o la reassignació, o bé tractar el problema públicament davant l'equip.


8. Estructures organitzatives del projecte

L'estructura de l'organització on viu el projecte determina quanta autoritat té el director de projecte sobre l'equip i els recursos. El PMBOK ordena les estructures en un espectre, de menys a més autoritat del director:

Estructura Autoritat del director Qui controla el pressupost Dedicació del director
Funcional pràcticament nul·la el gerent funcional a temps parcial, com una tasca més
Matricial feble limitada, de coordinador o facilitador el gerent funcional a temps parcial
Matricial equilibrada baixa o moderada, compartida amb el gerent funcional mixta (compartida) a temps complet
Matricial forta moderada o alta majoritàriament el director a temps complet
Projectitzada alta, gairebé total el director a temps complet

La pregunta típica dona una descripció de l'equip —doble dependència, dedicació parcial o exclusiva, qui aprova el pressupost— i demana identificar l'estructura. A més matriu «forta», més s'assembla a una projectitzada; a més «feble», més s'assembla a una funcional.


Claus d'examen


Per recordar

Tema 8

Gestió de projectes (PMBOK v7): enfocaments de desenvolupament i cicle de vida

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Enfocaments de desenvolupament i cicle de vida del projecte (predictiu, àgil i híbrid).


1. Cicle de vida del projecte

Definició: sèrie de fases per les quals travessa un projecte des del seu inici fins al seu tancament. Les fases són generalment seqüencials i els seus noms i nombre es determinen segons les necessitats de gestió i control de l'organització.

El cicle de vida és del projecte, i un projecte és temporal —té principi i final definits— i produeix un resultat únic, que s'elabora de manera progressiva. La permanència no és mai una característica d'un projecte: allò que no s'acaba és una operació, no un projecte.

Estructura genèrica (PMBOK, Project Management Body of Knowledge, del PMI, Project Management Institute): inici del projecte → organització i preparació → execució del treball → tancament del projecte. Què hi passa, a cadascuna:

Característiques que cauen literalment:

Cost, dotació de personal i risc al llarg del cicle de vida Sobre les quatre fases (inici, organització i preparació, execució, tancament): la corba de cost i dotació de personal comença baixa, puja fins al màxim durant l'execució i cau ràpidament al tancament; la corba de risc i influència dels interessats comença alta i decreix de manera contínua fins al final. Inici Organització i preparació Execució Tancament Cost / dotació de personal Risc / influència dels interessats

1.1 Les fases i les portes de fase

Fase del projecte: conjunt d'activitats relacionades lògicament que culmina en la finalització d'un o més entregables. El nombre i el nom de les fases no estan fixats per cap norma: depenen del tipus de projecte, del control que en vulgui l'organització i del risc que s'hi assumeixi.

La transició entre fases es controla amb punts de revisió, portes de fase (phase gates, stage gates) o revisions de final de fase. Una porta de fase és una revisió on es decideix continuar a la fase següent, continuar amb modificacions o aturar el projecte; per aquesta última possibilitat també se'n diu punt de mort (kill point). No és una reunió de seguiment: qui hi decideix té autoritat per cancel·lar.

Les fases poden reflectir l'enfocament de desenvolupament que s'ha triat —predictiu, iteratiu, incremental, adaptatiu o híbrid—, i és per això que el cicle de vida i l'enfocament es tracten sempre junts (§2). La norma internacional de direcció de projectes s'aplica a qualsevol projecte, sigui quin sigui l'enfocament de lliurament i el model de cicle de vida: cap norma imposa un cicle únic ni un nombre de fases.

1.2 Tres cicles de vida que no són el mateix

Es confonen i es pregunten com a parell. Són tres contenidors encaixats, del més gran al més petit:

La direcció de la inclusió és el que es pregunta: un producte conté molts projectes, mai al revés. I el producte segueix viu quan el projecte que el va crear ja s'ha tancat: mantenir-lo és operació, no projecte.


2. Els enfocaments de desenvolupament

Enfocament de desenvolupament: mètode que es fa servir per crear i fer evolucionar el producte, servei o resultat durant el cicle de vida del projecte. El domini d'acompliment «Enfocament de desenvolupament i cicle de vida» de la v7 en tracta tres coses alhora, i les tres es poden preguntar separades:

  1. l'enfocament —com es construeix el producte (§2.1 a §2.4)—;
  2. la cadència de lliurament —cada quan s'entrega (§2.5)—;
  3. el cicle de vida —les fases que en resulten (§1)—.

Els resultats esperats del domini: enfocaments consistents amb els entregables, un cicle de vida que connecta el valor amb els interessats i lliuraments que faciliten la retroalimentació.

L'enunciat oficial en nomena tres —predictiu, àgil i híbrid—, que són els extrems i la barreja. L'espectre complet n'hi afegeix dos d'intermedis, l'iteratiu i l'incremental (§2.4), que és on el tribunal ha situat més d'una pregunta.

2.1 Predictiu (o en cascada, waterfall)

Fixa el què, el quan i el quant al començament i després en controla les desviacions. És l'enfocament de sempre a l'obra pública i a la infraestructura.

2.2 Adaptatiu o àgil

Fa el contrari: accepta que al principi no se sap prou i compra coneixement lliurant. Cada volta produeix alguna cosa que el client pot fer servir i opinar-ne, i aquesta opinió canvia el que es farà després.

2.3 Híbrid

Tria deliberadament què es fixa i què es deixa emergir dins d'un mateix projecte. No és un enfocament a mitges ni un àgil mal fet: es decideix apartat per apartat.

2.4 Iteratiu i incremental: el continu de cicles de vida

Entre el predictiu i l'àgil no hi ha un salt, hi ha un continu: predictiu → iteratiu → incremental → àgil. Els dos del mig es pregunten perquè es confonen entre si, i la manera de distingir-los no és la que sembla:

Cicle de vida Requisits Activitats Lliurament Objectiu
Predictiu fixos es fan una sola vegada per a tot el projecte un sol lliurament gestionar el cost
Iteratiu dinàmics es repeteixen fins que són correctes un sol lliurament correcció de la solució
Incremental dinàmics es fan una vegada per cada increment lliuraments freqüents i més petits rapidesa
Àgil dinàmics es repeteixen fins que són correctes lliuraments freqüents i petits valor per al client amb retroalimentació freqüent

El parany de la taula: l'iteratiu comparteix el lliurament únic amb el predictiu, no amb l'àgil. Iterar no vol dir entregar. El que separa la meitat de dalt de la de baix és el lliurament, no la repetició.

El continu de cicles de vida i el seu patró de lliurament Quatre línies de temps paral·leles. El predictiu no té cap iteració i acaba en un únic lliurament final. L'iteratiu té voltes de repetició al llarg del temps però també acaba en un únic lliurament final. L'incremental no dibuixa voltes i entrega quatre lliuraments repartits. L'àgil combina les dues coses: voltes de repetició i quatre lliuraments repartits. Predictiu Iteratiu Incremental Àgil temps → ■ lliurament ⌒ iteració

2.5 La cadència de lliurament

Cadència de lliurament: el moment i la freqüència amb què el projecte entrega els seus resultats. És la resposta a «entregues iteratives o entrega única», i té quatre formes:

La cadència està relacionada amb l'enfocament, però no és el mateix: el tipus d'entregable i l'enfocament triat condicionen quants lliuraments hi haurà i cada quan, i a la vegada la cadència condiciona com es tallen les fases del cicle de vida. Un projecte adaptatiu que construeix un sistema que només es pot posar en servei un cop segueix tenint lliurament únic cap enfora, encara que per dins iteri.

2.6 Com escollir l'enfocament

La tria no és una preferència de l'equip ni del director: es dedueix de les característiques del que s'ha de fer. La v7 les agrupa en tres famílies de variables:

Model Cynefin (Snowden) per decidir segons la complexitat del domini: clar/obvi (bones pràctiques, predictiu), complicat (bones pràctiques d'expert), complex (pràctiques emergents, àgil), caòtic (actuar primer) i confús.


3. El Manifest Àgil

Publicat el 2001 per disset professionals a Snowbird (Utah). Quatre valors —l'element de l'esquerra pesa més que el de la dreta, però els dos tenen valor:

Individus i interaccions sobre processos i eines. Programari funcionant sobre documentació exhaustiva. Col·laboració amb el client sobre negociació contractual. Resposta al canvi sobre seguir un pla.

Dotze principis. El primer, que és el que es pregunta com a «prioritat més important»:

«La nostra màxima prioritat és satisfer el client mitjançant el lliurament primerenc i continu de programari amb valor.»

La resta, resumits: acceptar els canvis de requisits fins i tot en fases avançades; lliurar programari funcional freqüentment (de dues setmanes a dos mesos, amb preferència pel període més curt); responsables de negoci i desenvolupadors treballen junts quotidianament; construir projectes al voltant d'individus motivats, donant-los l'entorn i el suport que necessiten i confiant que faran la feina; la conversa cara a cara és el mètode més eficient de transmetre informació; el programari funcionant és la mesura principal de progrés; els processos àgils promouen el desenvolupament sostenible a ritme constant indefinidament; l'atenció contínua a l'excel·lència tècnica i al bon disseny millora l'agilitat; la simplicitat —l'art de maximitzar la quantitat de treball no realitzat— és essencial; les millors arquitectures, requisits i dissenys emergeixen d'equips autoorganitzats; a intervals regulars l'equip reflexiona sobre com ser més efectiu i ajusta el seu comportament.

No són valors del manifest «documentació exhaustiva sobre programari funcionant» ni «seguir el pla sobre respondre al canvi»: les distractores solen invertir els parells.


4. Diferències clau entre predictiu i àgil

Predictiu Àgil
Requisits definits a l'inici i estables emergents, es refinen contínuament
Abast fix; varien temps i cost variable; es fixen temps i cost (time-boxing)
Lliurament una sola vegada, al final incremental i freqüent
Canvis es gestionen com a excepció, amb control de canvis s'esperen i es donen la benvinguda
Documentació extensa i formal la mínima suficient, prioritzant el producte
Client intervé a l'inici i a l'acceptació participa contínuament
Rol de direcció comandament i control facilitació i lideratge servidor
Mesura de progrés compliment del pla i percentatge d'avanç producte funcionant entregat
Equip especialitzat per fases multidisciplinari i autoorganitzat

Una diferència que es pregunta sovint: a l'àgil l'equip decideix com fer el treball; el director no assigna tasques individualment.


5. Contractació i sector públic


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 9

Gestió de projectes (PMBOK v7): planificació integrada

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Planificació integrada: abast, cronograma i costos.

Avís d'edicions. El marc d'aquest tema és la Guia del PMBOK (Project Management Body of Knowledge), del PMI (Project Management Institute). El temari diu PMBOK v7, però gairebé totes les preguntes d'exàmens anteriors estan redactades sobre la v6: processos, entrades, eines i sortides. La v7 (12 principis i 8 dominis d'acompliment) posa aquesta matèria dins del domini de Planificació; el vocabulari que es pregunta és el de la v6 i és el que desenvolupa aquest tema.


1. Què és la planificació integrada

Els tres àmbits de gestió —àrees de coneixement en el vocabulari de la v6— que responen a «què inclou el projecte, quan estarà i quant costa» són abast, cronograma i cost. Junts formen la triple restricció: per avaluar la viabilitat d'un projecte quant a requeriments a complir, terminis fixats i pressupost disponible cal considerar aquests tres i no uns altres. Modificar-ne un mou els altres dos, i per això la planificació és integrada.

On cauen aquests processos dins dels 5 grups de processos de la v6:

Elaboració progressiva: el pla es detalla a mesura que es disposa d'informació. La planificació gradual (rolling wave) en és l'aplicació pràctica: es planifica en detall el treball proper i a nivell alt el llunyà.


2. L'abast

2.1 Processos (v6)

Planificar la gestió de l'abast → Recopilar requisits → Definir l'abast → Crear l'EDT/WBS → Validar l'abast → Controlar l'abast. Els quatre primers són de planificació; els dos últims, de seguiment i control.

2.2 Recopilar requisits: eines i tècniques

Aquesta és la fase de presa de requeriments, i el tribunal hi pregunta quina tècnica s'aplica a cada situació. Les eines de la v6, agrupades com les agrupa la guia:

2.3 Documents de l'abast

2.4 L'EDT/WBS

EDT (Estructura de Descomposició del Treball) o WBS (Work Breakdown Structure): descomposició jeràrquica de l'abast total del treball a realitzar per l'equip del projecte per assolir els objectius i crear els entregables requerits. Estructurar el treball i desglossar-lo en tasques que després permetin avaluar terminis i costos associats és crear l'EDT, i pertany a la gestió de l'abast, dins del grup de planificació.

Característiques de gestió que s'hi recullen, i que el tribunal ha demanat literalment:

2.5 Validar i controlar


3. El cronograma

3.1 Processos (v6)

Planificar la gestió del cronograma → Definir les activitats → Seqüenciar les activitats → Estimar la durada de les activitats → Desenvolupar el cronograma → Controlar el cronograma.

Desenvolupar el cronograma és el procés que, partint de la ruta crítica i de les estimacions acordades amb l'equip, fixa les dates de calendari de cada activitat i produeix la línia base del cronograma. Seqüenciar només estableix l'ordre; les dates les posa desenvolupar.

3.2 Seqüenciació

PDM (Precedence Diagramming Method), o mètode de diagramació per precedència, construeix el diagrama de xarxa amb 4 relacions lògiques:

Avanç (lead): temps que una activitat successora s'avança respecte de la predecessora (valor negatiu). Retard (lag): temps que s'endarrereix.

Tipus de dependència —classificació diferent de les 4 relacions anteriors—: obligatòria (lògica dura, inherent al treball), discrecional (lògica tova, per bones pràctiques), externa i interna.

3.3 Estimació de durades

Els factors que determinen la durada d'una activitat són l'esforç requerit i la quantitat i disponibilitat dels recursos assignats a completar-la. Ni el pressupost ni l'espai físic no ho són directament.

Exemple resolt. Una fase de definició de requeriments amb 3 activitats seqüencials, amb durades en dies:

Activitat Optimista Més probable Pessimista tE beta
A 5 6 13 (5 + 24 + 13) / 6 = 7
B 7 10 19 (7 + 40 + 19) / 6 = 11
C 6 8 16 (6 + 32 + 16) / 6 = 9

Durada estimada total de la fase: 7 + 11 + 9 = 27 dies. Amb la mitjana simple sortiria 8 + 12 + 10 = 30, que és una de les respostes trampa.

3.4 El mètode de la ruta crítica

CPM (Critical Path Method), o mètode de la ruta crítica:

Com es resol a l'examen. Donada una taula de tasques amb la seva durada i la seva predecessora, es fa sempre igual: (1) es dibuixa el diagrama de xarxa; (2) s'enumeren tots els camins de l'inici al final; (3) se suma la durada de cadascun, en dies o en mesos; (4) el camí de suma més gran és el crític, i aquesta suma és la durada del projecte. La folgança d'un camí no crític és la diferència entre la seva suma i la del crític.

Diagrama de xarxa amb el camí crític marcatDos camins: A-B-D-E suma divuit setmanes i A-C-E en suma tretze. El crític és el llarg, marcat amb traç gruixut; C té cinc setmanes de folgança total, que és exactament la diferència.A3 set.B3 set.C6 set. · folgança total: 5 set.D8 set.E4 set.camí crític A-B-D-E = 18 setmanes

3.5 Compressió del cronograma

Quan el temps que requereix el projecte és més gran que el temps disponible, la resposta correcta no és treballar hores extres ni anunciar que no s'arriba: és determinar les opcions de compressió del cronograma i presentar-ne la resultant a qui decideix, amb el seu cost i el seu risc.

Optimització de recursos: anivellament de recursos (resource leveling), que ajusta el treball a la disponibilitat i pot allargar el camí crític, i estabilització de recursos (resource smoothing), que només fa servir la folgança i no modifica el camí crític.

Representacions: diagrama de Gantt (barres), diagrama de fites, diagrama de xarxa i cronograma de fites resum.


4. Els costos

4.1 Processos (v6)

Planificar la gestió dels costos → Estimar els costos → Determinar el pressupost → Controlar els costos.

Estimar els costos Determinar el pressupost
Què fa desenvolupa una aproximació dels recursos monetaris necessaris per completar CADA activitat suma els costos estimats de les activitats individuals o dels paquets de treball per establir una línia base de costos autoritzada
Benefici clau determina el cost monetari requerit per al treball determina la línia base contra la qual es pot monitorar i controlar l'acompliment
Sortida estimacions de costos, base de les estimacions línia base de costos, requisits de finançament del projecte

4.2 Estimar els costos

Les tècniques són les mateixes que per a les durades —anàloga, paramètrica, ascendent, per tres valors i judici d'experts—, aplicades a euros en comptes de a dies.

Al sector públic, la font de dades habitual per estimar la despesa és la consulta preliminar del mercat, prevista a l'art. 115 de la Llei de contractes del sector públic: es demana informació a les empreses del sector i, a partir de la resposta, s'estableix l'estimació. Si de la consulta surten un valor optimista, un de pessimista i un de més probable, la tècnica que s'està fent servir per concretar l'estimació és l'estimació per tres valors, no el judici d'experts ni l'estimació anàloga.

Exemple resolt. D'una consulta al mercat surten 150.000 € (optimista), 250.000 € (més probable) i 300.000 € (pessimista). Amb la distribució beta: (150.000 + 4 × 250.000 + 300.000) / 6 = 241.666,67 €.

4.3 El pressupost i les reserves

Estimacions de cost de les activitats
  + reserves de contingència          → línia base de costos (riscos CONEGUTS)
  + reserva de gestió                 → pressupost del projecte (riscos DESCONEGUTS)

4.4 Tipus de cost i control

Directes vs indirectes; fixos vs variables; costos de la qualitat (prevenció, avaluació, fallida interna, fallida externa); cost del cicle de vida, que inclou l'operació posterior. El cost enfonsat (sunk cost) no s'ha de tenir en compte en decidir si continuar un projecte.

Controlar els costos compara la despesa real amb la línia base amb la gestió del valor guanyat, EVM (Earned Value Management), que integra abast, cronograma i cost en un únic sistema de mesura. Les seves fórmules i índexs es desenvolupen al tema de mesura del rendiment, riscos i tancament.


5. La integració de les tres línies base


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 10

Gestió de projectes (PMBOK v7): gestió del treball del projecte

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Gestió del treball del projecte: execució, coordinació, qualitat i canvis.

Avís d'edicions. El marc d'aquest tema és la Guia del PMBOK (Project Management Body of Knowledge), del PMI (Project Management Institute). El temari demana la v7, d'on surt el domini d'acompliment Treball del projecte que obre el primer apartat; en canvi, les preguntes que han caigut estan redactades sobre els processos de la v6, i és aquest vocabulari el que cal saber-se.


1. El domini «Treball del projecte»

És un dels vuit dominis d'acompliment de la v7 —la taula completa dels vuit i qui desenvolupa cadascun és a enfocament orientat al valor i adaptació—, i respon de com es fa la feina. El domini veí, Lliurament, respon de què s'obté i de si serveix: aquesta és la frontera que el vocabulari de la v6 amagava, perquè allà tot cabia dins d'«execució».

Resultats esperats: acompliment eficient i efectiu, processos apropiats per al projecte i l'entorn, comunicació adequada amb els interessats, gestió eficient dels recursos físics, gestió eficaç de les adquisicions, millora contínua i gestió eficaç dels canvis.

Activitats: gestionar el flux de treball existent i el nou, eliminar els impediments (blockers), gestionar les reunions, mantenir el focus de l'equip, gestionar el coneixement i l'aprenentatge.

L'equilibri de les restriccions. El treball s'executa sotmès a restriccions que competeixen entre si —abast, cronograma, cost, qualitat, recursos i risc—, i les tres clàssiques són abast, temps i cost. Moure'n una mou les altres: acceptar més abast sense tocar cronograma ni pressupost es paga en qualitat o en risc. Quan el reequilibri afecta una línia base, el camí és una sol·licitud de canvi (apartat 5), no un acord informal; com es construeixen aquestes línies base és matèria de planificació integrada.


2. L'execució

El grup de processos d'execució de la v6 en té 10, i és on es gasta la major part del pressupost. Aquest tema en desenvolupa uns quants; la resta, els temes germans:

Procés d'execució (v6) On es desenvolupa
Dirigir i gestionar el treball del projecte · Gestionar el coneixement del projecte aquest tema, apartat 2
Gestionar la qualitat aquest tema, apartat 4
Efectuar les adquisicions aquest tema, apartat 3.2
Adquirir recursos · Desenvolupar l'equip · Dirigir l'equip lideratge, equip i recursos
Gestionar les comunicacions · Gestionar la participació dels interessats interessades i comunicació
Implementar les respostes als riscos rendiment, riscos i tancament

Dirigir i gestionar el treball del projecte (v6, integració, grup d'execució): liderar i portar a terme el treball definit al pla i implementar els canvis aprovats.

Sortides principals: entregables, dades d'acompliment del treball, registre d'incidents (issue log), sol·licituds de canvi i actualitzacions.

Gestionar el coneixement del projecte (integració, execució): utilitzar el coneixement existent i generar-ne de nou per assolir els objectius i contribuir a l'aprenentatge organitzatiu. Distingeix dos tipus de coneixement:

La sortida del procés és el registre de lliçons apreses, que s'ha d'alimentar durant tot el projecte i no només al final. Un cop escrites, les lliçons apreses són coneixement explícit, no tàcit: són precisament el coneixement que s'ha aconseguit codificar.

Els tres nivells de dades:

Nivell Què és On es genera
Dades d'acompliment del treball (work performance data) observacions i mesures en brut: dates d'inici reals, percentatges completats, costos reals, nombre de defectes Dirigir i gestionar el treball
Informació d'acompliment del treball (work performance information) dades analitzades i contextualitzades: estat dels entregables, estat d'implementació de canvis, previsions processos de control
Informes d'acompliment del treball (work performance reports) representació física o electrònica de la informació, agregada per generar decisions: informes d'estat, memòries, quadres de comandament Monitorar i controlar el treball

És una progressió: dades → informació → informes. La pregunta sol demanar quin nivell serveix per prendre decisions: els informes.

Progressió: dades, informació, informesTres coses diferents amb noms semblants, i cadascuna la produeix un procés diferent. Confondre-les és confondre el que es mesura amb el que s'explica.Dades d'acompliment del treballDirigir i gestionar el treballInformació d'acomplimentdel treballProcessos de controlInformes d'acompliment del treballMonitorar i controlar el treball

Registre d'incidents (issue log): recull les condicions o situacions actuals que poden impactar els objectius i que cal resoldre, amb responsable i data compromesa. Tres registres que es confonen i no són el mateix:

Registre Què hi entra Quan
d'incidents una condició que ja s'ha produït i bloqueja o amenaça el treball mentre dura
de riscos un esdeveniment futur i incert, amb probabilitat i impacte abans que passi
de canvis una sol·licitud formal que toca una línia base, amb el seu estat i la decisió quan es demana

Un incident es resol dins del pla vigent; només es converteix en sol·licitud de canvi si per resoldre'l cal moure una línia base. I el registre d'incidents no és el registre de lliçons apreses: aquell anota problemes oberts que algú ha de tancar; aquest, coneixement que serveix per a la resta del projecte i per als següents. Supòsit ≠ restricció: el supòsit es dona per cert sense prova; la restricció limita les opcions.


3. La coordinació

Coordinar és fer que encaixi la feina de persones, proveïdors i sistemes: reunions amb propòsit, contractes que diuen què s'espera de qui és de fora, i un sistema que serveixi la mateixa informació a tothom.

3.1 Les reunions i el llançament

Tipus: de llançament (kick-off), de seguiment, de comitè de direcció, tècniques i de tancament. Regles comunes: ordre del dia, participants adequats, durada limitada i acta amb acords i responsables.

La reunió de llançament és la que cau a l'examen, i sempre pel mateix:

3.2 Les adquisicions

Comprar o contractar de fora el que el projecte no farà per si mateix. Tres processos a la v6, un per grup:

  1. Planificar la gestió de les adquisicions (planificació): decidir què es compra i què es fa a casa, amb quin tipus de contracte i quins criteris de selecció.
  2. Efectuar les adquisicions (execució): obtenir respostes dels proveïdors, seleccionar-ne un i adjudicar el contracte.
  3. Controlar les adquisicions (seguiment i control): vigilar l'acompliment del contracte i tramitar-ne els canvis.
Família de contracte Com es paga Qui assumeix més risc
Preu fix: FFP (Firm Fixed Price), FPIF (Fixed Price Incentive Fee), preu fix amb EPA (Economic Price Adjustment) import tancat per un abast ben definit el venedor
Costos reemborsables: CPFF (Cost Plus Fixed Fee), CPIF (Cost Plus Incentive Fee), CPAF (Cost Plus Award Fee) costos reals més un honorari el comprador
T&M (Time and Materials, per temps i materials) preu unitari per hora o unitat, sense import total tancat d'entrada compartit; és el format híbrid

Al sector públic el marc jurídic no el tria el projecte: el mana la LCSP, amb els seus tipus de contracte, procediments d'adjudicació i plecs. La prospecció prèvia del mercat i el cas de negoci són de prospecció de solucions TIC.

3.3 El sistema d'informació i la configuració

Sistema d'informació per a la direcció de projectes (PMIS, Project Management Information System): eina de programació, gestió de la configuració, recollida i distribució d'informació i quadres de comandament. Serveix la informació; no substitueix la decisió del director.

Gestió de la configuració: identificació, control de versions, comptabilitat d'estat i auditoria dels elements de configuració. Al programari es concreta en el control de versions, la gestió de branques i la traçabilitat entre requisit, canvi i versió → desplegament continu i contenidors.


4. La qualitat

4.1 Processos (v6)

Planificar la gestió de la qualitat (planificació) → Gestionar la qualitat (execució) → Controlar la qualitat (seguiment i control).

La gestió de la qualitat s'aplica tant a la gestió del projecte com al producte que lliura: les dues coses, no una. No és, en canvi, gestionar la càrrega de l'equip —això és recursos— ni afegir funcionalitat —això és abast.

Planificar la gestió de la qualitat té com a sortida el pla de gestió de la qualitat: el component del pla per a la direcció del projecte que descriu com s'implementarà la política de qualitat de l'organització (responsabilitat, procediments, recursos, estàndards). En ser un pla subsidiari, si canvia durant el projecte, el que actualitza és el pla per a la direcció del projecte del qual forma part —no existeixen com a artefactes independents un «pla d'assegurament» ni un «pla de control» de la qualitat.

Gestionar la qualitat (assegurament) Controlar la qualitat
Objecte els processos els entregables
Pregunta fem les coses de la manera correcta? l'entregable compleix els requisits?
Orientació preventiva de detecció
Sortida informes de qualitat, sol·licituds de canvi mesures de control de qualitat, entregables verificats

Qualitat ≠ grau: la qualitat és el grau en què un conjunt de característiques inherents compleix els requisits; el grau és una categoria assignada a productes amb el mateix ús però diferents característiques tècniques. Un producte de baixa qualitat és sempre un problema; un producte de baix grau pot no ser-ho. I la qualitat no és l'excel·lència màxima costi el que costi: es mesura contra els requisits acordats, dins dels recursos disponibles.

Precisió (precision) = valors repetits agrupats; exactitud (accuracy) = proximitat al valor real. Prevenció (evitar l'error) és preferible a inspecció (detectar-lo).

Cost de la qualitat (COQ, Cost Of Quality), que és una tècnica de Planificar la gestió de la qualitat i no una eina de Controlar la qualitat:

4.2 Eines de qualitat

Les set eines bàsiques de la qualitat (Ishikawa):

  1. Diagrama causa-efecte o d'espina de peix o d'Ishikawa: descompon les causes possibles d'un problema en categories (les 6M: mà d'obra, màquina, mètode, material, medi, mesura). És la representació que ajuda a buscar la causa arrel; la tècnica analítica que la determina té nom propi i és l'anàlisi de causa arrel.
  2. Diagrames de flux o mapes de processos: mostren la seqüència de passos i les possibilitats de ramificació d'un procés que transforma una o més entrades en una o més sortides.
  3. Fulls de recopilació de dades (check sheets), també anomenats fulls de recompte: organitzen els fets de manera que faciliti la recollida efectiva de dades útils sobre un possible problema de qualitat, especialment comptant defectes per tipus mentre s'inspecciona.
  4. Diagrama de Pareto: histograma ordenat de major a menor freqüència que il·lustra la regla 80/20 —un nombre reduït de causes provoca la major part dels problemes.
  5. Histogrames.
  6. Diagrames de control: determinen si un procés és estable i té un acompliment previsible. Tenen línia central, límits de control superior i inferior (habitualment ±3σ) i límits d'especificació (definits pel client, sempre fora dels de control). Regla dels set: set punts consecutius al mateix costat de la mitjana indiquen que el procés està fora de control encara que estiguin dins dels límits.
  7. Diagrames de dispersió (correlació entre dues variables).

Full de recopilació de dades enfront de llista de verificació. Es tradueixen quasi igual i no són el mateix. El full (check sheet) compta defectes, com diu el punt 3. La llista de verificació (checklist) comprova passos: eina estructurada, normalment específica d'un component, que verifica que s'ha executat el conjunt de passos requerits i que ajuda a gestionar les activitats de qualitat d'una manera estructurada, perquè un defecte no es pugui atribuir a haver comprovat de maneres diferents.

Altres tècniques: anàlisi de causa arrel (RCA, Root Cause Analysis), que és la tècnica analítica per determinar el motiu subjacent bàsic que causa una variació, un defecte o un risc; anàlisi d'alternatives (comparar opcions); anàlisi de costos i beneficis; cost de la qualitat; benchmarking; disseny d'experiments (DOE, Design of Experiments); matrius de priorització; cinc per quès; auditories de qualitat i disseny per a X (DfX, Design for X).

Referents: Deming (cicle PDCA: Plan, Do, Check, Act; 14 punts; la qualitat es construeix, no s'inspecciona), Juran (trilogia: planificació, control i millora; adequació a l'ús), Crosby («zero defectes», la qualitat és gratis i el que costa és la no-qualitat), Ishikawa (cercles de qualitat), Six Sigma (DMAIC: Define, Measure, Analyze, Improve, Control).

ISO 9001 i els set principis de la gestió de la qualitat: enfocament al client, lideratge, compromís de les persones, enfocament a processos, millora, presa de decisions basada en l'evidència i gestió de les relacions. La norma entén l'organització com un conjunt de processos interrelacionats —el seu enfocament és a processos, no a producte ni a servei—, incorpora el pensament basat en el risc i el cicle PDCA. → qualitat del programari.

4.3 Validar l'abast enfront de Controlar la qualitat

Validar l'abast (v6, àmbit, seguiment i control): formalitza l'acceptació dels entregables completats. Es confon amb Controlar la qualitat perquè totes dues verifiquen l'entregable, però la diferència és qui i què:

Controlar la qualitat Validar l'abast
Verifica la correcció: compleix les especificacions? l'acceptació: el client el dona per bo?
Ho fa l'equip de projecte el client o el patrocinador, formalment
Entrada clau — entregables verificats (sortida de Controlar la qualitat)
Quan abans després de Controlar la qualitat

El seu benefici clau: aporta objectivitat al procés d'acceptació i n'incrementa la probabilitat, en oferir una oportunitat perquè apareguin diferències d'opinió entre client i equip abans que sigui massa tard per resoldre-les.


5. La gestió dels canvis

Realitzar el control integrat de canvis (v6, integració, seguiment i control): revisar totes les sol·licituds de canvi, aprovar-les, ajornar-les o rebutjar-les, gestionar els canvis als entregables, als actius dels processos, als documents del projecte i al pla per a la direcció del projecte, i comunicar-ne la decisió.

Quan s'aplica: des de l'inici del projecte fins al seu tancament, sense interrupció. No és una etapa ni una porta que s'obre en una fase: mentre el projecte existeix, qualsevol canvi de qualsevol línia base hi ha de passar. La responsabilitat última és del director del projecte.

Regla d'or: cap canvi a una línia base es pot fer sense una sol·licitud de canvi aprovada. El benefici clau és considerar el canvi de forma integrada, evitant que un canvi d'abast passi sense avaluar-ne l'impacte en cronograma, cost, qualitat i risc.

Procediment quan un interessat demana afegir una funcionalitat no prevista:

  1. No acceptar-la ni rebutjar-la sobre la marxa.
  2. Registrar-la com a sol·licitud de canvi formal.
  3. Avaluar-ne l'impacte en abast, cronograma, cost, qualitat, recursos i riscos.
  4. Sotmetre-la al Comitè de control de canvis (CCB, Change Control Board) o a l'autoritat que correspongui segons el pla de gestió de canvis.
  5. Si s'aprova, actualitzar tot el que descriu l'abast vigent —l'enunciat de l'abast, la línia base de l'abast i la matriu de traçabilitat de requisits— i comunicar-ho.
  6. Si es rebutja, documentar la decisió al registre de canvis.

Registre de canvis (change log): llista de totes les sol·licituds amb el seu estat i decisió. Anota la decisió, no la implementa: actualitzar-lo i seguir executant deixa l'abast desactualitzat.

Tipus de sol·licitud de canvi. «Sol·licitud de canvi» és el gènere; aquestes quatre en són espècies i s'han de saber distingir:

Als enfocaments àgils el canvi no passa per un CCB: entra a la pila de producte, el Product Owner el prioritza i s'incorpora en un sprint futur. Durant un sprint en curs, l'abast no es modifica.


6. Monitorar i controlar

Monitorar i controlar el treball del projecte: fer el seguiment, revisar i informar de l'avanç global per complir els objectius definits al pla. Comprèn comparar l'acompliment real amb el pla, avaluar l'acompliment per determinar si calen accions correctives o preventives, identificar riscos nous, mantenir una base d'informació precisa i actualitzada, proporcionar informació per als informes d'estat i previsions, i monitorar la implementació dels canvis aprovats.

Dels 12 processos del grup de seguiment i control de la v6, aquest tema en desenvolupa cinc: Monitorar i controlar el treball, Realitzar el control integrat de canvis, Controlar la qualitat, Validar l'abast i Controlar les adquisicions. Els d'abast, cronograma i cost són de planificació integrada; les mètriques i previsions, i amb elles el valor guanyat, de rendiment, riscos i tancament.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 11

Gestió de projectes (PMBOK v7): mesura del rendiment, riscos i tancament

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

Enunciat oficial. Gestió de projectes (PMBOK v7): Mesura del rendiment, riscos i incertesa, i tancament orientat a resultats.

Avís d'edicions. El marc d'aquest tema és la Guia del PMBOK (Project Management Body of Knowledge), del PMI (Project Management Institute). El temari demana la v7, que tracta aquesta matèria als dominis Mesura i Incertesa; les preguntes d'exàmens anteriors, però, fan servir el vocabulari de processos de la v6 —les fórmules de l'EVM són les mateixes a totes dues edicions—.


1. Mesura del rendiment: la gestió del valor guanyat (EVM, Earned Value Management)

L'Earned Value Management integra abast, cronograma i cost en un únic sistema de mesura.

1.1 Les tres variables base

Sigla Nom Què és
PV (Planned Value) valor planificat pressupost autoritzat assignat al treball planificat fins a la data
EV (Earned Value) valor guanyat pressupost associat al treball realment completat
AC (Actual Cost) cost real cost realment incorregut pel treball realitzat
BAC (Budget at Completion) pressupost a la conclusió suma total dels pressupostos, la línia base de costos completa

1.2 Variacions i índexs — memoritza les fórmules

CV  = EV − AC          variació del cost
SV  = EV − PV          variació del cronograma
CPI = EV / AC          índex d'acompliment del cost
SPI = EV / PV          índex d'acompliment del cronograma

Corba en S de l'EVM: PV, EV i ACTres acumulats en el temps, sense números: el que compta és com queden l'un respecte de l'altre. La separació vertical entre EV i AC és la variació del cost (CV); l'horitzontal entre EV i PV, la del cronograma (SV). Aquí l'EV va per sota de tots dos: tard i car.TempsAcumulatPVACEVCVSV

Interpretació de la SV (Schedule Variance, variació del cronograma), el CPI (Cost Performance Index, índex d'acompliment del cost) i el SPI (Schedule Performance Index, índex d'acompliment del cronograma) —la pregunta d'examen és sempre aquesta—:

Valor Significat
CV < 0 (negatiu) sobrecost: s'ha gastat més del pressupostat per al treball fet
CV > 0 estalvi respecte del pressupost
SV < 0 (negatiu) retard: s'ha fet menys treball del planificat
SV > 0 avançament
CPI < 1 sobrecost
CPI > 1 eficiència de cost favorable
SPI < 1 el projecte va endarrerit respecte del cronograma: s'ha completat menys treball del previst
SPI > 1 avançat

Fixa't que CV i SV negatius són dolents, i que CPI i SPI inferiors a 1 també. La regla mnemotècnica: negatiu i menor que u, malament.

1.3 Previsions

EAC = BAC / CPI                       si les desviacions actuals continuaran (cas típic)
EAC = AC + (BAC − EV)                 si les desviacions són atípiques i no es repetiran
EAC = AC + [(BAC − EV) / (CPI × SPI)] si cal considerar tots dos índexs
ETC = EAC − AC                        estimació fins a la conclusió
VAC = BAC − EAC                       variació a la conclusió
TCPI = (BAC − EV) / (BAC − AC)        índex de rendiment del treball per completar

EAC (Estimate at Completion, estimació a la conclusió) i VAC (Variance at Completion, variació a la conclusió) surten directament de BAC, AC i EV; el TCPI (To-Complete Performance Index, índex de rendiment del treball per completar) indica l'eficiència que cal mantenir en el treball restant.

TCPI > 1 vol dir que cal ser més eficient en el treball restant del que s'ha estat fins ara.

1.4 Altres mesures


2. Riscos i incertesa

2.1 Conceptes

Risc: esdeveniment o condició incerta que, si es produeix, té un efecte positiu o negatiu sobre un o més objectius del projecte. Els riscos poden ser amenaces (negatius) o oportunitats (positius).

2.2 Els set processos (v6)

  1. Planificar la gestió dels riscos → pla de gestió dels riscos (metodologia, rols, pressupost, calendari, categories de riscos / RBS (Risk Breakdown Structure), definicions de probabilitat i impacte, matriu de probabilitat i impacte, formats d'informe, seguiment).
  2. Identificar els riscos → registre de riscos i informe de riscos. Tècniques: pluja d'idees, llistes d'idees ràpides (prompt lists: PESTLE (Political, Economic, Social, Technological, Legal, Environmental), TECOP (Technical, Environmental, Commercial, Operational, Political) i VUCA (Volatility, Uncertainty, Complexity, Ambiguity)), llistes de verificació, entrevistes, anàlisi de causa arrel, anàlisi de supòsits i restriccions, anàlisi DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats) i anàlisi de documents.
  3. Realitzar l'anàlisi qualitativa dels riscos → prioritza els riscos per a l'anàlisi o acció posterior avaluant probabilitat d'ocurrència i impacte. Eines: matriu de probabilitat i impacte, avaluació de la qualitat de les dades sobre riscos, categorització de riscos, avaluació de la urgència, i representacions com el diagrama de bombolles. És ràpida i subjectiva.
  4. Realitzar l'anàlisi quantitativa dels riscos → analitza numèricament l'efecte combinat dels riscos identificats i altres fonts d'incertesa sobre els objectius generals del projecte. No es fa a tots els projectes. Eines: - Simulació de Monte Carlo: executa el model del projecte moltes vegades amb valors d'entrada mostrejats aleatòriament de distribucions de probabilitat, per obtenir una distribució de resultats possibles (per exemple, la probabilitat d'acabar en una data o dins d'un cost). És la resposta quan es pregunta pel mètode que simula múltiples escenaris i n'obté una distribució. - Anàlisi de sensibilitat, representada amb el diagrama de tornado, que determina quins riscos individuals tenen més impacte potencial sobre el resultat del projecte. - Anàlisi de l'arbre de decisions, amb el càlcul de l'EMV (Expected Monetary Value, valor monetari esperat) = probabilitat × impacte. - Diagrames d'influència i anàlisi mitjançant models de simulació del cronograma.
  5. Planificar la resposta als riscos.
  6. Implementar la resposta als riscos (grup d'execució — l'únic procés de riscos que hi és).
  7. Monitorar els riscos (seguiment i control).

La identificació és iterativa, no un acte únic de la planificació. Apareixen riscos nous a mesura que avança el projecte, així que la majoria dels riscos s'identifiquen repartits entre dos processos: Identificar els riscos (la identificació inicial) i Monitorar els riscos (la reidentificació contínua, dins del grup de seguiment i control) — no només al primer.

Pregunta clàssica: quin NO és un procés de la gestió de riscos? Sol aparèixer «controlar els riscos» amb la nomenclatura antiga o inventades com «avaluar els riscos». Els set noms exactes són els d'aquesta llista.

2.3 Estratègies de resposta

Planificar la resposta és un procés que es duu a terme al llarg de tot el projecte, no un tràmit inicial, i el seu principal benefici és identificar les formes adequades d'abordar el risc general del projecte i els riscos individuals.

La inversió que sempre cau. Unes respostes efectives i adequades redueixen al mínim les AMENACES individuals, maximitzen les OPORTUNITATS i redueixen l'exposició global al risc. La distractora ho intercanvia —«redueixen les oportunitats i maximitzen les amenaces»— i llavors afirma el contrari del que es busca.

Una resposta ben plantejada ha de ser adequada a la importància del risc, rendible respecte de les accions que exigeix, realista dins del context del projecte, acordada per totes les parts implicades i a càrrec d'una persona responsable.

Per a amenaces (riscos negatius):

Estratègia Descripció
Escalar el risc està fora de l'abast d'autoritat del director del projecte; es trasllada al nivell de programa, portafoli o organització. Un cop escalat, no es monitora més al registre del projecte
Evitar eliminar l'amenaça o protegir el projecte del seu impacte: canviar el pla, ampliar el cronograma, reduir l'abast, cancel·lar
Transferir traslladar la propietat de l'amenaça a un tercer: assegurances, avals, garanties, contractes a preu fix. Sol tenir una prima
Mitigar reduir la probabilitat i/o l'impacte a un llindar acceptable: prototipatge, redundància, més proves, proveïdor més fiable
Acceptar reconèixer el risc sense actuar-hi de manera proactiva. Activa (establir una reserva de contingència) o passiva (no fer res i tractar-lo si es materialitza)

Quan la millor estratègia és executar accions focalitzades a capgirar o disminuir la probabilitat o l'impacte, l'estratègia és mitigar. Si les accions eliminen completament l'amenaça, és evitar.

Per a oportunitats (riscos positius): escalar, explotar (assegurar que es produeixi), compartir (associar-se amb un tercer millor capacitat per capturar-la), millorar (augmentar-ne probabilitat o impacte) i acceptar.

Respostes de contingència: plans que només s'executen si es donen unes condicions definides (disparadors o triggers). El pla alternatiu (fallback plan) s'activa si la resposta principal no és efectiva. Els riscos residuals són els que queden després de la resposta; els riscos secundaris, els que sorgeixen com a conseqüència directa de la resposta.

Qui aprova la reserva que finança la resposta. La reserva de contingència cobreix els riscos coneguts i acceptats activament; forma part de la línia base de costos i la gestiona el director del projecte, sense aprovació addicional. La reserva de gestió cobreix els riscos desconeguts (unknown unknowns); queda fora de la línia base, dins del pressupost total del projecte, i la gestiona el patrocinador — usar-la exigeix la seva aprovació formal. La línia base de costos, el pressupost del projecte i aquesta distinció es desenvolupen a tic/pmbok-planificacion-integrada; aquí queda només qui en respon davant del risc.

2.4 Monitorar els riscos

Assegurar l'eficàcia del procés al llarg del projecte requereix:

La resposta a «què assegura l'eficàcia de monitorar els riscos al llarg del projecte» és la revisió i reavaluació periòdica i sistemàtica, no fer-ho una sola vegada a l'inici.


3. El tancament

Tancar el projecte o fase (v6, integració, grup de tancament): finalitzar totes les activitats per al projecte, fase o contracte. Beneficis clau: la informació del projecte s'arxiva, el treball planificat es completa i s'alliberen els recursos organitzacionals per emprendre nous esforços.

Activitats del tancament:

  1. Assegurar que s'ha completat tot el treball i que els entregables han estat acceptats formalment (procés Validar l'abast).
  2. Tancar els contractes i les adquisicions, amb el tancament administratiu i financer.
  3. Transferir el producte, servei o resultat a la unitat que l'ha d'operar i mantenir: aquesta és l'activitat crítica perquè el resultat sigui sostenible. Comprèn la documentació d'operació, la formació dels operadors, els acords de nivell de servei i el traspàs de la responsabilitat.
  4. Recopilar i registrar les lliçons apreses i incorporar-les al repositori de coneixement de l'organització.
  5. Mesurar la satisfacció dels interessats.
  6. Alliberar els recursos i reconèixer l'equip.
  7. Actualitzar els actius dels processos de l'organització.
  8. Elaborar l'informe final, que compara resultats amb objectius i documenta la realització dels beneficis.

Sortides: transferència del producte, servei o resultat final, informe final, actualitzacions dels actius dels processos de l'organització (registre de lliçons apreses, documents del projecte, documentació de tancament).

Pregunta d'examen: la sortida clau del procés de tancament que contribueix a l'organització és la transferència del producte final juntament amb les lliçons apreses. No forma part del tancament «executar les accions correctives pendents» ni «resoldre els incidents oberts»: això s'ha de fer abans, al seguiment i control.

Tancament anticipat: quan el projecte es cancel·la, també s'ha de tancar formalment, documentant els motius i l'estat en què queda el treball.


Claus d'examen

Per recordar

Tema 12

Metodologia àgil al BIT: Scrum@BIT

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

Enunciat oficial. Metodologia àgil a l'Institut Municipal Barcelona Innovació i Tecnologia (BIT): Scrum@BIT (marc, fases, rols, governança i artefactes).

Nomenclatura. L'IMI (Institut Municipal d'Informàtica) va passar a dir-se BIT (Barcelona Innovació i Tecnologia) el 28 de novembre de 2025. El document metodològic oficial encara es titula Scrum@IMI: tots dos noms poden aparèixer en un enunciat.


1. Scrum: el marc de referència

Definició de la Guia Scrum: Scrum és un marc de treball lleuger que ajuda persones, equips i organitzacions a generar valor a través de solucions adaptatives per a problemes complexos. No és una metodologia: és un marc intencionadament incomplet, que només defineix les parts necessàries per implementar la teoria Scrum.

Davant dels mètodes clàssics en cascada —abast tancat des del principi—, el que fa determinant Scrum és la necessitat de lliuraments parcials de funcionalitats desplegables a producció, que aportin valor a la persona usuària de manera progressiva, Sprint a Sprint.

Fonament: l'empirisme. El coneixement prové de l'experiència i les decisions es prenen sobre el que s'observa. Scrum és també lean: redueix el malbaratament i se centra en l'essencial.

1.1 Els tres pilars

Transparència — el procés i el treball emergent han de ser visibles tant per als qui executen com per als qui reben la feina. Inspecció — els artefactes i el progrés cap als objectius s'han d'inspeccionar amb freqüència i diligència per detectar variacions o problemes potencials. Adaptació — si algun aspecte del procés es desvia dels límits acceptables o el producte resultant és inacceptable, s'ha d'ajustar el procés o el material al més aviat possible.

1.2 Els cinc valors

Compromís, Focus, Obertura, Respecte i Coratge (Commitment, Focus, Openness, Respect, Courage). L'ús exitós de Scrum depèn de la capacitat de les persones de viure aquests cinc valors.

1.3 L'equip Scrum

Característiques que cauen literalment: l'Scrum Team és:

Tres responsabilitats (a la Guia Scrum 2020 ja no s'anomenen «rols»):

Product Owner Scrum Master Developers
Responsabilitat maximitzar el valor del producte resultant del treball de l'equip establir Scrum tal com es defineix a la Guia i l'eficàcia de l'equip; proposar, promoure i potenciar millores sobre la forma de treball i sobre l'equip crear un Increment utilitzable a cada Sprint
Sobre el backlog és responsable de la gestió eficaç del Product Backlog (la pila de producte): desenvolupar i comunicar explícitament l'Objectiu de Producte, crear i comunicar clarament els elements, ordenar-los i assegurar que el backlog és transparent, visible i comprès facilita, entrena i elimina impediments; tasques de coordinació de l'inici de l'Sprint: crear la pàgina d'informació de l'Sprint, avisar l'equip que comença i actualitzar les estadístiques de velocitat i capacitat fan el Sprint Backlog, hi apliquen la Definició d'Acabat, ajusten el pla diàriament i es responsabilitzen mútuament com a professionals
Persona una sola persona, no un comitè. Pot delegar la feina, però la responsabilitat continua sent seva una persona; líder servidor típicament 3–9 persones
Decisió perquè els seus criteris tinguin èxit, tota l'organització els ha de respectar; ningú no pot obligar l'equip a treballar en un requisit diferent — ningú els diu com convertir el backlog en increments

El que NO és funció del Product Owner: gestionar el pressupost del projecte, assignar tasques als desenvolupadors, dirigir tècnicament l'equip o fer d'interlocutor únic amb el proveïdor. La seva funció és el valor i el backlog.

1.4 Els cinc esdeveniments

Esdeveniment Durada màxima (Sprint d'1 mes) Propòsit
Sprint un mes o menys; és el contenidor de la resta crear consistència; no es fan canvis que posin en perill l'Objectiu de l'Sprint, la qualitat no baixa, el Product Backlog es refina segons calgui i l'abast es pot clarificar i renegociar amb el Product Owner
Sprint Planning màxim 8 hores tres temes: per què és valuós aquest Sprint (Objectiu de l'Sprint), què es pot fer (selecció d'elements del backlog), com es farà (pla)
Daily Scrum 15 minuts, cada dia, mateix lloc i hora inspeccionar el progrés cap a l'Objectiu de l'Sprint i adaptar el Sprint Backlog. És per als Developers; si el Product Owner o l'Scrum Master hi treballen activament hi participen com a Developers, però no és una reunió oberta a qualsevol interessat
Sprint Review màxim 4 hores inspeccionar el resultat amb els interessats i determinar futures adaptacions; és una sessió de treball, no una presentació. Hi assisteixen el Product Owner, l'Scrum Master, els Developers i les persones interessades clau que el Product Owner convida — no és una reunió tancada a l'Scrum Team
Sprint Retrospective màxim 3 hores planificar maneres d'augmentar la qualitat i l'eficàcia: inspeccionar com ha anat pel que fa a individus, interaccions, processos, eines i Definició d'Acabat, identificar què ha anat bé, quins problemes hi ha hagut i com s'han resolt (o no)

Un Sprint nou comença immediatament després de la finalització de l'anterior. Els Sprints més curts es poden fer servir per generar més cicles d'aprenentatge i limitar el risc. La durada del Sprint, un cop triada, es manté constant durant tot el projecte: si canvien les prioritats o s'incorpora feina no prevista, el que es replanifica és l'abast, mai el calendari.

Cancel·lació de l'Sprint: només el Product Owner té l'autoritat per cancel·lar un Sprint, i només si l'Objectiu de l'Sprint esdevé obsolet. Passa poques vegades.

Si el Product Owner vol incorporar feina no prevista en ple Sprint, l'Scrum Master facilita que sigui l'equip qui valori la capacitat i la disposició per assumir-la — no ho decideix unilateralment ni ho imposa; l'alternativa és esperar-se al Sprint següent o replanificar l'Sprint actual amb el Product Owner.

1.5 Els tres artefactes i els seus compromisos

Artefacte Què és Compromís
Product Backlog llista emergent i ordenada del que cal per millorar el producte; única font de treball de l'equip Objectiu de Producte (Product Goal)
Sprint Backlog l'Objectiu de l'Sprint (per què), el conjunt d'elements seleccionats (què) i el pla per lliurar l'Increment (com); és un pla fet pels Developers i per als Developers Objectiu de l'Sprint (Sprint Goal)
Increment pas concret cap a l'Objectiu de Producte; cada Increment és additiu i verificat; ha de ser utilitzable. Poden crear-se diversos Increments dins d'un Sprint Definició d'Acabat (Definition of Done)

1.6 Estimació i seguiment

Gràfic burn-down d'un SprintEl treball que queda cada dia, contra la recta que hauria seguit si tots els dies haguessin estat iguals. El repunt és el dia que hi va entrar feina nova, i la corba acaba per sobre de zero: l'equip va més lent del previst i, a més, ha crescut l'abast.Dies de l'SprintTreball restant (punts d'història)IdealRealtotalnova feinadia 1últim diaL'eix vertical va de 0 al total de punts compromesos.


2. Altres marcs àgils


3. Scrum@BIT: l'adaptació municipal

El Scrum@IMI és l'adaptació de Scrum al context de l'Institut. L'objectiu declarat és aprofitar els avantatges d'aquest conjunt de pràctiques i eines àgils en un entorn amb tres condicionants que Scrum «pur» no contempla:

  1. La feina la fan proveïdors externs adjudicataris de contractes públics, no una plantilla interna: quan la insuficiència de recursos humans propis coincideix amb un abast puntual i limitat, l'Ajuntament hi recorre per contractació pública en lloc d'ampliar plantilla.
  2. Hi ha procediment administratiu: expedients, fites contractuals, facturació i justificació.
  3. Hi ha múltiples àrees de negoci municipals com a demandants, i una cartera de projectes que s'ha de governar.

3.1 Aportacions del marc

3.2 Fases

El marc estructura el treball en fases que enllacen la vessant administrativa amb la iterativa:

  1. Iniciació / Descobriment: identificació de la necessitat, definició de la visió del producte, identificació dels usuaris, primera versió del backlog i estimació de gruix. És on es prepara la licitació o l'encàrrec.
  2. Planificació: constitució de l'equip, definició de la Definició d'Acabat, planificació de releases i de la primera onada de Sprints.
  3. Execució iterativa: Sprints amb els cinc esdeveniments, integració contínua i lliuraments incrementals.
  4. Lliurament i desplegament (release): pas a producció, formació, comunicació i traspàs a operació.
  5. Tancament: tancament administratiu i contractual, lliçons apreses i mesura del valor obtingut.

Frontera amb PMBOK: la fase d'Iniciació és quan, seguint la terminologia PMBOK (Project Management Body of Knowledge) del PMI (Project Management Institute), s'ha de disposar de l'acta de constitució del projecte (project charter). L'acta inclou, entre altres coses, el cas de negoci del projecte —per què val la pena fer-lo—; no hi porten encara ni una estratègia detallada de gestió de riscos, ni estimacions dels paquets de treball, ni estimacions detallades de recursos: aquest detall arriba després, a la planificació, quan ja hi ha acta i s'ha autoritzat el projecte.

3.3 Rols

Als tres de Scrum, el marc municipal hi afegeix o precisa:

3.4 Governança i contractació

3.5 Adopció obligatòria del marc

Un equip sense experiència prèvia al BIT ha d'adoptar el marc Scrum@IMI/BIT publicat per l'Institut, que és d'aplicació obligatòria per als proveïdors — no pot proposar la seva pròpia metodologia ni aplicar Scrum «de manual» ignorant el marc municipal.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 13

Gestió de la qualitat dels serveis TIC. Norma ISO 20000

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

Sense esquema, expressament

Enunciat oficial. Gestió de la qualitat del serveis TIC. Norma ISO 20000.


1. Qualitat aplicada als serveis TIC

Qualitat (ISO 9000): grau en què un conjunt de característiques inherents d'un objecte compleix els requisits.

Un servei TIC (Tecnologies de la Informació i la Comunicació) té particularitats respecte d'un producte: és intangible, es produeix i consumeix simultàniament, és variable i no s'emmagatzema. Per això la qualitat d'un servei es mesura sobre la percepció de l'usuari i sobre els nivells de servei acordats, no només sobre la conformitat tècnica.

Model SERVQUAL (cinc dimensions de la qualitat percebuda): fiabilitat, capacitat de resposta, seguretat, empatia i elements tangibles.

ISO 9001 i els set principis de la gestió de la qualitat: enfocament al client, lideratge, compromís de les persones, enfocament a processos, millora, presa de decisions basada en l'evidència i gestió de les relacions.


2. ISO/IEC 20000

Què és la ISO: la ISO (International Organization for Standardization) és una organització internacional no governamental i independent, formada pels organismes nacionals de normalització que hi participen de manera voluntària —a Espanya, l'UNE (Una Norma Espanyola), l'Asociación Española de Normalización—. Publica normes de consens voluntàries: no són obligatòries per si mateixes, només quan una llei o un contracte les incorpora. La IEC (International Electrotechnical Commission) n'és la contrapart en electrotècnia; per això moltes normes es codifiquen conjuntament com ISO/IEC, cas de la 20000.

Què és la ISO/IEC 20000: la norma internacional per als sistemes de gestió de serveis (SGS/SMS, Service Management System). És l'única norma certificable en gestió de serveis TI —ITIL (Information Technology Infrastructure Library) és un marc de bones pràctiques, no és certificable per a organitzacions, només per a persones.

Història: neix de la britànica BS (British Standard) 15000 (2000); primera edició ISO el 2005; segona el 2011; tercera edició: ISO/IEC 20000-1:2018, que adopta l'estructura d'alt nivell.

Parts principals:

Part Contingut
20000-1 Requisits del sistema de gestió de serveis. És la part certificable
20000-2 Guia per a l'aplicació dels sistemes de gestió de serveis
20000-3 Guia sobre la definició de l'abast i l'aplicabilitat
20000-5 Pla d'implementació exemplar
20000-6 Requisits per als organismes d'auditoria i certificació
20000-10 Conceptes i vocabulari

2.1 Estructura de la ISO/IEC 20000-1:2018

Segueix l'Annex SL:

2.2 La millora contínua a la ISO/IEC 20000

Afirmació correcta que cauen a l'examen: la norma exigeix que l'organització determini i seleccioni oportunitats de millora, i estableixi criteris d'avaluació i priorització de les millores; les millores s'han de registrar, avaluar, aprovar, prioritzar, planificar, implementar, mesurar i informar. La millora contínua és un requisit del sistema de gestió, no una recomanació opcional, i s'aplica tant al SGS com als serveis.

Compte amb les distractores: la norma no diu que la millora contínua sigui responsabilitat exclusiva de la direcció, ni que només s'apliqui als processos i no als serveis, ni que requereixi una certificació anual.

2.3 Gestió de la disponibilitat a la ISO/IEC 20000

La norma exigeix determinar i documentar els requisits de disponibilitat i els objectius a partir de les necessitats de negoci, mesurar la disponibilitat dels serveis, investigar la indisponibilitat no planificada i emprendre les accions necessàries. La disponibilitat s'ha de monitorar i registrar, i els resultats s'han de comparar amb els objectius acordats. → tema 21.

2.4 Certificació


3. Relació entre ISO 20000, ITIL i altres marcs

ISO/IEC 20000 ITIL COBIT
Naturalesa norma certificable marc de bones pràctiques marc de govern i gestió de la TI
Diu què s'ha de complir (requisits) com fer-ho (guia) què s'ha de governar i com mesurar-ho
Certificació d'organitzacions de persones de persones
Propietari ISO/IEC PeopleCert / Axelos ISACA (Information Systems Audit and Control Association)

Altres normes de la família: ISO/IEC 27001 (seguretat de la informació), ISO 22301 (continuïtat de negoci), ISO/IEC 19770 (gestió d'actius de programari), ISO/IEC 33000 (avaluació de processos, successora de la 15504/SPICE, Software Process Improvement and Capability dEtermination), ISO/IEC 12207 (cicle de vida del programari) i ISO/IEC 25010 (qualitat del producte programari) → tema 46.

Marcs de gestió de serveis digitals que sí que ho són: ITIL, ISO/IEC 20000, COBIT (Control Objectives for Information and Related Technologies), FitSM, MOF (Microsoft Operations Framework), USM (Unified Service Management), VeriSM. No ho són: PMBOK (Project Management Body of Knowledge: direcció de projectes), CMMI (Capability Maturity Model Integration: maduresa de processos de desenvolupament), TOGAF (The Open Group Architecture Framework: arquitectura empresarial), Scrum (marc de desenvolupament de producte) ni Six Sigma (millora de la qualitat). Aquesta és la pregunta «quin NO pot ser considerat un marc de treball de la gestió de serveis digitals».


4. La qualitat dels processos i dels productes

Principi que es pregunta literalment: la qualitat dels productes i serveis està altament influïda per la qualitat dels processos que els produeixen. D'aquí surten els models de maduresa de processos (CMMI, ISO/IEC 33000) i l'enfocament a processos de la ISO 9001.

Enfocament a processos: entendre i gestionar els processos interrelacionats com un sistema contribueix a l'eficàcia i eficiència en l'assoliment dels resultats previstos. Cada procés té entrades, transformació, sortides, propietari, indicadors i controls; el conjunt es representa al mapa de processos → tema 1.

Classificació habitual dels processos: estratègics, fonamentals o clau i de suport —les definicions de cadascuna, al mapa de processos del tema 1.

Auditories: internes (de primera part), de segona part (client sobre proveïdor) i de tercera part (organisme de certificació independent). Cal independència de l'auditor respecte de l'activitat auditada.


Claus d'examen


Per recordar

Tema 14

Gestió de serveis TIC. Marc ITIL v4

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

Enunciat oficial. Gestió de serveis TIC. Marc ITIL v4: conceptes fonamentals, sistema de valor del servei i cadena de valor.

Avís d'edicions. El programa oficial demana ITIL v4, però la major part de les preguntes d'exàmens anteriors —14 de les 25 d'aquest tema, i n'hi ha de 2018, 2021, 2023 i 2025— està redactada sobre ITIL v3, amb el seu cicle de vida de cinc fases i les seves publicacions. Cal saber les dues.


1. Conceptes fonamentals d'ITIL 4

Gestió de serveis (service management): conjunt de capacitats organitzatives especialitzades per generar valor per als clients en forma de serveis. És la definició canònica d'ITIL i cau literalment. La paraula que la sosté és capacitats: no és una unitat organitzativa —això és una funció—, ni una seqüència d'activitats —això és un procés—, ni la direcció de projectes (§1.5). La disciplina que l'aplica a la informàtica s'anomena ITSM (Information Technology Service Management, gestió de serveis de TI), i ITIL n'és el marc de referència més estès.

ITIL no és una norma d'obligat compliment, sinó un marc de bones pràctiques: un conjunt de recomanacions que cada organització ha d'adaptar a les seves necessitats i particularitats, no a l'inrevés. És el principi conegut com «adopt and adapt» (adoptar i adaptar). ITIL no defineix cap «Core Rules» d'obligat compliment per certificar-se: la certificació és de persones, no d'organitzacions.

Origen: ITIL va néixer al Regne Unit a finals dels anys vuitanta, encarregat per la CCTA (Central Computer and Telecommunications Agency), l'agència informàtica del govern britànic, per millorar la qualitat dels seus serveis de TI. Ni va néixer als Estats Units ni és una metodologia.

No tots els marcs de referència fan el mateix, i el tribunal ho aprofita: ITIL i la norma ISO 20000 són marcs de gestió de serveis (→ tema 13), COBIT és de govern de la TI (→ tema 15) i el CMMI (Capability Maturity Model Integration) mesura la maduresa dels processos (→ tema 22). En canvi Scrum és un marc àgil de desenvolupament de programari, no un marc de gestió de serveis (→ tema 12).

1.1 Servei, valor, utilitat i garantia

1.2 Organitzacions i persones

1.3 Les quatre dimensions de la gestió de serveis

Les quatre s'han de considerar totes per a cada servei; ignorar-ne una degrada el resultat:

  1. Organitzacions i persones — estructura, cultura, competències, rols.
  2. Informació i tecnologia — la informació que es gestiona i les tecnologies que la suporten.
  3. Socis i proveïdors — relacions amb tercers, contractes, integració.
  4. Fluxos de valor i processos — com s'organitzen les activitats per crear valor.

Al voltant hi actuen els factors PESTLE (polítics, econòmics, socials, tecnològics, legals i ambientals).

No s'han de confondre amb els set principis guia (§1.4): les dimensions diuen què s'ha de mirar en cada servei; els principis, com s'ha de decidir. Són quatre i set, i són llistes independents.

1.4 Els set principis guia

Principi guia: recomanació que guia l'organització en qualsevol circumstància, independentment dels canvis en els seus objectius, estratègies, tipus de treball o estructura de gestió. Són universals i perdurables, i apliquen a qualsevol iniciativa:

  1. Enfocar-se en el valor.
  2. Començar on ets (start where you are): no descartis el que ja existeix sense mesurar-ho.
  3. Progressar iterativament amb retroalimentació.
  4. Col·laborar i promoure la visibilitat.
  5. Pensar i treballar de manera holística.
  6. Mantenir-ho senzill i pràctic.
  7. Optimitzar i automatitzar — optimitza primer, automatitza després.

1.5 Pràctica, procés i funció

Les tres paraules descriuen «una manera d'organitzar el treball» i no són sinònimes. Les dues primeres són, a més, els distractors amb què el tribunal construeix la pregunta de què és la gestió de serveis.

Definició Quantes i a quina versió
Procés conjunt estructurat d'activitats dissenyat per assolir un objectiu concret, que pren una o més entrades definides i les converteix en sortides definides 26 a ITIL v3; ITIL 4 el conserva dins de les pràctiques, però ja no hi organitza el marc
Funció equip o grup de persones, amb les eines i els altres recursos que fan servir, per dur a terme un o més processos o activitats — és una unitat organitzativa 4 a ITIL v3 (service desk, gestió tècnica, gestió d'operacions de TI i gestió d'aplicacions); ITIL 4 elimina la paraula
Pràctica conjunt de recursos organitzatius dissenyat per realitzar un treball o assolir un objectiu 34 a ITIL 4, i substitueixen els 26 processos i les 4 funcions de v3

La diferència que importa: una pràctica és més ampla que un procés, perquè es descriu amb les quatre dimensions —hi entren les persones, la informació i la tecnologia, i els socis, no només les activitats—; un procés és només la seqüència d'activitats, i una funció, només qui les fa. Per això el service desk és una funció a v3 i una pràctica a ITIL 4 → tema 25.


2. SVS: el Sistema de Valor del Servei

Definició: descriu com tots els components i activitats de l'organització treballen conjuntament com un sistema per possibilitar la creació de valor. L'entrada és la demanda i les oportunitats; la sortida, el valor.

Components del SVS:

Component Què és
Principis guia els set anteriors
Governança el mitjà pel qual l'organització és dirigida i controlada
Cadena de valor del servei el model operatiu central, amb sis activitats
Pràctiques els 34 conjunts de recursos organitzatius per realitzar treball
Millora contínua activitat recurrent a tots els nivells

L'SVS ha de contrarestar els sitges (silos): la seva arquitectura està dissenyada perquè l'organització sigui flexible i adaptable.

SVS i cadena de valor no són el mateix, i confondre'ls és la trampa més barata del tema: el SVS és el sistema sencer —principis guia, governança, pràctiques i millora contínua incloses—, i la cadena de valor n'és un component, el model operatiu de sis activitats que hi ha al centre (§3).

I l'SVS no és el cicle de vida de v3: aquell eren cinc fases en ordre (§5.1) i aquest és un sistema sense seqüència. ITIL 4 va substituir l'un per l'altre.


3. La cadena de valor del servei

Definició: model operatiu que enumera les activitats clau necessàries per respondre a la demanda i facilitar la realització de valor mitjançant la creació i la gestió de productes i serveis. És el component central del SVS.

Sis activitats. No són una seqüència fixa: es combinen en fluxos de valor diferents segons l'escenari.

La cadena de valor del serveiSis activitats sense ordre fix: qualsevol d'elles pot cridar-ne una altra. Entra la demanda, surt el valor.Demanda i oportunitatsDissenyar i transicionarInvolucrarLliurar i donar suportMillorarObtenir i construirPlanificarValor

Activitat Propòsit
Planificar (Plan) assegurar una comprensió compartida de la visió, l'estat actual i la direcció de millora per a les quatre dimensions i per a tots els productes i serveis
Millorar (Improve) assegurar la millora contínua de productes, serveis i pràctiques a través de totes les activitats de la cadena de valor i de les quatre dimensions
Involucrar (Engage) proporcionar una bona comprensió de les necessitats dels interessats, transparència, i compromís i relacions contínues amb tots ells
Dissenyar i transicionar (Design & Transition) assegurar que els productes i serveis compleixen contínuament les expectatives de qualitat, cost i temps de comercialització
Obtenir/construir (Obtain/Build) assegurar que els components del servei estan disponibles quan i on calen i que compleixen les especificacions acordades
Lliurar i donar suport (Deliver & Support) assegurar que els serveis es lliuren i se'n dona suport d'acord amb les especificacions acordades i les expectatives dels interessats

Flux de valor (value stream): sèrie de passos que una organització realitza per crear i lliurar productes i serveis als consumidors. Cada flux combina activitats de la cadena i pràctiques diferents.

Cadena i flux no són el mateix: la cadena és el model —les sis activitats disponibles, sempre les mateixes i per a tota l'organització—; el flux és un recorregut concret per aquest model per a un escenari determinat —donar d'alta un empleat, resoldre una incidència, publicar una versió—, i decideix quines activitats hi entren, amb quines pràctiques i en quin ordre. Una sola cadena de valor sosté molts fluxos de valor.


4. Les 34 pràctiques d'ITIL 4

Pràctica: conjunt de recursos organitzatius dissenyat per realitzar un treball o assolir un objectiu (§1.5). Substitueixen els 26 processos i les 4 funcions d'ITIL v3. Es divideixen en tres grups:

Pràctiques de gestió general (14): gestió de l'arquitectura, millora contínua, gestió de la seguretat de la informació, gestió del coneixement, mesura i informes, gestió del canvi organitzatiu, gestió de la cartera (portfolio), gestió de projectes, gestió de relacions, gestió de riscos, gestió financera del servei, gestió de l'estratègia, gestió de proveïdors, gestió del talent i de la força de treball.

Pràctiques de gestió del servei (17): gestió de la disponibilitat, anàlisi de negoci, gestió de la capacitat i el rendiment, gestió de canvis (Change enablement), gestió d'incidents, gestió d'actius de TI (Tecnologies de la Informació), monitoratge i gestió d'esdeveniments, gestió de problemes, gestió de versions (release), gestió del catàleg de serveis, gestió de la configuració del servei, gestió de la continuïtat del servei, disseny del servei, service desk, gestió de nivells de servei, gestió de peticions de servei, validació i proves del servei.

Pràctiques de gestió tècnica (3): gestió del desplegament, gestió d'infraestructura i plataformes, desenvolupament i gestió de programari.

Estructura d'una pràctica: propòsit, termes i conceptes, abast, PSF (Practice Success Factors, factors d'èxit de la pràctica), KPI (Key Performance Indicators, indicadors clau de rendiment), fluxos de valor i processos, organitzacions i persones, informació i tecnologia, socis i proveïdors.


5. ITIL v3: el que continua caient

5.1 El cicle de vida del servei

Cinc fases, en aquest ordre — és una pregunta literal habitual:

1. Estratègia del Servei (Service Strategy) → 2. Disseny del Servei (Service Design) → 3. Transició del Servei (Service Transition) → 4. Operació del Servei (Service Operation) → 5. Millora Contínua del Servei (Continual Service Improvement, CSI)

El nucli d'ITIL v3 es compon de cinc publicacions, una per fase, que proporcionen la guia necessària per a un enfocament integrat.

Fase Propòsit Processos principals
Estratègia definir la perspectiva, posició, plans i patrons que un proveïdor ha d'executar per assolir els resultats de negoci del client gestió de l'estratègia, gestió de la cartera de serveis, gestió financera, gestió de la demanda, BRM (Business Relationship Management, gestió de relacions amb el negoci)
Disseny dissenyar serveis nous o modificats per a la seva introducció a l'entorn de producció coordinació del disseny, gestió del catàleg de serveis, SLM (Service Level Management, gestió del nivell de servei), gestió de la capacitat, gestió de la disponibilitat, ITSCM (Information Technology Service Continuity Management, gestió de la continuïtat), gestió de la seguretat de la informació, gestió de proveïdors
Transició construir, provar i desplegar els serveis nous o modificats assegurant que compleixen els requisits definits al disseny planificació i suport a la transició, gestió de canvis, SACM (Service Asset and Configuration Management) i la seva CMDB (Configuration Management Database, base de dades de gestió de la configuració), gestió de versions i desplegaments, validació i proves del servei, avaluació del canvi, SKMS (Service Knowledge Management System, sistema de gestió del coneixement)
Operació lliurar i donar suport als serveis acordats de manera eficaç i eficient gestió d'esdeveniments, gestió d'incidents, compliment de peticions, gestió de problemes, gestió d'accessos. Funcions: Centre de Servei a l'Usuari (Service Desk), Gestió Tècnica, Gestió d'Operacions TI i Gestió d'Aplicacions
CSI (Continual Service Improvement) alinear contínuament els serveis amb les necessitats canviants del negoci procés de millora en 7 passos; model CSI i PDCA (Plan-Do-Check-Act, cicle de Deming)

El disseny de les proves d'un servei té per objectiu assegurar que el servei nou o modificat compleix les especificacions de disseny i els requisits del negoci — no només detectar defectes tècnics.

5.2 Les quatre P del disseny del servei

Persones (People), Processos (Processes), Productes (Products, incloent-hi tecnologia i eines) i Socis (Partners).

Propòsit: assegurar que el disseny d'un servei consideri de manera integrada tots quatre elements, perquè un servei ben dissenyat tecnològicament però sense persones formades, sense processos definits o sense els socis adequats fracassarà. És l'expressió al disseny del pensament holístic.

5.3 Cartera i catàleg

Aquí hi són perquè la gestió de la cartera de serveis és un procés de l'Estratègia i la gestió del catàleg ho és del Disseny (§5.1). El contingut del catàleg, les seves dues vistes i els acords de nivell de servei es desenvolupen al tema 20.

5.4 Recursos i capacitats

Actius del servei = recursos + capacitats.

La pregunta habitual: la diferència és que els recursos es poden adquirir mentre que les capacitats s'han de desenvolupar i són les que transformen els recursos en valor.

5.5 Millora contínua i mètriques

A v3 la millora contínua era una fase sencera del cicle de vida —la cinquena, el CSI— amb el seu procés de millora en 7 passos, el model CSI de sis preguntes i el cicle de Deming (PDCA) com a model de gestió de base. A ITIL 4 ja no hi ha cap fase: és una de les 34 pràctiques i, alhora, un dels cinc components del SVS.

Els set passos, el model, el PDCA i els indicadors amb què es mesura es desenvolupen al tema 22.


6. Governança

Segons ITIL 4, la governança és el mitjà pel qual una organització és dirigida i controlada. Té tres activitats: avaluar, dirigir i monitorar (coincidents amb el domini EDM, Evaluate, Direct, Monitor, de COBIT, Control Objectives for Information and Related Technologies). → tema 15.


Claus d'examen


Per recordar

Tema 15

Governança en el marc ITIL v4

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

Enunciat oficial. Governança en el marc ITIL v4 (Governance).


1. Concepte

Governança (ITIL 4): el mitjà pel qual una organització és dirigida i controlada. És un component del Sistema de Valor del Servei i s'exerceix sobre totes les altres parts del sistema: principis guia, cadena de valor, pràctiques i millora contínua.

Governança ≠ gestió, i aquesta és la distinció que més cau:

Governança Gestió
Pregunta què s'ha d'assolir i per què com s'assoleix
Qui òrgan de govern (consell d'administració, comitè de direcció, plenari) direcció executiva i comandaments
Activitats avaluar, dirigir i monitorar planificar, construir, executar i controlar
Horitzó estratègic, orientat a les parts interessades tàctic i operatiu
Producte polítiques, direcció, prioritats, apetit al risc plans, processos, procediments

2. Les tres activitats de governança

ITIL 4 adopta el model EDM (coincident amb COBIT):

L'òrgan de govern és el responsable d'aquestes tres activitats i ha de retre comptes (accountable) del compliment de l'organització amb polítiques i regulacions externes.


3. Governança dins del Sistema de Valor del Servei

El SVS (Sistema de Valor del Servei) s'alimenta d'oportunitat i demanda i produeix valor. La governança hi actua de la manera següent:

Mecanismes concrets: polítiques i estàndards corporatius, comitès (de direcció TIC, d'arquitectura, de canvis, de seguretat), quadres de comandament i informes a la direcció, auditories internes i externes, gestió de riscos i model de delegació d'autoritat (qui pot aprovar què, i fins a quin import o nivell de risc).

La governança envoltant el SVSLa governança envolta el Sistema de Valor del Servei, que al seu torn conté la cadena de valor i les pràctiques.Governançaavaluar, dirigir, monitorarSVSCadena de valor ipràctiques

Rols de responsabilitat: ITIL assigna rols, no llocs de treball, i és un mecanisme més de governança perquè fixen qui respon de què. El service owner (propietari del servei) és accountable que la prestació del servei i el suport s'ajustin als requeriments acordats amb el client, d'extrem a extrem, encara que no en presti cap component directament. El process owner (propietari del procés) és accountable pel disseny i el rendiment d'un procés o pràctica. El product owner, incorporat des d'Agile, prioritza el backlog d'un producte segons el valor per al client. Els tres decideixen i responen; no executen — la línia que separa governança de gestió (§1).

Model organitzatiu: la governança aprova l'estructura del departament TIC, però ITIL no n'imposa cap ni la declara obligatòria. És un marc adaptable: l'organigrama depèn de la mida, el context i els objectius de cada organització —la dimensió Organitzacions i persones ho desenvolupa a ITIL v4: conceptes fonamentals—. No hi ha, doncs, un organigrama perfecte ni una separació obligatòria entre àrees com Infraestructures, Telecomunicacions o Desenvolupament.

Errors habituals (i respostes falses típiques): confondre governança amb el comitè de canvis, situar la governança dins de la gestió d'operacions, o suposar que la governança executa processos. La governança no executa: dirigeix i controla.


4. Governança de la TI: marcs de referència

4.1 COBIT (ISACA)

COBIT 2019, publicat per l'ISACA (Information Systems Audit and Control Association), és el marc de referència de govern i gestió de la informació i la tecnologia empresarial.

4.2 ISO/IEC 38500

Norma internacional de govern corporatiu de la TI (Tecnologies de la Informació), elaborada per ISO i l'IEC (International Electrotechnical Commission). Estableix sis principis: responsabilitat, estratègia, adquisició, acompliment, conformitat i comportament humà, i el mateix model d'avaluar, dirigir i monitorar.

4.3 Altres


5. La governança al sector públic i a l'Ajuntament


6. Governança i compliance


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 16

Gestió de la relació amb els usuaris interns. BRM

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

Enunciat oficial. Gestió de la relació amb els usuaris interns. Business Relationship Management (BRM). Gestió d'expectatives.


1. Què és el BRM

Business Relationship Management és la pràctica —gestió de relacions a ITIL 4, gestió de relacions amb el negoci a ITIL v3— que estableix i cultiva els vincles entre l'organització i els seus interessats a nivell estratègic i tàctic.

Propòsit (ITIL 4): identificar les necessitats dels interessats i assegurar que el proveïdor de serveis les satisfà adequadament, prioritzant els serveis i les millores segons el valor que aporten al negoci.

Objectius d'ITIL v3 per al procés BRM:

El BRM és estratègic i tàctic; no és operatiu. Aquesta és la confusió que els exàmens exploten més.


2. BRM, SLM i Service Desk: qui fa què

La gestió del nivell de servei —SLM (Service Level Management)— és la pràctica veïna amb què més es confon el BRM a examen: totes dues tracten amb el client, però a horitzons i amb artefactes diferents.

BRM SLM Service Desk
Nivell estratègic / tàctic tàctic operatiu
Interlocutor client (qui decideix i paga) client i proveïdor usuari
Focus relació, valor, necessitats de negoci a mitjà i llarg termini acords concrets: SLA, OLA, UC i el seu compliment incidents i peticions del dia a dia
Horitzó anys cicle de revisió dels acords minuts i hores
Pregunta clau «què necessita el negoci i com hi contribuïm?» «complim el que hem acordat?» «t'ho resolem ara»
Artefacte informe de valor, pla de relació SLA (Service Level Agreement), OLA (Operational Level Agreement), UC (Underpinning Contract) tiquet, registre d'incident
Fase ITIL v3 Estratègia del Servei Disseny del Servei funció d'Operació del Servei

Els acords que formalitza l'SLM i el catàleg que els conté es desenvolupen a Catàleg de serveis TIC i acords de nivell de servei; aquí n'hi ha prou amb saber que el BRM gestiona l'expectativa i l'SLA en fa el compromís escrit.

Client, usuari i ciutadà: el client defineix els requisits i és responsable dels resultats del consum del servei —a l'Administració, la gerència o el departament demandant, que és qui assigna el pressupost—; l'usuari intern és qui utilitza el servei en el dia a dia —l'empleat públic, el tècnic, el comandament— i gairebé mai és qui paga: el pressupost el gestiona el client mitjançant el govern de la demanda (→ Gestió de la demanda TIC, que capta i prioritza la necessitat que el BRM ha ajudat a identificar). El ciutadà, finalment, és l'usuari final dels serveis públics que l'Administració presta a través de les TIC, no l'interlocutor directe del BRM.

El BRM també es distingeix de la gestió d'interessades de projecte (PMBOK v7: gestió d'interessades i comunicació estratègica): aquella s'acota a un projecte, amb principi i fi; el BRM és una relació permanent amb la mateixa estructura de negoci, independent de qualsevol projecte concret.

Els tres nivells de relació amb el clientNecessitats i requisits baixen per la pila; dades operatives i satisfacció hi pugen.BRM — nivell estratègic / tàcticinterlocutor: client · horitzó: anys ·valor, necessitats de negociService Desk — nivell operatiuinterlocutor: usuari · horitzó: minuts ihores · incidents, peticionsSLM — nivell tàcticinterlocutor: client i proveïdor ·horitzó: cicle de revisió · SLA, OLA, UCnecessitats, requisitsdades, satisfacció


3. Activitats del BRM

  1. Coneixement del negoci: entendre els processos, els objectius i el llenguatge de l'àrea client. Un BRM que no entén el negoci no pot traduir necessitats.
  2. Captació i qualificació de la demanda: recollir peticions estratègiques, distingir necessitat real de solució preconcebuda, i canalitzar-les cap a la gestió de la demanda i la cartera → tema 17.
  3. Definició i articulació dels requisits de negoci per a serveis nous o modificats, que després alimenten el disseny.
  4. Gestió de la cartera de clients i del portafoli d'acords.
  5. Mesura de la satisfacció: enquestes periòdiques (CSAT), NPS, enquestes post-incident, panells d'usuaris.
  6. Gestió de queixes i elogis: canalitzar-les, analitzar-ne les causes i tancar el cicle amb el client.
  7. Reunions periòdiques de servei amb el client i informes de valor, no només d'activitat.
  8. Gestió d'expectatives (secció següent).
  9. Comunicació proactiva dels canvis, incidències majors i evolucions previstes.

Rols: el Business Relationship Manager és el punt de contacte únic de nivell tàctic-estratègic amb una àrea de negoci. A les organitzacions grans hi ha un BRM per gerència o àmbit.

Maduresa de la relació: fora d'ITIL, el BRM Institute —que publica el seu propi cos de coneixement, el BRMBoK (Business Relationship Management Body of Knowledge)— classifica la relació entre proveïdor i negoci en sis nivells de maduresa, del 0 (Ad Hoc) al 5 (Strategic Partner, soci estratègic), passant per estadis intermedis com el 3 (Service Provider, proveïdor de servei, on la innovació encara és un repte) i el 4 (Trusted Advisor, assessor de confiança, amb pensament estratègic compartit). És una escala per distingir «fer tasques de BRM» de «tenir una relació BRM madura», no un estàndard ITIL. En la mateixa línia, COBIT (Control Objectives for Information and Related Technologies) 2019, d'ISACA (Information Systems Audit and Control Association), tracta la matèria a l'objectiu de gestió número 08 del domini APO (Align, Plan and Organise) —Managed Relationships, relacions gestionades—, domini ja vist a Governança en el marc ITIL v4.


4. La gestió d'expectatives

Expectativa: allò que el client creu que rebrà, que no sempre coincideix ni amb el que s'ha acordat ni amb el que és tècnicament possible.

La qualitat percebuda = percepció − expectativa. Es pot millorar per dues vies: elevant la percepció (millor servei) o ajustant l'expectativa (comunicació honesta). Ignorar la segona porta a clients insatisfets amb serveis que compleixen l'SLA.

Model de bretxes (GAP model) de Parasuraman, Zeithaml i Berry — cinc bretxes:

  1. Entre les expectatives del client i la percepció que en té la direcció.
  2. Entre la percepció de la direcció i les especificacions de qualitat del servei.
  3. Entre les especificacions i el servei realment lliurat.
  4. Entre el servei lliurat i la comunicació externa al client (promeses).
  5. Bretxa del client: entre el servei esperat i el servei percebut — és la suma de les anteriors.

Pràctiques per gestionar expectatives:

Senyals d'alerta: peticions que arriben pel canal informal saltant-se el procés, escalats freqüents a la direcció, discrepància entre els indicadors d'SLA (verds) i la satisfacció (baixa), i clients que munten pel seu compte «TI (Tecnologies de la Informació) a l'ombra» (shadow IT).


5. Instruments de mesura

Compte amb el «paradigma de la sandvitxeria»: complir tots els SLA i tenir clients insatisfets vol dir que els indicadors mesuren el que és fàcil de mesurar, no el que importa al negoci. La resposta és revisar els acords amb el client, no ajustar l'indicador.


6. El BRM al sector públic


Per recordar

Tema 17

Gestió de la demanda TIC

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

Enunciat oficial. Gestió de la demanda TIC. Models de govern de la demanda. Relació TIC-negoci i alineació estratègica en ITIL v4.


1. Concepte de demanda

Demanda (ITIL (Information Technology Infrastructure Library) 4): entrada al sistema de valor del servei, procedent dels consumidors interns i externs, que consisteix en la necessitat o el desig de productes i serveis.

Gestió de la demanda (ITIL v3, fase d'Estratègia del Servei): comprendre, anticipar i influir en la demanda de serveis per part dels clients, i, en cooperació amb la gestió de la capacitat, assegurar que el proveïdor té la capacitat suficient per satisfer-la.

Dos vessants:

Conceptes clau d'ITIL v3:

Tècniques per influir en la demanda: preus diferenciats (facturació interna més cara en hores punta), restriccions tècniques (quotes, límits), incentius (finestres de manteniment, càrrega diferida), campanyes i comunicació, i autoservei per desviar demanda del Service Desk.


2. Models de govern de la demanda

El govern de la demanda és el mecanisme que decideix quines peticions s'atenen, en quin ordre i amb quins recursos. Sense ell, la capacitat s'assigna per pressió, per urgència aparent o per proximitat jeràrquica.

Elements d'un model de govern de la demanda:

  1. Canal únic d'entrada: totes les peticions entren pel mateix lloc i es registren. El que no entra pel canal, no existeix.
  2. Classificació: incident, petició de servei, canvi menor, evolutiu, projecte nou, obligació normativa.
  3. Qualificació: anàlisi de la necessitat real, dimensionament de gruix, identificació d'alternatives i de solucions ja existents al catàleg.
  4. Criteris de priorització explícits i publicats: valor per al negoci, alineació estratègica, obligació legal, risc de no fer-ho, cost, dependències, disponibilitat de capacitat.
  5. Òrgans de decisió: comitè de demanda o comitè de direcció TIC, amb representació del negoci i de TIC, i una cadència fixa de reunions.
  6. Capacitat disponible declarada: la priorització només té sentit si es coneix la capacitat real; en cas contrari es prioritza sobre un pastís infinit.
  7. Transparència: estat de cada petició visible per al sol·licitant.
  8. Mesura: temps d'espera, taxa d'aprovació, valor lliurat, demanda no atesa.

La captació inicial de la demanda estratègica sol fer-la el BRM (→ Gestió de la relació amb els usuaris interns. BRM): identifica la necessitat amb el negoci i l'ajuda a qualificar-la abans que entri pel canal formal. El procés que ve després —classificar, prioritzar i aprovar— és el que es descriu aquí:

El procés de govern de la demandaCinc passos entre una petició i la capacitat assignada. El pas que fa la feina és la priorització, i només serveix si els criteris són explícits abans de rebre les peticions.Aprovació pel comitè dedemandaCanal d'entradaCapacitat assignadaClassificacióPrioritzacióamb criteris explícitsQualificació

Models organitzatius:

Model Com decideix Quan encaixa
Centralitzat un únic comitè corporatiu prioritza tota la demanda organitzacions petites o amb recursos molt escassos; garanteix coherència, però pot ser lent
Descentralitzat cada àrea prioritza el seu pressupost i la seva capacitat assignada àrees amb autonomia pressupostària; risc de duplicitats i de pèrdua de visió global
Federat o híbrid un marc i uns criteris corporatius comuns, amb decisió delegada dins de cada àmbit i escalat al comitè corporatiu per als casos que superen llindars el més habitual a les administracions grans, i el model de facto de l'Ajuntament

Instruments de priorització: matriu valor–esforç, puntuació ponderada multicriteri, MoSCoW, WSJF (Weighted Shortest Job First — cost of delay dividit per la mida del treball), cost of delay, buckets de capacitat (percentatges preassignats a manteniment correctiu, obligacions normatives, evolutius i innovació).

Assignació de capacitat típica: reservar un percentatge fix per a manteniment i correctius, un altre per a compliment normatiu (que no es prioritza: és obligatori) i deixar el marge restant a la priorització de valor. Aquesta reserva evita que l'urgent devori l'important.


3. Relació TIC-negoci i alineació estratègica

3.1 Alineació

Alineació estratègica: grau en què els objectius, l'estructura i els recursos de TIC donen suport i habiliten els objectius de l'organització. Models → tema 1 (SAM (Strategic Alignment Model) de Henderson i Venkatraman, cascada d'objectius de COBIT (Control Objectives for Information and Related Technologies), Balanced Scorecard de TI (Tecnologies de la Informació)).

Símptomes de desalineació: cartera TIC plena de projectes que ningú no reclama, àrees que compren solucions pel seu compte (shadow IT), pressupost consumit en manteniment sense marge per a evolució, indicadors tècnics en verd amb negoci insatisfet.

3.2 Com ho tracta ITIL 4

3.3 Pràctiques implicades


4. La demanda no governada (shadow IT)

Shadow IT (Information Technology): maquinari, programari o serveis —sovint SaaS al núvol, contractats amb targeta corporativa— que una àrea de negoci adquireix, contracta o posa en marxa sense passar pel canal de demanda ni pel coneixement de l'àrea TIC.

No és un acte de rebel·lia: és el símptoma d'un govern de la demanda que falla. Apareix quan el canal oficial és lent (terminis de contractació llargs, cua de peticions sense resposta), quan la resposta és un «no» sense alternativa, quan el catàleg de serveis no cobreix la necessitat, o quan un autoservei improvisat —una eina gratuïta, un SaaS pagat amb la targeta pròpia— és més ràpid que demanar-ho pel canal formal. La demanda que no troba cauce no desapareix: es desvia.

Riscos:

Com es recondueix: no es combat prohibint —això només l'amaga—, es recondueix absorbint-la: un canal ràpid per a peticions de baix risc i baix cost, un catàleg ampliat amb autoservei governat, i plataformes de baix codi corporatives i catalogades (→ Low-code i no-code, on precisament l'ús no governat d'aquestes mateixes eines és avui una de les vies més esteses de shadow IT). Una auditoria periòdica de contractació i de trànsit de xarxa és el mecanisme per fer-la visible.


5. De la demanda a la capacitat

La demanda i la capacitat són les dues cares del mateix problema:

Demanda de negoci (PBA)  →  Càrrega de treball  →  Requisits de capacitat
                                                  ↕
                        Capacitat disponible (recursos, serveis, components)

Si la demanda supera la capacitat: es prioritza, s'amplia la capacitat (cost) o s'influeix en la demanda (modulació). Si la capacitat supera la demanda de manera sostinguda, hi ha sobredimensionament i malbaratament de recursos. → tema 21.

Al núvol la relació canvia: l'elasticitat permet ajustar la capacitat a la demanda gairebé en temps real, i el problema es desplaça de la planificació de capacitat al control de la despesa (FinOps) → temes 59 i 27.


6. El govern de la demanda a l'Ajuntament de Barcelona


Per recordar

Fonts d'aquest tema

Tema 18

Pràctiques ITIL v4 de suport al servei

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

Enunciat oficial. Pràctiques ITIL v4 de suport al servei: gestió d'incidents, problemes i sol·licituds de servei.


1. Els quatre conceptes que no s'han de barrejar

ITIL (Information Technology Infrastructure Library) defineix quatre conceptes de suport al servei que no s'han de confondre entre si:

Definició Objectiu
Esdeveniment (event) qualsevol canvi d'estat que té significació per a la gestió d'un element de configuració o d'un servei de TI (Tecnologies de la Informació) detectar-lo, entendre'l i decidir si cal acció
Incident interrupció no planificada d'un servei o reducció de la seva qualitat restaurar el servei tan ràpidament com sigui possible
Problema causa, o causa potencial, d'un o més incidents trobar la causa arrel i eliminar-la
Petició de servei (service request) sol·licitud d'un usuari o del seu representant que inicia una acció de servei acordada com a part normal del lliurament del servei atendre-la de manera estandarditzada i eficient

Regla d'or: la gestió d'incidents restaura, la gestió de problemes investiga. Un incident es pot tancar sense conèixer-ne la causa; el problema es manté obert fins que es troba.


2. Gestió d'esdeveniments (monitoring and event management)

Propòsit: observar sistemàticament els serveis i els components del servei, i registrar i informar dels canvis d'estat identificats com a esdeveniments, identificant i prioritzant els d'infraestructura, servei, procés de negoci i seguretat de la informació, i establint la resposta adequada.

Tres tipus d'esdeveniment:

Monitoratge i gestió d'esdeveniments no són sinònims: el monitoratge comprova l'estat d'un component encara que no es produeixi cap esdeveniment —per exemple, verificar que un servidor respon dins del llindar acceptable—; la gestió d'esdeveniments és la que genera i detecta les notificacions significatives sobre aquest estat i en decideix la resposta.

Dos eixos del monitoratge, independents l'un de l'altre:

Un monitoratge pot ser alhora actiu i reactiu, o passiu i proactiu: els dos eixos es combinen lliurement, no en formen un de sol.

Correlació: motor que agrupa esdeveniments relacionats, elimina duplicats i decideix quan crear un incident. Sense correlació, una caiguda genera centenars d'alarmes.

SNMP (Simple Network Management Protocol): el protocol que fa possible el monitoratge passiu — els agents envien esdeveniments (traps) al gestor, l'NMS (Network Management System), que els interpreta contra la MIB (Management Information Base) de cada dispositiu. SNMPv3 hi afegeix autenticació i xifratge, absents a les versions 1 i 2c, que només tenen community strings en clar. El detall del protocol —gestor, agent, MIB i notificacions— el desenvolupa la plataforma d'observabilitat..


3. Gestió d'incidents

Propòsit: minimitzar l'impacte negatiu dels incidents restaurant l'operació normal del servei al més aviat possible.

3.1 Cicle de vida

Detecció → registre → categorització → priorització → diagnòstic inicial → escalat (si cal) → investigació i diagnòstic → resolució i recuperació → tancament.

3.2 Incidents que afecten múltiples serveis i usuaris

La bona pràctica davant un incident d'alt impacte (incident major):

  1. Declarar-lo formalment com a incident major i activar el procediment específic.
  2. Assignar un gestor d'incident major i un equip dedicat, separat del flux ordinari.
  3. Convocar una sala de crisi (war room) amb els especialistes necessaris.
  4. Comunicar proactivament a usuaris i interessats: què passa, què n'està afectat, quina és l'estimació i quan hi haurà la propera actualització. La comunicació és periòdica i pautada, no a demanda.
  5. Restaurar el servei com a prioritat absoluta, encara que sigui amb un workaround.
  6. Registrar un problema associat per investigar la causa arrel després de la restauració.
  7. Revisió post-incident (post-incident review) sense buscar culpables (blameless), amb accions de millora.

La resposta correcta a l'examen combina coordinació centralitzada, comunicació proactiva i restauració prioritària, obrint un problema per a la causa. Les distractores solen proposar tractar-lo com un incident ordinari, o aturar la restauració fins a trobar la causa — que és exactament el que no s'ha de fer.

3.3 Mètriques

Pròpies de la gestió d'incidents: MTTA (Mean Time To Acknowledge, temps mitjà d'acceptació — quant triga a agafar-se la incidència), MTBF (Mean Time Between Failures, temps mitjà entre fallides — la fiabilitat d'un component) i MTBSI (Mean Time Between Service Incidents, temps mitjà entre incidents de servei — si les fallides s'acumulen o s'espaien). La resta —FCR (First Contact Resolution), compliment de l'SLA (Service Level Agreement, acord de nivell de servei), incidents reoberts, backlog— són les mateixes mètriques del Service Desk (tema 25).


4. Gestió de problemes

Propòsit: reduir la probabilitat i l'impacte dels incidents identificant-ne les causes reals i potencials i gestionant els workarounds i els errors coneguts.

4.1 Les tres fases

  1. Identificació del problema: anàlisi de tendències d'incidents, detecció de problemes recurrents, informació dels proveïdors, anàlisi d'incidents majors.
  2. Control del problema: anàlisi del problema per determinar-ne la causa arrel i documentar solucions temporals i errors coneguts. Un error conegut és un problema que ha estat analitzat però no resolt: no és el mateix que el workaround —el workaround és l'acció que redueix l'impacte; l'error conegut és l'estat del problema, ja diagnosticat, que aquell workaround documenta. Pot haver-hi workaround sense diagnòstic (davant un incident aïllat); no hi ha error conegut sense diagnòstic.
  3. Control de l'error: gestionar els errors coneguts, reavaluar-ne l'impacte i, quan es justifiqui, promoure una sol·licitud de canvi per a la solució definitiva.

4.2 Reactiva i proactiva

Un cop adreçada l'obertura de problemes amb un procediment clar —equips formats i eines adaptades als nous procediments—, el pas que cal abordar és implementar-lo de manera regular: analitzar les incidències i problemes per identificar tendències, no aturar-se ni parlar encara de la imputació de costos, que és prematur. És l'efecte esperat de fer-ho bé: un cop redreçada la situació, fent-ne el seguiment corresponent, el nombre d'incidències repetitives es reduirà.

4.3 Tècniques d'anàlisi de causa arrel

No totes serveixen per al mateix cas: els cinc perquès funcionen quan la cadena de causes és lineal i cal arribar-hi de pressa; el diagrama d'Ishikawa (espina de peix), quan les causes possibles s'agrupen per categories (persones, procés, tecnologia...); l'anàlisi de Pareto, quan cal prioritzar entre moltes causes candidates i atacar primer les que més pesen; i l'aïllament per bisecció, quan el sistema es pot dividir per parts i descartar-ne la meitat a cada pas. Menys freqüents: l'anàlisi cronològica, la de Kepner-Tregoe, l'FTA (Fault Tree Analysis, arbre de fallides) i l'FMEA (Failure Mode and Effects Analysis, anàlisi de modes de fallida i efectes).

Davant d'incidències recurrents, la pràctica correcta és obrir un problema i fer anàlisi de causa arrel, no seguir resolent els incidents un per un. Aquesta és la pregunta literal de l'examen.

Relació amb la gestió del coneixement: cada workaround i cada error conegut alimenta la KEDB (Known Error Database, base de dades d'errors coneguts) i el SKMS (Service Knowledge Management System, sistema de gestió del coneixement), i redueix el temps de resolució dels incidents futurs.


5. Gestió de peticions de servei

Propòsit: donar suport a la qualitat acordada del servei gestionant totes les peticions de servei predefinides i iniciades per l'usuari d'una manera efectiva i amable.

Característiques:

Peticions vs canvis estàndard: el que l'usuari viu com una petició de servei, per dins pot tramitar-se com un canvi estàndard —preautoritzat, de risc baix— si toca un element de configuració (instal·lar programari, obrir un port); si no en toca cap (una consulta, una reserva), es queda en petició. El detall dels tipus de canvi és al tema 19.


6. Model integrat de suport

Flux integrat entre esdeveniment, incident, problema i canviEl Service Desk és el punt únic de contacte i des d'allà surten tres vies. Un esdeveniment només arriba a incident quan és una excepció; un incident només obre problema quan es repeteix.CanviCompliment estandarditzatBase de coneixementConsultaService Deskpunt únic de contacteEsdevenimentIncidentMonitoratgePetició de serveiProblemaUsuarisi és excepciósi és recurrentcausa arrel

Nivells de suport: nivell 1 (Service Desk, resolució al primer contacte), nivell 2 (especialistes per àmbit), nivell 3 (experts, desenvolupament, arquitectura) i nivell 4 (proveïdors i fabricants). El Service Desk manté la titularitat de l'incident encara que l'escali: és el responsable davant l'usuari fins al tancament. → tema 25.

Gestió del coneixement: la pràctica que manté i millora l'ús efectiu, eficient i convenient de la informació i el coneixement a tota l'organització. SKMS i KEDB en són els repositoris.

Front a una fusió de departaments —dos edificis o organitzacions que s'integren—, la bona pràctica és centralitzar, no duplicar: establir un únic Service Desk sota un únic responsable, i nomenar un únic responsable tècnic central per als equips de Suport Tècnic dels dos edificis, en lloc de mantenir estructures separades per ubicació o externalitzar-ho tot per evitar la complexitat.

Per sostenir una operació 24×7, cal també assignar responsables de torn que es facin càrrec de la cobertura contínua a cada franja horària —no n'hi ha prou amb centralitzar la titularitat si ningú respon fora d'horari—. És un canvi organitzatiu diferent d'acotar un rol a la integració puntual (un gestor de problemes només per als incidents de la fusió) o de traslladar la responsabilitat operativa fora de l'equip (superusuaris externs, o canviar de marc de treball sencer per un problema puntual d'organització).


7. L'Operació del Servei: fase en ITIL v3, sense fase en ITIL v4

7.1 El domini de l'Operació del Servei (ITIL v3)

ITIL v3 organitza la gestió del servei, com a metodologia, en cinc fases del cicle de vida: Estratègia, Disseny, Transició, Operació i Millora Contínua del Servei. Cada un dels processos pertany a una fase concreta, i en aquest context és fonamental saber a quina: la gestió d'esdeveniments, la gestió d'incidents, la gestió de problemes i la gestió de peticions —el domini d'aquest tema— juga el seu paper dins l'Operació del Servei, la fase que s'encarrega d'implementar i operar el servei ja en producció, dia a dia. La gestió de la disponibilitat i de la capacitat pertanyen a Disseny del Servei perquè es planifiquen abans de posar-se en marxa (→ tema 21), i la gestió del canvi i de versions pertanyen a Transició del Servei (→ tema 19).

ITIL v4 no té fases: la metodologia les substitueix per un conjunt de pràctiques que s'activen des de qualsevol punt de la cadena de valor del servei (SVC, Service Value Chain), sense estar lligades a una seqüència fixa. Per això el títol d'aquest tema parla de «pràctiques» i no de «processos de l'Operació del Servei»: és la nomenclatura v4. → tema 17.

7.2 Equilibris de l'Operació del Servei

L'Operació del Servei (ITIL v3) manté quatre tensions en equilibri constant:

8. Gestió d'accessos

Propòsit (ITIL v3): concedir als usuaris autoritzats el dret a utilitzar un servei, alhora que se n'impedeix l'accés als usuaris no autoritzats. Executa, no defineix, les polítiques que marca la gestió de la seguretat de la informació.

Les seves activitats pròpies són verificar la identitat de qui sol·licita l'accés i concedir els drets que li corresponen segons el rol autoritzat —la sol·licitud arriba normalment via la gestió de peticions de servei. El que no li pertoca: definir les polítiques de seguretat (és gestió de la seguretat de la informació, que la gestió d'accessos només executa) ni monitorar la disponibilitat dels sistemes (és gestió de la disponibilitat). El detall de l'autenticació, l'autorització i els seus protocols és al tema 64.


Claus d'examen

Per recordar

Tema 19

Pràctiques ITIL v4 de lliurament de serveis

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

Enunciat oficial. Pràctiques ITIL v4 de lliurament de serveis: gestió de canvis, versions, actius i configuració (CMDB).


1. Què cobreix aquest tema

L'ITIL (Information Technology Infrastructure Library) és el marc de bones pràctiques de gestió de serveis de TI (Tecnologies de la Informació). El títol diu «lliurament», però els quatre àmbits que enumera —canvis, versions, actius i configuració— són exactament els que l'ITIL v3 agrupava a la fase de transició del servei: el pont entre el disseny i l'operació.

Sonen a lliurament i no són d'aquí: incidents, problemes i peticions, el catàleg i l'SLA, la capacitat i la disponibilitat, la continuïtat, la cadena de valor i la canonada tècnica de desplegament. Aquí es tracta la pràctica de gestió: qui autoritza, què es registra, qui respon.


2. Control de canvis

Propòsit (ITIL 4): maximitzar el nombre de canvis de productes i serveis reeixits assegurant que els riscos s'avaluen adequadament, autoritzant els canvis a procedir i gestionant el calendari de canvis.

Canvi: addició, modificació o eliminació de qualsevol cosa que pugui tenir un efecte directe o indirecte sobre els serveis. A l'ITIL v3 la definició s'enuncia sobre el servei —no sobre el projecte ni sobre el programari— i els canvis poden ser estratègics, tàctics o operatius.

La sol·licitud formal que el dispara és la RFC (Request For Change, petició de canvi): descriu què es vol canviar, per què, amb quin impacte i amb quin pla de retorn. No s'ha de confondre amb la RFC de l'IETF (Internet Engineering Task Force), un document d'estandardització d'internet.

2.1 Els tres tipus de canvi

Tipus Descripció Autorització
Estàndard canvi de baix risc, preautoritzat, ben comprès, completament documentat i que es pot implementar sense necessitat d'autorització addicional preautoritzat; sovint es gestiona com a petició de servei
Normal canvi que ha de passar per avaluació, autorització i planificació; es prioritza segons el risc i l'impacte autoritat de canvi corresponent segons el nivell de risc
D'emergència canvi que s'ha d'implementar al més aviat possible, típicament per resoldre un incident major o aplicar un pedaç de seguretat crític procediment abreujat; ECAB (Emergency Change Advisory Board); es documenta igualment, encara que sigui a posteriori

Un canvi d'emergència no és un canvi sense control: se'n redueix la burocràcia, no la traçabilitat.

El model de canvi és el procediment predefinit per a una categoria de canvis repetitius: passos, ordre, responsabilitats i terminis. Un canvi estàndard és, precisament, un canvi amb model aprovat.

2.2 Autoritat de canvi, CAB i calendari

2.3 Les set erres del canvi

Per avaluar l'impacte, els beneficis i els riscos d'un canvi, l'ITIL 2011 proposa set preguntes conegudes com les set erres. Cauen tal com estan escrites, en anglès i en aquest ordre:

La distractora habitual substitueix la darrera per Report o la tercera per Rejoin. Les set són preguntes prèvies a l'autorització, no informes posteriors.

2.4 Avaluació del canvi i revisió posterior

L'avaluació del canvi és el procés que dona a l'autoritat de canvi un dictamen formal sobre l'efecte previst i real d'un canvi significatiu, contrastant el rendiment previst amb el real.

La PIR (Post Implementation Review, revisió posterior a la implementació) es fa després de desplegar i comprova que el canvi ha assolit l'objectiu i no ha causat efectes col·laterals. Quan el canvi venia justificat per un cas de negoci, el que es torna a mirar en una anàlisi post mortem són els riscos i les contingències que s'hi van declarar: si es van materialitzar i si les contramesures van funcionar. L'abast, els costos i els beneficis es revisen amb la realització de beneficis, no amb l'anàlisi de la fallida. El cas de negoci sencer és a prospecció de solucions.


3. Gestió de versions i desplegament

Definicions que es pregunten literalment i que cal no confondre:

Diferència: la release és què s'allibera —un conjunt coherent de canvis, provats i empaquetats junts, amb la decisió de negoci de posar-los a disposició—; el deployment és com i on s'instal·la tècnicament. Es pot desplegar sense alliberar (desplegar el codi a producció amb la funcionalitat desactivada per feature flag) i es pot alliberar sense desplegar de nou (activar una funcionalitat ja desplegada).

Una diferència de versió entre l'ITIL v3 i l'ITIL 4: la v3 tenia un sol procés, «gestió de versions i desplegaments», dins la transició del servei. L'ITIL 4 el parteix en dues pràctiques separades, amb propòsits diferents:

Aquesta separació és la base del desplegament continu: el desplegament passa a ser un acte tècnic freqüent i de baix risc, i l'alliberament una decisió de negoci independent.

Models de desplegament: big bang (tothom alhora), per fases (phased), continu*, pull (l'usuari se'l baixa quan vol) i push* (l'organització l'empeny). Les estratègies avançades —blau-verd, canari, rolling, A/B— són a DevOps i CI/CD.

Entorns: desenvolupament → integració → proves o QA (Quality Assurance, assegurament de la qualitat) → preproducció (staging) → producció.

Repositoris autoritzats, que cauen com a parella:

3.1 La posada en marxa

Desplegar els components no és posar el servei en marxa. El pla de formació es té a punt abans o durant, mai després: ajornar-lo fins a l'acceptació tècnica de l'equip d'operació —que no és el final de la posada en marxa— és la distractora clàssica. El pla de suport s'executa durant i després (early life support). La documentació de lliurament inclou la funcional, el disseny tècnic, els manuals d'usuari, tècnics i d'administració i el full d'escalats per al servei d'atenció. I la instal·lació «cega» —desplegar a producció sense publicar l'accés, per comprovar configuració i components— és correcta: és el cas concret de «desplegar sense alliberar».


4. Validació i proves del servei

Propòsit (ITIL v3): assegurar que un servei nou o modificat coincideix amb el disseny i satisfà les necessitats del negoci, proporcionant la confiança que una entrega crearà un servei que lliurarà els resultats i el valor esperats dins dels costos i restriccions previstos.

Objectiu del disseny de les proves: desenvolupar models de proves i casos de prova que mesurin els aspectes correctes, per establir si el servei complirà amb el seu ús pretès dins de les restriccions especificades. És a dir, el disseny de proves decideix què s'ha de mesurar, no els límits tècnics d'una màquina ni el nombre de peticions per minut d'una base de dades.

El que NO és propòsit d'aquest procés: registrar els canvis dels actius i elements de configuració al sistema de gestió de la configuració —això és de la gestió de la configuració—, aprovar el canvi o mesurar la satisfacció de l'usuari en producció.

4.1 El model V del servei

A cada nivell d'especificació li correspon un de prova, i es dissenyen alhora, no un després de l'altre:

Especificació Prova corresponent
requisits de negoci proves d'acceptació del negoci
requisits de servei i criteris d'acceptació proves d'acceptació del servei
disseny de la solució proves d'integració i d'operació del servei
disseny de components proves de components

4.2 Tipus de prova

Provar no és només l'acceptació d'usuari:

4.3 Què passa si no es prova prou

Introduir a producció un servei insuficientment provat incrementa les incidències del propi servei i genera impactes en altres serveis que comparteixen infraestructura, amb costos de correcció més alts i pèrdua de confiança. La confiança i la identificació anticipada de riscos són el resultat de provar, no de no provar: aquesta inversió de sentit és la distractora clàssica.


5. Gestió d'actius de TI

Propòsit: planificar i gestionar el cicle de vida complet de tots els actius de TI, per maximitzar-ne el valor, controlar-ne els costos, gestionar riscos, donar suport a la presa de decisions sobre compra, reutilització i retirada, i complir els requisits legals i regulatoris.

Actiu de TI: qualsevol component financerament valuós que pugui contribuir al lliurament d'un producte o servei de TI. La pràctica es coneix com ITAM (Information Technology Asset Management).

Cicle de vida de l'actiu: planificació → adquisició → desplegament → operació i manteniment → retirada i disposició segura. A cada baula hi ha una decisió econòmica: comprar o llogar, quan amortitzar, quan surt més a compte substituir que mantenir. El número que es compara entre alternatives és el TCO (Total Cost of Ownership, cost total de propietat) → gestió financera.

Àmbits:

Auditoria de llicències: revisió —interna o del fabricant— que compara les llicències adquirides amb les instal·lacions i els usos reals. Un dèficit es paga amb regularització i sovint penalització; un excedent vol dir que s'ha pagat de més.

Altres riscos que cobreix l'ITAM: maquinari fora de suport, actius fantasma (pagats i no localitzats) i fuita de dades en la retirada, que exigeix esborrat segur o destrucció certificada.


6. Gestió de la configuració del servei i la CMDB

Propòsit: assegurar que hi ha disponible informació precisa i fiable sobre la configuració dels serveis i sobre els elements de configuració que els suporten, quan i on calgui, incloent-hi informació sobre com estan configurats els CI i sobre les relacions entre ells.

6.1 Conceptes

6.2 Activitats

Identificació dels CI i del seu model de dades → control (cap CI canvia sense un canvi autoritzat) → registre i informe de l'estat → verificació i auditoria, que compara la CMDB amb la realitat. El descobriment automàtic (discovery) escaneja la infraestructura i l'alimenta; sense ell, la deriva de configuració creix sola.

6.3 Diferència entre actiu i element de configuració

Gestió d'actius (ITAM) Gestió de la configuració
Pregunta què tinc, què val, qui n'és el propietari i quan caduca com està muntat i de què depèn
Focus financer, contractual i de cicle de vida tècnic i relacional
Registra cost, llicència, garantia, ubicació, amortització atributs tècnics i relacions entre CI
Abast tot l'actiu, tingui o no impacte en el servei només el que cal per lliurar el servei

Un mateix element pot ser actiu i CI alhora; però hi ha CI que no són actius (un procés documentat, una relació entre components) i actius que no són CI rellevants (una llicència en desús, una impressora sense paper al magatzem). A l'ITIL v3 les dues coses anaven juntes en un únic procés, la SACM (Service Asset and Configuration Management).

6.4 Per a què serveix la CMDB

6.5 Reptes i riscos de la gestió d'actius i configuració

Els reptes que fan fracassar les implantacions reals, i que l'examen recull:

El risc que se'n deriva és la degradació de l'exactitud de la informació amb el temps, cara i difícil de corregir. Una CMDB desactualitzada és pitjor que no tenir-ne: indueix decisions errònies amb aparença de fonament.


7. La transició del servei a l'ITIL v3

Propòsit de la fase: construir, provar i desplegar els serveis nous o modificats, assegurant que compleixen els requisits documentats a l'etapa de disseny, i gestionar el risc del canvi per minimitzar-ne l'impacte en l'operació.

La transició del servei entre el disseny i l'operacióEl disseny lliura a la transició i la transició lliura a l'operació. La CMDB, el CMS i la DML són el registre que sosté totes les etapes.Transició del serveiDesplegamentDisseny del serveiOperació del serveiValidació i provesCMDB · CMS · DMLel registre que sosté totes les etapesRevisió posteriorAutorització del canvi (RFC)Construcció de la versió

7.1 Els set processos

  1. Planificació i suport a la transició
  2. Gestió de canvis
  3. Gestió d'actius de servei i configuració (SACM)
  4. Gestió de versions i desplegament
  5. Validació i proves del servei
  6. Avaluació del canvi
  7. Gestió del coneixement

Pregunta habitual: quin procés NO forma part de la Transició del Servei? Les distractores són incidents i esdeveniments (Operació), capacitat i nivell de servei (Disseny) i demanda (Estratègia).

El seu lloc al cicle de vida: la transició se situa entre el disseny del servei i l'operació del servei. No entre el projecte i l'operació: el projecte no és una fase del cicle de vida de l'ITIL.

7.2 Beneficis

La resposta correcta ajunta sempre tres coses: satisfacció del client i de l'usuari, reducció de les taxes d'incidències i errors dels serveis en transició i reducció dels costos de la transició.

7.3 Riscos i reptes

Els riscos documentats són l'alienació del personal de suport —canvien responsabilitats i pràctiques, i això desmotiva—, costos excessius per una pràctica exageradament aversa al risc i endarreriments inacceptables per al negoci. La resposta correcta és aquesta terna, no cap versió que negui que hi hagi riscos. Els reptes principals: cadena de subministrament complexa, equilibri entre estabilitat i capacitat de resposta, processos dispars i sistemes heretats.

7.4 Què mesurar quan els recursos són limitats

L'ITIL demana decidir explícitament què és més important, la velocitat de la transició o el cost, i establir després una jerarquia aplicable de mesures: velocitat, diners i funcionalitat. I s'ha de conscienciar i implicar tota l'organització dels requisits: sense això cada equip optimitza el seu paràmetre i cap prioritat es compleix.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 20

El catàleg de serveis TIC i els acords de nivell de servei

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

Enunciat oficial. Catàleg de serveis TIC. Definició, manteniment i publicació. Acords de nivell de servei (SLA/OLA/UC).


1. Cartera i catàleg de serveis

Aquest tema parteix d'ITIL (Information Technology Infrastructure Library), el marc de gestió de serveis de TI (Tecnologies de la Informació) més estès i la font que manda en aquesta matèria (sin-fuente-oficial: no és d'accés lliure).

Cartera de serveis (service portfolio): el repositori superior amb tots els serveis d'un proveïdor, en qualsevol estat del seu cicle de vida. Tres blocs: el pipeline (allò que encara s'està avaluant, dissenyant o desenvolupant), el catàleg (el que ja està actiu i disponible) i els serveis retirats. Les tres fases hi entren: un servei que només està planificat, un que ja s'està lliurant i un que s'ha donat de baixa formen part igualment de la cartera.

Catàleg de serveis (service catalogue): el subconjunt de la cartera amb només els serveis actius i disponibles, és a dir, la part que es mostra a qui els pot demanar. La formulació canònica d'ITIL v3, que ha caigut més d'un cop amb paraules gairebé idèntiques, és aquesta: «una única font d'informació consistent sobre tots els serveis acordats, i garantir que està completament disponible per a qui se li hagi autoritzat l'accés». Una segona manera de dir el mateix, també literal: «una base de dades o document estructurat amb informació sobre tots els serveis TI en explotació, incloent-hi els que ja estan preparats per al desplegament».

El catàleg no és cap d'aquestes tres coses, amb què es confon sovint:

El primer pas perquè un servei nou hi entri no és donar-lo d'alta al catàleg: és justificar-lo amb un cas de negoci que n'avaluï el valor i el risc per a l'organització. Amb el cas de negoci aprovat, el servei entra al pipeline de la cartera; només quan ja està operatiu, o llest per desplegar-se, passa a formar part del catàleg. Definir l'SLA o assignar-hi un gestor de canvis són passos posteriors, un cop decidit que el servei tira endavant.

El procés o pràctica que manté aquest moviment és la gestió del catàleg de serveis, diferent de la gestió del portfoli (que decideix, a nivell estratègic, què entra i què surt de la cartera sencera) i de la gestió del nivell de servei (que regula els acords, no l'inventari). Qui l'exerceix —el gestor del catàleg— respon de la precisió del catàleg i de la seva coherència amb el portfoli i amb els serveis realment operatius; no respon del flux de creació de serveis, que és responsabilitat del disseny del servei (§4).

2. Les dues vistes del catàleg

Catàleg de negoci Catàleg tècnic
Audiència client i usuari només personal de TI
Llenguatge de negoci: què aporta, com se sol·licita, cost, nivells de servei tècnic: components, elements de configuració, dependències
Es mostra al client? sí, és el que consulta i demana mai
Exemple «correu electrònic corporatiu», «tramitació de llicències» servidors de correu, emmagatzematge, directori, xarxa

Les dues vistes conviuen sempre: ITIL no en desaconsella cap ni prohibeix «en cap cas» barrejar-les, i cap de les dues formulacions absolutes és la seva. El catàleg tècnic ha d'incloure els serveis infraestructurals necessaris per proporcionar els de negoci, precisament perquè són transparents per al client —aquest no els veu ni els necessita veure.

3. Contingut d'una entrada del catàleg

Per a cada servei actiu, el catàleg recull:

No hi entra: sondes de monitoratge en temps real ni l'estat de disponibilitat instant a instant —això és matèria de la plataforma d'observabilitat—, ni els grups resolutoris i les incidències obertes, ni la llista de projectes que crearan, modificaran o retiraran el servei.

4. Gestió del catàleg: definició, manteniment i publicació

Definició. Els serveis s'identifiquen des de la perspectiva del client, mai des de l'estructura interna de TI. Ni un catàleg de centenars d'entrades que ningú llegeix (excés de granularitat) ni un de cinc línies que no serveix per a res (manca de detall).

Manteniment. El catàleg s'ha de mantenir viu: cada canvi que afecti la descripció, l'elegibilitat, els compromisos, les dependències o l'estat del cicle de vida d'un servei l'hauria d'actualitzar, amb revisions periòdiques i un propietari responsable de la seva vigència. Un catàleg desactualitzat perd credibilitat de seguida.

Publicació. Al portal d'autoservei o a la intranet, amb cercador i integració amb l'eina de tiquets: sol·licitar un servei ha de ser el mateix gest que consultar-lo. El catàleg de negoci es publica a les persones usuàries autoritzades —el mateix «qui se li hagi autoritzat l'accés» de la formulació d'ITIL v3 citada a l'inici—; el tècnic, només internament.

Governança. Segons ITIL v3, la gestió del catàleg de serveis és un procés que es descriu dins el llibre de Disseny del Servei (Service Design) —no dins Estratègia, que tracta la cartera a nivell estratègic; ni dins Transició, que desplega els canvis; ni dins Operació, que gestiona el dia a dia—. En ITIL 4 el mateix contingut es reformula com a pràctica de gestió del servei, sense el marc dels quatre llibres. Té com a interfícies la gestió del nivell de servei (§6), la gestió de la capacitat i la disponibilitat, la gestió de la demanda i la gestió financera dels serveis.

5. Les cartes de servei

Instrument propi del sector públic, que no s'ha de confondre amb el catàleg: mentre el catàleg informa de portes endins de què disposa l'organització, la carta de servei és el compromís que es fa davant la ciutadania. La Llei 19/2014, de transparència, accés a la informació pública i bon govern, regula les cartes de servei dins el marc dels serveis públics bàsics (art. 59) i en fixa el contingut mínim, els compromisos de qualitat i les regles d'aprovació i publicació aplicables —no és un deure incondicional per a qualsevol administració i qualsevol servei.

Contingut típic: dades identificatives de l'organisme, serveis prestats, compromisos de qualitat mesurables, els indicadors per verificar-los, drets dels usuaris i el sistema de queixes i suggeriments.

Es classifiquen per l'abast del compromís, mai per un altre criteri: de servei concret, d'unitat o organisme, d'àmbit territorial i interadministratives (quan diverses administracions es comprometen juntes sobre un servei compartit). No existeix —i és el distractor habitual— una classificació per «processos interns»: la carta és un document adreçat al ciutadà, no una eina de gestió interna.

A l'Ajuntament de Barcelona, qui les aprova de manera efectiva és la Comissió de Govern, no el Consell Plenari ni l'alcaldia: és una dada de règim especial municipal, i el reflex d'atribuir-ho a l'òrgan de màxima representació política és, precisament, el parany.

Relació amb l'SLA: la carta és el compromís públic; l'SLA és l'acord negociat amb un client concret. Els compromisos de la carta s'han de poder sostenir sobre els SLA i OLA de rerefons —si la carta promet un termini que cap acord intern garanteix, el compromís és fals.

6. Els acords de nivell de servei

La gestió del nivell de servei (SLM, Service Level Management) té un objectiu concret i únic: assegurar que es proporciona el nivell de servei acordat per als serveis de TI actuals. No és el mateix que:

I és l'SLM, no cap altra pràctica veïna, qui negocia, fa seguiment i informa de si els serveis assoleixen els seus objectius davant el client. La millora contínua identifica i implementa millores, però no reporta el compliment; la gestió de relacions amb el negoci —BRM— gestiona la relació estratègica, no els informes de rendiment; i la gestió de la disponibilitat només cobreix un dels atributs (§6.6), no el conjunt dels objectius del servei.

6.1 Qui signa amb qui: SLA, OLA i UC

Els tres acords no es distingeixen pel que prometen, sinó per amb qui es firmen:

SLA OLA UC
Entre qui proveïdor de serveis i client proveïdor de serveis i una altra unitat interna proveïdor de serveis i un tercer extern
Naturalesa acord de servei, contractual si el client és extern intern, mai contractual contracte legalment vinculant
Per què existeix és el compromís que es mesura perquè el proveïdor pugui complir l'SLA des de dins perquè el proveïdor pugui complir l'SLA des de fora

Els tres acords al voltant del proveïdor de serveisEl mateix compromís, amb tres noms segons amb qui se signa: contractual amb el client, intern amb una altra àrea, i legalment vinculant amb un tercer.ClientProveïdor externUnitat internauna altra àrea de TIProveïdor de serveis (TI)SLA — acord de nivell de serveiOLA — acord operatiu, no contractualUC — contracte legalment vinculant

En un plec públic d'adquisició, l'element que fixa indicadors de qualitat mesurables i el grau de consecució exigible a l'adjudicatari és sempre un acord de nivell de servei —de vegades anomenat ANS (Acord de Nivell de Servei) als plecs, la mateixa sigla en la seva forma catalana—, no unes fites de facturació (que regulen quan es paga, no amb quina qualitat) ni un model d'excel·lència com l'EFQM (European Foundation for Quality Management), que no és cap mecanisme contractual. El parany hi és en la perspectiva: si l'Administració el signa com a client d'un adjudicatari extern, és un SLA; si es mira des dels serveis que la unitat de TI presta després als seus propis usuaris, el mateix contracte fa de UC que els sosté per fora. Un OLA mai hi encaixa quan les dues parts són organitzacions diferents: és, per definició, l'acord de dues unitats de la mateixa casa.

6.2 Contingut d'un SLA

Un SLA ha d'incloure sempre objectius de servei mesurables —disponibilitat, temps de resposta, temps de resolució, rendiment— amb el seu procediment de mesura, l'horari de cobertura, les exclusions i el procediment d'escalat i revisió. No n'hi ha prou amb només penalitzacions (§6.5), ni és un lloc per a detalls tècnics interns de la solució —això és documentació tècnica, no un SLA—, ni es limita a informes històrics de rendiment, que són una sortida de la seva mesura i no un contingut fundacional de l'acord.

6.3 Estructures d'un SLA

Negociar un SLA es complica quan a l'altra banda no hi ha un interlocutor definit per parlar amb l'organització de TI. En canvi, ajuden a l'acord: personal habituat a expressar les seves necessitats de servei, serveis TI ja ben definits i avaluacions sistemàtiques del seu ús —si aquestes tres condicions es donen, l'acord és fàcil; la mancança d'interlocutor és, de les quatre, l'única que el dificulta.

6.4 Del requisit a l'indicador: SLR, SLO i SLI

Abans que existeixi cap acord signat, el negoci ja sap què necessita: això es recull en l'SLR (Service Level Requirements). Un cop negociat, cada objectiu concret que entra a l'SLA és un SLO; i la xifra real que es mesura per comprovar si es compleix un SLO és l'SLI. L'ordre és sempre el mateix: es defineix el requisit, es pacta l'objectiu, es mesura l'indicador i és l'acord —no l'indicador— el que es dona per complert o incomplert.

6.5 Penalitzacions per incompliment

Un SLA sense conseqüència per l'incompliment és una declaració d'intencions. Al sector públic, les penalitzacions no es pacten lliurement: les regula la Llei 9/2017, de contractes del sector públic, que exigeix que estiguin previstes al plec i que siguin proporcionals a la gravetat de l'incompliment, sense caràcter sancionador.

En el mercat privat i al núvol, el mecanisme habitual són els crèdits de servei (service credits): no es paga una multa, es descompta un percentatge de la factura del període incomplert, com a compensació i no com a indemnització del dany.

6.6 La relació amb la disponibilitat i la capacitat

L'SLA fixa l'objectiu —per exemple, un 99,9 % de disponibilitat—; qui l'ha de fer possible és la gestió de la capacitat i la disponibilitat, que dissenya la redundància, dimensiona la infraestructura i mesura si el compromís se sosté. Comprometre un objectiu de disponibilitat o de rendiment sense un pla de capacitat que l'aguanti és el mateix error que un SLA sense OLA ni UC de rerefons: una promesa que no té qui la sostingui per darrere.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 21

Gestió de la capacitat i disponibilitat TIC

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

Enunciat oficial. Gestió de la capacitat i disponibilitat TIC en ITIL v4. Monitoratge, previsió i optimització de recursos.


1. Gestió de la capacitat i el rendiment

Propòsit (ITIL, Information Technology Infrastructure Library, 4): assegurar que els serveis assoleixen l'acompliment acordat i esperat, satisfent la demanda actual i futura de manera rendible.

Objectius d'ITIL v3 per a la gestió de la capacitat:

No és objectiu de la gestió de la capacitat «garantir la disponibilitat del servei» (això és de la gestió de la disponibilitat), ni «reduir el cost de la infraestructura» com a finalitat en si. Aquestes són les distractores habituals de la pregunta «un dels següents NO és objectiu de la gestió de la capacitat».

1.1 Els tres subprocessos (ITIL v3)

Subprocés Focus Pregunta
Gestió de la capacitat del negoci requisits futurs derivats dels plans de negoci quanta capacitat necessitarem d'aquí a un any?
Gestió de la capacitat del servei rendiment i càrrega dels serveis en producció, extrem a extrem el servei respon dins l'SLA amb la càrrega actual?
Gestió de la capacitat dels components ús i rendiment de cada component (CPU (Central Processing Unit), memòria, disc, xarxa, llicències) quin component està a prop de saturar-se?

1.2 Activitats

1.3 El pla de capacitat

Document que recull la situació actual, les previsions de demanda, els escenaris i les inversions necessàries amb el seu calendari. Es revisa almenys anualment i cada cop que hi ha un canvi rellevant.

CDB (Capacity Database) / CMIS (Capacity Management Information System): repositori amb totes les dades de capacitat i rendiment.

1.4 Proves de rendiment

Tipus Objectiu
De càrrega comprovar el comportament amb la càrrega esperada
D'estrès portar el sistema més enllà del límit per trobar el punt de ruptura i com falla
De resistència (soak/endurance) càrrega sostinguda durant hores o dies per detectar fuites de memòria i degradació
De pic (spike) increments sobtats i breus
D'escalabilitat com respon en afegir recursos
De volum comportament amb grans volums de dades

Eines: JMeter, Gatling, k6, Locust, LoadRunner, Taurus, Artillery. La bona pràctica quan es vol augmentar la visió dels resultats és disposar d'una segona eina independent que validi les mesures de la primera, perquè cada eina té els seus biaixos de mesura i de generació de càrrega.

1.5 Gestió de la demanda i reducció de la incertesa

Una demanda mal gestionada és font de risc en els dos sentits: capacitat de més genera cost sense crear valor (encara que sempre cal un cert marge de reserva per sostenir el nivell de servei), i capacitat de menys degrada la qualitat dels serveis ja aprovisionats i limita el creixement del servei.

Per reduir la incertesa respecte a la demanda, la gestió de la capacitat s'apoia en dues línies:

El procés complet de govern de la demanda —canal d'entrada, classificació, priorització, comitès— es desenvolupa a tic/gestion-de-la-demanda-tic; aquí queda la seva relació directa amb la incertesa que la planificació de capacitat ha d'absorbir.


2. Gestió de la disponibilitat

Propòsit (ITIL 4): assegurar que els serveis lliuren els nivells de disponibilitat acordats per satisfer les necessitats de clients i usuaris.

Objectiu d'ITIL v3: garantir que el nivell de disponibilitat lliurat en tots els serveis iguala o supera les necessitats acordades actuals i futures del negoci, de manera rendible.

Valor per al negoci: la gestió de la disponibilitat aporta que els serveis de TI (Tecnologies de la Informació) estiguin disponibles quan el negoci els necessita, reduint la freqüència i la durada de les interrupcions, i assegurant que els nivells de disponibilitat es dissenyen, mesuren i gestionen de manera proactiva i alineada amb les necessitats i la criticitat de cada procés de negoci, i al cost justificat. Aquesta formulació és la que apareix a l'examen.

2.1 Disponibilitat, fiabilitat, mantenibilitat i servibilitat

2.2 Càlcul

Disponibilitat (%) = (TAS − TI) / TAS × 100

on TAS = temps acordat de servei i TI = temps d'indisponibilitat dins del temps acordat.

Regles que decideixen si el càlcul és correcte:

Forma equivalent del càlcul, expressada amb els temps mitjans:

Disponibilitat = MTBF / (MTBF + MTTR)

on MTTR (Mean Time To Repair) és, a efectes d'aquest càlcul, el mateix temps mitjà de restauració que el MTRS.

La taula dels «nous»: cada nou de disponibilitat redueix la indisponibilitat anual per deu (sobre un any de 365 dies = 525.600 minuts):

Disponibilitat Indisponibilitat anual
99 % (dos nous) ≈ 3,65 dies (87,6 h)
99,9 % (tres nous) ≈ 8,76 h (≈ 525 min)
99,99 % (quatre nous) ≈ 52,6 min
99,999 % (cinc nous) ≈ 5,3 min
99,9999 % (sis nous) ≈ 31,5 s

Disponibilitat de components en sèrie i en paral·lel: en sèrie es multipliquen les disponibilitats (i el conjunt és menys disponible que qualsevol component); en paral·lel (redundància) la indisponibilitat és el producte de les indisponibilitats, i el conjunt és més disponible.

Components en sèrie contra components en paral·lelEls mateixos dos components, connectats de dues maneres. En sèrie les disponibilitats es multipliquen i el conjunt val menys que qualsevol de les peces; en paral·lel, el conjunt val més que totes dues.En sèrieEn paral·lelA99 %El conjunt: 99,99 %millor que cada peçaB99 %A99 %B99 %El conjunt: 98,01 %pitjor que cada peça

2.3 Tècniques d'anàlisi

2.4 Tècniques de disseny

Redundància (activa/passiva, N+1, 2N), clústers, balanceig de càrrega, replicació, failover automàtic, eliminació de SPOF, desacoblament (cues, circuit breakers, degradació elegant) i desplegament multizona. → temes 55 i 58.

2.5 Rols i responsabilitats: la matriu RACI aplicada

La matriu RACI (Responsible, Accountable, Consulted, Informed) —qui és R (Responsible, executa), A (Accountable, respon del resultat), C (Consulted, es consulta) i I (Informed, s'informa)— no és pròpia d'aquest tema: la teoria completa es desenvolupa a tic/pmbok-liderazgo-equipo-y-recursos. Aplicada al procés de gestió de la disponibilitat:


3. Monitoratge

Monitoratge: observació sistemàtica i contínua d'un sistema, servei o component per detectar-ne els canvis d'estat. La gestió d'esdeveniments hi actua a sobre → tema 18.

Què es monitora:

Capa Exemples
Infraestructura CPU, memòria, disc, IOPS (Input/Output Operations per Second), temperatura, alimentació
Xarxa ample de banda, latència, pèrdua de paquets, errors, estat d'interfícies
Sistema operatiu i middleware processos, serveis, cues, connexions, GC (Garbage Collection)
Aplicació (APM: Application Performance Monitoring) temps de resposta per transacció, taxa d'error, traces distribuïdes
Experiència d'usuari monitoratge sintètic (robots que executen transaccions) i RUM (Real User Monitoring)
Negoci tràmits completats, transaccions per minut, taxa d'abandonament

Tipus de monitoratge: actiu/proactiu (consulta i provoca accions) vs passiu/reactiu (rep esdeveniments); sense agent (SNMP: Simple Network Management Protocol; WMI: Windows Management Instrumentation; SSH: Secure Shell; API: Application Programming Interface) vs amb agent.

Protocols i formats: SNMP, syslog, NetFlow/sFlow/IPFIX (Internet Protocol Flow Information eXport), WMI, JMX (Java Management eXtensions), OpenTelemetry, Prometheus exposition format, IPMI (Intelligent Platform Management Interface)/Redfish per a maquinari. El detall de SNMP —versions, operacions GET/SET/TRAP, MIB (Management Information Base)— es desenvolupa a tic/plataforma-de-observabilidad.

Eines habituals: Zabbix, Nagios/Icinga, Checkmk, PRTG, Prometheus, Grafana, Elastic Stack, Dynatrace, Datadog, New Relic, AppDynamics, SolarWinds, Centreon, LibreNMS. → tema 23.

Definició de llindars: cal establir-los sobre la tendència i el comportament normal, no sobre valors absoluts arbitraris, i cal evitar la fatiga d'alertes: si tot alerta, res no alerta. Bones pràctiques: alertes accionables (cada alerta té una acció associada), basades en símptomes i no en causes, amb agrupació i supressió durant manteniments, i amb revisió periòdica dels llindars.


4. Previsió i optimització


Claus d'examen


Per recordar

Tema 22

Mesura i millora contínua dels serveis TIC

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

Enunciat oficial. Mesura i millora contínua dels serveis TIC. KPIs, CSFs i quadres de comandament de serveis en el marc de ITIL v4.


1. La millora contínua a ITIL

Millora contínua (ITIL 4 — Information Technology Infrastructure Library): pràctica i component del Sistema de Valor del Servei que consisteix a alinear les pràctiques i els serveis de l'organització amb les necessitats canviants del negoci mitjançant la identificació i millora contínues de serveis, components, pràctiques o qualsevol altre element implicat en la gestió eficient i efectiva dels productes i serveis. Aplicada als serveis TIC (Tecnologies de la Informació i la Comunicació), vol dir mesurar el que es lliura i actuar sobre el que la mesura destapa.

Responsabilitat: la millora contínua és responsabilitat de tothom, no d'un departament. Això no vol dir que no tingui amo: l'organització n'ha de designar un propietari i mantenir un registre d'oportunitats de millora on es prioritzen (§1.6).

El marc general d'ITIL —les quatre dimensions, el Sistema de Valor del Servei, la cadena de valor i les 34 pràctiques— no es desenvolupa aquí: → tema 14.

1.1 El model de millora contínua d'ITIL 4 — set passos

  1. Quina és la visió? — es connecta amb la visió i els objectius de l'organització.
  2. On som ara? — avaluació objectiva de la situació actual (línia base). Sense línia base no es pot demostrar cap millora: aquest és el pas que més es menysprea.
  3. On volem estar? — objectius mesurables.
  4. Com hi arribem? — pla.
  5. Passa a l'acció — executar.
  6. Hem arribat? — verificar amb mesures.
  7. Com mantenim l'impuls? — consolidar i institucionalitzar.

Què hi va afegir ITIL 4. El model ve del model CSI d'ITIL v3, que planteja les mateixes preguntes menys la cinquena. ITIL 4 hi intercala «passa a l'acció» entre «com hi arribem?» i «hem arribat?»: és el pas que impedeix que el pla es quedi al paper, i la diferència que es pregunta quan un enunciat contraposa les dues versions.

Compte amb la sigla CIP. El CIP (Continual Improvement Process, procés de millora contínua) és el nom genèric que la gestió de la qualitat dona a la millora per petits passos, hereva del kaizen i emparentada amb el PDCA (§1.3). ITIL no fa servir la sigla: el que ITIL 4 té és la pràctica de millora contínua i el model d'aquests set passos. Si un enunciat parla de «CIP», parla del concepte general de qualitat, no d'un artefacte d'ITIL.

1.2 ITIL v3: la Millora Contínua del Servei (CSI)

A ITIL v3 la millora contínua no era una pràctica sinó una fase sencera del cicle de vida del servei, la cinquena, anomenada Millora Contínua del Servei (CSI — Continual Service Improvement), amb el seu propi llibre. ITIL 4 va eliminar el llibre i el cicle de vida: la matèria hi passa a ser una de les 34 pràctiques de gestió, rebatejada simplement millora contínua. El cicle de vida de v3 sencer, amb les seves cinc fases, es desenvolupa al tema 14.

La distinció importa perquè els dos vocabularis cauen a l'examen, i l'enunciat sol dir de quina versió parla: si diu «v3» o «cicle de vida», la resposta porta les lletres CSI; si diu «ITIL 4» o «pràctica», porta millora contínua.

El gestor de CSI (CSI manager) és el rol propietari de la millora a v3. Les seves responsabilitats clau:

El que no és seu: liderar el desenvolupament de serveis nous —això és disseny i transició— ni «crear una organització imaginativa que estimuli la innovació», que és un tret genèric de lideratge. Les dues formulacions són els distractors amb què el tribunal ha construït la pregunta (TS-TIC 2018 pràctica, s2-p30), i les dues frases anteriors són les respostes correctes.

El procés de millora en 7 passos és l'altre artefacte de la fase CSI, i no s'ha de confondre amb el model de §1.1: el model planteja preguntes de direcció, i aquest és el procediment de mesura que les respon.

  1. Identificar l'estratègia de millora (visió, necessitat de negoci, objectius).
  2. Definir què es mesurarà.
  3. Recopilar les dades (qui, com, quan; integritat de les dades).
  4. Processar les dades (format, agregació, precisió).
  5. Analitzar la informació i les dades — tendències, objectius, millores necessàries.
  6. Presentar i utilitzar la informació — resum, plans d'acció.
  7. Implementar la millora.

1.3 El cicle de Deming

PDCA — Plan, Do, Check, Act. És el model de gestió en què es basa la millora contínua del servei. Cada volta consolida el nivell assolit (la «falca» que impedeix retrocedir) i n'inicia una de nova.

El cicle PDCAQuatre etapes que tornen a començar: no hi ha final, només una volta més.PPlanplanificarDDoferCCheckverificarAActactuar

S'aplica a qualsevol procés, no només als de gestió de TI (Tecnologies de la Informació) o de qualitat formal: si es planifica un canvi, s'implementa, i se n'avalua l'impacte, el conjunt és un cicle PDCA encara que l'àmbit sigui, per exemple, administratiu o de contractació.

Exemple: unes entrades de dades es recullen a mà de documents, cosa que alenteix el còmput d'uns criteris expressats en fórmules i pot introduir errors. Un grup interdisciplinari avalua la situació, arriba a unes conclusions i decideix proposar automatitzar la recollida; la proposta és acceptada, s'implementa i se n'avalua l'impacte. Això és un PDCA complet — Plan (proposta), Do (implementació), Check (avaluació) i Act (adopció) — encara que l'àmbit no sigui, en sentit estricte, un procés de TI sinó, per exemple, la contractació pública.

1.4 Altres mètodes i tècniques de millora

El catàleg que ITIL recull sota l'etiqueta «mètodes i tècniques de millora contínua» té un tret comú: totes mesuren o comparen contra un referent —un estàndard, una altra organització, un objectiu—. Són:

Al costat, i fora d'aquest catàleg, hi ha metodologies de millora nascudes a la indústria i al món àgil que sí que milloren però no són tècniques de mesura o comparació: Lean (eliminació de malbaratament, Kaizen, Value Stream Mapping, 5S), Six Sigma (DMAIC: Define, Measure, Analyze, Improve, Control), la Teoria de les Restriccions, les retrospectives d'esprint i els post-mortems sense culpables. I el pla de millora del servei (SIP — Service Improvement Plan) no és una tècnica sinó el pla que en surt (§1.6).

Pregunta habitual: quin NO és un mètode o tècnica de millora contínua? La distinció que fa servir el tribunal és la del paràgraf anterior: la retrospectiva d'esprint —una reunió d'equip per reflexionar sobre la forma de treballar— no compta com a tècnica de millora contínua, mentre que les avaluacions, el benchmarking i el quadre de comandament integral sí (TS-TIC 2023, específic, s0-p42). També apareixen com a distractors ITIL mateix (que és un marc, no una tècnica), PMBOK (Project Management Body of Knowledge), TOGAF (The Open Group Architecture Framework) o COBIT (Control Objectives for Information and related Technology), i respostes com «gestió d'incidents» o «gestió de canvis», que són pràctiques operatives.

1.5 Anàlisi de GAP

Anàlisi de GAP (gap analysis): eina de negoci que compara l'estat actual d'una organització amb l'estat futur desitjat per identificar les àrees on hi ha marge de millora, i que pot incloure necessitats i aspectes desitjables encara no coberts. La diferència identificada (el «buit» o gap) és la base per construir el pla d'accions que la tanca.

Operacionalitza directament els passos 2 i 3 del model de millora contínua d'ITIL 4 (§1.1): on som ara? és l'estat actual; on volem estar?, l'estat desitjat.

1.6 El registre de millores i la priorització d'iniciatives

Registre de millora contínua (CIR — continual improvement register): el registre únic i viu on l'organització apunta i prioritza totes les oportunitats de millora detectades, des que algú les identifica fins que es tanquen o es descarten. Una oportunitat que no s'apunta enlloc es perd, i aquest és l'artefacte que ho impedeix. La sigla depèn de la versió d'ITIL:

Versió Com es diu Observació
ITIL v3 / edició 2011 registre CSI (CSI register) s'hi introdueix el 2011; abans, la millora acordada es vehiculava només pel SIP
ITIL 4 registre de millora contínua (CIR — continual improvement register) mateix artefacte, nom nou; pot haver-n'hi més d'un (per equip, per servei, per organització)

Què hi consta de cada iniciativa: la descripció de l'oportunitat i d'on ha sortit (una revisió del servei, un post-mortem, una queixa, una desviació d'un KPI), el benefici esperat, el cost o esforç estimat, el risc d'implantar-la, el propietari, l'estat i la data. El registre serveix precisament per fer visible el conjunt: què s'està fent, què ja està tancat i què s'ha deixat aparcat per revisar-ho més endavant.

Com es prioritza. No hi ha una fórmula normativa, sinó un criteri constant: primer les de benefici alt, urgència alta i cost baix, ponderant a més el risc d'execució i l'alineació amb els objectius de negoci. Aquesta priorització és el que converteix una llista d'idees en una cartera de millora; sense ella el registre és un abocador.

Registre i pla no són el mateix. El registre és la llista prioritzada de candidates; el pla de millora del servei (SIP — Service Improvement Plan) és el pla formal d'una millora ja aprovada, amb accions, responsables i terminis. Del registre surten SIP, no a l'inrevés. I el registre de millores tampoc és el registre de riscos ni la cua de peticions de canvi: aquells recullen amenaces i canvis a autoritzar, aquest recull oportunitats.

A la ISO 20000 el que aquí és bona pràctica és requisit auditable: la norma exigeix determinar i seleccionar oportunitats de millora i establir criteris d'avaluació i priorització. El desenvolupament normatiu és matèria d'aquell tema; aquí n'hi ha prou de saber que ITIL i la ISO diuen el mateix amb força distinta.


2. CSF, KPI i mètriques

2.1 Definicions

Relació: CSF → KPI → mètriques. Cada CSF té diversos KPI; cada KPI s'alimenta de diverses mètriques.

Exemple: CSF «reduir l'impacte dels incidents en el negoci» → KPI «percentatge d'incidents crítics resolts dins l'SLA (Service Level Agreement)», «MTTR (Mean Time To Repair) dels incidents crítics» → mètriques «hora d'obertura», «hora de resolució», «prioritat».

2.2 Els tres tipus de mètriques d'ITIL

2.3 La funció dels indicadors en la millora contínua

Els indicadors serveixen per:

Aquests quatre verbs — validar, dirigir, justificar, intervenir — són la resposta a la pregunta «quina és la funció principal dels indicadors en el context de la millora contínua». Els indicadors no serveixen per avaluar les persones: fer-ho destrueix la fiabilitat de les dades.

2.4 Com han de ser els indicadors

2.5 Mètrica vs indicador

Diferència clau que es pregunta: una mètrica és una mesura en brut d'un atribut, sense context; un indicador és una mètrica interpretada respecte d'un objectiu o llindar, que indica si l'acompliment és acceptable i, per tant, suporta una decisió. «250 incidents al mes» és una mètrica; «el 92 % dels incidents crítics resolts dins l'SLA, contra un objectiu del 95 %» és un indicador.


3. Quadres de comandament de serveis

Quadre de comandament (dashboard): representació visual, en temps real o periòdica, dels indicadors rellevants per a un públic concret.

Nivells:

Nivell Audiència Contingut Freqüència
Operatiu equips tècnics, Service Desk estat dels serveis, cua de tiquets, alertes actives temps real
Tàctic responsables de servei, caps compliment d'SLA, tendències, capacitat, canvis, problemes setmanal o mensual
Estratègic direcció, comitè TIC, negoci valor lliurat, cost del servei, satisfacció, risc, avanç de la cartera trimestral

Balanced Scorecard aplicat a TI: perspectives de contribució corporativa, orientació a l'usuari, excel·lència operativa i orientació al futur. Al sector públic la perspectiva superior és la missió/ciutadà.

Bones pràctiques de disseny: una pantalla per audiència, contextualitzar sempre (objectiu, tendència, període comparatiu), evitar la decoració (gràfics 3D, semàfors sense llindar definit), i acompanyar cada indicador de l'acció prevista si es desvia.

Informes de servei: la pràctica de mesura i informes (measurement and reporting) d'ITIL 4 té com a propòsit donar suport a la bona presa de decisions i a la millora contínua reduint els nivells d'incertesa, mitjançant la recopilació de dades rellevants sobre diversos objectes gestionats i la seva avaluació vàlida en el context adequat.

Un informe de rendiment del servei no és un bolcat d'indicadors. Perquè serveixi per decidir ha de portar, com a mínim: el període i l'abast (quins serveis), el compliment respecte dels objectius acordats —no el valor a seques—, la tendència contra períodes anteriors, l'explicació de les desviacions i les accions que se'n deriven amb propietari i termini. Aquestes accions són, precisament, les que alimenten el registre de millores (§1.6): un informe que acaba en un gràfic i no en una entrada del registre no ha tancat el cicle.

Quadre de comandament i informe no són el mateix: el quadre és una vista contínua que es consulta, l'informe és un lliurament periòdic que s'envia, es comenta en una revisió del servei i deixa constància. Un no substitueix l'altre.


4. Mesura al sector públic


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 23

Plataforma d'observabilitat

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

Enunciat oficial. Plataforma d'Observabilitat: Components, característiques i reptes d'implantació.


1. Concepte

Observabilitat: capacitat de deduir l'estat intern d'un sistema a partir de les seves sortides externes. El terme prové de la teoria de control: un sistema és observable si es pot determinar el seu estat intern observant-ne les sortides.

Observabilitat ≠ monitoratge, i és la distinció que més cau:

Monitoratge Observabilitat
Pregunta funciona? per què no funciona?
Enfocament comprovar condicions conegudes: llindars i comprovacions definits per endavant explorar el sistema per respondre preguntes que no s'havien previst
Tipus de problema «known unknowns» — sé què pot fallar «unknown unknowns» — no sé què buscar
Model reactiu, basat en alertes exploratori, basat en dades riques i correlacionades
Dades mètriques predefinides mètriques, registres i traces d'alta cardinalitat i correlacionats

L'observabilitat inclou el monitoratge: no el substitueix. Un sistema observable permet seguir fent monitoratge, però també investigar sense haver de desplegar codi nou per obtenir informació.


2. Els tres pilars

L'observabilitat es construeix sobre tres tipus de telemetria —els tres pilars— que responen a preguntes diferents i no se substitueixen entre si: amb només un dels tres, hi ha vigilància, no diagnòstic.

Pilar Què és Respon a
Mètriques (metrics) valors numèrics agregats en el temps: comptadors, mesuradors (gauges), histogrames, resums què està passant i quant
Registres (logs) esdeveniments discrets amb marca de temps, idealment estructurats en JSON (JavaScript Object Notation) i amb context què ha passat exactament
Traces (traces) seguiment d'una petició a través de tots els serveis que travessa, formada per spans amb relació pare-fill on s'ha gastat el temps i quin servei ha fallat

Cada pilar té un cost i una precisió diferents: les mètriques són barates i agregades, els registres són cars i literals, i les traces són les úniques que reconstrueixen el camí d'una petició concreta. Sovint s'hi afegeixen dos senyals més: els perfils (profiling) —consum de CPU (Central Processing Unit) i memòria per funció, que OpenTelemetry està normalitzant com a quart senyal— i els esdeveniments de negoci.

El que fa útil la plataforma no són els tres pilars per separat, sinó la seva correlació: poder saltar d'un pic d'una mètrica a les traces d'aquell moment i, d'allà, als registres del span concret. Sense correlació hi ha tres eines, no una plataforma d'observabilitat.


3. Components d'una plataforma d'observabilitat

Una plataforma d'observabilitat és una cadena: la telemetria es genera al codi, viatja fins a un magatzem i acaba en una pantalla o en una alerta. Cada baula té productes propis, i el disseny consisteix a triar-los de manera que el pas següent segueixi podent correlacionar.

Components d'una plataforma d'observabilitatSis etapes en cadena. Res del que no s'ha instrumentat es pot consultar després, i és per això que la primera etapa decideix el sostre de totes les altres.Alerta i respostaConsulta i visualitzacióEmmagatzematgeInstrumentacióProcessamentRecol·lecció

  1. Instrumentació: codi i agents que generen la telemetria. Pot ser manual (biblioteques al codi), automàtica (agents que injecten instrumentació sense tocar el codi) o eBPF (extended Berkeley Packet Filter, a nivell de nucli, sense agent ni canvis al codi). S'hi afegeixen el monitoratge d'usuari real —telemetria del navegador de qui fa servir el servei— i el monitoratge sintètic, que simula transaccions des de fora per detectar caigudes abans que hi hagi cap usuari.
  2. Recol·lecció i transport: agents i col·lectors (OpenTelemetry Collector, Fluent Bit, Vector, Logstash, Beats), amb buffering i reintent. La recollida pot ser per extracció (pull: el sistema va a buscar les dades, com fa Prometheus) o per empenta (push: l'aplicació les envia).
  3. Processament: enriquiment amb metadades, normalització, mostreig (sampling), filtratge, agregació i correlació mitjançant identificadors comuns (trace id, span id).
  4. Emmagatzematge: bases de dades de sèries temporals per a mètriques (Prometheus, VictoriaMetrics, InfluxDB, Mimir), índexs de text per a registres (Elasticsearch/OpenSearch, Loki), i magatzems de traces (Tempo, Jaeger).
  5. Consulta i visualització: llenguatges de consulta —PromQL i LogQL (Prometheus i Loki), KQL (Kusto Query Language, Microsoft) i SPL (Search Processing Language, Splunk)— i quadres de comandament (Grafana, Kibana).
  6. Alerta i resposta: motor de regles, deduplicació, agrupació, encaminament i guàrdies (Alertmanager, PagerDuty, Opsgenie), i integració amb la gestió d'incidents.
  7. Capa d'anàlisi avançada: AIOps — detecció d'anomalies, correlació automàtica, agrupació d'alertes i anàlisi de causa arrel assistida.
  8. Govern: retenció, control d'accés, anonimització i control de costos.

OpenTelemetry (OTel): projecte de la CNCF (Cloud Native Computing Foundation) que estandarditza la generació, recol·lecció i exportació de mètriques, registres i traces. És agnòstic de proveïdor: instrumentes un cop i pots canviar de rerefons. Ha absorbit OpenTracing i OpenCensus i és avui l'estàndard de facto. Adoptar OTel és la manera d'evitar el bloqueig de proveïdor en observabilitat.


3.1 SNMP, el protocol clàssic de gestió de xarxa

SNMP (Simple Network Management Protocol) és el protocol estàndard de gestió d'elements de xarxa —encaminadors, commutadors, tallafocs—, anterior a l'observabilitat moderna i encara vigent quan aquests dispositius no exposen telemetria d'OpenTelemetry. Intercanvia informació entre un gestor —el NMS (Network Management System), a la solució d'administració de xarxa— i un agent a cada dispositiu.

L'agent exposa les seves variables en una MIB (Management Information Base), una estructura jeràrquica on cada valor té un OID (Object Identifier) únic; la MIB-II en normalitza els objectes bàsics comuns a qualsevol dispositiu. Tres operacions bàsiques: GET (el gestor llegeix un valor), SET (el gestor el modifica) i TRAP (l'agent notifica un esdeveniment sense que li ho demanin — monitoratge passiu).

SNMPv1 i v2c autentiquen amb una community string que viatja en clar; SNMPv3 hi afegeix autenticació i xifratge, i és l'única versió recomanable en producció.


3.2 Alertes i correlació d'esdeveniments

Una regla d'alerta és una condició sobre una consulta mantinguda un temps mínim: no salta al primer pic, sinó quan la condició persisteix. Sobre això, la plataforma ha de reduir el soroll abans de despertar ningú:

La correlació d'esdeveniments és el pas que agrupa esdeveniments relacionats per topologia (quins components depenen de quins), per temps (què ha passat en la mateixa finestra) i per identificador (mateixa petició, mateix servei), i decideix quin d'ells és la causa i quins són conseqüència. És el que evita que una sola caiguda generi centenars d'alarmes; AIOps hi afegeix detecció d'anomalies sense llindar fix i suggeriment de causa arrel.

Sobre què s'alerta: sobre símptomes visibles per l'usuari —latència, errors— i sobre el ritme de consum (burn rate) del pressupost d'error, no sobre llindars de components («CPU > 80 %»), que salten sovint sense que ningú noti res.

Frontera. La pràctica de gestió d'esdeveniments d'ITIL (Information Technology Infrastructure Library) —què és un esdeveniment, els tipus informatiu, advertència i excepció, i els eixos actiu/passiu i reactiu/proactiu— es desenvolupa al tema 18. Aquí hi ha la plataforma tècnica que els genera i els correlaciona.


4. Característiques d'una plataforma d'observabilitat

Aquestes són les propietats que ha de tenir una plataforma perquè sigui d'observabilitat i no un conjunt d'eines de monitoratge. Les tres primeres són les que marquen la diferència; la resta són exigències d'explotació que decideixen si la plataforma és sostenible.

  1. Unificació dels tres pilars en un sol producte: mètriques, registres i traces al mateix lloc, amb el mateix model d'accés i el mateix vocabulari d'etiquetes.
  2. Correlació per identificadors comuns: trace id i span id a les traces, exemplars que enllacen una mètrica amb una traça concreta, i camps estructurats als registres. És el que permet la navegació guiada —de la gràfica a la traça i d'aquesta al registre— sense canviar d'eina.
  3. Alta cardinalitat i alta dimensionalitat: poder etiquetar la telemetria amb identificador d'usuari, de petició, de versió o de client i segmentar-hi després. La cardinalitat és el nombre de valors diferents que pot prendre una etiqueta; l'observabilitat en necessita molta i és justament el que dispara el cost. És la tensió central del disseny.
  4. Consulta exploratòria ad hoc: es poden fer preguntes que no s'havien previst, sense definir una mètrica nova ni desplegar codi.
  5. Temps real: ingesta i consulta amb latència de segons, perquè serveixi durant l'incident i no només per a l'anàlisi posterior.
  6. Instrumentació estàndard i agnòstica de proveïdor: OpenTelemetry i convencions semàntiques comunes d'atributs.
  7. Descobriment automàtic de serveis, de dependències i del mapa de serveis, generat a partir de les traces i no d'un inventari mantingut a mà.
  8. Escalabilitat elàstica i multi-inquilí: una sola plataforma per a moltes àrees, amb aïllament de dades, de permisos i de quotes entre elles.
  9. Retenció per capes i control del cost: dades detallades poc temps, agregades molt temps, i cost visible per equip.
  10. Alertes basades en objectius de servei i integrades amb la gestió d'incidents, en lloc de llindars per component.
  11. Govern de les dades: control d'accés per rol, anonimització del que pugui ser dada personal i traçabilitat de qui consulta què.

5. Arquitectura per a microserveis

En una arquitectura de microserveis, l'observabilitat escalable requereix:


6. Eines de visualització

Grafana és l'eina de referència per visualitzar mètriques, registres i traces en temps real en entorns d'observabilitat: és de codi obert, agnòstica de font de dades i s'integra amb Prometheus, Loki, Tempo, Elasticsearch, InfluxDB i desenes més. Alternatives: Kibana (per a l'Elastic Stack), Chronograf i les consoles pròpies dels productes comercials.

Un quadre de comandament tècnic útil no és una paret de gràfiques: porta les senyals daurades de cada servei, un panell d'estat dels objectius de servei amb el pressupost d'error consumit, el mapa de serveis, i enllaços de baixada que porten de la gràfica a la traça i d'aquesta al registre. Les variables de quadre —entorn, servei, versió— eviten haver de mantenir un panell per equip.

Piles habituals:

Pila Components
LGTM (Loki, Grafana, Tempo, Mimir) Loki (logs), Grafana (visualització), Tempo (traces), Mimir (mètriques)
Prometheus + Grafana mètriques + alertes + visualització
ELK (Elasticsearch, Logstash, Kibana) Elastic Stack: Elasticsearch, Logstash/Beats, Kibana, i APM (Application Performance Monitoring)
Comercials Dynatrace, Datadog, New Relic, Instana (IBM), Splunk Observability, Elastic Observability, Grafana Cloud, AppDynamics
Traçat Jaeger, Zipkin, Tempo

Plataforma d'observabilitat o eina de monitoratge? Són plataformes d'observabilitat en sentit ple Dynatrace, Datadog, New Relic, Instana (IBM), Splunk Observability, Elastic Observability i Grafana Cloud. Són eines de monitoratge clàssic —comproven disponibilitat i llindars de components, sovint per SNMP o amb agent, i no correlacionen els tres pilars— Nagios, Icinga, Zabbix, Checkmk, Centreon, PRTG (Paessler Router Traffic Grapher), Cacti, LibreNMS i SolarWinds. I no són ni una cosa ni l'altra Ansible o Jenkins, que són d'automatització i integració contínua.

El criteri no és la marca sinó la capacitat: diversos fabricants de monitoratge clàssic venen avui línies pròpies d'«observabilitat», i el que decideix és si el producte correlaciona els tres pilars o només vigila llindars.

Substituir una plataforma de monitorització comercial per codi obert al núvol. Quan el contracte d'administració i manteniment de la plataforma actual de monitorització està proper a finalitzar i es considera que els seus costos econòmics no compensen el rendiment que proporciona, l'opció que cal plantejar als caps és establir una solució similar de monitorització al núvol, on els costos són inferiors i l'administració és més àgil. La solució de codi obert que pot cobrir aquesta necessitat és la pila Prometheus + Grafana: Prometheus per a la recol·lecció i l'emmagatzematge de mètriques, i Grafana com a plataforma de visualització que crea panells combinant les mètriques recollides a diverses fonts en un sol quadre de comandament. Aquesta és la formulació literal que ha caigut, i la resposta són aquestes dues eines.


7. Beneficis


8. Reptes d'implantació

  1. Volum i cost: la telemetria creix més de pressa que el negoci. Cal mostreig, retencions per capes, agregació i control actiu de la cardinalitat. El cost de l'observabilitat pot superar el de la infraestructura observada si no es governa.
  2. Instrumentació del programari heretat: aplicacions antigues sense instrumentació ni codi disponible; solucions parcials amb agents, eBPF o intermediaris.
  3. Heterogeneïtat: entorns híbrids amb mainframe, màquines virtuals, contenidors i SaaS, cadascun amb els seus formats.
  4. Estandardització: sense convencions comunes de noms, etiquetes i identificadors, la correlació no funciona. És més un problema de govern que tècnic.
  5. Fatiga d'alertes: alertes no accionables, duplicades o sense propietari fan que s'ignorin. Cal alertar sobre símptomes visibles per l'usuari i basar-se en objectius de servei, no en llindars de components.
  6. Cultura i competències: l'observabilitat exigeix que els equips de desenvolupament instrumentin el seu codi i mirin les dades. Sense això, la plataforma queda com una eina d'operacions.
  7. Privadesa i seguretat: els registres i les traces poden contenir dades personals; cal minimització, emmascarament i control d'accés conforme al RGPD, art. 5 i a l'ENS, amb polítiques de retenció alineades.
  8. Bloqueig de proveïdor: la instrumentació propietària dificulta el canvi. La mitigació és OpenTelemetry.
  9. Governança del cicle de vida: qui crea els quadres de comandament, qui els manté, qui esborra els obsolets.
  10. Impacte de la instrumentació: agents i mostreig consumeixen CPU, memòria i xarxa del sistema observat; una plataforma mal dimensionada degrada allò que havia de vigilar.

9. Observabilitat i SRE

L'enginyeria de fiabilitat del servei —SRE (Site Reliability Engineering), formulada per Google— gestiona la fiabilitat amb mètodes d'enginyeria en comptes de per criteri. Fixa objectius mesurables sobre el servei i decideix amb dades quan cal deixar de desplegar canvis i posar-se a estabilitzar. És el vocabulari que millor connecta l'observabilitat amb la gestió de serveis, perquè és el que converteix la telemetria en un criteri de decisió.

SLI ≠ SLO ≠ SLA: l'SLI és la mesura, l'SLO l'objectiu intern i l'SLA el compromís extern. L'SLO s'ha de fixar sempre més exigent que l'SLA, perquè és el marge que avisa abans d'incomplir el contracte.

SRE ≠ DevOps: DevOps enuncia què cal aconseguir —unir desenvolupament i operació—; SRE és una manera concreta i mesurable de fer-ho, amb l'SLO i el pressupost d'error com a mecanisme d'arbitratge entre canviar i estabilitzar.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 24

Automatització i orquestració de serveis TIC. Serveis de RPA

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. Automatització i orquestració de serveis TIC. Serveis de RPA.


1. Automatització i orquestració

Una tasca s'automatitza; un procés s'orquestra.

Nivells d'automatització a les TIC:

Àmbit Exemples
Infraestructura com a codi (IaC) Terraform, OpenTofu, Pulumi, CloudFormation
Gestió de la configuració Ansible, Puppet, Chef, Salt
Orquestració de contenidors Kubernetes, Nomad → tema 41
CI/CD Jenkins, GitLab CI, GitHub Actions, Azure DevOps, Argo CD
Planificació de treballs (job scheduling) UC4/Automic, Control-M, Autosys, Rundeck, Airflow
Automatització de processos de negoci BPM amb motors BPMN (Camunda, Flowable, Activiti)
Automatització d'escriptori RPA
ITSM (Information Technology Service Management, gestió de serveis TIC) fluxos d'aprovació, provisió automàtica de peticions, autoremediació d'incidents

Beneficis: reducció d'errors humans, rapidesa i repetibilitat, traçabilitat i auditoria, alliberament de temps del personal per a tasques de més valor, i coherència entre entorns. Riscos: automatitzar un procés dolent el fa dolent més ràpidament; dependència de scripts sense manteniment; concentració de privilegis en comptes de servei.

Principi d'ITIL (Information Technology Infrastructure Library) 4: «optimitza i automatitza», en aquest ordre. Automatitzar un procés ineficient consolida la ineficiència: els millors processos a automatitzar són els simples i ben entesos, no els que mouen més gent ni els més crítics per al negoci.

1.1 BPM, BPMN, DMN i CMMN

BPM (Business Process Management, gestió de processos de negoci) és una disciplina, no una eina ni un producte: la disciplina per millorar un procés de negoci d'extrem a extrem fent-ne l'anàlisi, modelant-lo en diferents escenaris, executant-lo, monitoritzant-lo i aplicant-hi millora contínua. Els motors BPMN (Camunda, Flowable, Activiti, UC4/Automic) són el suport tècnic que l'implementa, no la disciplina en si.

BPMN (Business Process Model and Notation) és la notació estàndard de l'OMG (Object Management Group) per modelar processos —diagrames de flux amb esdeveniments, activitats i gateways—, adoptada com a norma ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 19510. No és exclusiva d'un tipus de producte (ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BPM): serveix per modelar qualsevol sistema d'informació basat en procediments definits.

L'OMG manté un trio complementari de notacions, cadascuna per a un tipus de treball diferent:

Notació Modela
BPMN el procés: la seqüència de passos d'extrem a extrem
DMN (Decision Model and Notation) la decisió: les regles de negoci que un pas del procés aplica
CMMN (Case Management Model and Notation) el cas: treball no predefinit, on l'ordre de les tasques el decideix qui el gestiona segons com evoluciona la situació

La pregunta que separa les tres notacions és què és el que varia. Si el que està fixat és l'ordre dels passos, es modela en BPMN; si el que canvia és la regla que es decideix dins d'un pas, aquesta regla es treu fora i es modela en DMN; i si no hi ha ordre predefinit perquè el marca qui porta l'assumpte, es modela en CMMN. Separar la regla del flux és precisament el que aporta el DMN: la regla de negoci canvia sovint —un llindar, un barem—, i el procés que la invoca, no.


2. Planificació i orquestració de treballs: UC4/Automic

UC4 Automation Engine (avui Broadcom Automic Automation) és una plataforma de planificació i orquestració de treballs per lots i de processos de negoci molt implantada a l'administració pública i a entorns SAP.

2.1 Arquitectura

Component Funció
Automation Engine (servidor) motor central: planifica, decideix, gestiona la cua i l'estat
Base de dades repositori d'objectes, definicions, històric i estadístiques
Agents el component que s'instal·la als servidors remots i que hi executa les tasques. N'hi ha per a cada plataforma: Windows, UNIX/Linux, SAP, base de dades, JMX (Java Management eXtensions), RA (Rapid Automation)
Clients (interfície) AWI (Automic Web Interface) o el client Java

Pregunta literal: el component de UC4 que s'instal·la als servidors remots i hi executa les tasques és l'AGENT. El motor decideix; l'agent executa.

2.2 Objectes i conceptes

Relació Job–Workflow: el workflow orquestra jobs; un job pot formar part de diversos workflows i un workflow pot contenir altres workflows (imbricació). El job és la unitat d'execució; el workflow, la unitat d'orquestració. Aquesta és la resposta correcta.


3. RPA — Robotic Process Automation

RPA (Robotic Process Automation, automatització robotitzada de processos): tecnologia que utilitza robots de programari que imiten les accions d'un usuari humà sobre la interfície gràfica de les aplicacions per executar processos repetitius i basats en regles.

3.1 Com interactua amb els sistemes

Els robots RPA interactuen amb els sistemes informàtics de la mateixa manera que ho faria una persona: a través de la capa de presentació (la interfície d'usuari), fent clics, escrivint, llegint pantalles i navegant per menús. Per això no requereixen modificar les aplicacions existents ni integracions per API (Application Programming Interface, interfície de programació d'aplicacions), i poden treballar amb sistemes heretats que no ofereixen cap altra via d'integració.

Tècniques de reconeixement: selectors de l'arbre d'interfície (UI (User Interface) Automation, HTML (HyperText Markup Language) DOM (Document Object Model), Java Access Bridge), coordenades de pantalla, OCR (Optical Character Recognition, reconeixement òptic de caràcters) i reconeixement d'imatge. Complementàriament poden usar API, bases de dades i fitxers quan estan disponibles, cosa que sempre és preferible per robustesa.

3.2 Tipus

3.3 Quan és adequat i quan no

Bons candidats: processos d'alt volum, repetitius, basats en regles clares, amb dades estructurades, estables i que travessen múltiples sistemes sense integració.

Mals candidats: processos que exigeixen judici, que canvien sovint, amb entrades no estructurades, amb excepcions freqüents, o de volum baix (no compensa).

3.4 Casos d'ús típics a l'Administració

El denominador comú: sistemes legacy sense API amb els quals cal interactuar «com si fos una persona», i volum prou alt perquè valgui la pena.

3.5 Limitacions davant la IA

Limitació clau del RPA respecte dels sistemes amb IA (Intel·ligència Artificial): el RPA només executa regles predefinides i no aprèn ni s'adapta. No pot gestionar variabilitat, ambigüitat ni dades no estructurades, i qualsevol canvi a la interfície de l'aplicació (posició d'un camp, canvi d'etiqueta, nova versió) trenca el robot i obliga a reprogramar-lo. La IA, en canvi, generalitza a partir de dades i tolera la variació.

Altres limitacions: fragilitat davant canvis, dificultat d'escalar sense governança, deute tècnic acumulat («automatitzar el caos»), i el fet que el RPA no soluciona el problema de fons: és un pegat sobre la manca d'integració.

3.6 La combinació: automatització intel·ligent

3.7 Plataformes

Sigui quin sigui el fabricant, una plataforma de RPA reparteix la feina en tres papers, i cadascun té el seu component:

Paper Què fa
Eina de disseny (studio, designer) on es dissenya i es desenvolupa el flux d'automatització; no és on s'executa
Robot (runtime, executor) el que executa el flux a una màquina concreta, en mode atès o no atès
Orquestrador (control room) el servidor que desplega, planifica, gestiona i monitoritza els robots de forma centralitzada, i que custodia les credencials, les cues de treball i els registres

Els noms canvien de fabricant a fabricant, però els tres papers no, i la confusió que cau a l'examen és sempre entre el primer i el tercer: qui dissenya el flux no és qui l'executa en màquines remotes.

UiPath, Automation Anywhere, Blue Prism, Microsoft Power Automate (Desktop), Robocorp, Automagica.

Arquitectura d'UiPath — component per component:

Component Funció
UiPath Studio entorn de desenvolupament on es dissenyen i desenvolupen els fluxos de treball d'automatització (arrossegar i deixar anar activitats, seqüències, diagrames de flux, màquines d'estats)
UiPath Robot executa els processos a la màquina; pot ser atès o no atès
UiPath Orchestrator el component que permet executar robots en màquines remotes i gestionar-los centralitzadament: desplegament de paquets, planificació, cues de treball, actius i credencials, monitoratge, registres i control d'accés
UiPath Assistant llançador per a l'usuari dels robots atesos
Action Center intervencions humanes dins d'un flux
Automation Hub / Task Capture / Process Mining identificació i priorització d'oportunitats
Document Understanding / AI (Artificial Intelligence) Center extracció intel·ligent i models de ML

Dues preguntes literals: el component que dissenya i desenvolupa fluxos és Studio; el que executa robots en màquines remotes i els gestiona centralitzadament és l'Orchestrator.

3.8 Governança del RPA

Cicle de vida d'un projecte de RPASet etapes en ordre, de la identificació del procés al manteniment del robot en producció.Desenvolupament (SDD)DesplegamentDisseny (PDD)IdentificacióMantenimentProvesViabilitat i ROI - Seguretat: els robots tenen credencials pròpies i sovint privilegis elevats —un robot és, a efectes de seguretat, un usuari més amb credencials, que sovint ningú revisa amb la mateixa disciplina que les d'una persona—. Cal magatzem de credencials (l'Orchestrator té Assets i Credential Store, integrable amb CyberArk), identitats nominatives per robot, principi de mínim privilegi i segregació de funcions —els mateixos requisits que l'ENS (Esquema Nacional de Seguretat) exigeix per al control d'accés (op.acc) de qualsevol identitat—, i registre d'auditoria complet. - Protecció de dades: si el robot tracta dades personals, l'organització continua sent responsable del tractament; cal incloure'l al registre d'activitats i valorar-ne l'impacte. Si el robot pren decisions automatitzades amb efectes sobre una persona, aplica l'RGPD, art. 22. - Continuïtat: què passa si el robot cau? Ha d'haver-hi procediment manual de reserva. - Fragilitat: es trenca amb qualsevol canvi de la pantalla que imita, i multiplica un error a velocitat de màquina si ningú el revisa: la governança no és un tràmit, és el que evita que un robot dolent faci mal ràpid.

3.9 RPA, automatització de workflow i iPaaS

L'automatització de flux de treball (workflow) és la que fa un motor de procés: executa un procés modelat prèviament —normalment en BPMN— encadenant tasques automàtiques i tasques humanes amb regles, aprovacions, terminis i excepcions. És la implementació tècnica de la disciplina BPM, i no s'ha de confondre amb ella: el BPM és la disciplina; el motor de workflow, l'eina que n'executa el model.

Les tres automatitzen, però a capes diferents i amb un mecanisme diferent:

RPA Automatització de workflow (BPM) iPaaS
Actua imitant un usuari sobre la interfície gràfica orquestrant tasques i persones segons un procés modelat (BPMN) connectant aplicacions entre si per API
Capa presentació procés / negoci integració
Es fa servir quan cal automatitzar un sistema heretat sense API cal coordinar tasques humanes i automàtiques amb regles, aprovacions i excepcions cal que dues aplicacions intercanviïn dades o esdeveniments sense intervenció d'usuari
Exemples UiPath, Automation Anywhere, Blue Prism Camunda, UC4/Automic, motors BPMN MuleSoft Anypoint, Boomi, Zapier, Azure Logic Apps

iPaaS (Integration Platform as a Service, plataforma d'integració com a servei): servei al núvol que connecta aplicacions i fonts de dades entre si mitjançant API i connectors predefinits, sense necessitat d'infraestructura pròpia. No imita cap interfície ni orquestra tasques humanes: connecta sistemes. Comparteix amb el low-code l'enfocament visual amb poc codi, però no és RPA ni construeix aplicació nova → low-code i no-code.

El que les separa és per on entra l'automatisme al sistema de destinació, i per això la tria no és de gust:

D'aquí ve que el RPA es descrigui com un pegat davant la manca d'integració: el dia que el sistema publica una API, la integració el substitueix, mentre que el motor de workflow i l'iPaaS no competeixen entre si —resolen problemes diferents i sovint conviuen al mateix procés.


4. Automatització a l'ITSM i AIOps


5. Al sector públic


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 25

El servei d'Atenció a l'Usuari

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

Enunciat oficial. El servei d'Atenció a l'Usuari: estructura organitzativa, funcions i eines.


1. Concepte i rol

Service Desk (Centre de Servei a l'Usuari): a ITIL (Information Technology Infrastructure Library) v3 és una funció; a ITIL 4, una pràctica. El seu propòsit és capturar la demanda de resolució d'incidents i de peticions de servei, i ser el punt d'entrada i únic punt de contacte (SPOC — Single Point of Contact) entre el proveïdor de serveis i tots els seus usuaris.

El rol que li correspon és el de punt únic de contacte per a l'usuari i propietari de tots els incidents i peticions durant tot el seu cicle de vida. Això vol dir:

Afirmacions certes que cauen a l'examen sobre el Service Desk:

El que NO és responsabilitat del Service Desk: gestionar la infraestructura, dissenyar serveis, autoritzar canvis normals, ni fer la gestió de problemes (hi contribueix aportant informació, però no la lidera). Tampoc és responsable dels SLA —això és la gestió del nivell de servei— ni una eina tecnològica que resol sola: és una funció organitzativa, i l'eina ITSM només la sosté.

Les altres tres funcions d'ITIL v3, que són les distractores habituals. A ITIL v3 el Centre de Servei a l'Usuari és una de les quatre funcions de l'Operació del Servei, i el que cau és atribuir-li el que fan les altres:

Funció El que li correspon a ella, no al Service Desk
Gestió d'Operacions de TI supervisar l'execució i el monitoratge de les activitats i els esdeveniments operatius del dia a dia; hi penja la Gestió d'Instal·lacions, que porta els centres de dades i els contractes d'instal·lacions externalitzades
Gestió Tècnica aportar els recursos i el coneixement tècnic per dissenyar, construir i desplegar la infraestructura
Gestió d'Aplicacions el mateix, per al cicle de vida de les aplicacions

El marc general d'ITIL —el cicle de vida del servei d'ITIL v3 i la cadena de valor d'ITIL 4— no es repeteix aquí → tema 14.


2. Funcions

  1. Registre i categorització de tots els contactes.
  2. Priorització segons impacte i urgència.
  3. Diagnòstic i resolució de primer nivell, amb l'objectiu de maximitzar la resolució al primer contacte (FCR).
  4. Compliment de peticions de servei estandarditzades.
  5. Escalat funcional i jeràrquic.
  6. Comunicació proactiva: incidències majors, manteniments planificats, canvis que afecten els usuaris.
  7. Gestió del cicle de vida del tiquet fins al tancament amb confirmació.
  8. Enquestes de satisfacció i recollida de retroalimentació.
  9. Alimentació de la base de coneixement amb solucions i preguntes freqüents.
  10. Detecció de tendències que alimenten la gestió de problemes.
  11. Actualització de la CMDB amb el que descobreix a cada contacte, sota els procediments acordats amb la gestió de la configuració. El Service Desk no en queda al marge: és qui té l'usuari al telèfon i qui detecta que el registre no s'assembla a la realitat.
  12. Canalització de les peticions de canvi cap a la gestió de canvis. Les canalitza; no les autoritza, que és la confusió que cau.

3. Estructures organitzatives

Estructura Descripció Quan encaixa
Local físicament proper als usuaris necessitats lingüístiques o culturals específiques, presència física necessària, usuaris VIP (Very Important Person)
Centralitzat un únic centre per a tota l'organització més eficient, més fàcil de gestionar i d'estandarditzar; és la tendència
Virtual diversos centres físics que funcionen com un de sol gràcies a la tecnologia organitzacions distribuïdes geogràficament
Segueix el sol (follow the sun) centres en fusos horaris diferents que es passen el relleu cobertura 24×7 sense torns nocturns
Especialitzat grups dedicats per tipus de servei o de tecnologia dins del Service Desk organitzacions grans amb catàlegs molt heterogenis

Nivells de suport:

Objectiu de disseny: desplaçar el volum cap avall (shift left): que el nivell 2 documenti perquè el nivell 1 pugui resoldre, i que el nivell 1 documenti perquè l'usuari pugui autoservir-se.

Piràmide dels cinc nivells de suportDe dalt a baix: nivell 4, proveïdors i fabricants; nivell 3, experts; nivell 2, especialistes; nivell 1, el Service Desk; i nivell 0, l'autoservei. El shift-left desplaça el volum cap avall.N4 ·Proveïdors ifabricantsN3 · ExpertsN2 · EspecialistesN1 · Service DeskN0 · Autoserveishift-left: el volum baixa cap a N1 i N0

L'escalat: dues escales que no són alternatives. Quan el nivell 1 no pot tancar el contacte, aquest puja — i puja per dos eixos diferents, que sovint s'activen alhora:

Escalar no és transferir: el Service Desk conserva la titularitat del tiquet i segueix sent qui respon davant l'usuari fins al tancament. El cicle de vida complet de la gestió d'incidents i de la gestió de peticions es desenvolupa al tema 18.

Rols: agent de primer nivell, supervisor de torn, gestor del Service Desk, gestor d'incidents majors, gestor de coneixement, analista de qualitat.

Dimensionament: es calcula a partir del volum de contactes, el temps mitjà de gestió (AHT), els horaris de cobertura i el nivell de servei objectiu, amb models de cues (Erlang C per a canal telefònic). Cal preveure ocupació màxima del 75-85 % per absorbir els pics.


4. Canals

Els canals: telèfon, portal web d'autoservei, correu electrònic, xat, xatbot i assistents virtuals, presencial (walk-up / tech bar), aplicació mòbil, integració amb eines de col·laboració (Teams, Slack) i suport remot assistit.

Multicanal no és omnicanal, i la distinció és pregunta clàssica:

Autoservei: el canal de creixement. Requereix una base de coneixement de qualitat, un catàleg de peticions ben publicat i cerca eficaç. La mètrica associada és la taxa de desviament (deflection rate).

Segmentació del missatge: en els canals d'atenció massiva (xarxes socials, portal, campanyes informatives) el missatge no és el mateix per a tothom. La segmentació és la tècnica comunicativa que adapta el contingut, el to i el canal a cada grup de destinataris (per edat, per necessitat, per col·lectiu) en lloc d'emetre un missatge únic. El seu objectiu és reforçar la connexió amb els destinataris, no simplificar el contingut (això és claredat) ni estructurar una narrativa (storytelling) ni avaluar resultats (analítica).


5. Eines

Categoria Exemples
ITSM (Information Technology Service Management) / gestió de tiquets ServiceNow, Jira Service Management, BMC Helix, Ivanti, EasyVista, ManageEngine ServiceDesk Plus, GLPI (Gestion Libre de Parc Informatique), OTRS (Open Ticket Request System)/Znuny, osTicket, Freshservice
Base de coneixement integrada a l'ITSM, Confluence, SharePoint
CMDB (Configuration Management Database) integrada a l'ITSM; Lansweeper i Device42 hi fan l'inventari i el descobriment automàtic → tema 19
Suport remot TeamViewer, AnyDesk, Bomgar/BeyondTrust, Escriptori remot, Quick Assist
Telefonia i contact center ACD (Automatic Call Distributor), IVR (Interactive Voice Response), CTI (Computer Telephony Integration), gravació de trucades, integració amb l'ITSM
Gestió del lloc de treball Intune, SCCM (System Center Configuration Manager)/MECM (Microsoft Endpoint Configuration Manager), Jamf → temes 52 i 54
Monitoratge integració perquè els esdeveniments generin tiquets automàticament → temes 18 i 21
Enquestes integrades: CSAT (Customer Satisfaction) posttiquet, NPS (Net Promoter Score) periòdic
Xatbots i IA (Intel·ligència Artificial) assistents que responen consultes freqüents i creen tiquets; suggeriment d'articles de coneixement a l'agent
Gestió de xarxes socials Hootsuite i eines equivalents (Buffer, Later): programen publicacions, optimitzen temps i recursos, i permeten fer seguiment de l'atenció a través de l'historial d'interaccions

Requisits d'una bona eina ITSM: flux configurable sense programar, catàleg de serveis integrat, portal d'autoservei, base de coneixement, CMDB, gestió d'SLA (Service Level Agreement) amb rellotges que s'aturen (temps d'espera de l'usuari, calendaris laborals), automatització de tasques, informes i API (Application Programming Interface) oberta.


6. Mètriques

Mètrica Què mesura
FCR (First Contact Resolution) percentatge resolt en el primer contacte, sense escalat
Temps mitjà de resposta i temps mitjà de resolució (MTTR — Mean Time To Resolution) rapidesa
Compliment de l'SLA per prioritat
Volum de contactes per canal, servei i categoria càrrega i tendències
Taxa d'abandonament de trucades i temps mitjà d'espera qualitat del canal telefònic
AHT (Average Handling Time) eficiència; compte: optimitzar-lo sol degradar la qualitat
Taxa de reobertura qualitat de la resolució
CSAT i NPS satisfacció → tema 16
Taxa de desviament a autoservei maduresa del nivell 0
Backlog i antiguitat mitjana dels tiquets oberts salut de la cua

FCR i MTTR no mesuren el mateix, i es poden moure en direccions contràries. És la contraposició que cau:

FCR MTTR
Què compta quants contactes es tanquen sense escalar quant de temps es triga a resoldre
Unitat un percentatge un temps
Puja quan el nivell 1 té coneixement, guions i permisos l'organització sencera respon de pressa, escalats inclosos

Un Service Desk que escala de seguida tot el que li costa pot lluir un MTTR excel·lent amb un FCR pèssim; i un que reté l'usuari al telèfon mentre el nivell 1 hi rumia pot lluir el contrari. Per això cap de les dues es llegeix sola.

Compte amb la sigla: MTTR s'expandeix de quatre maneres —Resolution, Repair, Recovery i Respond— i no mesuren el mateix; l'enunciat sol dir de quina parla, i aquí s'usa el temps mitjà fins a la resolució.

Equilibri: mesurar només velocitat degrada la qualitat; mesurar només satisfacció amaga la ineficiència. Cal parells contrapesats → tema 22.


7. L'atenció a l'usuari a l'Ajuntament de Barcelona

Cal distingir dos serveis d'atenció diferents:

Els canals d'atenció ciutadana, que el tribunal pregunta un per un:

Via Canals
Presencial les OAC (Oficines d'Atenció Ciutadana) de districte; les oficines especialitzades per matèria —habitatge, joventut, ocupació—; i els quioscos de tràmits i serveis, terminals d'autoservei per als tràmits més freqüents
Telefònica el 010, informació i tramitació, que no és l'únic telèfon municipal: hi conviuen el 092 de la Guàrdia Urbana i les línies pròpies de serveis concrets
En línia la seu electrònica, l'OAC Digital, l'aplicació mòbil, les xarxes socials i la bústia ètica i de bon govern

La bústia ètica i de bon govern és el canal en línia per comunicar males pràctiques i possibles casos de corrupció, i el que la caracteritza és que garanteix la confidencialitat i l'anonimat de qui informa. És un canal de comunicació ciutadana com els altres, no un servei intern.

Particularitats del sector públic:


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 26

Gestió del risc en ITIL v4

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

Enunciat oficial. Gestió del risc en ITIL v4.


1. Concepte

Risc: esdeveniment possible que podria causar dany o pèrdua, o dificultar l'assoliment dels objectius. També es pot definir com la incertesa del resultat, i pot ser positiu (oportunitat) o negatiu (amenaça).

Gestió de riscos (pràctica d'ITIL 4) — propòsit: assegurar que l'organització comprèn i tracta els riscos de manera eficaç, com a element essencial per garantir la sostenibilitat de l'organització i la cocreació de valor amb els clients.

Termes:


2. El procés

El procés de gestió del risc (ISO 31000)Sis passos en seqüència: establir el context, identificar, analitzar, avaluar, tractar i monitorar/revisar, envoltats per la comunicació i consulta contínues i pel monitoratge i revisió continus. Les dues activitats contínues no contenen els passos ni es contenen l'una a l'altra: acompanyen tots sis alhora, i és per això que van com a bandes i no com a contenidors.AnalitzarAvaluarContextIdentificarMonitorarTractarcomunicació i consulta contínuesmonitoratge i revisió continusLes dues activitats contínues acompanyen els sis passos; cap de les dues n'és una etapa.

Aquest és, essencialment, el procés de la ISO 31000 (gestió del risc) que ITIL 4 adopta.

  1. Establir el context: abast, criteris de risc, apetit, parts interessades.
  2. Identificació: pluges d'idees, entrevistes, llistes de verificació, anàlisi de dependències, revisió d'incidents i problemes previs, anàlisi DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats), PESTLE (Polític, Econòmic, Social, Tecnològic, Legal, Ambiental), escenaris.
  3. Anàlisi: determinar probabilitat i impacte. Pot ser qualitativa (escales alta/mitjana/baixa, matrius de colors), semiquantitativa (escales numèriques) o quantitativa (valor monetari esperat, ALE (Annualized Loss Expectancy, pèrdua anual esperada) = SLE (Single Loss Expectancy, pèrdua per incident) × ARO (Annualized Rate of Occurrence, freqüència anual), simulació de Monte Carlo).
  4. Avaluació: comparar el nivell de risc amb els criteris i prioritzar; decidir quins es tracten.
  5. Tractament: aplicar una de les estratègies.
  6. Monitoratge i revisió: reavaluar periòdicament, verificar l'eficàcia dels controls i actualitzar el registre.

Registre de riscos (risk register): per a cada risc, descripció, categoria, causa, probabilitat, impacte, nivell, propietari, controls actuals, resposta prevista, risc residual, indicadors i estat.

Matriu de probabilitat i impacte: quadrícula 3×3 o 5×5 que classifica els riscos en zones (baix, moderat, alt, crític). És l'eina d'avaluació qualitativa més usada.


3. Estratègies de tractament

Per a amenaces:

Estratègia Descripció
Evitar eliminar la causa o no fer l'activitat que genera el risc
Reduir / mitigar disminuir la probabilitat i/o l'impacte mitjançant controls
Transferir / compartir traslladar-lo a un tercer: assegurança, contracte, externalització. La responsabilitat última no es transfereix mai, especialment a l'Administració
Acceptar assumir-lo conscientment i documentadament, dins l'apetit al risc
Escalar quan supera l'autoritat de qui el gestiona

Per a oportunitats: explotar, millorar, compartir, acceptar i escalar.

Tipus de controls: preventius (eviten que passi), detectius (avisen que ha passat), correctius (redueixen l'impacte un cop passat) i dissuasius. Es classifiquen també en tècnics, organitzatius i físics.


4. On viu el risc dins d'ITIL 4

La gestió de riscos no és un procés aïllat: travessa tot el Sistema de Valor del Servei.


5. Marcs de referència del risc

Frontera amb PMBOK. Aquests són marcs de risc; no és aquí on es desenvolupa el PMBOK (Project Management Body of Knowledge), que és el marc de gestió de projectes del PMI (Project Management Institute). El risc de projecte —amb la mateixa distinció amenaça/oportunitat i termes com apetit o tolerància— es regeix per aquell marc i es desenvolupa a tic/pmbok-rendimiento-riesgos-y-cierre; aquí només el risc de servei que gestiona ITIL (Information Technology Infrastructure Library).


6. Risc i compliment


7. Riscos típics d'un servei TIC

Categories de risc d'un servei TIC (Tecnologies de la Informació i la Comunicació), amb exemples típics:

Categoria Exemples
Tecnològics obsolescència, deute tècnic, punts únics de fallida, incompatibilitats, fi de suport
De seguretat ransomware, fuita de dades, accés indegut, cadena de subministrament
Operatius error humà, canvi mal executat, manca de documentació, dependència d'una sola persona (bus factor)
De proveïdor insolvència, incompliment d'SLA (Service Level Agreement, acord de nivell de servei), bloqueig tecnològic (vendor lock-in), concentració
De dades pèrdua, corrupció, qualitat deficient, tractament il·lícit
De projecte sobrecost, retard, abast no assolit, requisits mal capturats
De compliment protecció de dades, accessibilitat, ENS, contractació
Financers despesa descontrolada al núvol, pressupost insuficient, canvi de model de llicenciament
Reputacionals caiguda visible d'un servei ciutadà, biaix algorítmic

Mesures transversals més rendibles: còpies de seguretat provades i immutables (ENS i tema 57), autenticació multifactor, mínim privilegi, gestió de vulnerabilitats i pedaços, segmentació de xarxa, documentació i formació, i plans de continuïtat provats.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 27

Gestió financera dels serveis en ITIL v4

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

Enunciat oficial. Gestió financera dels serveis en ITIL v4.


1. Propòsit

Gestió financera del servei (ITIL (Information Technology Infrastructure Library) 4) — propòsit: donar suport a les estratègies i plans de l'organització per a la gestió de serveis assegurant que els recursos i les inversions financeres de l'organització s'utilitzen de manera efectiva.

Funció principal dins de l'Estratègia del Servei (ITIL v3): quantificar en termes econòmics el valor dels serveis de TI i dels actius que els suporten, i proporcionar a la direcció la informació financera necessària per prendre decisions sobre inversió, priorització i prestació dels serveis, assegurant un finançament adequat per al lliurament i el consum dels serveis.

Dit d'una altra manera, la seva funció és traduir la TI (Tecnologies de la Informació) a llenguatge de diners perquè es pugui decidir amb criteri: quant costa cada servei, quant val per al negoci i si val la pena.

1.1 Les dades que aporta a l'estratègia i al disseny

La gestió financera agrega, afina i distribueix dades de cost que serveixen a dues altres pràctiques, i no a d'altres:

El que no aporta: fixar l'estructura d'un servei és una decisió de disseny, no una dada financera; i estimar el pressupost d'un projecte concret és gestió de projectes, no gestió financera del servei ja en funcionament.


2. Les tres activitats clàssiques

Activitat Pregunta Contingut
Pressupostar (budgeting) quant necessitarem? previsió de despeses i ingressos per a un període, control de la despesa contra el pressupost, i planificació de la inversió
Comptabilitat (accounting) en què s'ha gastat? seguiment del cost real per servei, client, activitat o centre de cost; permet saber què costa cada servei i on va cada euro
Facturació o repercussió (charging) qui ho paga? cobrament o repercussió interna als consumidors del servei. És l'activitat opcional: moltes organitzacions —i gairebé totes les administracions— fan pressupost i comptabilitat però no facturen

La comptabilitat de serveis exigeix un model de costos que permeti passar de la comptabilitat pressupostària (per capítols) a la comptabilitat per servei.

2.1 On es fa visible: el catàleg de serveis

La gestió financera no es queda en la comptabilitat interna: el seu resultat es publica al catàleg de serveis (→ tema 20), on cada entrada pot incorporar, a més de la descripció i l'SLA (Service Level Agreement), el cost indicatiu —o la tarifa, quan l'organització factura— d'aquell servei o d'aquella oferta. Coherentment amb el que s'ha dit més amunt, al sector públic el més freqüent és el showback (mostrar el cost sense cobrar-lo), no la tarifa. Quan el model s'aplica, és així com es fa operatiu: no es cobra «TI» de manera genèrica, es cobra o es mostra el cost de cada element concret del catàleg. Aquesta dada de preu és també el que permet al client regular la seva demanda —triar una oferta de servei més bàsica o més àmplia en funció del que costa— i preparar el seu propi pressupost amb la informació del catàleg com a referència.


3. El model de costos

3.1 Tipus de cost

3.2 Elements que componen el cost d'un servei

Maquinari · programari i llicències · allotjament (CPD, energia, refrigeració) · comunicacions · personal propi i extern · manteniment i suport de tercers · formació · assegurances · costos de transició i de retirada.

3.3 TCO i cicle de vida

El cost total de propietat (TCO, Total Cost of Ownership) cobreix tot el cicle de vida: adquisició, implantació, operació, manteniment, evolució, migració i retirada. És el nombre que cal comparar entre alternatives, no el preu de compra. → tema 3.

Costos que s'obliden sistemàticament: migració de dades, integracions, formació, gestió del canvi, sortida del proveïdor i egress de dades al núvol.

3.4 Repercussió interna (chargeback i showback)

3.5 Sistemes d'imputació de costos indirectes


4. Anàlisi d'inversions


5. FinOps: la gestió financera al núvol

Amb el núvol, el cost passa de ser una inversió planificada anualment (CAPEX) a una despesa variable generada per decisions tècniques quotidianes (OPEX). Qualsevol desenvolupador pot provocar despesa. Això trenca el model tradicional de control pressupostari i obliga a un enfocament nou.

FinOps: pràctica cultural i operativa que uneix equips financers, tècnics i de negoci per prendre decisions basades en el valor econòmic del núvol, amb responsabilitat distribuïda sobre el cost.

Els tres principis del cicle FinOps: Informar (Inform) → Optimitzar (Optimize) → Operar (Operate), iteratius i continus.

El cicle FinOpsTres fases iteratives que no s'acaben mai: cada volta afina la següent.Informarveure què es gastaOptimitzargastar-hi menysOperarmantenir-ho així

Pràctiques per controlar la despesa al núvol en temps real — la pregunta d'examen sobre «quina pràctica permet controlar la despesa en el núvol en temps real» respon a aquest conjunt:

El cost dels serveis gestionats: sovint és més barat un servei gestionat que operar-lo un mateix quan s'hi compta el cost de personal; el TCO ho ha de mostrar.

Cost de sortida (egress): transferir dades cap enfora del núvol es factura; és un factor de bloqueig de proveïdor i s'ha de valorar des del disseny. El Data Act (Data Act) hi ha intervingut, imposant la supressió progressiva de les tarifes de canvi de proveïdor.


6. La gestió financera al sector públic

La lògica pressupostària pública no és la comptabilitat analítica, i això condiciona tota la pràctica:


7. Indicadors financers de servei


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 28

Gestió de la innovació. Sistema de gestió de la innovació (SGI)

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

Pot estar desactualitzat

Enunciat oficial. Gestió de la innovació. Sistema de gestió de la innovació (SGI): principis, context i lideratge.


1. Conceptes

Innovació (Manual d'Oslo, 4a edició, OCDE (Organització per a la Cooperació i el Desenvolupament Econòmic) / Eurostat): producte o procés nou o millorat —o una combinació d'ambdós— que difereix significativament dels productes o processos anteriors de la unitat i que ha estat posat a disposició dels usuaris potencials (producte) o posat en ús per la unitat (procés).

Dos elements imprescindibles: novetat significativa i implantació efectiva. Una idea no implantada no és innovació: és una invenció.

Tipus d'innovació: la 4a edició del Manual d'Oslo simplifica la classificació a dos —de producte (béns o serveis) i de procés de negoci, que engloba producció, logística, màrqueting, sistemes d'informació i administració—. Les edicions anteriors en distingien quatre: producte, procés, organitzativa i de màrqueting. Poden preguntar per qualsevol de les dues.

Per grau de novetat: incremental, que millora allò existent, contra radical o disruptiva, que canvia les regles del joc entrant per segments desatesos amb un producte més accessible.

Per l'origen del coneixement: innovació oberta contra innovació tancada, totes dues al §8.2. La governança d'aquests fluxos es descriu com a triple hèlix (universitat–empresa–administració) i quàdruple hèlix, que hi afegeix la societat civil. Quan el resultat busca valor col·lectiu i no de mercat es parla d'innovació social i d'innovació pública.

1.1 El sistema de gestió de la innovació (SGI)

Un SGI (Sistema de Gestió de la Innovació) és el conjunt d'elements interrelacionats —política, objectius, estructura i rols, processos, recursos i indicadors— que una organització estableix per innovar de manera sistemàtica i repetible en comptes de per iniciatives aïllades. El que aporta no són idees: aporta que es busquin, es triïn, es financin i s'avaluïn sempre igual, i que el resultat es pugui auditar.

Un SGI és un sistema de gestió normalitzat, com el de qualitat o el de seguretat de la informació, i comparteix amb ells dues coses. Es fonamenta en el cicle de millora contínua —planificar, fer, verificar i actuar—: aquesta és la base de tots els sistemes de gestió, i la mesura d'indicadors, les auditories i les no conformitats en són eines i sortides, no el fonament. I s'ordena segons l'estructura d'alt nivell de l'Annex SL (§2.2), que permet integrar-lo amb els altres sistemes de la casa. El descriuen dues famílies de normes: la UNE 166000 (§2), sobre R+D+i, i la ISO 56000 (§3), sobre innovació en sentit ampli.


2. La família UNE (Una Norma Española) 166000

Sèrie espanyola de normes de gestió de la R+D+i:

Norma Contingut
UNE 166000 (2006) Terminologia i definicions de les activitats de R+D+i, base comuna de la família
UNE 166001 Requisits d'un projecte de R+D+i: certifica projectes individuals i dona accés a deduccions fiscals
UNE 166002 Requisits del sistema de gestió de la R+D+i: la certificable per a organitzacions
UNE 166006 Sistema de vigilància tecnològica i intel·ligència competitiva
UNE 166008 Transferència de tecnologia

2.1 UNE 166006 — Vigilància tecnològica i intel·ligència competitiva

Finalitat: establir els requisits d'un sistema de vigilància tecnològica i intel·ligència competitiva que permeti captar, analitzar, difondre i explotar de manera sistemàtica la informació científica, tecnològica i de l'entorn, per convertir-la en coneixement útil per a la decisió i reduir el risc. És la resposta quan es pregunta la seva finalitat: no certifica projectes ni és norma de qualitat. La vigilància capta i organitza la informació; la intel·ligència competitiva l'analitza i n'extreu conclusions accionables.

Cicle: identificació de necessitats i factors crítics → cerca i captació → anàlisi i validació → difusió → explotació i decisió → avaluació. Les fonts: patents, publicacions científiques, normes, informes d'analistes, fires, competidors i fonts internes.

2.2 UNE 166002 — El sistema de gestió de la R+D+i

Estat de la norma. La UNE 166002:2021 va ser anul·lada l'11 de desembre de 2024 i substituïda per la UNE-EN ISO 56001:2024 (§3), que certifica el sistema de gestió de la innovació i no només de la R+D+i. Es descriu igualment perquè el programa oficial la cita.

Estructura d'alt nivell (Annex SL), igual que la ISO 9001:

4 Context de l'organització · 5 Lideratge · 6 Planificació · 7 Suport · 8 Operació · 9 Avaluació de l'acompliment · 10 Millora

Etapes del procés de R+D+i. La revisió del 2021 va alinear la norma amb la ISO 56002 i va ordenar el procés en cinc blocs, que són els que es pregunten:

  1. Identificar oportunitats — des de la vigilància, la prospectiva i l'entorn (§7).
  2. Crear conceptes — les idees es tornen conceptes descrits i comparables (§6).
  3. Validar conceptes — contrastar-los amb evidència abans de gastar-hi: prototip, prova de concepte, pilot.
  4. Desenvolupar solucions — enginyeria i preparació del desplegament.
  5. Explotar resultats — comercialització o implantació interna, transferència de tecnologia i protecció de la propietat industrial i intel·lectual.

Compte amb la llista antiga. Fins al 2014 la norma desglossava el procés d'una altra manera —anàlisi de problemes, selecció d'idees, cartera de projectes, comercialització, protecció— i no és la que l'examen dona per bona: la correcta són els cinc blocs de dalt, amb validar conceptes com a fase pròpia.

Els dos cicles de la família UNE 166000, alineatsLa vigilància tecnològica i el procés d'innovació tenen gairebé la mateixa forma, i és per això que es confonen. Posats l'un al costat de l'altre, pas per pas, es veu on coincideixen i on no: la vigilància acaba avaluant el que ha difós; la innovació acaba explotant el que ha desenvolupat.UNE 166006 — vigilància tecnològicaUNE 166002:2021 — procés d'innovació123456Identificació de necessitatsCerca i captacióAnàlisi i validacióDifusióExplotació i decisióAvaluacióIdentificar oportunitatsCrear conceptesValidar conceptesDesenvolupar solucionsExplotar resultats

Unitat de gestió de la R+D+i: la norma exigeix designar-ne una amb responsabilitats i autoritat definides.


3. La ISO 56000: el sistema de gestió de la innovació

Família internacional més recent, que amplia el concepte de R+D+i a innovació en sentit ampli.

Norma Contingut
ISO 56000 fonaments i vocabulari
ISO 56001 requisits del sistema de gestió de la innovació: la certificable, del 2024
ISO 56002 orientació per implantar-lo; guia, no certificable
ISO 56005 · 56007 · 56008 propietat intel·lectual · gestió d'idees · mesura de les operacions

3.1 Els vuit principis de la gestió de la innovació

Són vuit i la UNE 166002:2021 els comparteix (§2.2): realització de valor, financer o no; líders orientats al futur; direcció estratègica amb objectius explícits; cultura que fa conviure creativitat i execució; explotació de coneixements interns i externs; gestió de la incertesa, acceptant el fracàs com a aprenentatge; adaptabilitat; i enfocament sistèmic.

3.2 Context i lideratge

Context (capítol 4): comprendre el context intern (cultura, recursos, competències, propietat intel·lectual) i extern (mercat, tecnologia, regulació, competidors, societat), les necessitats de les parts interessades, l'abast del sistema i la cultura de la innovació com a element específic d'aquesta norma (§8.1). Les eines de diagnosi —el DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats), el PESTEL (Polític, Econòmic, Social, Tecnològic, Ecològic i Legal) i el mapa de parts interessades— les desenvolupa el tema 1; aquí només s'hi apliquen.

Lideratge (capítol 5): l'alta direcció ha de retre comptes de l'eficàcia del sistema, establir la visió, l'estratègia, la política i els objectius d'innovació i fer-los compatibles amb la direcció estratègica, promoure una cultura que toleri el risc i l'error, assegurar els recursos, donar suport als altres rols de gestió i assignar rols, responsabilitats i autoritats.

El paper de la direcció no és generar les idees, sinó crear les condicions perquè es generin, es triïn i s'executin.

Planificació (6): riscos, objectius i carteres d'innovació. Suport (7): competències, temps dedicat, infraestructures, eines, propietat intel·lectual i comunicació. Operació (8): els processos d'innovació — identificar oportunitats, crear conceptes, validar conceptes, desenvolupar solucions i desplegar-les. Ull a l'última: la ISO 56002 tanca el procés en el desplegament i la UNE 166002:2021 en l'explotació dels resultats (§2.2).


4. Compra pública d'innovació

La CPI (Compra Pública d'Innovació) és la contractació pública orientada a adquirir béns o serveis que encara no existeixen al mercat, o a finançar-ne el desenvolupament, en comptes de comprar-ne una ja disponible al catàleg. És l'instrument amb què una administració converteix la seva demanda en palanca d'innovació; per això és aquí i no només com a matèria de contractació. El detall articulat de la LCSP el desenvolupa el tema 3; el que cau d'aquest tema és:


5. Tecnologies emergents com a objecte d'innovació

Apareixen al temari com a exemples d'innovació. La que ha caigut és la cadena de blocs.

Blockchain / DLT (Distributed Ledger Technology)

Bessó digital → tema 2. IoT → tema 62. La intel·ligència artificial és aquí un exemple de tecnologia emergent que cal avaluar; el seu desenvolupament tècnic i ètic és dels temes 29 i 30.


6. Generació, avaluació i selecció d'idees

És el bloc que la UNE 166002:2021 parteix en crear conceptes i validar conceptes (§2.2), i que la ISO 56007 desenvolupa a part. Té forma d'embut d'innovació: hi entren moltes idees barates i en surten poques solucions cares. Cada estretament és una porta on es decideix si allò continua, es reorienta o s'atura, amb criteris escrits abans —el model Stage-Gate—. Aturar una idea aviat no és un fracàs del sistema: és el que el fa barat.

L'embut d'innovació i les seves portesQuatre etapes separades per tres portes de decisió, on cada idea continua, es reorienta o s'atura. A l'entrada, moltes idees; a la sortida, poques solucions desplegades.portaportaportaGeneraciómoltes ideesAvaluació i seleccióValidació del concepteDesenvolupament i explotaciópoques solucions desplegades

D'on surten: de la vigilància i la prospectiva (§2.1 i §7), del personal propi (bústia d'idees, intraemprenedoria), de les persones usuàries, del mercat via consulta preliminar (§4) i de l'ecosistema extern (§8.2). L'anàlisi de queixes i incidències és la font més barata i més ignorada. Com es generen: pluja d'idees (brainstorming), amb la regla d'ajornar el judici; design thinking —empatitzar, definir, idear, prototipar i provar—; reptes i hackatons.

Com s'avaluen i se seleccionen: amb criteris explícits i ponderats —encaix estratègic, valor esperat, factibilitat tècnica, cost i termini, risc— sobre una matriu de puntuació o impacte–esforç, i amb una cartera equilibrada entre nucli, adjacent i transformacional. La incertesa no es resol discutint: es compra informació amb prototips i pilots.

On acaba aquest tema i on comença el 3. Aquí s'avalua una idea que encara no existeix, amb criteris qualitatius i molta incertesa. L'avaluació d'una solució concreta ja present al mercat —cas de negoci, retorn de la inversió, build vs buy— és del tema 3.


7. Prospectiva: anticipar en comptes de reaccionar

La prospectiva és l'exploració sistemàtica de futurs possibles a mitjà i llarg termini per decidir avui amb anticipació. No és la vigilància tecnològica (§2.1): els separa l'horitzó.

Vigilància tecnològica Prospectiva
Pregunta què està passant? què podria passar?
Horitzó curt termini, i de manera contínua mitjà i llarg termini, per exercicis
Matèria primera patents, publicacions, competidors judici expert, tendències, senyals febles
Producte butlletins, alertes, informes escenaris, full de ruta, visió compartida
Norma pròpia sí, la UNE 166006 no en té

No competeixen: la vigilància dona el material i la prospectiva el projecta. Mètodes:

La corba de maduresa (Hype Cycle) de Gartner i la seqüència prova de concepte → pilot → producció les desenvolupa el tema 3.


8. Cultura d'innovació i innovació oberta

8.1 La cultura d'innovació

La cultura és el quart dels vuit principis (§3.1) i l'element del context que la ISO 56002 afegeix respecte d'altres sistemes de gestió: sense ella el sistema es queda en paperassa. Es reconeix per fets:

A l'Administració la resistència no sol ser hostilitat, sinó aversió al risc induïda pel control: qui innova respon dels seus errors i qui no innova no respon de res.

8.2 Innovació oberta i els seus mecanismes

La innovació oberta (Chesbrough) és el model en què l'organització fa servir deliberadament fluxos de coneixement amb l'exterior, en comptes de generar i explotar tota la innovació dins de casa, com fa la innovació tancada. Té tres direccions: d'entrada (inbound), incorporar coneixement de fora —universitats, centres tecnològics, empreses emergents, ciutadania—; de sortida (outbound), cedir a tercers allò que no s'explota —llicències, alliberament de codi, transferència—; i acoblada (coupled), co-creació amb un soci, amb aportació i retorn per les dues bandes.

Obert/tancat i incremental/radical són dos eixos diferents, i el tribunal els creua: el primer diu d'on ve el coneixement i el segon quant canvia el que ja hi havia (§1). Una innovació oberta pot ser incremental, i una de tancada, radical.

Mecanismes: reptes i concursos d'innovació; hackatons; laboratoris ciutadans i living labs, que assagen amb persones usuàries reals; col·laboració amb universitats i centres tecnològics; empreses derivades (spin-off) i inversió corporativa; col·laboració massiva (crowdsourcing) i programari lliure; i l'espai de proves regulatori (sandbox) → tema 3.

I sobretot: en una administració, la compra pública d'innovació (§4) és el mecanisme d'innovació oberta propi: la consulta preliminar obre el problema a qui el pot resoldre i l'associació per a la innovació paga perquè el resolgui.


9. Indicadors d'innovació

Un SGI que no es mesura no es pot millorar: els indicadors alimenten el capítol d'avaluació de l'acompliment (§2.2) i tanquen el cicle de millora contínua (§1.1). La ISO 56008 hi és la guia. Es classifiquen per on cauen a la cadena, i confondre'n el tipus és l'error típic:

Tipus Què mesuren Exemples
D'entrada (input) els recursos dedicats despesa en R+D+i sobre el pressupost, persones i hores, finançament extern captat
De procés si l'embut funciona idees captades, taxa de conversió d'idea a projecte, temps de cicle, projectes aturats a temps
De sortida (output) què s'ha produït serveis nous o millorats desplegats, prototips validats, patents i registres
De resultat (outcome) quin efecte ha tingut percentatge d'ingressos —o de serveis— procedents de novetats dels darrers tres anys, estalvi, adopció, satisfacció

Tres regles que valen més que la llista. Un indicador d'entrada no mesura innovació: mesura esforç —un sistema avaluat només per la despesa en R+D premia gastar—. Els de procés diuen si el sistema està viu: moltes idees captades i taxa de conversió zero no és un problema de creativitat, és l'embut tapat a la porta d'avaluació. I cap indicador aïllat val: es miren en quadre de comandament, amb almenys un de cada tipus i una sèrie temporal al darrere.

El European Innovation Scoreboard de la Comissió Europea agrupa desenes d'indicadors en dimensions d'entrada, d'activitat i de resultat per comparar els estats membres.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 29

La Intel·ligència Artificial

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

Enunciat oficial. La Intel·ligència Artificial: tipus i nivells de complexitat, riscos i biaixos. IA ètica i responsable.


1. Concepte i tipus

Sistema d'IA (Reglament (UE) 2024/1689, d'Intel·ligència Artificial (RIA), art. 3, definició legal vigent): sistema basat en una màquina dissenyat per funcionar amb diferents nivells d'autonomia i que pot mostrar capacitat d'adaptació després del desplegament, i que, per a objectius explícits o implícits, infereix de la informació d'entrada que rep la manera de generar resultats de sortida —com prediccions, contingut, recomanacions o decisions— que poden influir en entorns físics o virtuals.

1.1 Per capacitat

1.2 Per tècnica i nivell de complexitat

Cinc cercles concèntrics: de la IA als TransformersLa intel·ligència artificial conté l'aprenentatge automàtic, que conté les xarxes neuronals, que contenen l'aprenentatge profund, que conté els Transformers.Intel·ligència artificialAprenentatge automàticXarxes neuronalsAprenentatgeprofundTransformers

Relació entre deep learning i machine learning (pregunta literal): el deep learning és un subconjunt del machine learning que utilitza xarxes neuronals artificials amb múltiples capes ocultes i que aprèn automàticament les característiques rellevants a partir de les dades brutes, sense necessitat d'enginyeria manual de característiques. Requereix molta més dada i capacitat de còmput que el ML clàssic. No és el revés, ni són sinònims, ni són disciplines independents.

Sistemes basats en regles / experts: la IA «simbòlica» clàssica, amb base de coneixement i motor d'inferència. No aprèn: aplica regles escrites per humans. És el nivell de complexitat més baix i el més explicable.

1.3 Tipus d'aprenentatge automàtic

Tipus Dades Objectiu Exemples
Supervisat etiquetades predir una etiqueta o un valor classificació (spam, risc), regressió (predicció de demanda). Algorismes: regressió lineal i logística, arbres de decisió, random forest, gradient boosting (XGBoost), SVM (Support Vector Machine), k-NN (k-Nearest Neighbors), xarxes neuronals
No supervisat sense etiquetar descobrir estructura agrupament (clustering) amb k-means o DBSCAN (Density-Based Spatial Clustering of Applications with Noise), reducció de dimensionalitat amb PCA (Principal Component Analysis), regles d'associació, detecció d'anomalies
Semisupervisat poques etiquetades i moltes sense aprofitar les no etiquetades
Per reforç recompenses de l'entorn aprendre una política d'accions robòtica, jocs, optimització de recursos
Autosupervisat genera les seves pròpies etiquetes preentrenament base dels LLM

1.4 IA generativa

Models que generen contingut nou (text, imatge, codi, àudio, vídeo) a partir de patrons apresos.


2. Riscos i biaixos

2.1 Biaix

Biaix algorítmic: desviació sistemàtica dels resultats que produeix tractament desigual injustificat de persones o grups.

Origen del biaix:

Font Descripció
Biaix de les dades les dades històriques reflecteixen desigualtats existents; el model les aprèn i les perpetua o amplifica
Biaix de mostreig o de representació col·lectius infrarepresentats al conjunt d'entrenament
Biaix d'etiquetatge qui etiqueta introdueix els seus judicis
Biaix de mesura la variable observada és un proxy imperfecte del que es vol mesurar (usar «detencions» com a proxy de «delinqüència»)
Biaix d'agregació un únic model per a poblacions heterogènies
Biaix de disseny l'elecció de variables, de funció objectiu i de llindars
Biaix d'automatització les persones confien excessivament en la sortida del sistema i no la qüestionen
Bucle de retroalimentació la decisió del model altera la realitat que després torna a alimentar el model (policia predictiva)

Mètriques d'equitat: paritat demogràfica, igualtat d'oportunitats, igualtat d'odds, calibratge per grups. Són matemàticament incompatibles entre si en el cas general: cal triar quina noció d'equitat s'aplica i justificar-la. Aquest és un punt clau de l'IA responsable.

Eliminar l'atribut protegit no elimina el biaix: altres variables actuen de proxy (codi postal → origen socioeconòmic).

2.2 Altres riscos


3. IA ètica i responsable

3.1 Principis

Directrius ètiques per a una IA fiable (Grup d'Experts d'Alt Nivell de la Comissió Europea, 2019). Una IA fiable ha de ser lícita, ètica i robusta, i complir set requisits:

  1. Acció i supervisió humanes (human agency and oversight): amb els models human-in-the-loop, human-on-the-loop i human-in-command.
  2. Solidesa tècnica i seguretat: resiliència als atacs, pla de contingència, precisió, fiabilitat i reproductibilitat.
  3. Gestió de la privadesa i de les dades: qualitat i integritat de les dades, i control d'accés.
  4. Transparència: traçabilitat, explicabilitat i comunicació (l'usuari ha de saber que interactua amb una IA).
  5. Diversitat, no-discriminació i equitat: evitar biaixos, accessibilitat i disseny universal, participació de les parts interessades.
  6. Benestar social i ambiental: sostenibilitat, impacte social i democràtic.
  7. Rendició de comptes: auditabilitat, minimització i informe d'impactes negatius, compensació i vies de reparació.

Els quatre principis ètics de què deriven: respecte de l'autonomia humana, prevenció del dany, equitat i explicabilitat.

Altres referents: Recomanació de la UNESCO (United Nations Educational, Scientific and Cultural Organization) sobre l'ètica de la IA (2021), Principis de l'OCDE (Organització per a la Cooperació i el Desenvolupament Econòmic) sobre IA, NIST AI Risk Management Framework i ISO/IEC 42001 (IEC: International Electrotechnical Commission; sistema de gestió de la IA, certificable).

3.2 El Reglament europeu d'IA

RIA (Reglament d'Intel·ligència Artificial) — Reglament (UE) 2024/1689. Primer marc jurídic integral del món. Enfocament basat en el risc, amb quatre nivells:

Nivell Tractament Exemples
Risc inacceptable prohibits manipulació subliminal, explotació de vulnerabilitats, puntuació social per part d'autoritats públiques, identificació biomètrica remota en temps real en espais públics amb finalitats policials (amb excepcions taxades), reconeixement d'emocions a la feina i a l'educació, categorització biomètrica per inferir dades sensibles, extracció massiva no dirigida d'imatges facials, predicció del risc de cometre un delicte basada únicament en el perfilat o en trets de personalitat (policia predictiva individual)
Alt risc permesos amb requisits estrictes components de seguretat de productes regulats; i els de l'annex III: biometria, infraestructures crítiques, educació, ocupació i selecció de personal, accés a serveis públics essencials i a prestacions, aplicació de la llei, migració i control de fronteres, administració de justícia i processos democràtics
Risc limitat obligacions de transparència xatbots (l'usuari ha de saber que parla amb una IA), marcatge del contingut generat o manipulat (deepfakes)
Risc mínim lliures filtres de correu brossa, videojocs

Obligacions dels sistemes d'alt risc: sistema de gestió de riscos al llarg de tot el cicle de vida, governança de dades (qualitat, representativitat, examen de biaixos), documentació tècnica, registre automàtic d'esdeveniments (logs), transparència i informació a l'usuari desplegador, supervisió humana efectiva, precisió, robustesa i ciberseguretat, sistema de gestió de la qualitat, avaluació de la conformitat i marcatge CE (Conformité Européenne), i registre a la base de dades de la UE (Unió Europea).

Avaluació d'impacte sobre els drets fonamentals (FRIA, Fundamental Rights Impact Assessment): obligatòria per als desplegadors que siguin organismes de dret públic o entitats privades que prestin serveis públics quan utilitzin sistemes d'alt risc. Això afecta directament els ajuntaments.

Models d'IA d'ús general (GPAI, General Purpose Artificial Intelligence): obligacions pròpies de documentació, drets d'autor i resum del contingut d'entrenament; per als de risc sistèmic, avaluacions i notificació d'incidents.

Calendari: en vigor l'1 d'agost de 2024; prohibicions de l'article 5 aplicables als 6 mesos (2 de febrer de 2025), si bé les dues prohibicions noves que hi va afegir el Digital Omnibus —generar material íntim sense consentiment i material d'abús sexual infantil— no s'apliquen fins al 2 de desembre de 2026; obligacions dels models GPAI als 12 mesos (2 d'agost de 2025); transparència de l'article 50 als 24 mesos (2 d'agost de 2026). Els terminis de l'alt risc es van ajornar pel Digital Omnibus (Reglament (UE) 2026/1744, en vigor el 27 de juliol de 2026): l'annex III (els sistemes d'alt risc de l'article 6.2, els anomenats autònoms), previst per al 2 d'agost de 2026, passa al 2 de desembre de 2027; l'annex I (productes regulats), previst per al 2 d'agost de 2027, passa al 2 d'agost de 2028. I una data que toca de ple les administracions: els sistemes d'alt risc ja en ús per autoritats públiques tenen fins al 2 d'agost de 2030 per adequar-s'hi. Autoritat espanyola: l'AESIA (Agencia Española de Supervisión de la Inteligencia Artificial).

3.3 Relació amb el RGPD


4. IA al sector públic

Casos d'ús habituals: atenció ciutadana amb assistents conversacionals, classificació i encaminament d'expedients, detecció de frau i d'irregularitats, manteniment predictiu d'infraestructures, gestió de la mobilitat i el trànsit, planificació de serveis socials, anàlisi d'imatges (residus, ocupació de l'espai públic), traducció i accessibilitat.

Requisits addicionals respecte del sector privat:

A Barcelona això s'articula amb la Mesura de govern d'IA i la Metodologia de sistemes algorítmics → tema 30.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 30

Estratègia municipal d'algoritmes i dades

Enunciat oficial. Estratègia municipal d'algoritmes i dades per a l'impuls ètic de la intel·ligència artificial.

Documents: Mesura de govern d'IA i Metodologia de sistemes algorítmics; marc de principis a la Mesura de digitalització oberta.


1. Origen i evolució

Any Fita
2017 Mesura de govern per a la digitalització oberta: programari lliure, estàndards oberts, desenvolupament àgil i sobirania de les dades
2018 Mesura de govern de gestió ètica i responsable de les dades i creació de l'OMD (Oficina Municipal de Dades) amb la figura del CDO (Chief Data Officer)
2021 Mesura de govern «Estratègia municipal d'algoritmes i dades per a l'impuls ètic de la intel·ligència artificial» — Barcelona és pionera a definir un marc ètic municipal per a la IA, amb una vintena d'actuacions
2024-2026 Actualització de l'estratègia per adaptar-la al Reglament europeu d'IA i als nous reptes, amb la mesura de govern vigent Mesura de govern d'IA

Naturalesa: és una mesura de govern, no una ordenança. No té rang normatiu vinculant per a tercers: obliga l'organització municipal i els seus proveïdors a través dels plecs i de les instruccions internes.


2. Objectius de l'estratègia

  1. Garantir que l'ús de la IA i de les tecnologies urbanes emergents als serveis municipals respecta els drets digitals de la ciutadania.
  2. Establir el marc normatiu i metodològic intern per a la incorporació d'aquestes tecnologies.
  3. Fomentar l'humanisme tecnològic: la tecnologia al servei de les persones.
  4. Promoure models transparents, auditables i oberts.
  5. Assegurar la sobirania tecnològica i de les dades i evitar la dependència de proveïdors.
  6. Reduir els biaixos i les discriminacions algorítmiques.
  7. Impulsar la innovació i l'ús de la IA per millorar els serveis públics.
  8. Generar coneixement i capacitat interna i formar el personal.

3. Principis


4. Instruments

Cicle de vida d'un sistema algorítmic municipalQuatre etapes: inscripció al RPA, avaluació d'impacte —que es bifurca en AIPD del RGPD si tracta dades personals i FRIA del Reglament d'IA si és d'alt risc en organisme públic—, contractació, i governança i auditoria.AIPD (RGPD)dades personals3. ContractacióFRIA (Reglament IA)alt risc annex III, ens públic4. Governançai auditoria2. Avaluació d'impacte1. Inscripció al RPA

4.1 Registre municipal d'algorismes

El RPA (Registre Públic d'Algorismes) és l'inventari públic dels sistemes algorítmics que utilitza l'Ajuntament. Tot sistema algorítmic hi ha d'inscriure's, sigui quin sigui el seu nivell de risc, amb la seva finalitat, l'abast, l'àrea responsable, les dades que tracta, el tipus de decisió que suporta, el nivell de risc i, quan n'hi ha, l'EIA (Estudi d'Impacte Algorítmic). És l'instrument central de transparència algorítmica i segueix la línia dels registres d'Amsterdam i Hèlsinki.

Qui l'audita: l'estudi d'impacte previ el revisa el Consell Assessor en Intel·ligència Artificial, Ètica i Drets Digitals, format per experts externs a l'Ajuntament per garantir-ne la imparcialitat; un cop en explotació, el sistema es revisa mitjançant auditories algorítmiques dutes a terme per una entitat externa, amb la contractació liderada per l'IMI (Institut Municipal d'Informàtica), avui BIT (Barcelona Innovació i Tecnologia). Si el sistema tracta dades personals, s'inscriu també al RAT (Registre d'Activitats de Tractament) municipal.

Rendició de comptes: la informació del RPA —finalitat, abast, dades, riscos, EIA, informes d'auditoria i balanç final— es difon al Portal de Transparència, el canal bàsic i general perquè la ciutadania pugui conèixer i exigir comptes sobre l'ús municipal de la IA.

4.2 Avaluació d'impacte algorítmic

Procediment d'anàlisi previ al desplegament que valora l'impacte sobre drets fonamentals, equitat, privadesa i seguretat, i que determina les mesures de mitigació i el nivell de supervisió humana necessari. S'articula amb l'AIPD (Avaluació d'Impacte de Protecció de Dades) del RGPD, art. 35 i, per als sistemes d'alt risc, amb la FRIA (Fundamental Rights Impact Assessment) del RIA (Reglament d'Intel·ligència Artificial). L'art. 27 del RIA no l'exigeix davant qualsevol sistema d'alt risc: només davant els de l'annex III —llevat del punt 2— i quan el desplegador és un organisme de dret públic o una entitat privada que presta serveis públics; i, sigui quin sigui el desplegador, davant els de l'annex III, punt 5, lletres b) i c).

4.3 Definició de metodologies i protocols de contractació

El document Metodologia de sistemes algorítmics estableix com s'han de contractar els sistemes algorítmics:

Alliberament del codi. Quan al plec no hi ha cap clàusula sobre la llicència del programari, cal mirar la titularitat: l'LCSP, art. 308.1 estableix que, llevat que el plec digui una altra cosa, els contractes de serveis que desenvolupen un producte protegit per propietat intel·lectual porten aparellada la cessió d'aquest dret a l'Administració contractant. Un cop l'Ajuntament n'és titular, alliberar-lo com a codi obert exigeix dos passos, no un de sol:

  1. Comprovar les llicències de tercers: si el codi incorpora llibreries amb llicència propietària incompatible, no es pot publicar el conjunt sense abans substituir-les o negociar-ne l'ús.
  2. Associar-hi una llicència de programari lliure adequada. L'ENI, art. 16 fixa les condicions de llicenciament de les aplicacions de titularitat pública (execució per a qualsevol propòsit, accés al codi font, modificació i redistribució) i indica que es procurarà l'aplicació de l'EUPL (European Union Public Licence, Llicència Pública de la Unió Europea).

4.4 Governança

L'estratègia crea quatre òrgans amb funcions diferenciades, dos d'interns i dos de participació externa:

A més: el Delegat de Protecció de Dades, amb intervenció preceptiva quan hi ha tractament de dades personals; l'Oficina Municipal de Dades (OMD), dirigida pel Chief Data Officer, per al govern de les dades municipals → tema 31; i la formació del personal en competències de dades i IA.

4.5 Altres actuacions


5. Els drets digitals com a marc

L'estratègia s'insereix en el discurs municipal de drets digitals:

Referències: la Mesura de digitalització oberta, els Barcelona Digital Standards i la guia de programari lliure municipal.


6. Encaix normatiu

Norma Què aporta
RIA classificació per risc; obligacions dels sistemes d'alt risc; FRIA de l'art. 27, amb l'àmbit acotat de l'annex III (§4.2); prohibició de la puntuació social
RGPD base de licitud, art. 22 (decisions automatitzades), art. 35 (AIPD), principis de minimització i exactitud
Llei 40/2015, art. 41 actuació administrativa automatitzada: òrgan competent per a especificacions, programació, manteniment, supervisió, control de qualitat i auditoria del codi font, i òrgan responsable a efectes d'impugnació
Llei 39/2015, art. 35 motivació dels actes: una decisió no explicable no es pot motivar
Llei 19/2013 i Llei 19/2014 transparència, publicitat activa i dret d'accés — base del registre d'algorismes
ENS seguretat dels sistemes que suporten els algorismes
LCSP, art. 308.1 contractació: criteris d'adjudicació, clàusules i cessió a l'Administració de la propietat intel·lectual del codi desenvolupat, llevat de pacte en contra
ENI, art. 16 condicions de llicenciament del programari de titularitat pública; preferència per l'EUPL en alliberar codi com a lliure

Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 31

Gestió de dades a l'Administració

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

Enunciat oficial. Gestió de dades a l'Administració. Estratègia de dades, inventari i catàleg. Data governance i qualitat del dada.


1. Les dades com a actiu

Una estratègia de dades defineix com l'organització captura, emmagatzema, governa, comparteix i explota les dades per assolir els seus objectius. Sense estratègia, cada sistema genera el seu sitja i la mateixa dada té valors diferents en llocs diferents.

Components d'una estratègia de dades:

  1. Visió i objectius de negoci que les dades han de suportar.
  2. Govern: rols, polítiques, comitès i responsabilitats.
  3. Arquitectura de dades: on viuen, com flueixen, quins models les descriuen → tema 32.
  4. Qualitat de les dades: dimensions, mesura i remediació.
  5. Metadades i catàleg: què hi ha, què significa, d'on ve.
  6. Seguretat i privadesa: classificació, control d'accés, cicle de vida.
  7. Compartició i obertura: interoperabilitat i dades obertes → tema 33.
  8. Cultura i competències: alfabetització de dades i presa de decisions basada en evidència.
  9. Mesura: indicadors de maduresa i de valor obtingut.

Marc de referència: DAMA-DMBOK (DAMA, Data Management Association; DMBOK, Data Management Body of Knowledge), amb la seva roda d'onze àrees de coneixement al voltant del govern de dades com a eix: arquitectura, modelatge i disseny, emmagatzematge i operacions, seguretat, integració i interoperabilitat, gestió de documents i contingut, dades mestres i de referència, data warehousing i BI (Business Intelligence), metadades, qualitat i govern.


2. Govern de les dades (data governance)

Definició: exercici d'autoritat i control —planificació, supervisió i execució— sobre la gestió dels actius de dades. Respon a qui decideix què sobre les dades.

No és el mateix que gestió de dades: el govern decideix i controla; la gestió executa.

2.1 Rols

Rol Responsabilitat
Chief Data Officer (CDO) màxim responsable de l'estratègia i el govern de les dades de l'organització
Comitè de govern de dades òrgan de decisió sobre polítiques, prioritats i conflictes
Propietari de la dada (data owner) responsable de negoci d'un domini de dades: en defineix el significat, la qualitat exigida i qui hi pot accedir
Custodi (data steward) garant operatiu de la qualitat, les definicions i el compliment dins d'un domini
Data custodian / administrador tècnic gestiona els sistemes que emmagatzemen les dades
Arquitecte de dades dissenya models i flux
DPD (Delegat de Protecció de Dades) supervisa el compliment del RGPD
Responsable de la informació (ENS) determina els requisits de seguretat de la informació

Regla: cada conjunt de dades ha de tenir un propietari de negoci identificat. Sense propietari, ningú no decideix ni respon de la seva qualitat.

2.2 Polítiques

Classificació de la informació, control d'accés i mínim privilegi, cicle de vida i retenció, qualitat mínima exigible, gestió de metadades, ús secundari i compartició, anonimització i pseudonimització, i ètica de les dades.


3. Inventari i catàleg de dades

3.1 Inventari

Inventari de dades: relació dels conjunts de dades que l'organització posseeix, amb el sistema on resideixen, el responsable, la categoria d'informació i la base jurídica del tractament. És obligatori de facto per dues vies:

3.2 Catàleg de dades (data catalog)

Va més enllà de l'inventari: és un repositori cercable de metadades que permet a qualsevol persona autoritzada descobrir quines dades existeixen, què signifiquen, d'on venen, quina qualitat tenen i com accedir-hi.

Contingut: nom i descripció en llenguatge de negoci, propietari i custodi, esquema i tipus, glossari de negoci (definició acordada de cada terme), llinatge (lineage), indicadors de qualitat, classificació de sensibilitat, política de retenció, freqüència d'actualització i condicions d'ús.

Tipus de metadades: de negoci (significat, propietari, regles), tècniques (esquema, tipus, ubicació, format) i operatives (data de càrrega, volum, errors, llinatge d'execució).

Llinatge de dades (data lineage): traçabilitat del recorregut d'una dada des de l'origen fins al consum, incloent-hi totes les transformacions. Serveix per a l'anàlisi d'impacte, la depuració d'errors, l'auditoria i el compliment.

Eines: DataHub, OpenMetadata, Amundsen, Apache Atlas, Collibra, Alation, Informatica, Microsoft Purview, CKAN (Comprehensive Knowledge Archive Network, per a dades obertes).

Marc normatiu: a l'Administració, el catàleg no és una bona pràctica opcional sinó una obligació que ve de l'ENI (RD, Reial Decret, 4/2010) i de les seves Normes Tècniques d'Interoperabilitat (NTI): la NTI de Catàleg d'estàndards fixa quins estàndards són d'ús obligatori, la NTI de Document electrònic en regula els metadades i el cicle de vida, i la NTI de Reutilització de recursos de la informació en condiciona la publicació com a dada oberta → tema 33.


4. Qualitat de les dades

4.1 Dimensions

Dimensió Pregunta
Exactitud el valor reflecteix la realitat?
Completesa hi són tots els valors que hi haurien de ser?
Consistència el mateix fet té el mateix valor a tots els sistemes?
Actualitat / oportunitat (timeliness) està prou al dia per a l'ús que se'n vol fer?
Validesa / conformitat compleix el format, el domini i les regles definides?
Unicitat hi ha duplicats?
Integritat les relacions entre entitats són coherents?
Traçabilitat se'n coneix l'origen i les transformacions?
Accessibilitat qui la necessita hi pot arribar?

Norma: ISO/IEC 25012 (IEC: International Electrotechnical Commission; model de qualitat del dada) i ISO 8000.

4.2 Gestió de la qualitat

Cicle: perfilat (profiling) de les dades → definició de regles i llindars → mesura amb indicadors → informe i quadre de comandament → remediació (correcció a l'origen) → prevenció (validació a l'entrada) → monitoratge continu.

Principi fonamental: corregir a l'origen, no al magatzem. Netejar les dades al procés d'ETL (Extract, Transform, Load) cada nit sense corregir el sistema font és treball perpetu.

Cost de la no-qualitat: decisions errònies, retreball, pèrdua de confiança en els sistemes analítics, incompliment normatiu (el RGPD, art. 5 imposa el principi d'exactitud) i, al sector públic, perjudici directe al ciutadà (notificacions a adreces errònies, prestacions mal calculades).


5. Dades mestres i de referència


6. Modelatge de dades

Conceptes bàsics que apareixen a l'examen amb freqüència:

Una entitat, una relació i una clauL'original està en notació de Chen, on la forma de cada caixa és el que diu si és entitat, relació o atribut. drawspec no dibuixa Chen: les seves formes signifiquen altres coses. Això diu el mateix amb el seu vocabulari — les entitats són caixes, la relació és el que hi ha escrit sobre la línia, i la clau primària va dita.AlumneExpedientNIFclau primàriaMatricula


7. El model de l'Ajuntament de Barcelona


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 32

Arquitectura de dades

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

Enunciat oficial. Arquitectura de dades. Data warehouse, data lake i data lakehouse.


1. OLTP i OLAP

OLTP (Online Transaction Processing) OLAP (Online Analytical Processing)
Finalitat operar el negoci analitzar el negoci
Operacions insercions, actualitzacions i esborrats freqüents i curts consultes complexes d'agregació sobre grans volums
Model normalitzat (3FN) desnormalitzat (estrella, floc de neu, cub)
Dades actuals i detallades històriques i agregades
Usuaris molts, concurrents, operatius pocs, analistes i direcció
Optimització escriptura i integritat lectura i agregació

Cub OLAP: estructura multidimensional on les dades s'organitzen per dimensions (temps, territori, servei) i mesures (imports, comptadors). Quan les dades s'estructuren en un cub OLAP, el model de base de dades al qual ens referim és el multidimensional, no el relacional ni el jeràrquic. Operacions típiques: roll-up (agregar), drill-down (desagregar), slice (fixar una dimensió), dice (subcub) i pivot.

Variants del cub: MOLAP (Multidimensional OLAP: matriu pròpia, ràpid, menys escalable), ROLAP (Relational OLAP: sobre taules relacionals, escalable, més lent) i HOLAP (Hybrid OLAP).


2. El magatzem de dades (data warehouse)

Definició de Bill Inmon: col·lecció de dades orientada a un tema, integrada, no volàtil i variant en el temps, destinada a donar suport al procés de presa de decisions de la direcció. Aquestes quatre característiques cauen literalment.

2.1 Arquitectures

2.2 Modelatge dimensional

2.3 ETL i ELT

ETL (Extract, Transform, Load): procés d'extracció de dades de les fonts d'origen, transformació —neteja, normalització, deduplicació, enriquiment, agregació i aplicació de regles de negoci— i càrrega al magatzem de destinació. És el mecanisme que fa possible integrar dades heterogènies en un model coherent, i el que consumeix la major part de l'esforç d'un projecte de BI (Business Intelligence, intel·ligència de negoci — desenvolupat a tic/analitica-de-datos-y-business-intelligence).

ELT (Extract, Load, Transform): s'extreu, es carrega en brut i es transforma dins del sistema destinació, aprofitant-ne la potència de càlcul. És el model dominant al núvol i als data lakes.

Eines: Talend, Pentaho, Informatica i SSIS (SQL Server Integration Services) per a l'ETL clàssic; dbt per a la transformació ELT; Apache Airflow per a l'orquestració.

Captura de canvis (CDC, Change Data Capture): replicació incremental llegint el registre de transaccions (Debezium, GoldenGate) en lloc de fer extraccions completes.


3. El llac de dades (data lake)

Definició: repositori centralitzat que permet emmagatzemar dades a qualsevol escala en el seu format natiu i sense estructura predefinida —estructurades, semiestructurades i no estructurades—, per processar-les i analitzar-les quan calgui.

Objectiu principal en l'ecosistema de Big Data: centralitzar dades de fonts i formats diversos en brut, sense pèrdua d'informació ni transformació prèvia, per explotar-les després amb finalitats no conegudes en el moment de la captació —analítica avançada, ciència de dades i entrenament de models.

La diferència clau amb el magatzem és quan s'aplica l'esquema: el magatzem l'exigeix abans de carregar (schema-on-write) i per això només hi entra dada curada; el llac l'aplica en llegir (schema-on-read) i per això hi cap la dada bruta de qualsevol format. La resta de diferències en surten, i van comparades amb el lakehouse al §8.

Zones d'un data lake, l'arquitectura medalló: bronze/raw (ingesta en brut), silver/curated (netejada i conformada) i gold/consum (agregada i modelada per a l'ús).

Tecnologies: emmagatzematge d'objectes (S3 (Simple Storage Service, Amazon), Azure Data Lake Storage, Google Cloud Storage, MinIO, HDFS (Hadoop Distributed File System)), formats columnars (Parquet, ORC (Optimized Row Columnar), Avro) i motors de processament.

El substrat d'un llac és l'emmagatzematge d'objectes, no el bloc ni el fitxer (→ tema 56), i no per casualitat: la dada és un objecte —contingut més metadades— amb una clau i sense jerarquia de directoris, així que s'hi pot abocar qualsevol format sense decidir abans on encaixa, que és la condició material del schema-on-read; escala sense límit pràctic i costa molt menys per TB (terabyte) que el bloc; i separa l'emmagatzematge del còmput, perquè les dades es queden quietes i els motors s'aixequen a sobre. El revers és que l'objecte és immutable —es reescriu sencer, no s'hi modifica una fila—, i per això un llac «pelat» no sap fer UPDATE ni DELETE: és la mancança que resolen els formats de taula del §4 i la que fa problemàtic el dret de supressió del §7. La immutabilitat com a defensa contra el ransomware és matèria de les còpies de seguretat (→ tema 57).

Apache Spark és el motor de processament de dades habitualment utilitzat en entorns de data lake per analitzar grans volums de dades de manera distribuïda. Substitueix MapReduce de Hadoop amb un model en memòria molt més ràpid, i ofereix Spark SQL, Structured Streaming, MLlib i GraphX. Alternatives: Flink (flux real), Trino (consulta federada) i Hive (SQL sobre HDFS).

3.1 Dades estructurades, semiestructurades i no estructurades

La distinció no és el format del fitxer, sinó on viu l'esquema: és el que separa el que pot entrar en un magatzem del que necessita un llac.

Estructurades Semiestructurades No estructurades
Esquema fix i previ, separat de la dada implícit i dins de la dada (etiquetes, claus) cap
Exemples taules relacionals, CSV (Comma-Separated Values), full de càlcul JSON, XML (eXtensible Markup Language), registres d'activitat text lliure, correu, imatge, àudio, vídeo, PDF escanejat
Consulta SQL directe cal recórrer l'estructura o aplanar-la cal extreure'n abans característiques o text
On encaixa magatzem de dades, OLTP documental NoSQL, llac llac, emmagatzematge d'objectes

Semiestructurada no vol dir «a mitges»: la dada porta l'esquema a dins, i per això dos registres del mateix conjunt poden tenir camps diferents —el que fa idònia una documental (§5.2) i el que un esquema relacional fix no tolera—. I el gruix de la informació d'una organització és no estructurada, justament la que un magatzem no pot admetre: aquest és el buit que va justificar el llac.


4. El lakehouse

Definició: arquitectura que combina la flexibilitat i el cost de l'emmagatzematge del data lake amb les garanties transaccionals, l'esquema i el rendiment del data warehouse, sobre una única còpia de les dades.

Com ho aconsegueix: amb formats de taula oberts que afegeixen una capa de metadades transaccional sobre els fitxers Parquet de l'emmagatzematge d'objectes:

Què hi perds: maduresa desigual, complexitat operativa i dependència de l'ecosistema triat.

Arquitectura medalló i lakehouseLes dades travessen tres zones dins del data lake. El que el converteix en lakehouse és un format de taula obert — Delta, Iceberg o Hudi — que val per a les tres.format de taula obert(Delta / Iceberg / Hudi)= LakehouseBronzerawBI i MLFontsGoldconsumSilvercuratedIngesta


5. Bases de dades: relacionals i NoSQL

5.1 Relacionals (SQL)

Model de taules amb files i columnes, esquema fix, relacions per claus foranes, llenguatge SQL i garanties ACID. Productes: Oracle, SQL Server, PostgreSQL, MySQL/MariaDB, DB2 (DataBase 2, IBM).

Adequades quan: integritat referencial i transaccional és crítica, l'esquema és estable, les consultes són complexes i relacionals, i hi ha requisits de compliment i auditoria. És el cas de la immensa majoria de sistemes de tramitació administrativa.

SQL (Structured Query Language, llenguatge de consulta estructurat), normalitzat a la ISO/IEC 9075 (IEC: International Electrotechnical Commission), es divideix en dos blocs d'operacions: DDL (Data Definition Language, llenguatge de definició de dades) —crear i modificar l'estructura de les taules (CREATE, ALTER, DROP)— i DML (Data Manipulation Language, llenguatge de manipulació de dades) —consultar, inserir, actualitzar i esborrar registres (SELECT, INSERT, UPDATE, DELETE)—. El que queda fora d'SQL: la programació i gestió automàtica de còpies de seguretat és una tasca d'administració del SGBD (Sistema de Gestió de Bases de Dades), no una operació del llenguatge.

5.2 NoSQL

Diferència fonamental amb les relacionals: les NoSQL no imposen un esquema fix ni el model relacional de taules; estan dissenyades per a l'escalabilitat horitzontal (afegir nodes) i per a dades semiestructurades o no estructurades, sacrificant sovint la consistència forta a canvi de disponibilitat i tolerància a particions.

Quatre famílies:

Família Model Quan Exemples
Clau-valor parells clau → valor opac accés extremament ràpid per clau i escalat horitzontal senzill: cachés, sessions, configuració Redis, DynamoDB, Memcached
Documental documents autocontinguts, normalment JSON (JavaScript Object Notation), amb estructura flexible i imbricada emmagatzema cada registre com un document complet amb la seva pròpia estructura, que pot variar entre documents i contenir dades imbricades, sense esquema comú MongoDB, CouchDB, Elasticsearch
Columnar (wide-column) files amb famílies de columnes disperses escriptura massiva, sèries temporals, grans volums Cassandra, HBase, Bigtable
De grafs nodes i arestes amb propietats relacions complexes: xarxes, fraus, recomanació Neo4j, JanusGraph, Amazon Neptune

Avantatge principal del model clau-valor: rendiment i simplicitat — l'accés per clau és directe i escala horitzontalment. Inconvenient: no permet consultar pel contingut del valor.

Quan triar NoSQL davant d'una relacional: si una administració local vol explotar en mode Big Data els milions de registres d'una xarxa de sensors IoT (Internet of Things) distribuïda pel municipi —sense esquema fix i creixent sense parar—, el sistema gestor amb millors prestacions de rendiment i capacitat és una documental com MongoDB, que escala horitzontalment; no MySQL, MariaDB ni PostgreSQL, pensades per escalar verticalment sobre un esquema estable.

Teorema CAP (Brewer): un sistema distribuït no pot garantir simultàniament Consistència, Disponibilitat i Tolerància a particions; en presència de particions cal triar entre C i A. BASE (Basically Available, Soft state, Eventual consistency) és l'alternativa a ACID en aquests entorns.

5.3 Bases de dades en microserveis

Cada microservei ha de tenir la seva pròpia base de dades independent (database per service); l'antipatró és compartir-ne una entre tots els serveis. El patró i les seves conseqüències —consistència eventual, patró Saga— es despleguen a tic/arquitectura-de-microservicios. El que en toca aquí és la polyglot persistence: cada servei tria el tipus de base de dades que s'ajusta a les seves dades, no un motor únic imposat a tots.

5.4 Altres

De sèries temporals (InfluxDB, Prometheus), vectorials (pgvector) per a IA (Intel·ligència Artificial) i cerca semàntica, NewSQL (CockroachDB) amb ACID i escalabilitat horitzontal, i en memòria (SAP HANA (High-performance ANalytic Appliance), Redis) → tema 50.


6. Big data i processament

Les V del Big Data — la formulació clàssica són quatre: Volum, Velocitat, Varietat i Veracitat. Sovint s'hi afegeix el Valor (cinc V) i, en algunes formulacions, Variabilitat i Visualització. Quan una pregunta demana «les 4 V», la resposta és volum, velocitat, varietat i veracitat.

L'objectiu fonamental del Big Data és extreure valor de les dades: convertir-les en informació útil per a les decisions de negoci.

Arquitectures de processament:


7. Al sector públic

7.1 La ingesta de dades IoT: el cas Sentilo

Sentilo és una plataforma de codi obert per gestionar sensors i actuadors de ciutat: recull informació de sensors actius repartits per la ciutat i en recopila i comparteix les dades en temps real. La va desenvolupar l'Ajuntament de Barcelona, a través de l'IMI (Institut Municipal d'Informàtica), i la van adoptar altres ciutats i administracions. Va guanyar l'Open Awards 2016 com a plataforma més innovadora desenvolupada amb programari lliure.

La norma UNE (Una Norma Espanyola) 178104 —interoperabilitat de les plataformes de ciutats intel·ligents— proposa un model de capes: la capa d'adquisició (la baixa), que recull les dades dels sensors i actuadors; per sobre, la capa d'interoperabilitat, que n'exposa l'accés amb seguretat; i la capa de coneixement, que transforma la dada en informació abans d'arribar a la de dades obertes. Sentilo forma part de la capa d'adquisició: és l'origen de la ingesta, no la capa de coneixement ni la d'OpenData.

Fins on arriba aquest tema. Aquí la ingesta interessa com a primera baula de l'arquitectura de dades: d'on ve la dada, en quina capa entra i on aterra. La connectivitat que la porta fins a la plataforma —les xarxes LPWAN (Low-Power Wide-Area Network) com LoRaWAN, el protocol de missatgeria MQTT (Message Queuing Telemetry Transport) i l'edge computing, que preprocessa a prop del sensor— és matèria de xarxes (→ tema 62), igual que la definició d'Internet de les coses.

La seqüència d'una aplicació smart city encadena tres paradigmes, i cadascun alimenta el següent: primer IoT —captar les dades dels sensors (Sentilo)—; després Big Data —manegar-ne el volum, de l'ordre de terabytes, amb les eines de la §6—; i finalment BI —convertir-les en informació per decidir.


8. Les tres generacions: com hem arribat aquí

No són tres opcions del catàleg: són tres generacions, i cadascuna neix del defecte que la seva predecessora no podia resoldre. Saber quin resol cadascuna és el que permet contestar quan l'enunciat descriu un problema en lloc de nomenar l'arquitectura.

El data mesh no és la quarta: no canvia la tecnologia sinó qui és el propietari de la dada, i es pot muntar damunt d'un lakehouse (→ tema 34, que també hi contraposa el data fabric).

Data warehouse Data lake Lakehouse
Esquema schema-on-write schema-on-read schema-on-read amb esquema aplicat i evolutiu
Dades estructurades i curades qualsevol format, en brut totes dues, en una sola còpia
Transaccions ACID cap ACID pel format de taula obert
Format propietari del fabricant fitxers oberts (Parquet, ORC, Avro) obert (Delta, Iceberg, Hudi)
Cost per TB (terabyte) alt baix (objectes) baix
Còpies una una, i se'n copia al magatzem una de sola
Usuaris analistes de negoci (BI) científics de dades tots dos
Risc rigidesa i cost data swamp maduresa i complexitat

Govern i qualitat no són el mateix, i cap arquitectura els substitueix: el govern de les dades decideix qui mana sobre cada dada; la qualitat de les dades mesura com és de bona. Un llac sense govern és el que es converteix en data swamp. Totes dues, al → tema 31.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 33

Dades obertes i reutilització de la informació

Enunciat oficial. Dades obertes i reutilització de la informació a l'Administració Local. Open Data BCN. Estàndards, llicències i interoperabilitat.


1. Conceptes

Dades obertes (open data): dades que qualsevol pot utilitzar, reutilitzar i redistribuir lliurement, amb l'única exigència, com a màxim, d'atribució i de compartir amb la mateixa llicència.

RISP (Reutilització de la informació del sector públic): ús per part de persones físiques o jurídiques de documents en poder del sector públic amb finalitats comercials o no comercials diferents del propòsit inicial del servei públic per al qual es van produir.

Tres conceptes que no s'han de barrejar:

Transparència Dret d'accés a la informació Dades obertes / RISP
Què publicació activa d'informació institucional dret subjectiu a demanar informació concreta publicació de conjunts de dades reutilitzables
Iniciativa de l'Administració del ciutadà de l'Administració
Format comprensible el que existeixi estructurat i llegible per màquina
Norma Llei 19/2013, Llei 19/2014 Llei 19/2013, art. 12 i següents Directiva 2019/1024 i Llei 37/2007

2. Marc normatiu

Excepcions a la reutilització: informació afectada per la seguretat nacional, la defensa, la propietat intel·lectual de tercers, el secret estadístic o comercial, la protecció de dades personals i la informació que no obri en poder del sector públic.


3. Principis i qualitat de les dades obertes

Els principis internacionals (Open Data Charter, Sunlight Foundation):

Obertes per defecte · oportunes i exhaustives · accessibles i utilitzables · comparables i interoperables · per a la millora de la governança i la participació ciutadana · per al desenvolupament inclusiu i la innovació.

Requisits d'un conjunt de dades obert: complet, primari (a la font i amb el màxim detall), oportú (publicat aviat), accessible al major nombre d'usuaris i finalitats, processable per màquina, no discriminatori (sense registre previ), en format no propietari i lliure de llicències restrictives.

Criteri de classificació a l'hora de publicar: davant un conjunt de dades nou, l'Administració l'ha de situar en el model de les cinc estrelles per decidir si el format en què es publica és prou obert, i no només si es publica o no. Un criteri ben fonamentat combina el valor per a la ciutadania i la demanda existent, la facilitat i el cost d'anonimització i manteniment, i si el conjunt entra dins d'una de les categories d'alt valor (publicació obligatòria via API). El model de cinc estrelles és l'escala de referència per graduar-lo:

★ Requisit Exemple
★ disponible al web amb una llicència oberta, en qualsevol format un PDF escanejat amb llicència oberta
★★ disponible com a dades estructurades i llegibles per màquina un full de càlcul XLS
★★★ en un format no propietari CSV en lloc d'XLS
★★★★ s'utilitzen URI (Uniform Resource Identifier) per identificar les coses, de manera que s'hi pugui apuntar RDF amb URI
★★★★★ les dades s'enllacen amb altres dades per proporcionar context Linked Open Data

Les cinc estrelles de les dades obertesL'escala de Tim Berners-Lee: cada estrella afegeix una condició a l'anterior.★llicència oberta★★estructurades★★★no propietari★★★★URI★★★★★enllaçades


4. Formats, estàndards i metadades

Interoperabilitat: que un conjunt de dades es pugui reutilitzar sense dependre de qui l'ha publicat exigeix tres coses alhora: format obert i no propietari (perquè qualsevol eina el pugui llegir), vocabulari de metadades comú (perquè el significat dels camps es pugui interpretar igual en portals diferents) i API estandarditzada (perquè es pugui consultar per programa). És el que permet que data.europa.eu federi automàticament els portals nacionals (datos.gob.es) i regionals (dades.gencat.cat, Open Data BCN): sense estàndards compartits, cada portal seria una illa.

Formats de publicació adequats: CSV (Comma-Separated Values: el més estès i recomanat per a dades tabulars), JSON (JavaScript Object Notation), XML (eXtensible Markup Language), RDF (Resource Description Framework)/Turtle/JSON-LD (Linked Data: dades enllaçades), Parquet (grans volums), GeoJSON, SHP, GML (Geography Markup Language), KML (Keyhole Markup Language, geogràfics), GTFS (General Transit Feed Specification: transport públic).

No adequats per publicar un conjunt de dades obertes: XLSX (llegible per màquina però propietari), PDF (no és processable per màquina), una imatge o captura de pantalla (no és processable ni editable), i JS (JavaScript) —que no és un format de dades, sinó un llenguatge de programació: no descriu dades, les manipula.

Compte amb una errada de solucionari documentada al material: en una pregunta sobre formats geogràfics, GeoJSON SÍ que és un format geogràfic (és l'estàndard de facto per a dades geoespacials en JSON). El format que no ho és, en aquell enunciat, era MKV (Matroska Video: un contenidor de vídeo).

Metadades i vocabularis: les metadades no són les dades substantives del conjunt, sinó dades sobre les dades —i sovint es publiquen amb el conjunt i al catàleg—: qui les ha publicat, en quin format, quan es van actualitzar per última vegada, quina àrea temàtica cobreixen o amb quina llicència es distribueixen. És aquesta informació la que permet trobar un conjunt de dades al catàleg, saber si és fiable i de qui prové, i que una eina el pugui interpretar sense intervenció humana; per això un estàndard de metadades (DCAT) és tan necessari com el format de les dades pròpiament dites.

API (Application Programming Interface): la publicació moderna exigeix API REST (REpresentational State Transfer) amb consulta, filtratge i paginació, a més de la descàrrega massiva (bulk download). Els conjunts d'alt valor ho tenen com a obligació legal.

Plataformes: CKAN (Comprehensive Knowledge Archive Network: la més estesa al sector públic, de codi obert), Socrata, OpenDataSoft, DKAN, uData.

Portals: datos.gob.es (nacional), dades.gencat.cat (Catalunya), data.europa.eu (europeu, que federa els nacionals), Open Data BCN (municipal).


5. Llicències

Creative Commons és una organització sense ànim de lucre que publica un joc de llicències estàndard i gratuïtes amb les quals l'autor cedeix per endavant part dels seus drets: no és un domini públic ni una renúncia al dret d'autor, sinó una manera de dir per escrit què pot fer qui rep l'obra. Les sigles CC que porten totes les llicències de la taula són les seves.

Llicència Condicions
CC0 (Creative Commons Zero) domini públic, sense cap condició. La més oberta
CC BY 4.0 atribució de la font. És la recomanada per a dades obertes
CC BY-SA (Share Alike) atribució + compartir igual (viral)
ODbL Open Database License: atribució, compartir igual i mantenir obert
PDDL (Public Domain Dedication and License) domini públic per a bases de dades
Avís legal de reutilització model usat per l'Administració espanyola quan no s'adopta una CC

No són llicències obertes: CC BY-NC (Non-Commercial: prohibeix l'ús comercial) i CC BY-ND (No Derivatives: prohibeix les obres derivades). L'ús comercial ha de ser possible perquè unes dades siguin obertes; és una confusió freqüent.

Condicions generals de reutilització (art. 8 de la Llei 37/2007): no alterar el contingut, no desnaturalitzar el sentit de la informació, citar la font, esmentar la data de l'última actualització i no indicar que hi ha patrocini o aprovació del reutilitzador per part de l'organisme.


6. Open Data BCN

Portal de dades obertes de l'Ajuntament de Barcelona (opendata-ajuntament.barcelona.cat), un dels més antics d'Europa (des del 2010) i dels més ben valorats.

Característiques:

Marc de principis: la Mesura de digitalització oberta i la mesura de gestió ètica i responsable de les dades, amb la idea de les dades com a bé comú i la sobirania sobre les dades generades pels serveis municipals —incloent-hi les generades per concessionaris, que els plecs han d'obligar a cedir a l'Ajuntament.

Iniciatives associades: Decidim (participació, de codi obert), DECODE (DEcentralised Citizen-owned Data Ecosystems: projecte europeu de sobirania de dades ciutadana), Cities Coalition for Digital Rights, BCNROC (BCN Repositori Obert del Coneixement: repositori documental obert) i el Pla Barcelona Ciutat Digital.


7. Valor i reptes

Valor: transparència i retiment de comptes, reutilització econòmica (aplicacions, serveis, recerca), eficiència interna (les àrees municipals també consumeixen l'API), participació ciutadana i innovació oberta.

Reptes:


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 34

Dominis de dades en arquitectura Data Mesh

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

Enunciat oficial. Dominis de dades en arquitectura DATA MESH.


1. El problema que resol

Les arquitectures analítiques monolítiques —un data warehouse o un data lake central operat per un únic equip de dades— topen amb tres límits quan l'organització creix:

Data Mesh (Zhamak Dehghani, 2019) proposa descentralitzar l'arquitectura i la propietat analítiques cap als equips de domini, aplicant al món de les dades les lliçons del disseny orientat al domini i dels microserveis.

Data Mesh és, primer, un canvi organitzatiu i de responsabilitats, i només després una arquitectura tècnica. Aquest és el punt que més es malinterpreta.


2. Els quatre principis

2.1 Propietat de les dades orientada al domini

Les dades analítiques les posseeix i gestiona l'equip del domini de negoci que les genera i que millor les entén, no un equip central.

Domini (en Data Mesh): àrea de negoci amb límits clars i un equip responsable, que posseeix, gestiona i serveix les seves pròpies dades analítiques com un producte, amb responsabilitat completa sobre el seu cicle de vida —ingesta, model, qualitat, documentació, accés i evolució.

Aquesta és la definició que respon la pregunta d'examen. Un domini no és una carpeta del data lake, ni un esquema de base de dades, ni un data mart departamental gestionat pel centre: és una unitat organitzativa amb propietat i responsabilitat sobre les seves dades.

Tipus de domini: de font (genera dades des dels sistemes operacionals), de consum (les explota per a un cas d'ús) i agregat (combina dades de diversos dominis per crear una visió transversal).

Delimitació: els límits del domini se solen fer coincidir amb els contextos delimitats (bounded contexts) del Domain-Driven Design i amb les capacitats de negoci de l'organització.

Fronteres entre dominis: quan un domini consumeix dades d'un altre no n'hereta l'esquema intern, sinó el contracte de dades (data contract) que aquell publica —l'esquema, els objectius de qualitat i les regles d'evolució—, perquè un canvi al domini font no trenqui els consumidors sense avís. Els identificadors i les dades mestres compartides (client, ciutadà, immoble) es defineixen com a estàndard comú de la malla, no els imposa cap domini concret als altres.

2.2 Dades com a producte (data as a product)

Cada domini publica les seves dades com un producte amb un propietari (data product owner) i uns consumidors. Un producte de dades ha de complir les característiques DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure):

S'hi afegeixen sovint valuós per si sol i natiu multientorn.

El producte de dades inclou codi, dades i metadades, i la infraestructura que el serveix: no és només un fitxer.

2.3 Plataforma de dades d'autoservei

Una plataforma comuna proporciona als dominis les capacitats tècniques —emmagatzematge, processament, orquestració, catàleg, control d'accés, observabilitat, CI/CD— de manera autoservei, perquè cada domini pugui publicar productes de dades sense dependre d'un equip central i sense haver de ser expert en infraestructura.

Objectiu: reduir el cost cognitiu del domini. Si publicar un producte de dades exigeix conèixer Kubernetes, la descentralització no funciona.

Plans de la plataforma: infraestructura d'utilitat (emmagatzematge, còmput), experiència del producte de dades (crear, publicar, versionar, monitorar) i malla (mesh) supervisora (catàleg global, llinatge, polítiques).

2.4 Govern federat computacional

Un model de govern federat: un comitè amb representació de tots els dominis i de la plataforma acorda les polítiques globals —estàndards d'interoperabilitat, identificadors, seguretat, privadesa, qualitat mínima—, i cada domini decideix la resta.

Computacional vol dir que les polítiques s'implementen com a codi automatitzat a la plataforma, no com a documents que algú ha de recordar complir: validacions d'esquema, comprovacions de qualitat al desplegament, control d'accés declaratiu, etiquetatge automàtic de dades sensibles.

Els quatre principis del Data MeshQuatre dominis, cadascun amb el seu producte de dades, sota un govern federat computacional i assentats sobre una plataforma de dades d'autoservei comuna.Govern federat computacionalpolítiques com a codiDomini Aproducte de dadesDomini Bproducte de dadesDomini Cproducte de dadesDomini Dproducte de dadesPlataforma de dades d'autoservei


3. Comparació amb altres arquitectures

Data warehouse / Data lake centralitzat Data Mesh
Propietat equip central de dades equip de domini
Arquitectura monolítica distribuïda
Model canonical, definit al centre per domini, amb estàndards comuns d'interoperabilitat
Escalabilitat limitada pel centre escala organitzativament
Govern centralitzat federat i computacional
Risc coll d'ampolla i desconnexió semàntica fragmentació i duplicació si el govern federat és feble
Quan organitzacions petites o mitjanes, domini únic organitzacions grans, molts dominis, alta demanda analítica

Data Mesh vs Data Fabric: el Data Fabric és un enfocament tecnològic —una capa d'integració, metadades actives i automatització que unifica l'accés a dades distribuïdes—; el Data Mesh és organitzatiu. No són excloents: es pot fer servir tecnologia de fabric per implementar una malla.

Data Mesh vs Data Lakehouse: el lakehouse és una arquitectura d'emmagatzematge i processament → tema 32; el mesh és un model de propietat i govern. Un mesh es pot construir sobre lakehouses per domini.


4. Implantació

Passos habituals:

  1. Identificar els dominis i els seus límits, alineats amb l'estructura de negoci.
  2. Designar propietaris de producte de dades a cada domini.
  3. Definir els estàndards globals mínims: identificadors, formats, metadades, SLO de qualitat, classificació de sensibilitat.
  4. Construir la plataforma d'autoservei de manera incremental, començant pel que més fricció genera.
  5. Començar amb pocs dominis i un cas d'ús transversal que demostri el valor.
  6. Automatitzar el govern: cada política nova, un control a la plataforma.
  7. Formar els equips de domini en enginyeria de dades.

Riscos i condicions de fracàs:


5. Aplicació al sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 35

Analítica de dades i Business Intelligence

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

Enunciat oficial. Analítica de dades i Business Intelligence. Visualització, quadres de comandament i presa de decisions basada en dades.


1. Analítica de dades i Business Intelligence

1.1 Què és el Business Intelligence

BI (Business Intelligence, intel·ligència de negoci): conjunt d'estratègies, processos, tecnologies i eines que transformen dades en brut en informació útil per a la presa de decisions. Dit amb les paraules amb què s'ha preguntat, la seva funció principal és l'anàlisi i la presentació de dades per donar suport a la decisió.

Característiques del BI:

No és característica del BI «predir el futur amb models d'aprenentatge automàtic» —això és analítica avançada o predictiva—, ni «processar transaccions operatives» —això és OLTP—, ni «substituir el criteri del gestor». Són les distractores habituals de la pregunta «quina NO és una característica del BI».

Les quatre prestacions amb què se sol descriure una solució de BI, i que convé no confondre entre si: reporting —crear informes personalitzats per presentar dades—, anàlisi —accedir a les dades i analitzar-les, també en temps real—, autoservei —que l'usuari se les faci sense demanar-ho a ningú— i integració amb altres sistemes.

El BI comparat amb els sistemes veïns, que és l'altra manera de preguntar el mateix:

Sistema Funció principal
BI analitzar i presentar dades per decidir
CRM (Customer Relationship Management) gestionar la relació amb el client
ERP (Enterprise Resource Planning) executar els processos de gestió de l'organització
BPM (Business Process Management) modelar, executar i optimitzar processos
Gestió d'identitats control d'accés

El BI s'alimenta dels tres primers; no els substitueix.

1.2 Els quatre graus d'analítica

L'escala de maduresa analítica, i la pregunta que respon cada graó:

Grau Pregunta Tècniques
Descriptiva què ha passat? informes, quadres de comandament, OLAP
Diagnòstica per què ha passat? drill-down, correlació, anàlisi de causa arrel
Predictiva què passarà? models estadístics i d'aprenentatge automàtic
Prescriptiva què hauríem de fer? optimització, simulació, sistemes de recomanació

El BI clàssic cobreix els dos primers graus; el tercer i el quart són analítica avançada i entren en el terreny dels models → tema d'intel·ligència artificial.

1.3 BI, analítica i ciència de dades

Tres paraules que el tribunal fa servir com a distractores l'una de l'altra:

L'intrús habitual de la llista és l'exportació de dades (data export): treure dades d'un sistema a un fitxer és una operació, no una disciplina.


2. D'on surten les dades del BI

Aquest apartat només arriba fins on cal per entendre el BI: el magatzem, el llac, el lakehouse, l'ETL i l'ELT els desenvolupa el tema d'arquitectura de dades.

Cadena de valor d'una solució de Business IntelligenceDe les dades que produeix el negoci fins a la pregunta que algú s'hi fa, passant per una capa que dona nom a les mesures.Informes, quadres decomandament i autoserveiIntegracióETL o ELTFonts operativesOLTP, fitxers, APIMagatzem o llac de dadesCapa semànticamesures i jerarquies

Quan cal tecnologia de big data i quan no. No ho decideix el domini —«són sensors de ciutat»— sinó el volum, la velocitat i la varietat. El volum s'estima abans de decidir: nombre de dispositius × lectures per dia × mida del registre. Uns quants centenars de sensors que envien una lectura de desenes de bytes cada pocs minuts generen pocs megabytes al dia, i això es tracta amb tecnologia convencional.


3. Eines de BI

Família Exemples
Suites de BI més esteses Power BI (Microsoft), Tableau, Qlik (QlikView, Qlik Sense), SAP BI
No és BI de negoci Grafana: sèries temporals i observabilitat

Pregunta real: quina NO és una eina de reporting BI? (TS-TIC 2023 pràctica, s4, p. 22). La distractora sol ser un producte inventat amb nom versemblant, o una eina real però d'una altra família: integració, base de dades, orquestració o monitoratge.

Power BI, pel que se n'ha preguntat:


4. Visualització de dades

4.1 Quin gràfic per a què

Objectiu Gràfic
Comparar categories barres (horitzontals si les etiquetes són llargues)
Evolució temporal línies
Composició barres apilades, àrea, treemap; el de sectors només amb poques categories
Distribució histograma, caixa (box plot), violí
Correlació dispersió (scatter), bombolles
Geogràfic mapa de coropletes, mapa de punts, mapa de calor
Flux Sankey, diagrama de xarxa
Un sol valor amb objectiu indicador amb comparació, gràfic de bala (bullet)

Principis de disseny (Tufte, Few, Cairo; recollits també a les regles de presentació d'Eurostat):

4.2 Com menteix un gràfic

Els sis casos que es reconeixen a la primera i que són la base de les preguntes de «quin d'aquests gràfics és enganyós»:

4.3 Visualització accessible

Una visualització publicada per una administració està sotmesa a la normativa d'accessibilitat del sector públic —el Reial decret 1112/2018, que remet a la norma europea EN 301 549 i, per tant, al nivell AA de les WCAG (Web Content Accessibility Guidelines). El que això vol dir en un gràfic:


5. Quadres de comandament

5.1 Què és i de quins tipus

Quadre de comandament (dashboard): conjunt de visualitzacions organitzades en una sola pantalla que mostra els indicadors clau necessaris per assolir un o més objectius. Es distingeix d'un informe en tres coses: cap en una pantalla, s'actualitza sol i està pensat per mirar-se, no per llegir-se.

Per nivell d'ús:

Nivell Audiència Contingut Freqüència
Operatiu equips que executen estat actual, alarmes, cues temps real
Tàctic responsables de servei o d'àrea compliment d'objectius, tendències, comparatives setmanal o mensual
Estratègic direcció i òrgans de govern visió global, mapa estratègic, valor lliurat trimestral

El quadre de comandament d'un servei de tecnologies de la informació —quins KPI (Key Performance Indicator, indicador clau de rendiment) i quins CSF (Critical Success Factor, factor crític d'èxit) porta, i com encaixa amb la millora contínua— el desenvolupa el tema de mesura i millora contínua dels serveis. Aquí el quadre de comandament es tracta com a artefacte de visualització: què és, com es construeix i què el fa llegible o enganyós.

5.2 El quadre de comandament integral

El QCI, quadre de comandament integral (Balanced Scorecard) de Kaplan i Norton, és el sistema que tradueix l'estratègia en objectius i indicadors repartits en quatre perspectives connectades per relacions causa-efecte:

El mapa estratègic és el dibuix d'aquestes relacions causa-efecte: mostra que millorar la formació (aprenentatge) escurça el temps de tramitació (procés), que augmenta la satisfacció (ciutadania). Al sector públic la perspectiva superior és la de la missió i la ciutadania, no la financera, perquè els diners són un mitjà i no la finalitat.

Els requeriments funcionals bàsics que ha de complir un sistema per implementar un QCI, segons els estàndards de la Balanced Scorecard Collaborative, es divideixen en quatre seccions: disseny del quadre de comandament integral, capacitació estratègica i comunicació, explotació del negoci, i feedback i aprenentatge.

5.3 Com es construeix

L'ordre importa, i és el que es pregunta. Un indicador triat abans de saber quin objectiu mesura és un indicador que no es fa servir mai:

  1. Planificació i delimitació del projecte: abast, unitats implicades, patrocini directiu.
  2. Definició d'objectius estratègics a partir de la missió i les línies estratègiques.
  3. Elaboració del mapa estratègic: les relacions causa-efecte entre aquells objectius.
  4. Selecció i disseny d'indicadors per a cada objectiu, amb la seva fórmula, la font de dades i el responsable.
  5. Establiment de metes: el valor desitjat de cada indicador en un període determinat. Un indicador sense meta no diu si la cosa va bé.
  6. Determinació dels plans d'acció i de les mesures correctores quan hi ha desviació.
  7. Comunicació, implantació i retroalimentació: formació, transparència del sistema i revisió periòdica.

La seqüència que sol caure és mapa estratègic → selecció i disseny d'indicadors → metes, i la trampa és col·locar els plans d'acció just després del mapa, saltant-se els indicadors i les metes.

5.4 Tipus d'indicadors

Per l'objecte que mesuren —la classificació que ha caigut dues vegades:

Per la dimensió de gestió que valoren:

5.5 Què fa llegible un quadre de comandament

Una pantalla per audiència, sense desplaçament; el més important a dalt a l'esquerra; agrupació per temes; filtres coherents entre els panells; cada indicador amb objectiu i tendència, mai una xifra sola; semàfors només amb llindar definit i documentat; i la definició de cada mesura consultable des del mateix quadre.

Què el fa mentir, més enllà dels gràfics de l'apartat 4.2: massa indicadors —amb quaranta no se'n mira cap—, agregar territoris o col·lectius molt diferents en una sola xifra, barrejar períodes de càlcul, i indicadors sense propietari, que ningú actualitza i que envelleixen sense que es noti.


6. BI d'autoservei

Definició: model en què els usuaris de negoci creen els seus propis informes i anàlisis sense dependre del departament de tecnologia, sobre un conjunt de dades governat i preparat prèviament.

Característiques del BI d'autoservei:

NO és característica del BI d'autoservei que «les persones usuàries hagin de ser expertes en tecnologia» —això és justament el que evita—, ni que «cada usuari defineixi les seves pròpies regles de negoci i mètriques», ni que «l'usuari accedeixi directament a les bases de dades operacionals», ni «requerir la intervenció del departament de tecnologia per a cada informe», que és el contrari del concepte.

Riscos: proliferació d'informes duplicats, indicadors incompatibles, fulls de càlcul a l'ombra, i problemes de rendiment i de seguretat si l'accés no està delimitat. Mitigació: catàleg de conjunts de dades certificats, capa semàntica única, formació, i govern del contingut (qui pot publicar què i per a qui).


7. Presa de decisions basada en dades

Decisió basada en dades (data-driven decision making): fonamentar les decisions en evidència mesurada en lloc de la intuïció o l'antiguitat de qui parla.

Condicions perquè funcioni:

  1. Dades de qualitat i governades → tema de gestió de dades.
  2. Indicadors ben definits, amb propietari, fórmula i definició única.
  3. Accés de qui decideix a la informació, en el moment i el format adequats.
  4. Alfabetització de dades (data literacy): saber llegir un interval de confiança, distingir correlació de causalitat i reconèixer un gràfic enganyós.
  5. Cultura: acceptar que les dades contradiguin la intuïció, i que la mesura no és una amenaça.

Trampes freqüents: confondre correlació amb causalitat; biaix de supervivència; paradoxa de Simpson (una tendència agregada s'inverteix en desagregar per grups); cherry-picking del període o del segment que confirma la tesi; llei de Goodhart (quan la mesura es converteix en l'objectiu, deixa de ser una bona mesura); i decidir sobre mostres massa petites.

Al sector públic: l'evidència ha d'orientar-se al valor públic —equitat, cobertura, accessibilitat, satisfacció— i no només a l'eficiència. L'avaluació de polítiques públiques i la transparència (Llei 19/2013, art. 8, que obliga a publicar informació estadística sobre el grau de compliment i la qualitat dels serveis) donen a la mesura una dimensió de retiment de comptes.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 36

SAP FI i EA-PS

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

Enunciat oficial. SAP FI (Financial Accounting) i EA-PS (Enterprise Aplication for Public Sector).


1. Context: SAP a l'Administració

SAP ERP (Enterprise Resource Planning) és la plataforma de gestió econòmica, financera i de recursos humans de l'Ajuntament de Barcelona i de bona part de les grans administracions espanyoles. L'evolució tecnològica és SAP R/3 → SAP ERP (ECC 6.0, ERP Central Component) → SAP S/4HANA, aquest últim sobre la base de dades en memòria SAP HANA (High-performance ANalytic Appliance) → tema 50.

Estructura organitzativa financera (imprescindible per entendre la resta):

Element Què és
Mandant (client) unitat més alta; separació lògica completa de dades
Societat (company code) unitat mínima per a la qual es pot elaborar un balanç i un compte de resultats complets i legals. És la unitat de la comptabilitat financera externa
Àrea de control (controlling area) unitat de la comptabilitat analítica (CO)
Divisió (plant), centre de cost, centre de benefici unitats organitzatives operatives i analítiques
Àrea de comptabilitat pressupostària (FM area) unitat de la gestió pressupostària pública

2. SAP FI — Financial Accounting

Què és: el mòdul de comptabilitat financera externa de SAP. Registra tots els fets econòmics amb rellevància comptable i produeix els estats financers legals (balanç, compte de pèrdues i guanys) i la informació per a tercers (hisenda, auditors, proveïdors).

Quan la pregunta és quin mòdul cal parametritzar per gestionar la comptabilitat financera dins d'un entorn SAP, la resposta és FI.

Submòduls de FI:

Submòdul Contingut
FI-GL (General Ledger) comptabilitat general: pla de comptes, assentaments, tancaments, balanços. A S/4HANA, el Universal Journal (taula ACDOCA) unifica FI i CO en una única taula de documents
FI-AP (Accounts Payable) comptabilitat de proveïdors: factures rebudes, pagaments, retencions
FI-AR (Accounts Receivable) comptabilitat de clients/deutors: factures emeses, cobraments, reclamacions
FI-AA (Asset Accounting) immobilitzat: altes, amortitzacions, baixes, revaloracions
FI-BL (Bank Ledger) bancs i tresoreria: extractes, conciliació, mitjans de pagament
FI-TV (Travel Management) desplaçaments i dietes
FI-SL (Special Purpose Ledger) llibres especials per a requisits específics

Conceptes clau de FI:

Integració: FI rep automàticament els fets econòmics d'MM (compres i logística), SD (vendes), HCM (nòmina), AA i PS (projectes). El principi és que el document es genera on passa el fet i FI el recull.


3. SAP EA-PS — Enterprise Extension Public Services

Què és: l'extensió (Enterprise Extension) de SAP ERP específica per al sector públic — el prefix EA (Enterprise Add-On) designa la família de mòduls opcionals de SAP ERP. Adapta el nucli financer a la lògica de la comptabilitat pressupostària pública, que és radicalment diferent de la comptabilitat empresarial.

Funcionalitat directament relacionada amb EA-PS dins d'un entorn SAP ERP per al sector públic: la gestió pressupostària pública —elaboració, aprovació i control de l'execució del pressupost, amb les seves fases de despesa i el control de disponibilitat de crèdit—, juntament amb la gestió de subvencions i les competències específiques del sector públic. Aquesta és la resposta a la pregunta d'examen.

Components principals d'EA-PS:

Component Sigles Funció
Funds Management FM gestió pressupostària: estructura del pressupost, dotacions, control de disponibilitat, execució de la despesa i de l'ingrés. És el mòdul responsable de la gestió pressupostària en una organització amb comptabilitat pressupostària com un ajuntament
Grants Management GM (Grants Management) gestió de subvencions, tant rebudes com concedides, amb el seu cicle de vida i la justificació
Funds Management–Budget Control System BCS (Budget Control System) sistema de control pressupostari: versions de pressupost, modificacions de crèdit, bloquejos
Public Sector Collection and Disbursement PSCD (Public Sector Collection and Disbursement) gestió de cobraments i pagaments massius amb els ciutadans i contribuents. És el compte contracte del sector públic i la base de SAP TRM → tema 37
Tax and Revenue Management TRM (Tax and Revenue Management) gestió tributària → tema 37
Funds Management – Cash Budget Management CBM (Cash Budget Management) pressupost de tresoreria

Estructura pressupostària a FM:

El cicle pressupostari a SAP té quatre etapes: elaboració i aprovació del pressupost (dotacions inicials a FM), execució (les fases de la despesa, taula següent), i liquidació i tancament (romanents, compte general → tema comú 13, que en desenvolupa el marc normatiu). Aquí ens centrem en l'etapa d'execució: les fases de la despesa pública i el seu reflex a SAP FM —la correspondència que cal saber:

Fase administrativa Document SAP
Autorització (A) — autorització de la despesa reserva de crèdit / sol·licitud de comanda
Disposició (D) — compromís amb el tercer comanda de compra (MM) o contracte
Obligació reconeguda (O) — reconeixement del deute factura comptabilitzada (FI-AP)
Pagament (P) document de pagament (FI-BL)

Cadena de la despesa pública A-D-O-PQuatre fases, cadascuna amb el seu document. Cada fase consumeix el crèdit que va reservar l'anterior, i és per això que no se'n pot saltar cap.Autorització (A)reserva de crèditDisposició (D)comanda de compra ocontracte (MM)Obligació reconeguda (O)factura comptabilitzada (FI-AP)Pagament (P)document de pagament (FI-BL)

Cada fase consumeix crèdit i FM en fa el control de disponibilitat: si no hi ha crèdit suficient a la posició, el sistema bloqueja l'operació. Aquesta és la diferència essencial amb un ERP privat, on no hi ha crèdit pressupostari limitatiu.

Altres especificitats del sector públic: exercici pressupostari i romanents, modificacions de crèdit (transferències, crèdits extraordinaris, suplements, generacions, incorporacions de romanents), plurianualitat, finançament afectat, liquidació i compte general → tema comú 13.


4. Altres mòduls SAP rellevants

Mòdul Contingut
CO Controlling: comptabilitat analítica, centres de cost, ordres internes, comptabilitat de costos
MM Materials Management: compres, comandes, recepcions, inventari
SD Sales and Distribution: vendes i facturació
HCM Human Capital Management: personal i nòmina → tema 38
PS Project System: projectes i inversions
PM Plant Maintenance: manteniment
RE (Real Estate)-FX (Flexible Real Estate Management) gestió immobiliària
BASIS (Business Application Software Integrated Solution) capa tècnica: administració del sistema → tema 50
Solution Manager plataforma de gestió del cicle de vida de la solució SAP → tema 50

5. Aspectes tècnics i de gestió


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 37

SAP TRM (Tax and Revenue Management)

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

Enunciat oficial. SAP TRM (Tax and Revenue Management).


1. Què és i què no és

SAP TRM és la solució de SAP per a la gestió tributària i d'ingressos de dret públic de les administracions: gestió del padró de contribuents, liquidació, notificació, recaptació voluntària i executiva, fraccionaments, devolucions i inspecció.

Objectiu de SAP TRM: gestionar de manera integrada el cicle complet dels ingressos públics —tributs, taxes, preus públics, multes i altres ingressos de dret públic— des de la determinació del deute fins al seu cobrament o la seva declaració de fallida, amb el compte del contribuent com a eix.

Compte amb la confusió d'acrònims: SAP TRM també és la sigla de Treasury and Risk Management, el mòdul de gestió de tresoreria i risc financer (operacions financeres, instruments, gestió de liquiditat, risc de mercat i de crèdit). Els exàmens hi han jugat: llegeix bé si l'enunciat parla de tributs o de tresoreria. En el context del temari municipal, TRM és Tax and Revenue Management.

1.1 Delimitació respecte a altres mòduls SAP

Davant d'un supòsit de tribut o de taxa, els exàmens ofereixen com a distractors altres mòduls SAP que no hi tenen res a veure. Cap gestiona un compte de contribuent ni un deute públic:

Mòdul Per a què serveix Per què no gestiona un tribut
PCM (Profitability and Cost Management) anàlisi de la rendibilitat i dels costos per producte, client o línia de negoci és una eina d'anàlisi de marges, no de gestió de contribuents ni de deutes
BPC (Business Planning and Consolidation) planificació pressupostària i consolidació financera de grup planifica i consolida xifres agregades, no liquida ni recapta un ingrés concret
HCM (Human Capital Management) administració de personal, organització i nòmina → tema 38 gestiona empleats, no contribuents ni objectes tributaris

2. Arquitectura

TRM s'assenta sobre PSCD (Public Sector Collection and Disbursement), que al seu torn és l'adaptació al sector públic de FI-CA (Contract Accounts Receivable and Payable), la comptabilitat de comptes contracte dissenyada per a volums massius de deutors.

SAP TRM (gestió tributària)
   └─ PSCD (cobraments i pagaments massius del sector públic)
        └─ FI-CA (comptabilitat de comptes contracte)
             └─ FI (comptabilitat general)  ·  FM (pressupost)

Arquitectura en capes de SAP TRMCada capa se sustenta sobre la següent: la gestió tributària sobre els cobraments massius, aquests sobre els comptes contracte, i tots sobre la comptabilitat general i el pressupost.SAP TRMgestió tributàriaPSCDcobraments i pagaments massius del sector públicFI-CAcomptabilitat de comptes contracteFI / FMcomptabilitat general i pressupostcada capa se sustenta sobre la de sota

Per què no s'usa FI-AR (Accounts Receivable) clàssic: FI-AR està pensat per a centenars o milers de clients amb factures individuals. Un ajuntament té centenars de milers o milions de contribuents amb desenes de milions de rebuts periòdics. FI-CA/PSCD està dissenyat per a aquest volum: processament massiu, paral·lelització, i un model de dades optimitzat.


3. Conceptes de PSCD

Concepte Descripció
Interlocutor comercial (business partner) el contribuent: persona física o jurídica, amb els seus rols, dades de contacte i relacions
Compte contracte (contract account) agrupa les condicions de gestió del deute d'un interlocutor: forma de pagament, domiciliació, criteris de compensació i de reclamació
Objecte contracte / objecte tributari el fet imposable concret: un immoble a l'IBI, un vehicle a l'IVTM, una activitat a l'IAE
Partida oberta (open item) cada deute individual pendent
Document FI-CA registre de la liquidació, del pagament, de la compensació o de la baixa

Classe de document a PSCD i a FI-CA: igual que a FI (Financial Accounting, comptabilitat general), classifica el document, determina el rang de numeració i el comportament del procés. La funció de la classe de document en els documents del mòdul financer PSCD associat a TRM és, doncs, identificar el tipus d'operació i determinar-ne el tractament comptable, la numeració i les característiques del procés.

Classe d'operació principal i secundària (main transaction / sub transaction): parell de claus que determina la naturalesa del deute i la seva imputació comptable automàtica (a quin compte de major i a quina posició pressupostària va cada import). És el mecanisme de traducció entre el món tributari i el comptable.


4. El cicle de gestió tributària a TRM

  1. Gestió del padró i de les dades mestres: alta i manteniment de contribuents i objectes tributaris, sovint alimentat des de fonts externes (Cadastre, DGT, padró municipal d'habitants, registres d'activitats).
  2. Determinació i liquidació: càlcul de la quota a partir de la base imposable, el tipus i els beneficis fiscals. Pot ser per padró (massiva i periòdica: IBI, IVTM, IAE) o per autoliquidació o liquidació individual (ICIO, plusvàlua, taxes).
  3. Facturació i emissió: generació massiva dels rebuts o liquidacions.
  4. Notificació: individual o col·lectiva per edicte en el cas dels padrons, amb la seva publicació al butlletí oficial. Integració amb notificació electrònica (e-NOTUM) i amb la seu electrònica.
  5. Recaptació en període voluntari: domiciliació bancària (SEPA, Single Euro Payments Area, quaderns bancaris), entitats col·laboradores, passarel·la de pagament en línia, TPV (Terminal Punt de Venda), pagament a la carta i fraccionaments i ajornaments.
  6. Període executiu: recàrrecs, provisió de constrenyiment, interessos de demora, embargaments (comptes bancaris, salaris, devolucions d'hisenda, vehicles, immobles), subhasta.
  7. Devolucions d'ingressos indeguts i compensacions.
  8. Inspecció: comprovació, actes, liquidacions complementàries i expedients sancionadors.
  9. Recursos i reclamacions: recurs de reposició i, a Barcelona, reclamació davant el Consell Tributari → tema comú 11.
  10. Comptabilització: cada moviment genera els documents corresponents a FI i el consum o generació de drets a FM (pressupost d'ingressos).
  11. Baixes: crèdits incobrables, prescripció, insolvència.

Processos massius: TRM/PSCD executa la facturació, la domiciliació, la reclamació, la generació de rebuts i la comptabilització en execucions massives paral·lelitzades amb intervals de treball, cosa que permet tractar milions de partides en finestres nocturnes.


5. Integració


6. A l'Ajuntament de Barcelona


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 38

SAP HCM (Human Capital Management)

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

Enunciat oficial. SAP HCM (Human Capital Management).


1. Què és

SAP HCM (Human Capital Management; abans SAP HR, Human Resources) és el mòdul de gestió de recursos humans de SAP ERP: administració de personal, organització, temps, nòmina, contractació, formació, desenvolupament i autoservei.

HCM és un mòdul, no un producte: el producte és l'ERP (Enterprise Resource Planning, planificació de recursos empresarials) de SAP, un sistema integrat que gestiona sobre una única base de dades tots els processos de l'organització —finances, compres, logística i també RRHH (Recursos Humans)— i que es desenvolupa al detall al tema tic/soluciones-erp. Un ERP no és: un CRM (Customer Relationship Management, gestió de la relació amb el client, centrat en vendes i atenció al client), un BPM (Business Process Management, gestió i automatització de processos de negoci) ni una BI (Business Intelligence, intel·ligència de negoci, orientada a l'anàlisi de dades). HCM no és cap d'aquests tres: és el mòdul de l'ERP dedicat als recursos humans.

Pregunta d'examen: quan es parla de SAP-HCM per a la gestió de RRHH, s'està parlant d'un mòdul del producte SAP ERP (històricament SAP R/3 i després SAP ECC, ERP Central Component), no d'un producte independent. L'evolució al núvol és SAP SuccessFactors, i a S/4HANA el component en local es denomina SAP S/4HANA for Human Resources o s'integra amb SuccessFactors.


2. Els infotips

Concepte central del mòdul i pregunta recurrent.

Infotip (infotype): estructura de dades de recursos humans identificada per un codi numèric de quatre dígits que agrupa un conjunt lògic de camps relacionats i que s'emmagatzema amb VALIDESA TEMPORAL, és a dir, amb una data d'inici i una data de fi.

Característiques que cal saber:

Infotips més coneguts:

Codi Nom
0000 Mesures (Actions)
0001 Assignació organitzativa
0002 Dades personals
0006 Adreces
0007 Horari de treball teòric
0008 Emoluments bàsics (salari base)
0009 Relacions bancàries
0014 / 0015 Devengaments i deduccions periòdics / puntuals
0016 Elements del contracte
0021 Familiars
2001 / 2002 Absències / presències

3. Submòduls

Submòdul Sigles Contingut
Administració de personal PA (Personnel Administration) dades mestres de l'empleat, infotips, mesures de personal (alta, baixa, canvi de lloc, excedència)
Gestió de l'organització OM (Organizational Management) estructura organitzativa amb objectes i relacions: unitat organitzativa (O), lloc de treball (S, position), funció (C, job), persona (P), centre de cost (K)
Gestió del temps PT (Personnel Time Management) calendaris, torns, absències, presències, hores extres, quotes de vacances; registre de jornada
Nòmina PY (Payroll) càlcul de la nòmina, esquemes i regles de càlcul, retencions, IRPF (Impost sobre la Renda de les Persones Físiques), cotitzacions, pagaments i comptabilització
Contractació PB (Personalbeschaffung, alemany: contractació de personal) / E-Recruiting selecció i cobertura de vacants
Formació i esdeveniments PE plans formatius, cursos, assistents
Desenvolupament del personal PD (Personnel Development) perfils, qualificacions, plans de carrera, avaluació
Gestió de viatges FI-TV (Travel Management) desplaçaments i dietes
Autoservei ESS (Employee Self-Service) / MSS (Manager Self-Service) l'empleat consulta la seva nòmina, demana vacances o actualitza dades; el comandament aprova

Objectes i relacions de l'OMCinc tipus d'objecte de la gestió de l'organització. El lloc de treball és el subjecte: la unitat el conté, la funció el descriu, s'imputa a un centre de cost i una persona l'ocupa. La persona no penja de la unitat organitzativa.Funció (C)Centre de cost (K)Unitat organitzativa (O)Persona (P)Lloc de treball (S)contédescrit perimputat aocupat per

Les tres estructures de HCM que cal distingir:


4. La nòmina

Al sector públic cal, a més: gestió de la RLT (relació de llocs de treball) i de la plantilla, control del capítol 1 del pressupost, triennis i carrera professional, complements específics i de destinació, situacions administratives (TREBEP, art. 85), i tota la casuística del TREBEP → tema comú 14. SAP ofereix per a aquest àmbit l'extensió SAP HCM PSe (Public Sector), que sí inclou processos de selecció i provisió de personal (selecció externa i promoció interna), a banda d'acció social i gestió disciplinària.


5. Evolució i alternatives


6. Protecció de dades

HCM tracta dades personals de categoria especial en alguns casos (salut per a les baixes, afiliació sindical per a les quotes, discapacitat).


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 39

Desenvolupament d'aplicacions mòbils

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

Sense esquema, expressament

Enunciat oficial. Desenvolupament d'Aplicacions Mòbils. (APPS).


1. Tipus d'aplicació mòbil

Abans de començar un projecte cal escollir el tipus d'aplicació, en comparació amb les alternatives, segons els criteris principals que segueixen la taula.

Tipus Com es fa Avantatges Inconvenients
Nativa llenguatge i SDK (Software Development Kit) de la plataforma: Swift/SwiftUI + Xcode per a iOS, Kotlin/Java + Android Studio per a Android millor rendiment, accés complet al maquinari i a les API (Application Programming Interface, interfície de programació d'aplicacions) del sistema, millor UX (User eXperience, experiència d'usuari) i integració amb el sistema operatiu, funcionament fora de línia complet cal desenvolupar i mantenir una base de codi per plataforma: més cost i més temps
Web (web app) web responsiu executat al navegador una sola base de codi, desplegament immediat sense botigues, cap instal·lació accés limitat o nul al maquinari del dispositiu (sensors, contactes, Bluetooth, notificacions natives), rendiment inferior, dependència de la connexió i experiència d'usuari menys integrada
PWA (Progressive Web App, aplicació web progressiva) web + service worker + manifest instal·lable, funcionament fora de línia, notificacions push (limitades a iOS), sense botiga encara amb límits d'accés al maquinari, especialment a iOS
Híbrida web empaquetat en un contenidor natiu (Cordova, Ionic, Capacitor) una base de codi, accés al maquinari via connectors rendiment intermedi, sensació «no nativa»
Multiplataforma compilada Flutter (Dart), React Native (JS, JavaScript/TS, TypeScript), .NET MAUI (Multi-platform App UI), Kotlin Multiplatform una base de codi amb rendiment gairebé natiu, UI (User Interface, interfície d'usuari) consistent dependència del marc, retard en adoptar novetats del sistema, mida de l'aplicació

PWA: és la tendència recent de les aplicacions web que aprofiten funcions modernes del navegador per oferir experiències semblants a les de les aplicacions natives; així es coneixen les aplicacions web progressives.

Desavantatge clau de les WebApps davant les natives (pregunta literal): l'accés limitat a les funcionalitats i al maquinari del dispositiu —càmera, GPS d'alta precisió, biometria, NFC (Near Field Communication), Bluetooth, notificacions natives, treball en segon pla— i el rendiment i l'experiència d'usuari inferiors, especialment en interaccions gràfiques intensives.

Criteris de decisió: pressupost i equip disponible, necessitat d'accés al maquinari, exigència de rendiment, previsió de vida de l'aplicació, necessitat de funcionament fora de línia, i estratègia de distribució. Exemple: una app només per a Android que, accedint al micròfon del telèfon, ha de mesurar els decibels i dona prioritat al rendiment per proporcionar una experiència ràpida i bona és un cas clar de nativa: la tecnologia amb l'accés més directe al maquinari.

1.1 Llenguatges de programació

Compilats (C, Java, Swift): el codi font es tradueix sencer a codi màquina abans d'executar-se. Interpretats (Python, JavaScript): un intèrpret llegeix i executa el codi font línia a línia en temps d'execució, sense fase de compilació prèvia; és l'avantatge principal dels interpretats respecte als compilats —a canvi solen ser més lents en execució.

Els llenguatges que es fan servir depenen de la plataforma; el llenguatge tradicionalment més utilitzat a Android va ser Java, encara que avui Kotlin és el recomanat:

Plataforma Llenguatge
Android natiu Kotlin (recomanat) i Java
iOS natiu Swift i Objective-C
Multiplataforma Dart (Flutter), JavaScript/TypeScript (React Native)

2. Cicle de vida i metodologia

Metodologia àgil aplicada a les APP — la característica que la defineix principalment: el desenvolupament es fa en iteracions curtes que lliuren versions funcionals i utilitzables de l'aplicació de manera freqüent, incorporant la retroalimentació de l'usuari a cada cicle i acceptant els canvis de requisits. Això encaixa especialment bé amb el mòbil, on el retorn d'ús real (analítica, valoracions a les botigues, proves A/B) és immediat i abundant.

Fases: descobriment i definició de l'usuari → disseny UX/UI i prototipatge → desenvolupament iteratiu → proves → publicació → analítica i evolució.

Disseny mòbil: els conceptes clau per millorar l'experiència de les persones usuàries són la usabilitat —facilitat d'ús, navegació clara, poques passes per completar una tasca— i l'accessibilitat, i cal prioritzar-les per davant de l'acumulació de funcions o de l'estètica per si sola. mobile first, disseny responsiu i adaptatiu, guies de plataforma (Material Design d'Android, Human Interface Guidelines d'Apple), accessibilitat (WCAG (Web Content Accessibility Guidelines) 2.1 AA, lectors de pantalla VoiceOver i TalkBack, mida de text dinàmica, contrast), i suport de mode fosc i d'orientacions.

Proves: unitàries, d'interfície (Espresso, XCUITest, Appium), en dispositius reals i granges de dispositius (Firebase Test Lab, BrowserStack), i distribució beta (TestFlight, Google Play Internal Testing, Firebase App Distribution).

Publicació: App Store i Google Play, amb els seus processos de revisió, requisits de privadesa (privacy nutrition labels, formulari de seguretat de dades), signatura de l'aplicació i gestió de versions. Per a distribució interna: MDM (Mobile Device Management)/UEM (Unified Endpoint Management) i botigues corporatives → tema 52.

CI/CD mòbil: compilació automàtica, signatura, distribució i publicació (Fastlane, Bitrise, GitHub Actions) → tema 41.


3. Arquitectura i interoperabilitat

Aspecte fonamental per garantir la interoperabilitat d'una APP empresarial o municipal amb altres sistemes: exposar i consumir les dades mitjançant API estàndard, obertes i ben documentades —típicament REST (REpresentational State Transfer, transferència d'estat representacional) amb JSON (JavaScript Object Notation) i especificació OpenAPI—, amb formats de dades i vocabularis estàndard i amb un mecanisme d'autenticació i autorització també estàndard (OAuth 2.0 / OpenID Connect). L'aplicació mòbil ha de ser un client prim sobre serveis reutilitzables, no una integració punt a punt amb la base de dades de cada sistema.

Elements de l'arquitectura:


4. Seguretat mòbil

OWASP (Open Web Application Security Project) Mobile Top 10 (2024): ús indegut de credencials · cadena de subministrament insegura · autenticació i autorització insegures · validació d'entrada i sortida insuficient · comunicació insegura · controls de privadesa inadequats · proteccions binàries insuficients · configuració incorrecta de seguretat · emmagatzematge de dades insegur · criptografia insuficient.

Mesures:


5. Aplicacions mòbils al sector públic

Requisits específics:

Exemples municipals: Barcelona a la butxaca, apps de mobilitat i aparcament, Decidim (participació), i les apps de la Generalitat i de l'AOC (Administració Oberta de Catalunya).


6. Desplegament massiu a l'organització

Quan l'app és per als empleats i cal desplegar-la a tots els dispositius, la via correcta és el MDM/UEM: Microsoft Intune, Jamf, Workspace ONE, SOTI MobiControl. Permet distribució silenciosa, configuració remota, botiga corporativa, contenidorització del perfil de treball, polítiques de compliment i esborrat remot selectiu. → tema 52.

Programes de les plataformes: Apple Business Manager / Volume Purchase Program i Android Enterprise / Managed Google Play per a la distribució privada d'aplicacions.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 40

Eines de desenvolupament: LOW-CODE i NO-CODE

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. Eines de desenvolupament: LOWCODE i NOCODE.


1. Definicions

Les dues són eines de desenvolupament visual: es construeix l'aplicació component a component sobre un llenç, i la plataforma en genera l'execució, les dades i el desplegament. El que les separa és una sola cosa —si es pot escriure codi o no—, i d'aquí surt tota la resta: qui les pot fer servir, fins on arriben i quan es queden curtes.

Low-code No-code
Qui el fa servir desenvolupadors i perfils tècnics usuaris de negoci (citizen developers)
Codi interfície visual amb possibilitat d'escriure codi per a la lògica complexa, integracions i extensions exclusivament visual, sense escriure codi
Flexibilitat alta: es pot estendre gairebé sense límit limitada al que ofereix la plataforma
Casos aplicacions departamentals i corporatives, integracions, portals formularis, fluxos d'aprovació simples, aplicacions internes senzilles
Corba d'aprenentatge mitjana baixa

Tots dos comparteixen: desenvolupament visual (arrossegar i deixar anar), components predefinits, connectors a fonts de dades, plantilles, desplegament automatitzat i cicle de vida gestionat per la plataforma.

Concepte relacionat: el citizen developer és la persona d'una àrea de negoci, sense perfil tècnic, que construeix aplicacions amb aquestes eines dins d'un marc de govern establert per TI (Tecnologies de la Informació). El que el distingeix de qui munta una fulla de càlcul pel seu compte no és l'eina: és que treballa dins d'aquest marc; quan hi treballa fora, el resultat és shadow IT (§5).


2. Quan usar cadascun

El cas natural del no-code és el tràmit intern simple: agilitzar la creació d'un formulari de sol·licitud de material d'oficina, amb la seva aprovació i el seu seguiment, dins d'un projecte corporatiu. S'hi decanta perquè:

Casos d'ús habituals a una administració: sol·licituds i autoritzacions internes, inventaris i registres d'actius, reserves de sales i vehicles, recollida de dades de camp amb el mòbil (inspeccions, incidències a la via pública), enquestes i formularis de participació, quadres de seguiment d'un servei, i el seguiment intern de peticions que encara viu en una fulla de càlcul compartida. Una aplicació sectorial de tramitació —per exemple la gestió de llicències municipals— hi encaixa si el procediment no és reglat; si ho és, entra en joc el §7.

En canvi, es descarta el no-code quan hi ha requisits de rendiment exigents, lògica de negoci complexa, integracions no cobertes pels connectors, alta criticitat o volums grans.

Regla pràctica de decisió:

Situació Enfocament
Formularis, aprovacions, seguiment simple, ús intern i volum baix no-code
Aplicació departamental amb integracions i regles moderades low-code
Nucli de negoci, alt volum, alta criticitat, requisits singulars desenvolupament tradicional

3. Plataformes

Categoria Exemples
Suites empresarials low-code Microsoft Power Platform (Power Apps, Power Automate, Power Pages, Power BI (Business Intelligence), Dataverse), OutSystems, Mendix, Appian, ServiceNow App Engine, Salesforce Lightning, Oracle APEX (Application Express), SAP Build (abans AppGyver / Build Apps)
No-code / automatització Airtable, Notion, Bubble, Glide, Zapier, Make (Integromat), n8n
BPM (Business Process Management) low-code Camunda, Flowable, Bonita, Bizagi
Codi obert Budibase, Appsmith, ToolJet, NocoDB, Baserow, n8n, Directus

Power Platform és la més present a les administracions que ja tenen Microsoft 365 (→ tema 51): Power Apps (aplicacions), Power Automate (fluxos), Power Pages (portals), Dataverse (dades) i connectors a centenars de serveis.

Algunes d'aquestes plataformes tenen una modalitat específica per generar aplicacions mòbils natives o multiplataforma (Power Apps, OutSystems, Mendix, Appian); el detall del desenvolupament mòbil es tracta a desenvolupament d'aplicacions mòbils. I encara que el RPA comparteix l'enfocament visual amb poc codi, no construeix aplicació nova: automatitza un procés existent imitant una persona sobre la interfície; es tracta a automatització, orquestració i RPA. La distinció paral·lela amb el BPM és la mateixa vista des de l'altre costat: el BPM modela i orquestra el procés de punta a punta, mentre que el low-code construeix la interfície i l'aplicació que hi participen.


4. Integració amb sistemes existents: connectors i API

El que fa possible que una app low-code/no-code no visqui aïllada és que la plataforma exposa i consumeix serveis en comptes d'obligar a reescriure el que ja hi ha:

Per què això importa especialment a una administració: el sistema ja existent —el padró, el gestor d'expedients, l'ERP (Enterprise Resource Planning, planificació de recursos empresarials) municipal— gairebé mai es pot tocar per adaptar-lo a l'eina nova. La característica d'aquestes plataformes que facilita la integració amb altres sistemes és, doncs, que disposen de connectors i interfícies d'aplicació (API) predefinits; no que calgui codificació manual avançada, ni que la integració sigui impossible, ni que s'hagi d'adaptar el programari existent a la plataforma nova.

Com s'integra una aplicació low-code amb els sistemes existentsTres camins directes quan el sistema és accessible des d'internet, i un quart a través de la passarel·la, que inicia ella la connexió cap enfora — de manera que el sistema intern no ha d'obrir cap port entrant.Perímetre de l'organismeERPGestor d'expedientsPadróPassarel·la de dades localsPlataforma low-code / no-codeconnectorAPI RESTwebhook

El diagrama diu el que el tribunal explota: els tres camins directes exigeixen que el sistema existent sigui accessible, i el quart —la passarel·la— és el que serveix quan no ho és, que a l'administració és el cas normal.


5. Beneficis i riscos

Beneficis: rapidesa de lliurament, reducció del retard acumulat de peticions petites, acostament del negoci a la solució, prototipatge ràpid, menor cost per a aplicacions simples, i estandardització visual i d'accessibilitat si la plataforma ho aporta.

Riscos i límits:

  1. Bloqueig de proveïdor (vendor lock-in): el més greu. L'aplicació no és portable: viu dins de la plataforma i sovint no hi ha manera d'exportar-la a codi. La decisió d'assumir aquest risc, o de pagar per evitar-lo, es pren al cas de negoci → tema 3.
  2. Shadow IT (Information Technology): aplicacions crítiques construïdes fora del control de TI, sense còpies de seguretat, sense documentació i amb un únic responsable que un dia se'n va.
  3. Seguretat i protecció de dades: connectors que treuen dades fora del perímetre, permisos mal configurats, tractaments sense base de licitud ni registre d'activitats.
  4. Escalabilitat i rendiment limitats per la plataforma.
  5. Cost per usuari i per llicència, que creix amb l'adopció i pot superar el d'un desenvolupament propi. El salt de preu sol arribar quan cal un connector prèmium o la passarel·la (§4).
  6. Deute tècnic: no desapareix perquè no hi hagi codi; canvia de forma, i és més difícil de veure. La lògica viu dins d'un llenç visual que no es pot llegir en una revisió de codi ni cercar amb una eina de text; no hi ha proves automàtiques ni control de versions comparables als del desenvolupament tradicional; les mateixes regles es dupliquen d'una aplicació a una altra en comptes de compartir-se; i el coneixement de com funciona se'l queda qui la va fer. El resultat típic és un parc d'aplicacions òrfenes: funcionen, ningú sap com, i cap no es pot refactoritzar.
  7. Deute d'integració: cada aplicació nova crea dependències no documentades cap a sistemes que no saben que algú els està consumint.
  8. Manteniment i cicle de vida: canvis de versió de la plataforma —que decideix el fabricant, no l'organisme— que trenquen aplicacions ja en producció.

6. Governança

Perquè el low-code/no-code sumi i no fragmenti, cal un marc explícit:


7. Al sector públic


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 41

DevOps, CI/CD, contenidors i Kubernetes

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

Enunciat oficial. DevOps i integració/desplegament continus (CI/CD). Contenidors Docker i orquestració Kubernetes.


1. DevOps

Definició: DevOps és una filosofia, un conjunt de pràctiques culturals, organitzatives i tècniques que uneixen desenvolupament (Dev) i operacions (Ops). La seva finalitat principal és millorar la col·laboració entre els dos equips; reduir el temps de lliurament, retallar costos i pujar la qualitat en són conseqüències, no l'objectiu en si.

El problema que resol: el «mur de la confusió» entre un equip de desenvolupament incentivat pel canvi i un equip d'operacions incentivat per l'estabilitat.

DevOps no és una eina ni un producte: és una manera de treballar que després es materialitza en un flux automatitzat. Els components que sí que en formen part són el repositori de codi, la integració i les proves automàtiques i el desplegament automatitzat; tot allò que només observa el resultat —un quadre de comandament d'indicadors de producció— és útil, però no és una peça del cicle.

1.1 Els tres camins i CALMS

  1. Flux: optimitzar el flux d'esquerra a dreta, de desenvolupament a producció (lots petits, visualització del treball, eliminació de colls d'ampolla).
  2. Retroalimentació: crear cicles de retroalimentació ràpids de dreta a esquerra (proves automàtiques, monitoratge, alertes). Aquest camí és el que exigeix una plataforma d'observabilitat → tema 23.
  3. Aprenentatge continu i experimentació: cultura d'aprenentatge, post-mortems sense culpables, injecció de fallides.

CALMS (Culture, Automation, Lean, Measurement, Sharing) és la llista de comprovació d'adopció: cultura, automatització, eliminació del malbaratament, mesura i compartició.

1.2 Les mètriques DORA

DORA (DevOps Research and Assessment) és el grup de recerca —avui a Google— que publica cada any l'informe State of DevOps. Les seves quatre mètriques clau:

Mètrica Què mesura Eix
Freqüència de desplegament amb quina freqüència s'allibera a producció velocitat
Temps de lliurament del canvi del commit a producció velocitat
Temps de recuperació (MTTR, Mean Time To Restore) quant es triga a recuperar-se d'un desplegament fallit estabilitat
Taxa de fallides dels canvis percentatge de desplegaments que exigeixen intervenció immediata estabilitat

La troballa central de DORA és que no hi ha compromís entre velocitat i estabilitat: els equips d'alt rendiment són millors en totes quatre.

1.3 DevSecOps, SRE i plataforma


2. Integració contínua

Integració contínua (CI, Continuous Integration): pràctica en què els desenvolupadors integren el seu codi al repositori compartit de manera freqüent —diverses vegades al dia— i cada integració es verifica automàticament amb una compilació i una bateria de proves automatitzades.

Per què és essencial: detecta els errors d'integració i el codi conflictiu en minuts en lloc de setmanes, manté la branca principal sempre desplegable, redueix el cost de la correcció (com més tard es detecta un defecte, més car és), dona retroalimentació ràpida i objectiva, i és la base necessària per a qualsevol grau de lliurament o desplegament continus.

Pràctiques associades: control de versions únic per a tot (codi, configuració, infraestructura), compilacions automatitzades i reproduïbles —mateixa entrada, mateix artefacte—, bateria de proves ràpida, arreglar la compilació trencada com a màxima prioritat i branques de vida curta.


3. Lliurament i desplegament continus

Lliurament continu (Continuous Delivery) Desplegament continu (Continuous Deployment)
Què cada canvi que passa el pipeline queda llest per desplegar-se cada canvi que passa el pipeline es desplega a producció
Pas a producció decisió humana (un botó) automàtic, sense intervenció

Les dues comparteixen la sigla CD, i és la confusió que més es pregunta: el que canvia no és el grau d'automatització de les proves, sinó qui prem el botó final.

3.1 El pipeline

El pipeline és la cadena automatitzada que porta un canvi del repositori a producció. És la tècnica que implementa el lliurament continu: sense ell, «llest per desplegar en qualsevol moment» és una declaració d'intencions.

commit → build → proves unitàries → anàlisi estàtica i de seguretat →
empaquetat (imatge) → desplegament a proves → proves d'integració i
d'extrem a extrem → preproducció → aprovació → producció → verificació

Quines proves corren a quina etapa és matèria del tema de proves de programari (→ tema 49); aquí importa l'ordre: com més barata i ràpida és una prova, més aviat corre.

Qualitat i seguretat al pipeline: SAST (Static Application Security Testing, anàlisi estàtica del codi), SCA (Software Composition Analysis, dependències de tercers), DAST (Dynamic Application Security Testing, sobre l'aplicació en execució), escaneig de les imatges de contenidor, detecció de secrets i signatura d'artefactes → tema 46.

Artefactes i registre: el pipeline construeix una sola vegada l'artefacte —un fitxer empaquetat o una imatge de contenidor—, el desa en un repositori d'artefactes o registre d'imatges versionat i és aquest mateix artefacte el que puja per tots els entorns. Recompilar per a cada entorn trenca la garantia de que allò provat és allò desplegat.

Eines: Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps, Tekton, Argo CD i Flux.

3.2 Estratègies de desplegament


4. Infraestructura com a codi i GitOps

Infraestructura com a codi (IaC, Infrastructure as Code): gestionar servidors, xarxes i serveis mitjançant fitxers versionats en lloc de configuració manual. La forma correcta de gestionar la infraestructura en un projecte àgil és exactament aquesta: automatitzar-la amb una eina, no configurar-la a mà.

Dues famílies que no s'han de confondre:

Distincions que es pregunten:

Infraestructura immutable: els components no es modifiquen un cop desplegats; quan cal un canvi es construeix una instància nova a partir de la imatge actualitzada i se substitueix la vella. Elimina la deriva de configuració (configuration drift), fa els desplegaments reproduïbles i simplifica el retorn. S'oposa a la infraestructura mutable, on s'apedacen els servidors existents.

GitOps: portar el model anterior fins al final. L'estat desitjat viu a Git, que és l'única font de veritat, i un agent reconciliador dins del clúster compara contínuament l'estat real amb el declarat i el corregeix (Argo CD, Flux). Desplegar és fusionar un canvi; retornar és revertir-lo.


5. Contenidors i Docker

Contenidor: unitat d'empaquetat que conté l'aplicació i totes les seves dependències —biblioteques, configuració i entorn d'execució— i que s'executa aïllada compartint el nucli del sistema operatiu amfitrió.

Avantatges, per ordre del que es pregunta:

5.1 Contenidor, màquina virtual i chroot

Màquina virtual Contenidor
Què virtualitza el maquinari el sistema operatiu
Nucli el seu propi, dins d'un sistema operatiu convidat complet el de l'amfitrió, compartit
Sistemes operatius conviu Linux, Windows i macOS alhora sobre el mateix maquinari només càrregues del mateix nucli que l'amfitrió
Mida i arrencada gigabytes, minuts megabytes, segons
Aïllament de seguretat més fort més feble: comparteixen nucli

La conseqüència pràctica: si cal executar sistemes operatius diferents i complets sobre un mateix maquinari —programari que només funciona sobre Windows al costat d'aplicacions Linux—, la resposta és la màquina virtual, no el contenidor. Les dues tecnologies conviuen: el patró habitual és un clúster de contenidors sobre màquines virtuals.

L'antecessor és chroot, que només canvia el directori arrel que veu un procés: no aïlla processos, ni xarxa, ni usuaris, ni limita recursos, i no és una plataforma de desplegament.

Tecnologia de base a Linux: namespaces —aïllament de processos, xarxa, muntatges, usuaris, comunicació entre processos i nom d'amfitrió— i cgroups —límits de CPU (Central Processing Unit), memòria i entrada/sortida—, més capabilities, seccomp i SELinux/AppArmor.

5.2 La imatge en capes i el contenidor efímer

D'aquí surt la regla que més cau: tot el que s'escriu dins d'un contenidor viu en aquesta capa i desapareix quan el contenidor s'elimina. Modificar a mà un fitxer de configuració dins d'un contenidor no toca la imatge: en tornar a instanciar-la reapareix la configuració original i el problema torna. Per això:

5.3 Docker, OCI i els altres motors

5.4 Seguretat dels contenidors

La guia de referència és la NIST SP (Special Publication) 800-190, que ordena els riscos pels components: imatge, registre, orquestrador, contenidor i sistema operatiu amfitrió. Contramesures mínimes:


6. Kubernetes

Definició: plataforma de codi obert per a l'orquestració de contenidors. Automatitza el desplegament, l'escalat, la recuperació i la gestió d'aplicacions contenidoritzades sobre un clúster de màquines. Un contenidor sol no dona alta disponibilitat; l'orquestrador sí: manté el nombre de rèpliques declarat, reprograma els contenidors d'un node caigut i retira del balanceig els que no superen les proves de vida.

6.1 Arquitectura

Els components d'un clúster de KubernetesEl pla de control i dos nodes de treball, amb els components que viuen a cadascun. Tota comunicació passa pel servidor d'API.Pla de controlNode 1Node 2kube-apiservercloud-controller-managerkube-controller-manageretcdkubeletkubeletpodspodskube-proxykube-proxytemps d'execució (containerd)temps d'execució (containerd)kube-scheduler

Pla Component Funció
Control kube-apiserver exposa l'API (Application Programming Interface) del clúster; tota la comunicació hi passa
etcd magatzem clau-valor consistent amb l'estat del clúster
kube-scheduler assigna a cada pod encara sense node el node adequat
kube-controller-manager executa els bucles de control que reconcilien estat real i desitjat
cloud-controller-manager integració opcional amb el proveïdor de núvol
Node kubelet agent que garanteix que els pods del node s'executen
kube-proxy manté les regles de xarxa que implementen els serveis
temps d'execució executa els contenidors, per l'interfície CRI (Container Runtime Interface)

Model declaratiu i reconciliació: es declara l'estat desitjat i els controladors treballen contínuament perquè l'estat real hi coincideixi. És el fonament de GitOps i el que dona l'autoreparació.

6.2 Objectes de càrrega de treball

6.3 Xarxa, configuració i emmagatzematge

6.4 Recursos, escalat, seguretat i ecosistema


7. Al sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 42

Solucions ERP (Enterprise Resource Planning)

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

Enunciat oficial. Solucions ERP (Enterprise Resource Planning).


1. Definició

ERP (Enterprise Resource Planning, planificació de recursos empresarials): sistema d'informació integrat que gestiona de manera unificada els processos i els recursos de tota l'organització —finances, compres, logística, producció, recursos humans, projectes— sobre una base de dades única i compartida, amb processos estandarditzats i informació en temps real.

Aquesta és la definició que cal saber donar. Els tres elements que la caracteritzen:

  1. Integració: els mòduls comparteixen dades; un fet s'introdueix una sola vegada i es propaga a tots els àmbits afectats.
  2. Base de dades única: no hi ha còpies ni sincronitzacions; hi ha una sola versió de la veritat.
  3. Processos estandarditzats basats en bones pràctiques del sector, parametritzables.

2. Característiques

Característica Descripció
Modular s'implanta per mòduls, però tots comparteixen el nucli i les dades
Integrat la informació flueix entre mòduls sense interfícies
Adaptable (customizable) es parametritza per adaptar-lo a l'organització
Universal / transversal cobreix tota l'organització, no una àrea
Base de dades única i centralitzada element definitori
Temps real la informació és immediatament disponible per a tothom
Traçabilitat i auditoria cada document deixa rastre de qui, quan i què
Escalable creix amb l'organització

NO és característica pròpia d'un ERP: «estar format per aplicacions independents amb bases de dades separades», «orientar-se exclusivament a la relació amb el client» (això és el CRM, Customer Relationship Management, gestió de la relació amb el client), «no requerir parametrització» o «ser específic d'una única àrea funcional». Aquestes són les distractores de la pregunta «quina d'aquestes característiques NO seria pròpia d'un sistema ERP».


3. Mòduls habituals

Financers: comptabilitat general, comptes a pagar i a cobrar, immobilitzat, tresoreria, comptabilitat analítica, pressupost. Logístics: compres i aprovisionament, gestió d'inventari i magatzems, vendes i distribució, gestió de la cadena de subministrament. Producció: planificació de materials (MRP, Material Requirements Planning, planificació de necessitats de materials), planificació de la capacitat, ordres de fabricació, qualitat. Recursos humans: administració de personal, nòmina, temps, formació, selecció. Projectes: planificació, imputació de costos, facturació. Manteniment: actius, ordres de treball, preventiu i correctiu. Analítica: informes integrats i connexió amb el BI (Business Intelligence, intel·ligència de negoci).

Al sector públic s'hi afegeixen com a mòduls imprescindibles: gestió pressupostària amb control de disponibilitat de crèdit, gestió de subvencions, gestió tributària i contractació pública. → temes 36 i 37.


4. El mercat

Producte Perfil
SAP (ECC, ERP Central Component / S/4HANA) líder en gran empresa i administració; el que fa servir l'Ajuntament de Barcelona
Oracle (E-Business Suite, Oracle Fusion Cloud ERP, NetSuite) gran i mitjana empresa
Microsoft Dynamics 365 (Finance & Operations, Business Central) mitjana empresa i sector públic
Infor, Sage, Odoo, ERPNext, Dolibarr mitjana i petita empresa; els tres últims, codi obert
Workday orientat a HCM (Human Capital Management, gestió del capital humà) i finances

Tendències: ERP al núvol (SaaS) en substitució del model en local; arquitectura composable (nucli ERP prim + solucions especialitzades integrades per API, Application Programming Interface, interfície de programació d'aplicacions, sense modificar-lo); i incorporació d'IA (Intel·ligència Artificial) per a previsió, detecció d'anomalies i automatització. Cada fabricant té el seu propi principi d'extensibilitat del nucli i la seva pròpia plataforma de núvol per a implementar-lo —el cas de SAP es desenvolupa al tema corresponent.


5. Implantació

Fases: preparació del projecte → anàlisi de processos (blueprint) → realització i parametrització → proves i migració de dades → preparació final i formació → arrencada (go-live) i suport → estabilització i millora contínua.

Metodologies: SAP Activate (successora d'ASAP, Accelerated SAP), Oracle OUM (Oracle Unified Method), Microsoft Sure Step.

Estratègies d'arrencada: big bang (tot alhora, més risc i menys cost de convivència), per fases (per mòdul o per unitat, menys risc però amb interfícies temporals) i pilot (una unitat primer).

Factors crítics d'èxit:

Riscos: sobrecost i retard, excés de desenvolupaments a mida que hipoteca les actualitzacions futures, resistència al canvi, migració de dades deficient, dependència del proveïdor implantador, i pèrdua de coneixement quan marxa el consultor.


6. Model de dades i integració

Cadena de documents d'un procés ERPCada fletxa és una dada que no es torna a teclejar. Aquest és tot l'argument d'un ERP: el document següent neix de l'anterior.ComandaFacturaPagamentRecepcióSol·licitud


7. ERP vs altres sistemes

ERP CRM SCM BI CMS
Focus processos interns i recursos de tota l'organització relació amb el client cadena de subministrament anàlisi i decisió publicació de continguts web
Dades transaccionals internes del client i de la interacció de proveïdors i logística històriques i agregades pàgines, textos i indicadors, sense flux transaccional
Naturalesa operacional (OLTP) operacional operacional analítica (OLAP) publicació, manteniment manual del contingut

OLTP (OnLine Transaction Processing, processament transaccional) prioritza transaccions curtes i freqüents; OLAP (OnLine Analytical Processing, processament analític) prioritza consultes agregades sobre grans volums. SCM (Supply Chain Management, gestió de la cadena de subministrament) coordina proveïdors, transport i inventari fora dels murs de l'organització.

Els ERP moderns incorporen mòduls de CRM i de SCM, però la distinció conceptual es manté i es pregunta. → temes 43 i 35.

Un CMS (Content Management System, sistema de gestió de continguts) no és cap dels tres anteriors: és l'eina per crear i mantenir manualment un lloc web —pàgines, indicadors, notícies— sense necessitat de programar. El seu tret distintiu és que separa el contingut de la presentació (disseny/plantilla): cadascun es pot gestionar de manera independent, de manera que qui edita text no toca el disseny i canviar l'aparença no obliga a retocar els continguts. Quan l'enunciat demana l'eina per a un web informatiu de manteniment manual, la resposta és el CMS, no l'ERP: l'ERP gestiona processos i transaccions internes, no publicació de contingut.


Claus d'examen


Per recordar

Tema 43

Solucions CRM (Customer Relationship Management)

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

Enunciat oficial. Solucions CRM (Customer Relationship Management).


1. Definició

CRM (Customer Relationship Management — gestió de la relació amb el client): estratègia de negoci, suportada per tecnologia, orientada a gestionar i optimitzar totes les relacions i interaccions d'una organització amb els seus clients actuals i potencials, centralitzant la informació del client en un únic repositori per millorar-ne el coneixement, l'atenció, la fidelització i el valor a llarg termini.

Les tres paraules de la sigla, enteses literalment:

Tres nivells del concepte:

Un CRM no és una eina de gestió interna de recursos (això és l'ERP — Enterprise Resource Planning), ni una base de dades de màrqueting per enviar correus, ni un sistema de tiquets tècnics (això és l'ITSM — Information Technology Service Management), encara que en comparteixi funcionalitats.


2. Mòduls habituals d'un CRM

Aquesta és la pregunta més freqüent del tema: quins mòduls són propis d'un CRM.

Mòdul Contingut
SFA (Sales Force Automation, automatització de la força de vendes) gestió de contactes i comptes, oportunitats, embut de vendes (pipeline), previsions, ofertes i comandes, gestió del territori i de les quotes
Automatització del màrqueting segmentació, campanyes multicanal, gestió de contactes potencials (leads) i puntuació (lead scoring), automatització de recorreguts, mesura del retorn
Servei al client i suport (help desk) gestió de casos i incidències, base de coneixement, SLA (Service Level Agreement), centre de contacte i canals (telèfon, correu, xat, xarxes)
Camp / servei tècnic (field service) planificació i despatx de tècnics, ordres de treball, mobilitat
Analítica i informes de client quadres de comandament, segmentació, valor del client, taxa de rotació
Portal d'autoservei l'usuari consulta i gestiona el seu propi cas
PRM (Partner Relationship Management), gestió de socis i canals quan hi ha xarxa de distribuïdors

Escenari típic d'examen: cal una solució per automatitzar el màrqueting i la força de venda, així com gestionar el servei al client i el help desk. La resposta és un CRM, no un ERP ni una eina d'ITSM: aquests quatre àmbits —màrqueting, vendes, servei al client i help desk— són precisament els mòduls nuclears d'un CRM.


3. Tipus de CRM

Tipus Funció
Operacional automatitza els processos de contacte amb el client: vendes, màrqueting i servei. És el que la majoria entén per CRM
Analític explota les dades del client per segmentar, predir i personalitzar; s'alimenta del CRM operacional i s'integra amb el BI (Business Intelligence)
Col·laboratiu comparteix la informació del client entre departaments i amb socis externs, i unifica els canals de comunicació

4. Conceptes

Embut de vendes: del lead al compteMolts contactes potencials entren; pocs acaben essent un compte amb el seu contacte.Contacte potencial (lead)OportunitatCompte i contacte


5. Modalitats de solució

Suite generalista vs. CRM vertical: la majoria de fabricants (Salesforce, Microsoft Dynamics 365, SAP CX, Oracle CX, HubSpot) ofereixen una suite amb mòduls vàlids per a qualsevol sector; un CRM vertical ve preconfigurat per a un sector concret (banca, salut, sector públic) amb els processos i camps ja modelats, a canvi de menys flexibilitat.

SaaS vs. on-premise: la majoria de CRM actuals es contracten com a SaaS —el fabricant allotja i actualitza el sistema, pagament per usuari i mes—; l'alternativa on-premise, instal·lada i mantinguda per l'organització, és minoritària i típica del codi obert (SuiteCRM, Odoo CRM, EspoCRM), que també permet personalitzar-ne el codi.

Tendència: integració creixent amb l'ERP i incorporació d'IA (Intel·ligència Artificial) generativa per resumir converses i suggerir respostes.


6. CRM al sector públic: la relació amb la ciutadania

L'equivalent públic del CRM és el CzRM (Citizen Relationship Management). Les diferències són substancials:

CRM privat CRM públic (CzRM)
Objectiu ingressos, fidelització, valor del client qualitat del servei, equitat, accessibilitat i confiança institucional
Relació voluntària i competitiva sovint obligatòria i sense alternativa
Segmentació per rendibilitat mai per rendibilitat: seria discriminatòria. Per necessitat i vulnerabilitat
Dades consentiment i interès legítim missió d'interès públic o obligació legal (RGPD, art. 6); l'interès legítim no és aplicable a les autoritats públiques en l'exercici de les seves funcions
Personalització perfilat comercial limitada per l'RGPD, art. 22 i pel principi d'igualtat

Aplicacions municipals: sistema d'atenció ciutadana multicanal (OAC (Oficina d'Atenció Ciutadana), 010, seu electrònica, xarxes), gestió d'incidències i suggeriments de la via pública, seguiment d'expedients des de la perspectiva del ciutadà, carpeta ciutadana i comunicació personalitzada de tràmits i venciments.

Cauteles imprescindibles:


7. Integració ERP–CRM


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 44

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.

Sigla Què és Abast
DMS (Document Management System) gestió del cicle de vida dels documents: emmagatzematge, versionat, metadades, cerca, control d'accés i flux d'aprovació documents, generalment estructurats i corporatius
ECM (Enterprise Content Management) estratègia i conjunt de tecnologies per capturar, gestionar, emmagatzemar, preservar i lliurar TOT el contingut de l'organització —documents, correus, imatges, vídeo, web, registres, contingut col·laboratiu— al llarg de tot el seu cicle de vida i per a tots els processos de negoci tot el contingut, estructurat i no estructurat
RMS (Records Management System) gestió de registres i expedients amb valor probatori, retenció i disposició evidències
Content Services l'evolució de l'ECM segons Gartner: serveis de contingut modulars i integrats per API en lloc d'un repositori monolític

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.

El DMS és un component de l'ECML'ECM engloba tot el contingut de l'organització; el DMS, al centre, és només la gestió de documents.ECMtot el contingutDMSdocuments

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

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ó

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.

Fase Qui el custodia Quan
Arxiu de gestió (o d'oficina) la unitat que tramita procediment obert o molt recent, consulta freqüent
Arxiu central l'arxiu de l'organisme procediment finalitzat, consulta ocasional
Arxiu intermedi un arxiu comú a diversos organismes vigència administrativa esgotada, pendent del destí final
Arxiu històric l'arxiu històric conservació permanent i accés públic

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:

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:

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:

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:

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:

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

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


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 45

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:

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.

Vectorial Ràster
Representació punts, línies i polígons definits per coordenades matriu de cel·les (píxels), cadascuna amb un valor
Precisió alta; independent de l'escala limitada per la mida de la cel·la (resolució)
Adequat per a objectes discrets amb límits definits: parcel·les, carrers, edificis, xarxes de serveis fenòmens continus: altitud, temperatura, pendent, contaminació, imatges de satèl·lit i ortofotos
Volum menor per a objectes discrets gran; creix amb el quadrat de la resolució
Topologia es pot modelar (adjacència, connectivitat) no la té de manera nativa
Anàlisi consultes topològiques i de xarxa àlgebra de mapes i superposicions cel·la a cel·la

Una mateixa parcel·la: vectorial contra ràster La mateixa parcel·la representada de dues maneres: a l'esquerra com a polígon de vèrtexs (vectorial), amb els límits nets i independents de l'escala; a la dreta com a quadrícula de píxels acolorits (ràster), on la forma queda limitada per la mida de la cel·la. Vectorial Ràster

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.


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:

Estàndard Funció
WMS (Web Map Service) serveix imatges de mapa renderitzades (PNG (Portable Network Graphics), JPEG (Joint Photographic Experts Group)). L'usuari rep un dibuix, no les dades
WMTS (Web Map Tile Service) mapes en tessel·les precalculades; molt més ràpid per a visors web
WFS (Web Feature Service) serveix les dades vectorials amb la seva geometria i atributs, i permet consultar-les i (amb WFS-T) editar-les
WCS (Web Coverage Service) serveix dades ràster originals (cobertures), no imatges renderitzades
CSW (Catalog Service for the Web) catàleg de metadades: permet descobrir quins conjunts i serveis existeixen
WPS (Web Processing Service) processament geoespacial remot
SLD (Styled Layer Descriptor) descripció d'estils de simbolització
GML, GeoPackage, SensorThings API, OGC API (la família moderna, basada en REST (Representational State Transfer) i OpenAPI: Features, Tiles, Maps, Records, Processes)

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:

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:

Programari:


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:

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


Per recordar

Fonts d'aquest tema

Tema 46

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:

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:

Assegurament (SQA) Control (SQC)
Objecte els processos els productes i entregables
Naturalesa preventiva detectiva
Pregunta ho estem fent de la manera correcta? el resultat compleix els requisits?
Activitats definició d'estàndards, auditories de procés, revisió de metodologia, formació proves, inspeccions, revisions de codi, mesures

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:

Característica Subcaracterístiques
Adequació funcional completesa, correcció, pertinència
Eficiència d'acompliment comportament temporal, ús de recursos, capacitat
Compatibilitat coexistència, interoperabilitat
Usabilitat reconeixibilitat, aprenentatge, operabilitat, protecció davant errors, estètica, accessibilitat
Fiabilitat maduresa, disponibilitat, tolerància a fallides, capacitat de recuperació
Seguretat confidencialitat, integritat, no-repudi, responsabilitat, autenticitat
Mantenibilitat modularitat, reusabilitat, analitzabilitat, modificabilitat, capacitat de ser provat
Portabilitat adaptabilitat, capacitat d'instal·lació, capacitat de ser reemplaçat

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ò:

Canvi 2011 2023
Nova — Safety (seguretat física: que el producte no causi dany a persones, béns o entorn)
Renom Usabilitat Interaction Capability
Renom Portabilitat Flexibility (hi absorbeix l'escalabilitat)
Renom Seguretat Security (es manté, però ara conviu amb Safety)

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:

Tipus Què fa Es dispara per
Correctiva esmena defectes ja detectats i reportats una errada operacional evidenciada
Preventiva detecta i corregeix disfuncions latents abans que esdevinguin errades anàlisi proactiva, sense incident previ
Adaptativa adapta el programari a un entorn que canvia (nova normativa, nou sistema operatiu) un canvi extern al programari
Perfectiva / evolutiva afegeix noves funcionalitats o millora el rendiment i la mantenibilitat una necessitat nova dels usuaris

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—:

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

Nivell Nom Descripció
1 Inicial processos imprevisibles, reactius, dependents de les persones. Tota organització hi és per defecte
2 Gestionat els processos es planifiquen i s'executen segons una política, per projecte; encara reactiu
3 Definit processos estandarditzats a nivell d'organització, adaptats per cada projecte a partir del conjunt estàndard; proactiu
4 Gestionat quantitativament processos mesurats i controlats estadísticament, amb objectius quantitatius
5 En optimització millora contínua basada en l'anàlisi quantitativa i la innovació

Els cinc nivells de maduresa de CMMICinc nivells acumulatius: cap nivell s'assoleix sense el de sota.5. Enoptimització4. Gestionat quantitativament3. Definit2. Gestionat1. Inicial

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:

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ó


8. Al sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 47

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:


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:

  1. 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.
  2. Telemetria: instrumentar l'aplicació des del disseny, no afegir-la a posteriori.
  3. 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

Patró Funció
Tallacircuits (circuit breaker) atura les crides a un servei que falla per evitar l'efecte dominó, i reintenta passat un temps
Reintent amb retrocés exponencial i jitter reintenta amb esperes creixents i aleatoritzades
Mampara (bulkhead) aïlla recursos perquè la fallida d'un component no consumeixi tots els recursos
Limitació de ritme (rate limiting) i contrapressió protegeix davant sobrecàrrega
Degradació elegant el servei continua amb funcionalitat reduïda en lloc de caure
Sidecar funcionalitat transversal en un contenidor adjunt
Cau distribuïda Redis, Memcached
Cua de missatges i esdeveniments desacoblament temporal: Kafka, RabbitMQ, SQS (Simple Queue Service)
Prova de salut (health check) liveness i readiness per a l'orquestrador
Escalat automàtic horitzontal segons mètriques
Enginyeria del caos injectar fallides deliberadament per validar la resiliència

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:


6. Seguretat: els 4C

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

Model de seguretat dels 4CQuatre capes concèntriques: el núvol conté el clúster, que conté el contenidor, que conté el codi.CloudClústerContenidorCodi

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


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 48

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 SOA Microserveis
Granularitat una aplicació serveis grans i empresarials serveis petits
Comunicació crides internes sovint ESB amb lògica al bus API lleugeres, bus «tonto»
Dades base de dades única sovint compartida una per servei
Desplegament tot alhora per servei, amb coordinació independent
Governança centralitzada centralitzada descentralitzada
Protocol típic — SOAP/WS-* REST, gRPC, missatgeria

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:

REST SOAP
Naturalesa estil arquitectònic protocol
Format JSON (o el que sigui) XML obligatori
Contracte OpenAPI (opcional) WSDL (obligatori)
Estat sense estat, orientat a recursos identificats per URI (Uniform Resource Identifier, identificador uniforme de recurs) i manipulats amb els mètodes HTTP orientat a operacions
Pes lleuger pesant
Seguretat HTTPS, OAuth 2.0 WS-Security a nivell de missatge
Transaccions no natives WS-AtomicTransaction

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.

API Gateway vs. API ManagerEl gateway està al camí de cada petició; el manager no: governa el cicle de vida de les API, fora del camí de la petició.Microservei AMicroservei BMicroservei CClientsAPI Gatewayexecució en temps realAPI Managergovern del cicle de vida:catàleg, claus, quotes, analítica

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).

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ó

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.

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

Coreografia Orquestració
Qui decideix el pas següent cada servei, reaccionant a un esdeveniment un coordinador central que dona ordres
Acoblament baix: cap peça coneix el flux sencer l'orquestrador coneix el flux sencer
Risc el flux no està escrit enlloc: costa de seguir i de depurar l'orquestrador acumula lògica de negoci i és un punt únic

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:

Patró Què fa, i què el distingeix
Temps d'espera (timeout) posa un límit a l'espera d'una resposta. Sense ell cap dels altres funciona: un fil bloquejat per sempre no es pot reintentar ni comptar com a fallada
Reintent amb retrocés exponencial i jitter torna a provar una fallada transitòria, amb esperes creixents i aleatoritzades perquè tots els clients no reintentin alhora. Exigeix que l'operació sigui idempotent, i reintentar sense límit amplifica la sobrecàrrega
Tallacircuits (circuit breaker) deixa de trucar el servei que ja se sap que falla, en lloc d'esperar el temps d'espera cada vegada: tancat (passa tot), obert (rebutja a l'instant) i mig obert (deixa passar unes poques crides de prova). No és una variant del reintent: el reintent insisteix, el tallacircuits desisteix
Mampara (bulkhead) aïlla recursos —una reserva pròpia de fils o de connexions per a cada dependència— perquè la dependència que falla no es begui tot el que el procés té i deixi sense servei les altres
Degradació elegant i resposta de reserva (fallback) continuar amb funcionalitat reduïda —dada de cau, valor per defecte, missatge honest— en lloc de caure
Limitació de ritme i contrapressió protegir-se de qui truca massa, no de qui respon malament, que és el cas dels quatre primers

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


5. Costos

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

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


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 49

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:

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

Nivell Objecte Qui Correspondència al model en V
Unitàries una unitat aïllada (funció, classe, mòdul) desenvolupadors disseny detallat
Integració la interacció entre components o sistemes desenvolupadors i QA disseny arquitectònic
Sistema el sistema complet contra els requisits QA especificació de requisits
Acceptació el sistema des de la perspectiva de l'usuari o el client usuari, client requisits de negoci

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:

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?.


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.

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».

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.

Piràmide de provesAl cim, poques proves d'extrem a extrem, lentes i cares; al mig, proves d'integració i de servei; a la base, moltes proves unitàries, ràpides i barates.E2E, extrem a extrempoques, lentes i caresIntegració i serveiUnitàriesmoltes, 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.

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:

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


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 50

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:

Component Funció
Dispatcher reparteix les peticions entre els processos de treball
Processos de treball (work processes) executen les peticions. Tipus: DIA (diàleg), BTC (Background, fons/batch), UPD i UPD2 (Update i Update 2, actualització), ENQ (Enqueue, bloquejos), SPO (Spool, impressió)
Servidor de missatges (message server) comunica les instàncies i fa el balanceig de càrrega
Servidor de cues (enqueue server) gestiona els bloquejos lògics de l'aplicació
Gateway comunicació RFC amb altres sistemes
ICM (Internet Communication Manager) connexió amb internet: HTTP, HTTPS (HyperText Transfer Protocol Secure) i SMTP (Simple Mail Transfer Protocol)
Instància central (ASCS, ABAP SAP Central Services) i instàncies de diàleg arquitectura escalable i d'alta disponibilitat

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ó.

Paisatge de sistemes i ordre de transportEl canvi es desenvolupa a DEV, viatja registrat en una ordre de transport fins a QAS i d'allà a PRD. Mai es toca producció directament, i és l'ordre de transport la que ho fa possible: el que arriba a PRD és el que es va provar.Cada instància: presentació →aplicació → base de dadesDEVdesenvolupamentPRDproduccióQASprovesordre de transportordre de transport

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:

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:

Canvi Descripció
Universal Journal (taula ACDOCA, Universal Journal Entry Line Items) una única taula de partides que unifica FI (Financial Accounting), CO (Controlling), AA (Asset Accounting), CO-PA (Profitability Analysis) i ML (Material Ledger). Desapareixen les taules redundants i les reconciliacions entre comptabilitat externa i analítica → tema 36
Eliminació de taules agregades i d'índexs les taules de totals, d'índex i d'històric ja no calen: HANA agrega sobre les partides en temps real
Business Partner model únic de client, proveïdor i interlocutor, obligatori (substitueix les transaccions separades)
SAP Fiori interfície d'usuari basada en el web, orientada a rols i a tasques, responsiva i executable a qualsevol dispositiu. Substitueix el SAP GUI clàssic
Analítica incrustada informes en temps real dins de l'aplicació operativa, sense necessitat d'un data warehouse per a l'anàlisi bàsica
CDS (Core Data Services) Views model de dades declaratiu que empeny la lògica a la base de dades i alimenta Fiori i l'analítica
Extensibilitat in-app i side-by-side el principi de clean core: no modificar el nucli, estendre'l amb serveis a la SAP BTP (Business Technology Platform)

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:

Tipus Per a què serveix
Diàleg persona que entra per la interfície; se li comproven la caducitat i la contrasenya inicial, i se la pot canviar ell mateix
Sistema processos interns i treballs de fons; no pot entrar per diàleg i la contrasenya no caduca
Comunicació crides entre sistemes (RFC); tampoc pot entrar per diàleg
Servei accés anònim compartit a un servei web; no se li comproven caducitat ni contrasenya inicial
Referència no s'hi entra mai: existeix només per prestar autoritzacions addicionals a altres usuaris

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:

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


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 51

Eines de treball col·laboratiu en entorn Microsoft 365

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

Enunciat oficial. Eines de treball col·laboratiu en entorn Microsoft 365.


1. Què és una eina de treball col·laboratiu

Programari que permet que diverses persones treballin sobre un mateix objecte compartint informació, en comptes d'intercanviar-se còpies. El nom clàssic és groupware. Fa tres coses, i convé distingir-les perquè les eines concretes solen cobrir-ne només una part:

Un wiki és el cas net de la tercera: un espai web que qualsevol persona autoritzada pot editar, pensat per compartir informació i coneixement de manera acumulativa. No és un canal de difusió: publicar anuncis, difondre notícies o recollir queixes són usos unidireccionals, amb un emissor i molts receptors.

Què no és col·laboratiu. El criteri és si més d'una persona intervé sobre el mateix objecte de treball. La gestió financera, la comptabilitat o la nòmina són aplicacions de gestió: tenen molts usuaris, però cadascú hi fa la seva feina sobre registres propis. Tenir usuaris no és col·laborar.

1.1 La matriu de temps i lloc

La classificació habitual creua quan (a la vegada o no) i on (junts o separats):

Mateix temps Temps diferent
Mateix lloc reunió amb pissarra digital, sistemes de votació plafó de l'equip, sala de projecte
Llocs diferents xat, videoconferència, telefonia, coedició en directe correu, wiki, gestió documental, gestió de tasques

La fila de baix és la que interessa a una administració amb teletreball i seus repartides, i és exactament el que cobreix una suite com Microsoft 365.


2. Microsoft 365: què és i com es llicencia

Conjunt de serveis de productivitat al núvol que integra les aplicacions ofimàtiques, el correu, la col·laboració, l'emmagatzematge i la identitat sota un sol compte corporatiu. Es deia Office 365 fins al 2020; el nom nou inclou, en algunes edicions, també el sistema operatiu i la gestió del dispositiu.

Tres coses distintes que sovint es confonen:

Edició empresarial Serveis al núvol Instal·lació local
E1 sí no: només web i mòbil
E3 sí sí
E5 sí, més seguretat i compliment avançats sí

El dret d'instal·lació de les edicions E3 i E5 és per usuari, no per equip: la mateixa persona pot instal·lar la suite en 5 ordinadors, 5 tauletes i 5 telèfons. És la resposta que s'ha preguntat dues vegades i el parany és sempre el mateix: fer creure que cap llicència permet instal·lar en local, o que totes ho permeten.


3. L'ofimàtica i els seus formats

3.1 Les tres aplicacions bàsiques

Aplicació Què és A què serveix en una administració
Processador de textos edició de documents de text amb format, estils, taules i control de canvis informes, propostes de resolució, actes, notificacions, plecs
Full de càlcul graella de cel·les organitzades en files i columnes on es poden escriure fórmules que es recalculen soles pressupostos, seguiment d'execució, inventaris, indicadors, explotació de dades
Presentació seqüència de diapositives amb text, imatge i esquemes per exposar davant d'un públic comitès, formació interna, rendició de comptes, jornades

El full de càlcul és el que més es pregunta perquè és el que més es confon. La seva unitat és la cel·la, identificada per columna i fila; una fórmula referencia altres cel·les i es recalcula automàticament quan canvien; sobre les dades s'hi munten gràfics, taules dinàmiques i filtres. A la pràctica és l'eina d'anàlisi ràpid d'una unitat administrativa —i, per això mateix, una font habitual de dades corporatives fora de control.

Completen la suite el client de correu i agenda, el quadern de notes, la base de dades d'escriptori i l'edició de formularis.

El correu i l'agenda es couen contra un servidor Exchange (en local o Exchange Online al núvol), que és una peça independent de la resta de la suite: per això migrar o actualitzar la versió del servidor de correu només obliga a actualitzar el client local d'Outlook a una versió compatible, mentre que la resta de mòduls (full de càlcul, processador de textos), que no dialoguen amb aquest servidor, no es veuen afectats.

3.2 Els formats de fitxer

Un format obert és aquell l'especificació del qual és pública, completa i implementable per qualsevol sense permís ni pagament de drets. És el que permet que un document es pugui obrir d'aquí a vint anys i amb un altre programa; el contrari és el format propietari, controlat per un fabricant.

Les dues famílies ofimàtiques actuals són totes dues normalitzades, i aquesta és la confusió típica: obert no vol dir lliure.

Família Qui la manté Text Full de càlcul Presentació
OOXML (Office Open XML) promoguda per Microsoft, norma ISO .docx .xlsx .pptx
ODF (Open Document Format) OASIS (Organization for the Advancement of Structured Information Standards), norma ISO .odt .ods .odp

Les dues són contenidors comprimits amb fitxers XML (eXtensible Markup Language) a dins, i per això la darrera lletra x de .docx distingeix el format modern del binari antic de la suite de Microsoft: .doc, .xls i .ppt. ODF cobreix a més el dibuix vectorial (.odg) i la base de dades (.odb).

Compatibilitat entre les dues famílies: per a fitxers de processador de text, full de càlcul i presentacions hi ha un alt grau de compatibilitat entre OOXML i ODF, amb certes restriccions, especialment amb les macros. Aquesta compatibilitat no s'estén a les bases de dades: LibreBase (.odb) i Microsoft Access no comparteixen format ni són interoperables.

Altres formats que hi conviuen:

Què admet l'administració espanyola. El Catàleg d'estàndards, que és una NTI (Norma Tècnica d'Interoperabilitat) de l'ENI (Esquema Nacional d'Interoperabilitat), fixa quins formats es poden fer servir: hi són admesos ODF, OOXML en la seva variant estricta, i PDF i PDF/A. La conseqüència pràctica és que un document publicat o intercanviat per l'administració ha d'anar en un format d'aquesta llista, i que triar la suite d'un fabricant no eximeix de desar en format admès.

3.3 Vincular i incrustar dades entre documents

Quan cal portar dades d'un full de càlcul dins d'un document de text hi ha tres maneres, i només una manté les dades vives:

El mecanisme es diu OLE (Object Linking and Embedding) i s'arriba amb l'ordre d'enganxament especial, triant l'opció de vincle en comptes de l'enganxament normal. Es pot mostrar el resultat com a taula, com a imatge o com a icona; això és només l'aspecte i no té res a veure amb que el vincle funcioni. El preu del vincle és la fragilitat: si el fitxer origen es mou o es reanomena, el vincle es trenca.


4. Microsoft Teams i les comunicacions unificades

4.1 Equips, canals i el que es crea sol

Teams és l'aplicació central de col·laboració: xat persistent, reunions, telefonia, fitxers i integració d'aplicacions, organitzada en equips i, dins de cada equip, canals per temes.

Quan es crea un equip nou, es provisionen automàticament un conjunt de recursos, i saber-ho és el que explica on són després les coses:

Recursos que es creen en crear un equip de TeamsRes d'això es crea a mà. El grup de Microsoft 365 és qui governa la pertinença, i tota la resta penja d'ell — cosa que explica per què esborrar el grup s'ho endú tot.Bústia compartida i calendariEquip de TeamsGrup de Microsoft 365pertinença i permisosQuadern de notesLloc de SharePointels fitxers dels canalsPla de tasques

El punt que més es pregunta és el lloc de SharePoint: els fitxers compartits en un canal no viuen a Teams, viuen a SharePoint, en una biblioteca de documents amb una carpeta per canal. Teams és la interfície; el magatzem és un altre. D'això depenen els permisos, les còpies i la retenció.

Tipus de canal Qui hi entra Lloc de SharePoint
Estàndard tots els membres de l'equip una carpeta del lloc de l'equip
Privat un subconjunt dels membres lloc propi
Compartit persones d'altres equips o organitzacions, sense afegir-les a l'equip lloc propi

Ús organitzatiu: un equip per unitat estable o per projecte de llarga durada, canals per als temes de dins, convenció de noms i política de creació d'equips limitada per evitar la proliferació. Quan cal muntar un espai de coordinació entre departaments, l'acció correcta és crear un equip amb els membres implicats —i segmentar amb canals privats o compartits si cal—, no repartir una carpeta ni obrir una llista de distribució de correu.

4.2 Comunicacions unificades

Teams és, en realitat, una plataforma de comunicacions unificades: la integració en un sol entorn de la veu, el vídeo, la missatgeria, la presència i el correu, sobre la xarxa de dades.

Reunions: convocatòria des del calendari, sala d'espera, sales de treball, gravació i transcripció, subtítols en directe, compartició de pantalla i control remot.


5. On viu el contingut

Els fitxers de la suite es desen en dos llocs, i la distinció és de propietat, no de tecnologia:

Regla pràctica: si el document interessa a més d'una persona, va a SharePoint o a Teams; si és teu i encara està en curs, a OneDrive. L'estructura interna —biblioteques, metadades, versionat, permisos, sincronització— es desenvolupa al tema 53.

Coautoria (co-authoring): és la funcionalitat que permet que diverses persones editin el mateix document alhora, veient els canvis dels altres a mesura que es produeixen i amb indicadors de presència que mostren on treballa cadascú, sense bloquejar el fitxer ni fer-ne còpies. Exigeix tres condicions: que el fitxer sigui a OneDrive o SharePoint —no en una unitat de xarxa local—, en format modern (.docx, .xlsx, .pptx) i obert amb una versió compatible de la suite o amb la versió web. Hi van associats el desat automàtic i l'historial de versions.

Correu i agenda: el servei corporatiu es consulta amb el client d'escriptori o amb el client web. No són equivalents: hi ha diferències tant de funcionalitat com d'interfície, i el client d'escriptori manté funcions —treball sense connexió, complements, gestió avançada de regles— que la versió web no cobreix del tot. Configurar un protocol de descàrrega de correu antic no iguala les funcionalitats: les redueix.


6. Gestió de tasques i llistes

Per a projectes amb dependències, camí crític i línies base, l'eina no és Planner sinó una de planificació de projectes → tema 9.


7. Alternatives lliures i estàndards oberts

La suite d'un fabricant no és l'única opció, i la Mesura de digitalització oberta municipal estableix la preferència pel programari lliure i els estàndards oberts. Les alternatives amb recorregut real:

Eina Què cobreix
LibreOffice suite ofimàtica d'escriptori completa; el seu format natiu és ODF
OnlyOffice suite amb coedició web i molt bona compatibilitat amb els formats .docx, .xlsx i .pptx
Collabora Online motor de coedició al navegador derivat de LibreOffice, per integrar en una plataforma pròpia
Nextcloud plataforma d'emmagatzematge, compartició i col·laboració autoallotjada; s'hi integren Collabora o OnlyOffice per a la coedició

Per a la resta de peces hi ha equivalents: Jitsi per a la videoconferència i Matrix amb el client Element per al xat federat. La diferència de fons no és de funcions una a una, sinó de control: amb una plataforma autoallotjada les dades i la configuració són de l'organització.

Lliure no vol dir gratuït ni sense esforç: hi ha costos de desplegament, suport, formació i migració de plantilles i macros. I format obert no vol dir programari lliure: la suite de Microsoft desa en un format normalitzat i LibreOffice obre els formats de Microsoft. La decisió tècnica que de debò tanca portes no és quin programa es fa servir, sinó en quin format es desa.


8. Què ha de mirar una administració


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 52

Gestió centralitzada de dispositius (endpoints)

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

Enunciat oficial. Gestió centralizada de dispositius (endpoints) dins d'una organització.


1. Conceptes i sigles

Sigla Significat Abast
MDM Mobile Device Management gestió del dispositiu mòbil sencer: inscripció, configuració, polítiques, esborrat
MAM Mobile Application Management gestió de les aplicacions i de les dades corporatives dins d'elles, sense controlar el dispositiu. Adequat per a BYOD
MCM Mobile Content Management gestió del contingut i dels documents corporatius al dispositiu
MIM Mobile Information Management el mateix vist des de la informació, no del fitxer: quines dades poden viure al dispositiu i quines no
EMM Enterprise Mobility Management MDM + MAM + MCM + identitat
UEM Unified Endpoint Management gestió unificada de tots els dispositius —PC (Personal Computer), portàtils, mòbils, tauletes, IoT— des d'una única consola i un únic conjunt de polítiques. És l'estat de l'art
ECM Endpoint Configuration Manager gestor de configuració d'estacions i servidors (l'antic SCCM, System Center Configuration Manager) → tema 54
EDR / XDR detecció i resposta a l'endpoint / estesa seguretat, no gestió

MDM és, en la definició que es pregunta, el programari que permet inscriure i administrar de manera centralitzada els dispositius d'una organització: instal·lar i desinstal·lar aplicacions, aplicar configuracions i polítiques de seguretat, localitzar i rastrejar telèfons mòbils, sincronitzar arxius, reportar l'inventari i l'estat, i esborrar-ne el contingut de manera remota.

Arquitectura: client-servidor. El servidor MDM aplica remotament, per xarxa sense fils, les configuracions, les aplicacions i les polítiques; els dispositius actuen com a clients. El servidor no manté una connexió permanent: aprofita els serveis de notificació push del fabricant —APNs (Apple Push Notification service), WNS (Windows Notification Service)— per despertar el client, que llavors inicia la sessió amb el servidor per rebre els canvis. Si el push falla —dispositiu apagat o sense connexió—, el client recorre a una sincronització periòdica de reserva.


2. Models de propietat del dispositiu

Model Significat Propietat Ús personal
COBO (Corporate Owned, Business Only) dispositiu de l'empresa només per a ús professional empresa prohibit
COPE (Corporate Owned, Personally Enabled) el dispositiu és propietat de l'empresa, però es permet un ús personal limitat empresa permès i limitat
CYOD (Choose Your Own Device) l'empleat tria d'un catàleg aprovat; el dispositiu és de l'empresa empresa segons política
BYOD (Bring Your Own Device) l'empleat fa servir el seu propi dispositiu per a la feina empleat complet

El model en què l'empresa és propietària del dispositiu però permet un ús limitat per a activitats personals és el COPE. És la resposta literal.

Implicacions de cada model:


3. Domini vs núvol: dues vies per gestionar el lloc de treball

El UEM (Unified Endpoint Management), amb el MDM de base (§1 i §4), és la via moderna, basada en el núvol. Però una part del parc —sobretot estacions de treball i portàtils Windows— es continua gestionant de manera centralitzada des d'un domini Active Directory local: és una via diferent per arribar al mateix objectiu, i totes dues cauen a l'examen.

Dues vies fins a l'endpoint gestionatEl domini i el núvol hi arriben per camins diferents i acaben al mateix lloc: un equip amb polítiques aplicades i accés condicionat al seu compliment.Domini (on-premise)Endpoint gestionatpolítiques aplicades iaccés condicionalUnió al domini i GPOdirectives de grupDispositiu nouNúvol (MDM/UEM)Inscripció i perfils per push

3.1 La via tradicional: domini Active Directory

3.2 Escriptoris virtuals (VDI)

VDI (Virtual Desktop Infrastructure): en lloc de gestionar el dispositiu físic, es centralitza l'escriptori mateix. Un host físic proporciona els recursos a diverses màquines virtuals (servidors virtuals, pròpiament); dins de cadascuna s'executa una instància de la màquina «client», que és el que s'anomena escriptori virtual. La diferència es confon sovint: la màquina virtual és el servidor que l'allotja, l'escriptori virtual és la instància client que l'usuari fa servir.

El rol de passarel·la (gateway) és el punt d'enllaç entre els clients que accedeixen des d'Internet i els servidors interns que presten el servei d'escriptori virtual: permet l'accés extern sense obrir directament la xarxa interna ni necessitar una VPN (Virtual Private Network) pròpia.

3.3 Suport remot i diagnòstic


4. Funcionalitats d'una plataforma UEM/MDM

Inscripció (enrollment):

Configuració i polítiques:

Aplicacions:

Contingut i dades: contenidorització, prevenció de pèrdua de dades entre aplicacions, xifratge del contenidor.

Operació: inventari de maquinari i programari, estat de compliment, informes, localització (amb els límits legals), accions remotes — bloqueig, restabliment de codi, esborrat total (wipe) i esborrat selectiu (selective wipe) només de les dades corporatives.

Cicle de vida: provisió → operació → renovació → retirada amb esborrat segur certificat i esborrat de la vinculació (activation lock).

El suport del sistema operatiu el fixa el fabricant i mai és il·limitat. Cada edició —Home, Pro, Enterprise— i cada versió té la seva data de fi de servei publicada: el suport estès de Windows 7 es va acabar el 2020, i les edicions LTSC (Long-Term Servicing Channel) de Windows 10 tenen un cicle propi, molt més llarg que el de les edicions estàndard, que el 2025 ja l'havien esgotat. Per això no és cert ni que el suport sigui complet per a tot, ni il·limitat en el temps, ni exclusiu de l'última versió. Un sistema sense suport és un sistema sense pedaços de seguretat: planificar la renovació del parc és, abans que res, planificar contra aquestes dates.


5. Plataformes del mercat

Microsoft Intune (part de Microsoft Endpoint Manager, integrat amb Entra ID i amb el Configuration Manager en model co-management), VMware Workspace ONE (abans AirWatch), Jamf Pro (referència per a l'ecosistema Apple), MobileIron / Ivanti Neurons, SOTI MobiControl, IBM MaaS360, ManageEngine Endpoint Central, Citrix Endpoint Management, Google Endpoint Management, i de codi obert Headwind MDM, Flyve MDM i Fleet o Puppet/Ansible per a estacions.

Pregunta habitual: quina d'aquestes plataformes NO és un gestor de configuració d'endpoints? Les distractores solen ser eines d'altres categories: Nagios o Zabbix (monitoratge), Jira (gestió de projectes), Splunk (registres), Docker (contenidors), Veeam (còpies), Wireshark (anàlisi de xarxa) o SAP Business One (ERP, Enterprise Resource Planning). IBM Endpoint Manager (l'antic BigFix), en canvi, sí que n'és un.

Solucions de MDM pròpiament dites, quan es demana un exemple: Intune, Jamf, Workspace ONE, MobileIron/Ivanti, SOTI, MaaS360.


6. Seguretat de l'endpoint

La gestió i la seguretat són capes diferents que s'han de combinar:


7. Al sector públic


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 53

Treball documental: SharePoint i OneDrive

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

Enunciat oficial. Treball documental: SharePoint, OneDrive.


1. Les dues peces

SharePoint Online és la plataforma de col·laboració i de gestió de contingut d'equip de Microsoft 365: organitza els documents en llocs, i dins de cada lloc en biblioteques i llistes amb metadades, versions i permisos propis. OneDrive for Business és la biblioteca de documents personal de cada usuari, construïda sobre la mateixa tecnologia i amb les mateixes funcions. La diferència entre les dues no és tècnica sinó de propietat: qui mana sobre el contingut i què passa amb els documents quan la persona marxa.

SharePoint Online OneDrive for Business
Naturalesa plataforma de col·laboració i gestió de contingut d'equip biblioteca personal de cada usuari, sobre la mateixa tecnologia
Propietat l'equip o el lloc; sobreviu a les persones la persona; si marxa, cal transferir-ne la propietat
Estructura llocs → biblioteques i llistes → carpetes i fitxers, amb metadades biblioteca única
Ús adequat documents compartits, intranet, processos documentals, contingut de Teams esborranys, treball en curs, documents propis
Compartició permisos per lloc, biblioteca, carpeta o element enllaços puntuals

Regla pràctica: si el document interessa a més d'una persona o té valor per a la unitat, va a SharePoint; si és teu i encara és en curs, a OneDrive.

Relació amb Teams: cada equip té un lloc de SharePoint associat on s'emmagatzemen tots els fitxers dels canals; cada canal hi té una carpeta; els canals privats i compartits tenen lloc propi. Teams és la interfície; SharePoint és el magatzem → tema 51.


2. Estructura de SharePoint

El contingut de SharePoint viu dins d'un lloc, que és la unitat de propietat, de permisos i de navegació: cada lloc té els seus membres, la seva pàgina d'inici i els seus contenidors de contingut. Els llocs no s'anideguen els uns dins dels altres com les carpetes d'un disc; s'agrupen amb un hub.

Tipus de lloc:

Elements:

Element Funció
Biblioteca de documents contenidor de fitxers amb metadades, versions i permisos
Llista contenidor de dades estructurades en columnes tipificades, sense fitxer al darrere (sol·licituds, inventari, registre)
Columnes i tipus de contingut metadades que descriuen el document i n'habiliten la classificació i la cerca
Vistes filtres, ordenacions i agrupacions predefinits sobre la mateixa biblioteca
Pàgines contingut web del lloc

Biblioteca o llista és una distinció que cau: la biblioteca guarda documents i cada element és un fitxer; la llista guarda registres i cada element és una fila de columnes, encara que hi pugui adjuntar fitxers. Un tipus de contingut és la plantilla que lliga un conjunt de metadades —i, si escau, una plantilla de document i un flux— a una categoria: «contracte», «acta», «informe tècnic».

Jerarquia de contenció de SharePointCaixes anidades: un lloc conté biblioteques i llistes, que contenen carpetes i fitxers. Les metadades apareixen com una etiqueta lateral sobre el fitxer, no com un nivell més de la jerarquia. El traç que hi porta és discontinu i sense punta: aparella les dues coses sense dir que una porti a l'altra, que és el que una punta hauria afirmat.Biblioteca / llistaLlocCarpeta i fitxerMetadades(etiqueta, no un nivell més)

Metadades o carpetes: SharePoint permet classificar amb metadades en lloc de carpetes imbricades. És millor pràctica: una jerarquia de carpetes obliga a triar un únic criteri d'organització i genera rutes llarguíssimes; les metadades permeten múltiples vistes del mateix conjunt i una cerca molt superior. La botiga de termes (term store) permet mantenir vocabularis controlats corporatius i compartir-los entre llocs.


3. Funcionalitats de treball documental


4. Permisos i governança

Nivells de permís predefinits: control total, disseny, edició, col·laboració, lectura i accés limitat. Els dos extrems —control total i accés limitat— no es poden modificar; els altres sí, i se'n poden crear de nous. L'accés limitat no s'assigna a mà: és el que el sistema posa sol perquè algú pugui obrir un document concret sense veure la resta del lloc.

Grups: els grups de SharePoint del lloc (propietaris, membres, visitants) i, preferiblement, grups de seguretat d'Entra ID per gestionar-los, perquè així la pertinença es manté en un únic lloc → tema 64.

Herència de permisos: els permisos flueixen del lloc a les biblioteques, les carpetes i els elements. Trencar l'herència en molts punts és l'error de disseny més freqüent: fa la gestió ingovernable i genera fuites silencioses, perquè cap canvi posterior al nivell superior arriba als àmbits trencats. La bona pràctica és gestionar els permisos al nivell més alt possible i usar enllaços de compartició per als casos puntuals.

Etiquetes de sensibilitat i de retenció de Microsoft Purview: xifratge i marcatge que viatgen amb el document encara que surti de la biblioteca, i polítiques de conservació i eliminació. La DLP (Data Loss Prevention, prevenció de pèrdua de dades) detecta contingut sensible —DNI (Document Nacional d'Identitat), targetes de crèdit, dades de salut— i bloqueja o avisa en compartir-lo. El govern de la suite sencera, al tema 51; aquí, què li passa a un fitxer d'una biblioteca.

Cicle de vida: polítiques de caducitat de grups, arxivat de llocs inactius i propietaris responsables de revisar-ne el contingut i els accessos.


5. OneDrive: espai personal, sincronització i compartició

OneDrive for Business és una biblioteca de documents com les de SharePoint, amb un únic propietari. Per això hereta el versionat, la paperera de dos nivells, la coautoria i la cerca de l'apartat 3, i el que li és propi és com arriba al lloc de treball i com se'n surt el document.

Sincronització amb l'escriptori. El client de sincronització de OneDrive porta al disc local tant el OneDrive personal com les biblioteques de SharePoint i de Teams que la persona esculli:

Compartició amb enllaços. Un document no es comparteix donant permisos un a un, sinó generant un enllaç, i el tipus d'enllaç és el que decideix qui hi entra:

Tipus d'enllaç A qui deixa entrar
Qualsevol persona amb l'enllaç tothom qui el rebi, sense autenticar-se; per això és el que no es pot auditar i el que primer es desactiva en una administració
Persones de l'organització qualsevol persona de l'organització que rebi l'enllaç, encara que li'l reenviïn
Persones amb accés existent no canvia cap permís: només és una drecera per a qui ja hi entrava
Persones concretes només les persones nomenades en compartir; si es reenvia, no funciona

Cada enllaç porta associats el permís de visualització o edició i, opcionalment, caducitat i contrasenya.

Compartició externa: cal decidir-la conscientment, per organització i per lloc, i és la via de fuita més habitual. Mesures: enllaços per defecte limitats a l'organització, caducitat obligatòria per als convidats, revisions d'accés periòdiques i informes de compartició.


6. Fluxos de treball i integració amb Microsoft 365

Un flux de treball documental automatitza el que abans es feia per correu: quan un document entra en una biblioteca o canvia una columna, el sistema avisa, demana una aprovació, mou el fitxer o li canvia l'estat.


7. Escenaris de treball documental col·laboratiu

Escenari Com es resol
Diverses persones redacten alhora un informe biblioteca d'un lloc d'equip i coautoria, amb desat automàtic i historial de versions
Un document de format delicat que no admet edició simultània check-out mentre s'edita i check-in amb comentari en acabar
Un esborrany que encara no és de ningú més OneDrive, i es mou a la biblioteca de l'equip quan deixa de ser un esborrany
Un plec que ha de passar revisió i aprovació formals versions principals i secundàries més aprovació de contingut, i un flux de Power Automate si hi ha diverses persones aprovadores
Un document que s'ha de treballar amb una empresa externa compartició externa autoritzada i enllaç de persones concretes amb caducitat
Cal treballar en un desplaçament sense connexió client de sincronització, fitxer marcat per conservar-lo sempre al dispositiu
S'ha esborrat un document per error paperera de l'usuari i, si ja no hi és, la de la col·lecció de llocs, dins dels 93 dies
Cal saber qui va canviar què historial de versions de l'element i registre d'auditoria de Purview

8. El límit: SharePoint i OneDrive no són l'arxiu electrònic

Aquest és el punt de risc real per a una administració i el que cal tenir clar:

I la peça de fons: la Mesura de digitalització oberta estableix la preferència pel programari lliure i els estàndards oberts, i qui contracta la suite ha de preveure al plec l'exportabilitat i la reversibilitat i signar el contracte d'encarregat del tractament de l'RGPD (Reglament General de Protecció de Dades) — art. 28. Les alternatives lliures de plataforma col·laborativa —Nextcloud amb Collabora Online o OnlyOffice— es comparen al tema 51; els gestors documentals lliures —Alfresco, OpenKM—, al tema 44.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 54

Desplegament d'aplicacions. SCCM

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

Enunciat oficial. Desplegament d'aplicacions. SCCM.


1. Què és SCCM

System Center Configuration Manager (SCCM), avui Microsoft Configuration Manager (part de Microsoft Intune / Endpoint Manager), és l'eina de gestió centralitzada de servidors i estacions de treball en un entorn Windows: permet la implementació, l'administració i la supervisió centralitzades de recursos en una xarxa basada en Windows.

Aquesta última formulació és la que apareix literalment a l'examen quan es demana quina eina d'administració de sistemes permet la implementació, administració i supervisió centralitzada de recursos en una xarxa basada en Windows: la resposta és SCCM / Microsoft Endpoint Configuration Manager. I quan es parla de l'eina de gestió centralitzada de servidors i estacions de treball desplegada sobre servidors Windows, també.

Funcions principals:

Funció Descripció
Inventari de maquinari i de programari, i mesura d'ús (software metering)
Distribució de programari desplegament d'aplicacions i de paquets, silenciós o amb interacció, obligatori o disponible
Gestió de pedaços Software Updates, integrat amb WSUS: aprovació, distribució i compliment
Desplegament de sistemes operatius (OSD, Operating System Deployment) imatges, seqüències de tasques, migració d'estat d'usuari (USMT, User State Migration Tool), arrencada per xarxa (PXE, Preboot eXecution Environment)
Configuració desitjada Compliance Settings: línies base de configuració i remediació automàtica
Punt de servei d'aplicacions Software Center i catàleg d'aplicacions per a l'autoservei de l'usuari
Protecció integració amb Microsoft Defender
Informes amb SQL Server Reporting Services (SQL: Structured Query Language)
Co-management gestió compartida amb Intune per a càrregues de treball concretes

2. Arquitectura

Component Funció
Site Server i jerarquia de llocs CAS (lloc administratiu central), lloc primari i llocs secundaris
Base de dades SQL Server, que emmagatzema tota la informació del lloc
Punts de sistema de lloc (site system roles) Management Point (comunicació amb els clients), Distribution Point (distribució del contingut, amb suport de BranchCache i Peer Cache), Software Update Point (WSUS), Reporting Services Point, State Migration Point, Cloud Management Gateway (gestió de clients fora de la xarxa corporativa)
Client de Configuration Manager agent instal·lat a cada equip
Col·leccions (collections) agrupacions estàtiques o dinàmiques (per consulta) de dispositius o d'usuaris, sobre les quals s'apliquen els desplegaments
Límits i grups de límits (boundaries) definició de la topologia de xarxa per assignar clients i punts de distribució

Jerarquia de llocs de SCCMEl CAS, lloc administratiu central, al capdamunt; en depenen els llocs primaris, i de cada lloc primari en poden dependre llocs secundaris.CASlloc administratiu centralLloc primariLloc primariLloc secundari (opcional)

Requisit: SCCM depèn de l'Active Directory i, per a moltes funcions, de PKI (Public Key Infrastructure) i de WSUS.


3. El procés de desplegament d'aplicacions

  1. Empaquetat: preparació de l'aplicació en un format desatès (MSI, MSIX, App-V, executable amb paràmetres silenciosos, script). Cal definir el mètode de detecció que determina si l'aplicació ja hi és.
  2. Creació de l'aplicació a SCCM amb els seus tipus de desplegament (un per plataforma o condició), requisits (sistema operatiu, memòria, arquitectura) i dependències.
  3. Distribució del contingut als Distribution Points.
  4. Creació del desplegament sobre una col·lecció, amb el propòsit Obligatori (Required) —s'instal·la sola— o Disponible (Available) —apareix al Software Center perquè l'usuari la instal·li.
  5. Planificació: finestra de manteniment, data límit, comportament de reinici i notificacions a l'usuari.
  6. Desplegament per fases (phased deployment): pilot → col·lectiu ampli → tota l'organització, amb criteris d'èxit entre fases.
  7. Monitoratge: informes de compliment, èxits, errors i codis de retorn.
  8. Remediació dels equips fallits i desinstal·lació quan cal.

Abast del desplegament: les aplicacions es poden assignar tant a col·leccions d'usuaris com de dispositius —construïdes amb llistes directes, grups de seguretat o UO (Unitat Organitzativa)— i els requisits poden filtrar, per exemple, per versió de sistema operatiu o per altres aplicacions necessàries. Els clients reben el desplegament tant si estan connectats físicament a la xarxa corporativa com si hi arriben per VPN (Virtual Private Network) o des d'un escriptori virtual (VDI, Virtual Desktop Infrastructure), sempre que puguin contactar el Management Point.

Bones pràctiques: sempre un pilot abans del desplegament general; finestres de manteniment definides; mètodes de detecció fiables; desinstal·lació provada; i documentació del paquet.

Les dues estratègies que es combinen són l'empenta (push) —l'organització decideix, el desplegament és obligatori i s'instal·la sol dins de la finestra— i l'estirada (pull) o autoservei —el desplegament es publica com a disponible i és la persona usuària qui l'instal·la des del Software Center quan li convé—. La primera serveix per al programari obligatori i els pedaços; la segona, per al catàleg opcional, i redueix les peticions al centre d'atenció.

3.1 Aplicació, paquet i programa

SCCM té dos objectes diferents per distribuir programari, i confondre'ls és l'error habitual:

Sistema de gestió de paquets és el nom genèric del conjunt d'eines que cobreix tot el cicle d'un paquet —crear-lo, actualitzar-lo, configurar-lo i eliminar-lo— i que n'automatitza la distribució. És el mateix concepte que a Linux implementen apt, dnf/yum o zypper, i a Windows el paquet de SCCM o les eines de línia d'ordres Winget i Chocolatey. No s'ha de confondre amb la infraestructura que mou el contingut per la xarxa —els Distribution Points i la seva replicació—, que resol un problema diferent: que el fitxer arribi a prop del client.

3.2 Revisió, substitució i retirada

Una aplicació desplegada al parc no s'esborra i es torna a crear cada vegada que canvia: SCCM li dona un cicle de vida propi.

3.3 Automatització amb scripts

Moltes actuacions sobre les estacions —empaquetat, configuració prèvia o posterior— es couen amb la línia d'ordres de Windows dins de scripts:


4. Desplegament del sistema operatiu

El desplegament del sistema operatiu, o OSD (Operating System Deployment), és la funció que instal·la el sistema operatiu en un equip des de zero i el deixa llest per treballar: aplica una imatge del sistema, hi injecta els controladors, uneix l'equip al domini, hi instal·la les aplicacions del lloc de treball i, si l'equip en substitueix un altre, hi trasllada el perfil de la persona usuària. No és una instal·lació manual repetida cent vegades, sinó una seqüència de tasques que l'orquestra sola.


5. Gestió de pedaços


6. Alternatives i evolució

Àmbit Eines
Windows modern Microsoft Intune amb Autopilot, Windows Update for Business, Winget
Multiplataforma Ivanti Endpoint Manager, ManageEngine Endpoint Central, Tanium, BigFix, Workspace ONE
Apple Jamf Pro, Munki, Apple Business Manager
Linux i servidors Ansible, Puppet, Chef, Salt, Foreman/Katello, Spacewalk/Uyuni, Landscape
Empaquetat i distribució lliure Chocolatey, Winget, Homebrew, Flatpak/Snap, PDQ Deploy
Virtualització d'aplicacions App-V, MSIX App Attach, Citrix, VDI i AVD (Azure Virtual Desktop)

L'alternativa que no necessita cap eina: una GPO (Group Policy Object) pot definir una directiva que forci la instal·lació d'un paquet .msi a les estacions afectades. És el mecanisme de distribució de programari natiu d'Active Directory —ve amb el domini, no s'hi afegeix res—, i per això és la comparació obligada amb SCCM: menys versatilitat i menys control (ni col·leccions, ni finestres de manteniment, ni mètode de detecció, ni informes d'èxit del §3).

Tendència: del model imatge + domini + SCCM a la xarxa corporativa al model núvol + Autopilot + Intune + identitat, on el dispositiu no necessita mai estar a la xarxa interna. El co-management és el pont entre tots dos.


7. Inventari de maquinari i de programari

L'inventari és la funció que fa que SCCM sàpiga què hi ha realment al parc: quins equips, amb quin maquinari, amb quin programari instal·lat i amb quina versió. No és un annex de la distribució de programari, és el seu fonament — sense inventari no es poden construir col·leccions dinàmiques, ni filtrar requisits, ni mesurar el compliment d'un desplegament.

Descobriment i inventari no són el mateix, i el tribunal ho pot separar:

Inventari de maquinari. El client llegeix WMI (Windows Management Instrumentation, la implementació de Microsoft de l'estàndard WBEM, Web-Based Enterprise Management) i el registre de Windows. Les classes que es recullen es trien a la configuració del client (client settings) i s'amplien amb el fitxer Configuration.mof, que a més registra els proveïdors que llegeixen la informació. Malgrat el nom, recull molt més que maquinari: qualsevol dada present a WMI o al registre —programari instal·lat, versió del sistema, estat del xifratge de disc—, i és la font de les col·leccions dinàmiques i dels requisits dels tipus de desplegament.

Inventari de programari. Recorre el sistema de fitxers buscant fitxers d'un tipus determinat i, si es demana, en recull una còpia al servidor de lloc (file collection). Ve activat per defecte, però sense recollir cap fitxer: recollir-los és una decisió deliberada, perquè pot arrossegar dades personals i inflar la base de dades.

Mesura d'ús (software metering). Registra si un programa instal·lat s'executa de veritat i quantes vegades. És el que distingeix «instal·lat» de «utilitzat» i, per tant, la base per recuperar llicències que ningú fa servir.

Asset Intelligence afegeix un catàleg que normalitza els títols de programari —el mateix producte no s'ha de comptar tres vegades perquè s'anomeni de tres maneres— i hi penja la gestió de llicències.

L'inventari té dues cares que sovint es pregunten juntes: és l'instrument del compliment del llicenciament i de l'inventari d'actius que exigeix l'ENS, i alhora és una recollida massiva de dades sobre els equips de persones identificables, de manera que se li aplica el principi de minimització — es recull el que fa falta per gestionar, no tot el que WMI podria donar.


8. Al sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 55

Centres de Processament de Dades (CPD)

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

Enunciat oficial. Centres de Processament de Dades (CPD): components, infraestructures de suport, seguretat física i ambiental, nivells de disponibilitat i redundància.


1. Components

Un CPD (Centre de Processament de Dades) és la instal·lació que allotja els sistemes d'informació crítics amb les infraestructures de suport que en garanteixen el funcionament continu.

Subsistema Elements
Obra civil i sala tècnica fals sòl tècnic (aire i cablatge), fals sostre, tancaments RF (resistència al foc), càrregues del forjat
Racks i cablatge armaris de 19", passadissos de disseny fred i calent, cablatge estructurat de coure i fibra òptica
Alimentació elèctrica escomeses, quadres, SAI (Sistema d'Alimentació Ininterrompuda) / UPS (Uninterruptible Power Supply), grups electrògens, PDU (Power Distribution Unit, regleta del rack) i commutadors de transferència STS (Static Transfer Switch) / ATS (Automatic Transfer Switch)
Climatització CRAC (Computer Room Air Conditioner) / CRAH (Computer Room Air Handler), refredadores, confinament de passadissos, control d'humitat
Detecció i extinció d'incendis VESDA (Very Early Smoke Detection Apparatus, detecció per aspiració), extinció per gas net: FM-200, NOVEC 1230, o gasos IG (Inert Gas) com l'IG-541 (Inergen)
Seguretat física control d'accés, CCTV (Closed-Circuit Television), mantrap, vigilància
Xarxa core, distribució, accés, tallafocs, acomesa de diversos operadors
Còmput i emmagatzematge servidors, balancejadors de càrrega, cabines SAN (Storage Area Network) / NAS (Network Attached Storage), còpies de seguretat
Monitoratge i gestió BMS (Building Management System) / DCIM (Data Center Infrastructure Management), sensors ambientals, detecció de líquids

Una granja de servidors (server farm): màquines que donen un sol servei; el balancejador de càrrega hi reparteix les peticions.

1.1 Cablatge estructurat

És un dels elements de la xarxa amb més vida útil —15 a 20 anys, molt més que els equips actius (5 a 8 anys)—: es dimensiona a llarg termini, perquè canviar-lo implica obra. Normes: ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 11801, EN 50173, TIA (Telecommunications Industry Association) -568 (cablatge genèric) i TIA-942 (específica de CPD, aprovada també per l'ANSI (American National Standards Institute)).

1.2 Espais funcionals TIA-942 i sala d'entrada de proveïdors

La TIA-942 fixa els nivells TIER (§5) i divideix el CPD en espais funcionals, del cablatge troncal (backbone) cap avall:

El cablatge troncal uneix ER, MDA i HDA; l'horitzontal, HDA i EDA.

1.3 Virtualització

1.4 L'armari de 19 polzades i la unitat de rack

L'armari o bastidor (rack) de 19 polzades és el moble normalitzat on es munta l'equipament actiu del CPD. Les 19" (482,6 mm) són la separació entre els muntants de fixació, no l'amplada de l'armari (600 o 800 mm); les fixen l'EIA (Electronic Industries Alliance) -310 i la IEC 60297.


2. Infraestructura elèctrica

Eficiència energètica:


3. Climatització i condicions ambientals


4. Seguretat física i ambiental

Protecció activa i passiva (la distinció que es pregunta):

Extinció: no s'usa aigua sobre els equips, sinó gasos nets —FM-200, NOVEC 1230, IG-541 (Inergen), CO2 (perillós per a les persones)—, que actuen sense residus ni conductivitat.

Control d'accés: múltiples factors (targeta + PIN (Personal Identification Number) o biometria), mantrap o esclusa, registre d'accessos, acompanyament de visites i CCTV amb retenció conforme al RGPD.

Fins on arriba aquest apartat. Aquí només la seguretat física i ambiental; les defenses lògiques (tallafocs perimetrals, segmentació, detecció d'intrusions, Zero Trust) són del → tema 70.

Marc normatiu: l'ENS dedica la família mp.if (protecció de les instal·lacions) a aquests controls: àrees separades amb control d'accés, identificació de les persones, condicionament dels locals, protecció davant incendis i inundacions, registre d'equipament i instal·lacions alternatives. La ISO/IEC 27001 hi dedica els controls de seguretat física i de l'entorn.


5. Nivells de disponibilitat: la classificació TIER

L'Uptime Institute i la norma ANSI/TIA-942 estableixen un conjunt de categories en funció del nivell de disponibilitat requerit i del nivell de redundància de la infraestructura de suport.

TIER Redundància Vies de distribució Manteniment sense parar Tolerància a fallides Disponibilitat Indisponibilitat anual
I — Bàsic N 1 no no 99,671 % ~28,8 h
II — Components redundants N+1 1 no no 99,741 % ~22 h
III — Mantenible simultàniament N+1 2 (una activa i una passiva) SÍ: qualsevol component es pot retirar per manteniment sense aturar el servei no 99,982 % ~1,6 h (≈1 h 36 min)
IV — Tolerant a fallides 2N (fins a 2(N+1)) 2 actives simultàniament sí SÍ: suporta una fallida imprevista de qualsevol component sense impacte 99,995 % ~26 min

La diferència principal entre un TIER III i un TIER IV: el TIER III és «mantenible simultàniament» —manteniment planificat sense aturar el servei, però una fallida imprevista pot causar una parada—; el TIER IV és «tolerant a fallides»: 2N amb dues vies actives i suporta una fallida imprevista sense impacte.

Altres classificacions: EN 50600 amb les seves classes de disponibilitat 1 a 4, i la ISO/IEC 22237.


6. Estratègies d'allotjament

Model Descripció
CPD propi (on-premise) l'organització és propietària de la instal·lació i l'opera
Housing / col·locació (colocation) l'organització hi porta els seus equips i lloga espai, energia i connectivitat a un proveïdor
Hosting el proveïdor aporta també el maquinari
Núvol model de servei IaaS/PaaS/SaaS → tema 59
Híbrid combinació; el model habitual a les administracions
Edge petits nodes de còmput a prop de l'origen de les dades, per reduir latència. Tendència emergent per als ajuntaments (mobilitat, videoanàlisi, IoT urbà)

On es col·loca un servidor no ho decideix l'espai disponible, sinó l'enllaç. Un equip que ha de rebre o servir molt de trànsit va on hi ha l'amplada de banda: dins del CPD, penjat de la troncal. Posar-lo en una sala remota unida al CPD per un enllaç d'accés modest el deixa limitat per aquest enllaç, i cap canvi de tecnologia local —una xarxa sense fil, un commutador propi al costat, un encaminador mòbil— eixampla un coll d'ampolla que és aigües amunt. El raonament invers justifica l'edge: el trànsit no ha de viatjar perquè es processa a l'origen.

Distribució geogràfica: dos CPD principals prou lluny per no compartir riscos (elèctrics, inundació, sísmics) però prou prop per a la replicació síncrona —fins a 50–100 km—, amb una tercera ubicació o núvol per a les còpies. Units per enllaços redundants, formen la base de l'alta disponibilitat i del DRP (Disaster Recovery Plan, pla de recuperació davant desastres): l'estratègia i el conjunt de procediments per recuperar els sistemes informàtics i les dades perdudes després d'un incident greu, amb un RTO (Recovery Time Objective, temps objectiu de recuperació) i un RPO (Recovery Point Objective, punt objectiu de recuperació) → tema 58.

Tendències: SDDC (Software-Defined Data Center, CPD definit per programari) —virtualització de còmput, emmagatzematge i xarxa (SDN, Software-Defined Networking) gestionats per programari, amb orquestració que n'automatitza el desplegament, la configuració i el control sense intervenció manual—, HCI (Hyper-Converged Infrastructure, hiperconvergència), CPD modulars i prefabricats, refrigeració líquida per a la IA i CPD sostenibles.

SDDC: la virtualització de l'emmagatzematge dins d'un SDDC la dona l'SDS (Software-Defined Storage), que desacobla el programari d'emmagatzematge del maquinari i agrega els discs locals dels servidors en una plataforma comuna i escalable. No s'ha de confondre amb l'hipervisor (§1.3), que virtualitza el còmput, ni amb la NIC (Network Interface Card, targeta de xarxa). → tema 56.


7. Gestió i operació


8. Arquitectura de xarxa del CPD

L'arquitectura clàssica de tres capes —core, agregació i accés— està pensada per a trànsit nord-sud, el que entra i surt del CPD. Amb la virtualització, la major part del trànsit passa a ser est-oest: entre servidors del mateix CPD. Aquí les tres capes fan mal: dos servidors de racks diferents han de pujar fins a l'agregació o el core i baixar.

SPINE&LEAF resol això amb dues capes i una regla: cada leaf es connecta a tots els spine, i cap leaf a un altre leaf ni cap spine a un altre spine.

Arquitectura spine-leafCada leaf es connecta a tots els spine i cap leaf es connecta amb un altre leaf: així qualsevol servidor és a la mateixa distància de qualsevol altre.Leaf 1Leaf 2Leaf 3Servidors del rack AServidors del rack BServidors del rack CSpine 1Spine 2cada leaf, a tots els spine

8.1 Segmentació per capes (frontend / aplicació / backend)

Els servidors d'una aplicació web se separen en tres capes lògiques: frontend (servidors web, exposats a l'exterior), aplicació (lògica de negoci) i backend (bases de dades). Cada capa és un segment de xarxa aïllat per tallafocs, perquè un atac al frontend no arribi a les dades.

Els commutadors de nivell 2 —que commuten per adreça MAC (Media Access Control)— hi són presents a totes les capes: cada segment necessita la seva connectivitat local d'accés.

8.2 Connectors, per no confondre'ls

El cablatge de coure acaba en RJ45 (Registered Jack 45, formalment 8P8C), el connector del parell trenat, apantallat —STP (Shielded Twisted Pair, per parell) o FTP (Foiled Twisted Pair, global)— o no: UTP (Unshielded Twisted Pair). La fibra fa servir connectors no intercanviables:

Connector Fibra Com es reconeix
RJ45 (8P8C) cap: és coure, parell trenat cos rectangular de plàstic amb pestanya i vuit contactes
LC (Lucent Connector) monomode i multimode petit, format dúplex, pestanya tipus RJ45 en miniatura
SC (Subscriber Connector) monomode i multimode quadrat, de pressió, més gran que l'LC
ST (Straight Tip) sobretot multimode rodó, amb baioneta que gira per fixar-se
MPO (Multi-fiber Push-On) / MTP (Multi-fiber Termination Push-on, variant enregistrada de l'MPO) troncals d'alta densitat rectangular ample, agrupa 12 o 24 fibres

El color del latiguillo no és normatiu: per convenció, groc sol ser monomode i taronja o aigua multimode.

8.3 Certificació del cablatge i reflectometria (OTDR)

Abans de posar en servei una fibra cal certificar-la: la pèrdua total no pot superar el pressupost òptic de TIA-568 i ISO/IEC 11801.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 56

Sistemes SAN i nivells de RAID

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

Enunciat oficial. Sistemes SAN i Nivells de RAID (Redundant Array of Independent Disks).


1. Arquitectures d'emmagatzematge

Les tres arquitectures clàssiques es distingeixen per on són els discos i, sobretot, per què veu el servidor: blocs —un disc que ell mateix particiona i formata— o fitxers que ja li serveix un altre.

DAS NAS SAN
Connexió directa al servidor per xarxa IP xarxa dedicada d'emmagatzematge
Accés bloc fitxer bloc
Protocol SAS, SATA, NVMe NFS, SMB/CIFS Fibre Channel, iSCSI, FCoE, NVMe-oF
Compartició no sí, a nivell de fitxer sí, a nivell de LUN
Ús típic servidor aïllat fitxers d'usuari, còpies bases de dades, virtualització, càrregues crítiques

SAS (Serial Attached SCSI) i SATA (Serial Advanced Technology Attachment) són les interfícies físiques dels discos de la fila «Protocol»; CIFS (Common Internet File System) és el dialecte amb què Microsoft va implementar originalment el protocol SMB per compartir fitxers en xarxa.

La frontera que es pregunta és aquesta: la NAS dona fitxers per la xarxa d'ús general, i la SAN dona blocs per una xarxa pròpia. Una base de dades, el disc d'una màquina virtual o un clúster que necessita disc compartit demanen blocs; un directori compartit entre persones, fitxers.

Emmagatzematge d'objectes (Amazon S3, Ceph RGW (Rados Gateway), MinIO): la tercera manera d'accedir a les dades, al costat del bloc i del fitxer. No lliura ni discos ni carpetes, sinó objectes —la dada amb les seves metadades— identificats per una clau i accessibles per API (Application Programming Interface) HTTP (Hypertext Transfer Protocol), sense jerarquia de directoris. Escala de manera massiva i barata, i admet bloqueig d'objectes (object lock, WORM (Write Once Read Many)), que és el que el fa idoni per a còpies i arxiu → tema 57. També és el substrat dels data lakes → tema 32.


2. La SAN

Segons la SNIA (Storage Networking Industry Association), l'objectiu d'una SAN (Storage Area Network) és transferir dades entre sistemes informàtics i elements d'emmagatzematge: és una xarxa dedicada d'alt rendiment que proporciona accés a nivell de bloc a dispositius d'emmagatzematge consolidats des de múltiples servidors, de manera que la capacitat aparegui davant el sistema operatiu com si fos local. Dit d'una altra manera, desacobla l'emmagatzematge dels servidors per gestionar-lo de manera centralitzada, compartida i escalable.

Aquesta formulació de la SNIA —«transferir dades entre sistemes informàtics i elements d'emmagatzematge»— és la que apareix literalment als exàmens, i és la resposta correcta quan la pregunta demana l'objectiu d'una SAN.

Beneficis: consolidació i millor aprofitament de la capacitat, alta disponibilitat (multicamí, redundància), rendiment, escalabilitat independent de còmput i emmagatzematge, funcions avançades de la cabina (instantànies, replicació, clonatge, thin provisioning) i l'habilitació de la virtualització i dels clústers, que necessiten disc compartit.

2.1 Components

2.2 Protocols

Tots els protocols de SAN fan la mateixa feina —portar ordres SCSI (Small Computer System Interface), o NVMe (Non-Volatile Memory Express), entre un iniciador (el servidor) i un objectiu (target, la cabina)— i es diferencien pel transport que utilitzen, i per tant pel preu i per la latència.

2.3 Conceptes de gestió

2.4 Virtualització de l'emmagatzematge

La virtualització de l'emmagatzematge abstrau els discos i les cabines físiques de la seva ubicació i el seu maquinari concret, i els presenta com un pool lògic de capacitat del qual es reparteixen volums. Serveix per agregar cabines de fabricants diferents en un sol conjunt, moure dades entre elles sense aturar el servei i aplicar en un sol lloc funcions com el thin provisioning o les instantànies. S'implementa en tres llocs: al servidor (gestor de volums o hipervisor), a la pròpia cabina, o en un dispositiu intermedi a la xarxa, davant de les cabines existents.

SDS (Software-Defined Storage, emmagatzematge definit per programari), segons la SNIA: separa el programari de gestió de l'emmagatzematge del maquinari físic subjacent, oferint una gestió flexible, escalable i automatitzada dels recursos de dades, amb independència del maquinari on s'executen, encara que sigui heterogeni o de diversos fabricants. És la resposta quan un enunciat descriu exactament això, i no s'ha de confondre amb una NAS (que és maquinari concret d'accés a fitxer), amb l'SDN (Software-Defined Networking, que fa el mateix però per a xarxes) ni amb serveis de xarxa com una VPC (Virtual Private Cloud) o una CDN (Content Delivery Network).


3. RAID

RAID (Redundant Array of Independent Disks): tècnica que combina diversos discs físics en una unitat lògica per obtenir redundància, rendiment o capacitat. Treballa sempre a nivell de bloc —no de fitxer ni d'objecte—, i per això és transparent per al sistema de fitxers que hi ha a sobre.

El mètode d'emmagatzematge de les dades en RAID es basa en tres tècniques que es combinen:

Com es reparteix una banda entre quatre discosUna fila per nivell de RAID i una columna per disc. Cada cel·la diu què hi guarda aquell disc d'una mateixa banda: un bloc de dades, una còpia o la paritat. RAID 1 només ocupa dos discos.Disc 1Disc 2Disc 3Disc 4RAID 0RAID 1RAID 5RAID 6ABCDAAABCPABPQDadesCòpiaParitat PParitat Q

3.1 Nivells

Nivell Tècnica Discs mín. Capacitat útil Tolerància Comentari
RAID 0 striping sense redundància 2 100 % cap la seva característica principal és repartir les dades entre tots els discs per maximitzar el rendiment i la capacitat, sense cap redundància: si falla un disc, es perden totes les dades. No és RAID en el sentit de «redundant», i és inadequat per a sistemes crítics
RAID 1 mirroring 2 50 % 1 disc (o n−1) crea una còpia exacta del conjunt de dades; lectura ràpida, escriptura com un disc; senzill i molt fiable
RAID 5 striping + paritat distribuïda 3 n−1 discs 1 disc també anomenat striping with parity: les dades i la paritat es reparteixen entre tots els discs, sense disc de paritat dedicat. Bon compromís capacitat/protecció. Penalització d'escriptura (llegir-modificar-escriure) i reconstrucció lenta i arriscada amb discs grans
RAID 6 striping + doble paritat distribuïda 4 n−2 discs 2 discs simultanis la diferència principal amb el RAID 5 és que manté dues paritats independents i, per tant, suporta la fallida de dos discs alhora, a canvi d'una capacitat útil menor i d'una penalització d'escriptura superior. És el recomanat amb discs de gran capacitat, on la reconstrucció triga dies i el risc d'una segona fallida és real
RAID 10 (1+0) mirall de conjunts segmentats 4 50 % 1 per mirall millor rendiment i reconstrucció; l'opció per a bases de dades exigents
RAID 50 / 60 striping de conjunts RAID 5 / 6 6 / 8 — segons grup grans volums
RAID 2, 3, 4 entrellaçat a nivell de bit amb codi de Hamming (2), de byte (3) o de bloc (4), amb disc de control dedicat — — 1 en desús; són els nivells de la paritat dedicada i del repartiment per bit, els dos distractors clàssics del RAID 5 i del RAID 1

Fórmules útils: capacitat útil de RAID 5 = (n−1) × mida del disc més petit; de RAID 6 = (n−2) × mida; de RAID 1 i 10 = 50 %.

3.2 Consideracions

3.3 El principi que no s'ha d'oblidar

El RAID no és una còpia de seguretat. Protegeix davant la fallida física d'un disc, i no davant l'esborrat accidental, la corrupció lògica, el ransomware, l'error humà ni la pèrdua del centre de processament de dades. La raó és que la redundància és simultània: el bloc equivocat s'escriu al mateix instant a tots els discs del conjunt, mirall inclòs. Contra tot això només protegeix una còpia de seguretat separada, verificada i immutable → tema 57.


4. Tolerància a fallades en l'emmagatzematge

El RAID només cobreix una de les maneres en què es perd la disponibilitat de les dades: que mori un disc. Un sistema d'emmagatzematge tolerant a fallades ho ha de ser a tots els nivells del camí entre l'aplicació i el plat del disc, perquè qualsevol component que estigui sol és un punt únic de fallida.

Què pot fallar Com es tolera
Un disc RAID i disc de reserva (hot spare)
Una controladora de la cabina dues controladores actives-actives, que assumeixen tota la càrrega si en cau una
Una HBA, un camí o un commutador multicamí sobre dos fabrics independents (A i B)
L'alimentació o la ventilació fonts i ventiladors redundants i substituïbles en calent
Un esborrat o una corrupció lògica instantànies i còpies de seguretat → tema 57
La pèrdua sencera del centre replicació a un segon emplaçament → tema 58

5. Requisits d'un plec d'emmagatzematge

Els requisits que cal exigir en les prescripcions tècniques d'una cabina, i que apareixen a les preguntes de supòsit:


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 57

Sistemes de còpia de seguretat model 3-2-1 i protecció contra ransomware

Enunciat oficial. Sistemes de Backup model 3-2-1. Backup i mitjans de protecció contra ransomware.


1. La regla 3-2-1

La regla bàsica del model de còpia de seguretat 3-2-1 estableix que s'han de mantenir:

3 còpies de les dades (l'original més dues còpies), emmagatzemades en 2 tipus de suport o mitjans diferents, amb 1 còpia fora de les instal·lacions (off-site).

Per què cada número:

Evolucions modernes, motivades pel ransomware:

Regla Significat
3-2-1-1-0 3 còpies · 2 suports · 1 fora de la seu · 1 còpia OFFLINE, aïllada o IMMUTABLE (air gap) · 0 errors verificats en la restauració
3-2-2 dues còpies fora de la seu, una d'elles al núvol
4-3-2 4 còpies, 3 ubicacions, 2 fora de la seu (per a entorns crítics)

El «1» addicional és avui la peça decisiva: una còpia que el ransomware no pot xifrar ni esborrar perquè és immutable, està desconnectada o resideix en un sistema amb credencials i domini separats.


2. Tipus de còpia

Tipus Què copia Espai Temps de còpia Temps de restauració
Completa (full) totes les dades màxim màxim mínim: només cal una peça
Incremental els canvis des de l'última còpia de QUALSEVOL tipus (completa o incremental) mínim mínim màxim: cal la completa més totes les incrementals de la cadena
Diferencial els canvis des de l'última còpia COMPLETA intermedi, creixent cada dia intermedi intermedi: cal la completa més l'última diferencial

Atenció a un error documentat al solucionari oficial d'un examen anterior: s'hi va definir la còpia «diferencial» amb la descripció que en rigor correspon a la incremental (canvis des de l'última còpia, sigui del tipus que sigui). La definició correcta és la d'aquesta taula: la diferencial sempre pren com a referència l'última còpia completa.

Altres esquemes: sintètica completa (es construeix una completa nova a partir de la completa anterior i les incrementals, sense tornar a llegir l'origen), incremental permanent (forever incremental) amb consolidació al repositori, CDP (Continuous Data Protection, replicació contínua amb punts de recuperació de segons), instantànies (snapshots) —que no són una còpia de seguretat perquè viuen al mateix sistema que les dades— i replicació —que tampoc no ho és: replica també l'error i el xifratge.

Rotació: avi-pare-fill (GFS, Grandfather-Father-Son), Torre de Hanoi, i les polítiques modernes de retenció per nivells (diàries, setmanals, mensuals, anuals).


3. Objectius i mètriques

Aquests valors surten de l'anàlisi d'impacte en el negoci (BIA, Business Impact Analysis) → tema 58.


4. Suports i arquitectures

Programari: Veeam, Commvault, Veritas NetBackup, Rubrik, Cohesity, Dell Networker/Avamar, IBM Spectrum Protect, i de codi obert Bacula, Bareos, Restic, Borg, Duplicati, Amanda, Proxmox Backup Server.


5. El ransomware

Com actua: accés inicial (phishing, RDP (Remote Desktop Protocol) exposat, vulnerabilitat sense pedaç, credencials robades, cadena de subministrament) → execució i persistència → escalada de privilegis → moviment lateral → reconeixement i EXFILTRACIÓ de dades → destrucció de les còpies de seguretat → xifratge → extorsió.

Cadena d'un atac de ransomwareVuit fases en ordre. La que decideix el resultat és la sisena: les còpies es destrueixen abans de xifrar res, perquè una còpia viva treu tot el valor a l'extorsió.1. Accés inicial6. Destrucció de les còpies3. Escalada de privilegis2. Execució i persistència5. Reconeixement i exfiltració8. Extorsió4. Moviment lateral7. Xifratge

Doble i triple extorsió: primer xifren, després amenacen de publicar les dades robades i, finalment, pressionen clients o afectats i denuncien l'incident als reguladors.

El primer que fa un atacant competent abans de xifrar és buscar i destruir les còpies de seguretat. Per això la protecció del sistema de còpies és la mesura més important de totes.

Perjudicis que cal preveure en un atac de ransomware: indisponibilitat dels serveis durant dies o setmanes, pèrdua de dades fins al darrer punt de recuperació vàlid, exfiltració i publicació de dades personals —amb la corresponent bretxa de seguretat notificable a l'autoritat de control en 72 hores (RGPD, art. 33) i, si hi ha alt risc, comunicació als afectats (RGPD, art. 34)—, cost de recuperació, dany reputacional i responsabilitats jurídiques.


6. Protecció de les còpies contra ransomware

Recomanacions correctes:

  1. Immutabilitat: repositoris amb bloqueig d'objectes (WORM) o instantànies immutables que no es poden esborrar ni modificar durant el període de retenció, ni tan sols per un administrador.
  2. Aïllament (air gap): còpia desconnectada físicament (cinta extreta) o lògicament (repositori accessible només durant la finestra de còpia, amb credencials pròpies).
  3. Versionat: conservar diverses còpies puntuals (point-in-time) enlloc de sobreescriure sempre l'última. Si una versió queda xifrada, es pot restaurar-ne una anterior neta. És una mesura diferent de la immutabilitat: sense bloqueig WORM, un atacant amb prou privilegis pot esborrar totes les versions retingudes; amb WORM, no.
  4. Separació de credencials i de domini: el sistema de còpies no ha d'estar unit al mateix Active Directory que els servidors que protegeix, ni compartir-hi comptes d'administració.
  5. Autenticació multifactor a la consola de còpies i mínim privilegi.
  6. Xifratge de les còpies en trànsit i en repòs, amb custòdia separada de les claus.
  7. Retenció suficient: el ransomware sol romandre latent setmanes; si només es guarden 7 dies, totes les còpies poden estar ja compromeses. Cal retenció de mesos i punts mensuals.
  8. Verificació automàtica de la restaurabilitat i proves de restauració periòdiques i documentades —la mesura més ignorada i la més decisiva.
  9. Detecció d'anomalies al repositori: canvis massius d'entropia, taxes de canvi inusuals, esborrats en bloc.
  10. Segmentació de xarxa entre el repositori i la producció.
  11. Còpia de la configuració del propi sistema de còpies.

El que NO és una recomanació vàlida —i que sol aparèixer com a distractora—: guardar les còpies al mateix servidor o a la mateixa xarxa que les dades originals, fer servir el mateix compte d'administrador de domini per al sistema de còpies, confiar només en les instantànies de la cabina, substituir la còpia per la replicació, o retenir només unes poques versions recents.


7. Passos abans de restaurar després d'un atac

Aquest és l'escenari d'examen: quins passos cal seguir abans de procedir a la restauració. L'ordre correcte:

  1. Declarar l'incident i activar el pla de resposta i el comitè de crisi.
  2. Contenir: aïllar els sistemes afectats de la xarxa, desconnectar els repositoris de còpies per protegir-los i revocar credencials compromeses. No apagar les màquines si es vol preservar la memòria volàtil per a l'anàlisi forense.
  3. Preservar evidències i fer anàlisi forense: determinar el vector d'entrada, l'abast i el moment de la compromís. Si no se sap com han entrat, es tornarà a repetir.
  4. Notificar: a l'autoritat de protecció de dades en 72 hores si hi ha dades personals afectades (RGPD, art. 33), al CCN (Centro Criptológico Nacional)-CERT (Computer Emergency Response Team) o al CSIRT (Computer Security Incident Response Team) competent, i a les autoritats policials. No pagar el rescat és la recomanació unànime.
  5. Identificar un punt de restauració net, anterior a la compromís, i verificar-ne la integritat i que no conté la persistència de l'atacant.
  6. Reconstruir sobre un entorn net: sistemes reinstal·lats o restaurats en una xarxa aïllada, amb pedaços aplicats, contrasenyes canviades i eliminació dels mecanismes de persistència.
  7. Restaurar les dades i validar-les funcionalment.
  8. Tornar a producció de manera controlada i amb monitoratge reforçat.
  9. Lliçons apreses i pla d'acció: la revisió post-incident sense buscar culpables → tema 18.

L'error greu i freqüent és restaurar directament sobre l'entorn compromès sense conèixer el vector d'entrada: el resultat és tornar a ser xifrat en dies.


8. Prevenció general

ENISA (European Network and Information Security Agency; des de 2019, European Union Agency for Cybersecurity, mantenint la sigla original), Threat Landscape 2023 (Annex B: Recommendations, pàg. 139), recomanació literal contra el ransomware: «Implement a secure and redundant backup strategy. Ensure you maintain offline, encrypted data backups that are regularly tested, following your backup procedures.» — còpies xifrades i fora de línia, verificades amb regularitat. El parany habitual a l'examen és canviar «fora de línia» per «en línia»: unes còpies en línia (connectades) no compleixen la recomanació, per molt xifrades que estiguin.

Recomanacions d'ENISA i del CCN-CERT per mitigar el ransomware:

Una afirmació incorrecta habitual a les preguntes és que pagar el rescat garanteix la recuperació de les dades: no la garanteix, finança el crim, no elimina la persistència i no evita la publicació de les dades exfiltrades.


9. Classificació d'actius i cicle de vida dels suports

Abans de triar la tecnologia, cal saber què es copia. El primer pas no és tècnic: és fer un inventari d'actius d'informació i classificar-los per la seva criticitat per a l'organització —no només «per a les TIC (Tecnologies de la Informació i la Comunicació)»: la classificació la fixa el valor del negoci (confidencialitat, integritat, disponibilitat), no la infraestructura que el sosté.

Cada actiu classificat té un cicle de vida que depèn de dos terminis independents:

Si el suport caduca abans que el contingut, cal traspassar les dades a un suport nou per garantir-ne la conservació. El cicle de vida determina també quan deixa de ser útil i, per tant, quan s'ha d'eliminar de forma segura.

Esborrament i destrucció (ENS, mesura mp.si.5): un suport que no es pot esborrar de manera segura no es pot reutilitzar en cap altre sistema; a partir de categoria mitjana calen productes certificats per a l'esborrament.

Un servei SaaS no elimina la necessitat de còpia pròpia. El proveïdor garanteix la disponibilitat de la seva infraestructura, no la recuperació de les dades de l'usuari (shared responsibility model — responsabilitat compartida). Cal una solució de còpia complementària, pròpia o de backup as a service.

10. Marc normatiu


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 58

Plans de recuperació davant desastres (DRP) i continuïtat de negoci (BCP)

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

Enunciat oficial. Plans de recuperació davant desastres (DRP) i continuïtat de negoci (BCP).


1. La família de plans

1.1 BCP i DRP

BCP (Business Continuity Plan) DRP (Disaster Recovery Plan)
Abast tota l'organització: persones, processos, instal·lacions, proveïdors, comunicació els sistemes d'informació i la infraestructura TIC (Tecnologies de la Informació i la Comunicació)
Objectiu mantenir les funcions crítiques de negoci operatives durant i després d'una interrupció restaurar els sistemes i les dades després d'un desastre
Pregunta com continuem donant servei? com tornem a engegar la tecnologia?
Relació és el marc és un component del BCP

El BCP, o pla de continuïtat de negoci, estableix el mètode per crear i validar les accions a seguir per assegurar la continuïtat de les operacions dels processos de negoci abans, durant i després de l'ocurrència d'esdeveniments disruptius. Aquesta és la definició que cal reconèixer: cobreix les tres finestres de temps i tot el negoci.

El DRP forma part del BCP, no a l'inrevés. Un DRP impecable amb un BCP inexistent significa que els servidors tornen però ningú no sap què fer amb ells. El DRP, a més, és específic d'un emplaçament: cobreix les interrupcions que obliguen a traslladar el servei a un centre alternatiu.

1.2 Els altres plans del conjunt

La guia de planificació de contingència del NIST descriu un conjunt de plans que s'han de coordinar entre ells perquè no es contradiguin ni es dupliquin:

Pla De què s'ocupa
BCP sostenir els processos de negoci durant i després d'una interrupció
COOP (Continuity of Operations Plan) restablir les funcions essencials de l'organització en un emplaçament alternatiu durant un període llarg
Pla de comunicació de crisi comunicació interna i externa; designa qui és l'única veu autoritzada davant dels mitjans i la ciutadania
Pla de resposta a incidents cibernètics detecció, contenció i recuperació davant d'un atac; sol ser un annex del BCP
DRP restaurar el servei en un emplaçament alternatiu després d'un desastre físic
ISCP (Information System Contingency Plan) recuperar un sistema concret, sigui on sigui: al seu lloc o al centre alternatiu
OEP (Occupant Emergency Plan) primera resposta per a les persones d'un edifici: evacuació, confinament, emergència mèdica

La frontera entre el DRP i l'ISCP: el DRP mou l'operació a un altre lloc; un cop mudada, cada sistema aplica el seu ISCP per restaurar-se. I la vida sempre és la primera prioritat: l'OEP s'executa primer i per separat de la resta.

1.3 El pla de contingència i els seus plans unitaris

L'esquema clàssic de l'Administració espanyola descompon el pla de contingència en plans unitaris, un per a cada finestra de temps:

Pla unitari Quan actua Què recull
Pla de respatller o de suport (plan de respaldo) abans tots els elements i procediments necessaris per poder operar en un centre alternatiu, si n'hi ha
Pla d'emergència durant una guia d'actuació pas a pas per a cada fallida o dany, amb una sèrie cronològica d'accions i una assignació de responsabilitats
Pla de recuperació després les normes d'actuació per reiniciar totes les activitats normals de l'organització, bé al CPD (Centre de Processament de Dades) propi, bé en un altre centre alternatiu

Un pla de migració no és un pla unitari del pla de contingència. La migració és un projecte de trasllat de serveis a una altra infraestructura, planificat prèviament; el pla de contingència respon a allò que no s'ha triat. La confusió és fàcil perquè tots dos acaben amb els serveis en una altra infraestructura.

D'on surten aquestes mesures: de l'estudi de detall dels riscos potencials i de la criticitat dels processos surt el nivell acceptable de seguretat, i d'aquí es determinen les mesures a adoptar. Un bon disseny estableix compromisos entre l'operativitat necessària del sistema, els mecanismes i les tècniques que permeten minimitzar els efectes d'una interrupció i els costos directes i indirectes d'aplicar-les. El resultat es tradueix en dues coses: seguretat preventiva i pla de contingència, que ha de recollir en plans unitaris la resposta als diferents problemes que poden sorgir.

1.4 El sistema de gestió

El SGCN (Sistema de Gestió de la Continuïtat de Negoci) és el marc de gestió que envolta tots aquests plans. La norma certificable és la ISO 22301, amb l'estructura d'alt nivell comuna a les normes de sistemes de gestió i el cicle de millora PDCA (Plan, Do, Check, Act). L'acompanyen la ISO 22313 (orientació), la ISO 22317 (l'anàlisi d'impacte) i la ISO/IEC 27031, de la IEC (International Electrotechnical Commission), sobre la preparació de les TIC per a la continuïtat.


2. El procés de planificació

El NIST el descompon en set passos, i l'ordre importa: triar l'estratègia abans de saber què val la interrupció és l'error típic.

  1. Política de continuïtat: qui té l'autoritat, quin abast, quins recursos.
  2. Anàlisi d'impacte en el negoci (BIA).
  3. Identificar controls preventius: evitar la interrupció surt més barat que reparar-la.
  4. Crear les estratègies de recuperació.
  5. Redactar el pla.
  6. Provar, formar i exercitar.
  7. Mantenir el pla.

2.1 L'anàlisi d'impacte en el negoci

El BIA (Business Impact Analysis) consisteix a identificar els processos relacionats amb la missió de l'organització, avaluar les conseqüències que tindria la seva interrupció al llarg del temps i determinar-ne els requisits de recuperació. El NIST el resumeix en tres passos, i la pràctica hi afegeix el detall:

  1. Determinar els processos i la seva criticitat: identificar els processos de negoci i les seves dependències (aplicacions, dades, persones, proveïdors, instal·lacions) i avaluar l'impacte de la interrupció al llarg del temps —econòmic, operatiu, legal, reputacional i, al sector públic, sobre el ciutadà—. L'impacte creix amb la durada, i sovint de manera no lineal. D'aquí surten el MTD, el RTO i el RPO de cada procés.
  2. Identificar els recursos necessaris per reprendre el procés: instal·lacions, personal, equipament, programari, fitxers de dades i registres vitals, i el mínim per operar en mode degradat.
  3. Fixar les prioritats de recuperació: classificar els processos en crítics, essencials i diferibles, i establir l'ordre de recuperació dels recursos que els suporten.

El BIA conté, doncs, els requisits temporals i de recursos dels processos del seu abast; juntament amb l'anàlisi de riscos defineix les iniciatives a implantar per recuperar-los en situació de contingència.

2.2 Les mètriques, i com es relacionen

Línia de temps d'un desastre amb RPO, RTO, WRT i MTDUna línia de temps horitzontal. A l'esquerra, el darrer punt de dades consistent. Al centre, l'instant del desastre. El RPO va del darrer punt consistent fins al desastre i mesura les dades perdudes. El RTO va del desastre fins que el sistema torna a estar tècnicament disponible. El WRT va des d'aquest instant fins que l'operació és normal. El MTD abasta el RTO més el WRT i és el sostre que fixa el negoci.darrera còpiaDESASTREsistema disponibleoperació normalRPOdades perdudesRTOWRTMTD = RTO + WRTEl RPO mira enrere i el RTO mira endavant des del mateix instant. El RPO no forma part del MTD.

El RPO mira enrere i el RTO mira endavant des del mateix instant, i el MTD no acaba quan el sistema arrenca, sinó quan es torna a treballar amb normalitat.

2.3 L'anàlisi de riscos

Complementa el BIA: mentre el BIA diu quant costa que un procés s'aturi, l'anàlisi de riscos diu què pot provocar l'aturada i amb quina probabilitat. Per planificar les estratègies cal començar avaluant la probabilitat i l'impacte de les possibles amenaces sobre els actius que suporten els processos crítics.

Amenaces típiques: incendi, inundació, tall elèctric perllongat, fallida de refrigeració, ciberatac i programari de segrest, error humà, fallida d'un proveïdor crític, pandèmia, vaga, terratrèmol, terrorisme.


3. Estratègies de recuperació

3.1 Emplaçaments alternatius

Tipus Descripció RTO típic Cost
Cold site espai amb energia, refrigeració i xarxa, sense equipament dies o setmanes baix
Warm site equipament instal·lat però sense dades actualitzades; cal restaurar hores o dies mitjà
Hot site rèplica operativa i amb dades sincronitzades, amb personal, llesta per assumir el servei minuts o hores alt
Mobile site contenidor transportable amb l'equipament necessari, que es porta on calgui un dia o més mitjà
Mirror site rèplica idèntica i activa en temps real, sense diferència tècnica amb el principal immediat molt alt
Actiu-actiu tots dos CPD donen servei simultàniament i es reparteixen la càrrega immediat molt alt
Acord de reciprocitat acord amb una altra organització per allotjar-se mútuament variable baix, però poc fiable
Núvol recuperació com a servei en un proveïdor de núvol, que es paga per ús hores variable, sense inversió inicial

L'ordre de la taula és el que es pregunta: de menys cost i més temps a més cost i menys temps. L'ENS hi afegeix una exigència que sovint s'oblida: els mitjans alternatius han d'estar materialitzats en acords o contractes i han de tenir les mateixes garanties de seguretat que els originals.

3.2 Replicació de dades

Es pot replicar a diferents nivells: cabina d'emmagatzematge, hipervisor, sistema operatiu, base de dades o aplicació. Com més a prop de l'aplicació, més consistent és la còpia i més cara de mantenir.

La còpia de seguretat és una entrada del DRP, no el DRP: fixa el RPO assolible i el seu temps de restauració condiciona el RTO.

3.3 Alta disponibilitat i recuperació de desastres

Un clúster local no és un DRP: si crema el CPD, cauen tots els nodes.


4. Contingut, activació i retorn

4.1 Què porta el pla

  1. Abast, objectius i supòsits; processos i sistemes coberts, amb els seus RTO i RPO.
  2. Rols i responsabilitats: comitè de crisi, coordinador de continuïtat, equips tècnics, portaveu, i suplents de cadascun.
  3. Criteris i autoritat d'activació: qui declara el desastre i amb quins llindars. Sense això, ningú no gosa activar el pla.
  4. Arbre de trucades i pla de comunicació intern, amb proveïdors, amb els mitjans i amb la ciutadania.
  5. Procediments de recuperació i ordre de restauració segons les dependències: primer directori i xarxa, després bases de dades, després aplicacions.
  6. Inventari de recursos: sistemes, contactes, contractes, llicències i credencials d'emergència accessibles sense els sistemes caiguts.
  7. Procediments de treball en mode degradat o manual.
  8. Criteris i procediment de retorn a la normalitat (failback), sovint més delicat que l'activació.
  9. Calendari de proves i registre de resultats.
  10. Control de versions i distribució: el pla ha d'estar disponible fora dels sistemes que protegeix. Un pla que només és a la intranet caiguda no serveix de res.

4.2 Les fases d'execució

El NIST ordena l'execució del pla en tres fases, precedides de la informació de suport que el pla ja porta escrita:

Fase Què passa
Activació i notificació es declara la interrupció, s'avisa el personal i s'avalua el dany per decidir l'estratègia i estimar la durada
Recuperació s'executen els procediments per restablir el servei, normalment als mitjans alternatius, en l'ordre de prioritat del BIA
Reconstitució es prova i es valida que el sistema torna a funcionar, es retorna al lloc definitiu i es tanca el pla

Quan un incident activa el pla de continuïtat. L'incident es tracta amb el procediment ordinari mentre la previsió de resolució cap dins del MTD; el pla s'activa quan l'avaluació del dany diu que no s'hi arribarà, o quan la persona amb autoritat declara el desastre. El llindar no és la gravetat tècnica: és el temps.


5. Proves, formació i manteniment

Escalons, de menys a més exigent:

Prova Descripció Interromp producció?
Revisió de llista de comprovació (checklist) lectura i verificació documental del pla no
Recorregut (walkthrough) revisió conjunta del pla pels equips implicats no
Exercici de taula (tabletop) un facilitador planteja un escenari i els participants discuteixen decisions, rols i coordinació; no es desplega cap equipament no
Exercici funcional o simulació el personal executa les seves funcions en un entorn simulat: notificacions, arrencada d'equips, restauració d'una còpia no
Prova en paral·lel s'activa l'emplaçament alternatiu sense aturar el principal i es comparen els resultats no
Prova d'interrupció completa (full interruption) s'atura el principal i s'opera realment des de l'alternatiu sí

Les dues últimes es confonen sovint: la paral·lela no toca el servei viu i la d'interrupció completa sí. La segona és la més valuosa i la més arriscada, i per això moltes organitzacions no la fan mai.

Regla d'or: un pla no provat no és un pla, és un document. La prova ha de tenir objectius mesurables —assolim el RTO?—, registre de resultats i pla d'acció sobre les desviacions. Freqüència mínima recomanada: anual, i sempre després d'un canvi rellevant.

La formació va a part de les proves: informar cada persona del seu paper abans que hi hagi cap exercici. I el manteniment és tan important com la redacció: cada canvi d'arquitectura o d'organització obliga a actualitzar el pla.


6. Al sector públic

6.1 L'ENS

L'ENS (Esquema Nacional de Seguretat) és el mandat directe: les administracions públiques han de desenvolupar un pla de continuïtat que estableixi les accions a executar en cas d'interrupció dels serveis prestats amb els mitjans habituals. Les mesures són la família op.cont de l'anexe II, i el que les activa no és la categoria del sistema sinó el nivell de la dimensió de disponibilitat:

Mesura Què exigeix S'aplica quan la disponibilitat és
op.cont.1 Anàlisi d'impacte determinar els requisits de disponibilitat de cada servei i quins elements són crítics per prestar-lo mitjana o alta
op.cont.2 Pla de continuïtat funcions i responsabilitats, coordinació de l'entrada en servei dels mitjans alternatius, contractes amb els proveïdors, formació de les persones afectades i integració amb els altres plans de l'organització alta
op.cont.3 Proves periòdiques localitzar i corregir els errors o deficiències del pla alta
op.cont.4 Mitjans alternatius instal·lacions, personal, equipament, comunicacions i serveis contractats a tercers alternatius, amb un temps màxim d'entrada en funcionament i les mateixes garanties de seguretat alta

És a dir: un sistema classificat com a alt en confidencialitat però baix en disponibilitat no està obligat a tenir pla de continuïtat, i només l'anàlisi d'impacte baixa fins al nivell mitjà.

6.2 La resta del marc


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 59

Models de computació híbrids. IaaS, PaaS i SaaS

Enunciat oficial. Models de computació híbrids. Models de servei IaaS, PaaS, SaaS. Núvols públics, privats, híbrids i multicloud.


1. La definició del NIST

NIST SP 800-145 (SP: Special Publication) — The NIST Definition of Cloud Computing: model que permet un accés ubic, convenient i sota demanda a través de la xarxa a un conjunt compartit de recursos informàtics configurables —xarxes, servidors, emmagatzematge, aplicacions i serveis— que es poden proveir i alliberar ràpidament amb un esforç mínim de gestió o d'interacció amb el proveïdor del servei.

Les cinc característiques essencials

  1. Autoservei sota demanda (on-demand self-service): l'usuari provisiona capacitat unilateralment, sense interacció humana amb el proveïdor.
  2. Accés ampli per xarxa (broad network access): disponible per la xarxa amb mecanismes estàndard, des de qualsevol tipus de client.
  3. Agrupació de recursos (resource pooling): els recursos del proveïdor s'agrupen per servir múltiples consumidors en model multiinquilí (multi-tenant), assignats i reassignats dinàmicament; el client no coneix ni controla la ubicació exacta, encara que en pot especificar el nivell —país, regió, CPD (Centre de Processament de Dades)—.
  4. Elasticitat ràpida (rapid elasticity): les capacitats es proveeixen i alliberen elàsticament, a vegades automàticament, i al consumidor li semblen il·limitades.
  5. Servei mesurat (measured service): l'ús es mesura, controla i informa automàticament, amb transparència per a totes dues parts. És el que fa possible el pagament per ús.

Aquestes cinc són les que es pregunten. No en són característiques la «seguretat garantida», la «ubicació física coneguda» ni el «cost sempre inferior».

1.1 Núvol, clúster i graella: paradigmes veïns, no sinònims

Un clúster de computació (cluster computing) és un conjunt de màquines individuals que treballen amb les seves capacitats individuals per executar un treball de càlcul col·lectiu: cada node hi aporta la seva CPU (Central Processing Unit) i memòria per a una sola tasca compartida, típicament de càlcul científic o d'alt rendiment. No té les característiques essencials del núvol —no és autoservei sota demanda ni serveix múltiples clients de manera elàstica i mesurada—, encara que sovint s'hi confon. La graella (grid computing) hi afegeix la distribució dels recursos entre institucions i ubicacions diferents, coordinades per resoldre una mateixa tasca.


2. Els tres models de servei

Els tres models responen sempre a la mateixa pregunta: on es talla la pila, és a dir, fins on arriba el que gestiona el proveïdor i què li queda al client. Com més amunt talla el proveïdor, menys feina d'administració té el client —i menys marge per configurar el que hi ha a sota—. IaaS li deixa el sistema operatiu cap amunt; PaaS li deixa només el codi i les dades; SaaS no li deixa ni el codi. No hi ha cap tall que sigui millor: n'hi ha un que encaixa amb cada cas d'ús (§4.1).

IaaS PaaS SaaS
El proveïdor gestiona xarxa, servidors, virtualització i emmagatzematge tot l'anterior + sistema operatiu, middleware i entorn d'execució tota la pila, fins a l'aplicació
El client gestiona sistema operatiu, middleware, temps d'execució, aplicacions i dades només el codi i les dades només la configuració i les dades
Analogia lloguer del solar i els fonaments lloguer de la casa a mig fer lloguer del pis moblat
Exemples EC2 (Elastic Compute Cloud), Azure VM (Virtual Machine), Compute Engine, OpenStack App Service, Elastic Beanstalk, Heroku, OpenShift, Cloud Run Microsoft 365, Salesforce, Gmail, Dropbox, ServiceNow

La pila IaaS / PaaS / SaaSLes mateixes tres capes en els tres models. El que canvia és on cau la frontera: com més amunt puja el que gestiona el proveïdor, menys en queda per al client.IaaSPaaSSaaSAplicacions i dadesSO i middlewareXarxa, servidors, virtualitzacióClientClientProveïdorClientProveïdorProveïdorGestiona el clientGestiona el proveïdor

Definicions literals que cauen:

Categories derivades: CaaS (contenidors), FaaS/serverless (funcions), DBaaS (bases de dades), DaaS (escriptori), STaaS (emmagatzematge), XaaS (qualsevol cosa com a servei).

Responsabilitat compartida — el concepte que més s'oblida: la responsabilitat sobre la seguretat es reparteix entre proveïdor i client segons el model, però la responsabilitat jurídica sobre les dades continua sent sempre del client, que és el responsable del tractament (RGPD) i el titular del servei públic. Regla mnemotècnica: el proveïdor és responsable de la seguretat del núvol; el client, de la seguretat en el núvol.


3. Els models de desplegament

Mentre que els models de servei diuen qui gestiona què, els de desplegament diuen qui pot fer servir la infraestructura. Els quatre del NIST es distingeixen per l'abast d'aquest ús —una sola organització, una comunitat, tothom, o una combinació lligada de les anteriors—, no per la ubicació física: aquesta confusió és la que el tribunal explota.

Model Definició NIST
Privat infraestructura proveïda per a l'ús exclusiu d'una sola organització. Pot ser propietat seva o d'un tercer i estar dins o fora de les seves instal·lacions
Comunitari ús exclusiu d'una comunitat específica d'organitzacions amb preocupacions compartides (missió, requisits de seguretat, compliment)
Públic proveït per a l'ús obert del públic en general
Híbrid composició de dues o més infraestructures de núvol diferents (privada, comunitària o pública) que romanen entitats úniques però estan lligades per tecnologia estandarditzada o propietària que permet la portabilitat de dades i aplicacions

Definicions que es pregunten literalment:

Motivacions de l'híbrid: dades o càrregues que no poden sortir per raons legals o de sobirania, sistemes heretats no migrables, inversió ja feta en CPD, latència, i cloud bursting (absorbir pics de demanda al núvol públic mantenint la base a casa).

Elements tècnics de l'híbrid: connectivitat dedicada (AWS (Amazon Web Services) Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) o VPN (Virtual Private Network); identitat federada; xarxa i adreçament coherents; Kubernetes com a capa d'abstracció comuna; i solucions de núvol estès al CPD del client (Azure Stack, AWS Outposts, Google Anthos, OpenShift).


4. Beneficis, riscos i decisió

Beneficis: elasticitat, pagament per ús, rapidesa de provisió, accés a serveis gestionats i a tecnologia que no es podria operar internament, resiliència multizona, i conversió de CAPEX (Capital Expenditure: inversió amortitzable en actius que es compren una vegada) en OPEX (Operating Expenditure: despesa corrent que es paga mentre dura el servei). No és un estalvi automàtic —el mateix consum pot sortir més car—: el que canvia és quan es paga i de quin capítol surt; l'anàlisi econòmica de la decisió es fa al tema 3.

Riscos:

Elasticitat vs escalabilitat: l'escalabilitat és la capacitat de créixer; l'elasticitat és fer-ho automàticament i en tots dos sentits segons la demanda, i alliberar el recurs quan ja no cal. Tota elasticitat és escalabilitat; no a l'inrevés: un sistema que només sap créixer, o que necessita una intervenció manual per fer-ho, és escalable i no elàstic. L'avantatge que ofereixen els proveïdors amb l'elasticitat en l'aprovisionament és que el client pot aprovisionar els recursos en funció de les seves necessitats de manera instantània, pagant només pel que s'utilitza i sense sobredimensionar per al pic: no cal informar el proveïdor per endavant dels aprovisionaments futurs —seria el contrari de l'autoservei sota demanda (§1)— ni el moviment és d'un sol sentit.

Escalat vertical (més recursos a la mateixa instància: té un sostre físic i sol exigir aturar el servei) davant d'horitzontal (més instàncies darrere d'un balancejador). El núvol premia l'horitzontal, que és l'únic que permet elasticitat de veritat.

Absorbir un pic de trànsit sense marge de temps: és el mateix escenari que decanta cap a PaaS quan cal sortir a temps sense assumir infraestructura (§2) — un lloc web perquè la ciutadania es descarregui dades, amb una campanya de comunicació imminent i un creixement exponencial de visites previst però no quantificat. La mesura més ràpida d'implementar per garantir que el servei ho aguanta és contractar una CDN (Content Delivery Network, xarxa de distribució de continguts) al núvol: replica el contingut a punts de presència distribuïts geogràficament, prop de qui el demana, i absorbeix el gruix del trànsit abans que arribi a l'origen. Escalar un sol servidor al màxim té un sostre físic (escalat vertical); balancejar-lo no serveix si no hi ha rèpliques darrere; i una CDN on-premise no dona l'abast geogràfic ni es desplega en pocs dies.

4.1 Criteris de selecció del model segons el cas d'ús

No hi ha un model millor: hi ha el que encaixa amb el que demana el cas. Les preguntes que el decideixen són poques i sempre les mateixes.

Quin model de servei. La pregunta és quanta pila vol —i pot— administrar el client:

Si el cas d'ús diu… Encaixa
ja hi ha al mercat una aplicació que fa el que cal i n'hi ha prou de configurar-la i posar-hi les dades SaaS
cal programari propi, l'equip no pot assumir tasques d'infraestructura i hi ha pressa per sortir PaaS
cal control del sistema operatiu —programari heretat, versions concretes, agents propis— o s'hi ha de moure una màquina tal com està IaaS
la càrrega és esporàdica i per esdeveniments, i no compensa tenir res encès esperant FaaS / serverless

Quin model de desplegament. La pregunta és qui pot fer servir la infraestructura i què impedeix que les dades surtin:

Si el cas d'ús diu… Encaixa
dades que no poden sortir per llei, sobirania o classificació, o un CPD acabat de pagar privat
unes quantes organitzacions amb els mateixos requisits volen compartir la despesa i el compliment comunitari
demanda molt variable, abast obert i cap valor a controlar la infraestructura públic
una part s'ha de quedar a casa i l'altra ha de sortir, i han d'interoperar híbrid
es vol evitar dependre d'un sol proveïdor, o cada servei el fa millor un de diferent multinúvol

Criteris transversals, per desempatar quan més d'un model val: el cost total i no només la factura mensual (migració, sortida, formació, egress); la reversibilitat i portabilitat que es puguin exigir al plec; la latència cap a on són els usuaris i els sistemes que hi parlen; i quina part de la responsabilitat compartida pot assumir de debò l'organització —un SaaS no elimina la seva responsabilitat sobre les dades, només la del que hi ha a sota (§2)—.


5. Al sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 60

Cloud sobirà i cloud per a l'Administració Pública

Enunciat oficial. Cloud sobirà i cloud per a l'Administració Pública. Regulació, sobirania del dada i cloud de confiança europeu.


1. El problema: què vol dir sobirania

Un núvol sobirà és el servei al núvol que garanteix alhora que les dades, les persones que hi accedeixen i la tecnologia que el sustenta queden sota una jurisdicció i un control determinats —a Europa, els de la UE—, de manera que ni una llei de fora en pugui forçar l'accés ni el proveïdor en pugui impedir la sortida. No el defineix on són els servidors: el defineixen les tres condicions que venen tot seguit, i n'hi ha prou que en falli una perquè la sobirania sigui nominal.

Sobirania de les dades (data sovereignty): les dades estan subjectes a les lleis del país on es troben o on opera qui les tracta. Emmagatzemar dades europees en un servei operat per una empresa nord-americana les fa potencialment accessibles sota la legislació dels Estats Units, encara que els servidors siguin a Europa.

Tres nivells que no s'han de confondre:

Nivell Pregunta Garanteix
Sobirania de les dades on són les dades i quina llei hi aplica residència i jurisdicció
Sobirania operativa qui pot accedir-hi i operar el sistema, i des d'on que el personal amb accés estigui sota jurisdicció europea
Sobirania tecnològica de qui és la tecnologia i es pot canviar codi obert, estàndards, portabilitat, absència de bloqueig

Residència de dades ≠ sobirania de dades. Que el CPD (Centre de Processament de Dades) sigui a Irlanda no impedeix una ordre judicial estrangera al proveïdor.

Els tres nivells de sobiraniaLa sobirania real del servei només es dona quan els tres nivells estan coberts alhora: falta'n un i no hi és.Dadeson són i quina llei hi aplicaOperativaqui hi accedeix i des d'onSobirania real del serveiTecnològicade qui és i si es pot canviar

El conflicte concret: la CLOUD (Clarifying Lawful Overseas Use of Data) Act dels EUA (Estats Units d'Amèrica) (2018) permet a les autoritats nord-americanes requerir dades a proveïdors sotmesos a la seva jurisdicció allà on estiguin emmagatzemades. Això entra en tensió directa amb el RGPD i és el nucli del debat europeu.


2. Marc jurídic

2.1 Protecció de dades i transferències

2.2 Seguretat

2.3 Dades i mercat


3. El núvol de confiança europeu

Iniciatives:

Alternatives tecnològiques amb sobirania per disseny: OpenStack i Kubernetes com a bases de núvols privats i comunitaris; Ceph, Proxmox, OpenNebula; i el programari lliure com a garantia de portabilitat.


4. El núvol per a l'Administració espanyola

Criteris de decisió per portar un servei al núvol públic:

  1. Classificació de la informació i categoria del sistema segons l'ENS.
  2. Base jurídica i transferències (RGPD).
  3. Criticitat i continuïtat: què passa si el proveïdor cau o si es perd la connectivitat.
  4. Reversibilitat i portabilitat: com se surt, en quant de temps i a quin cost. És la cara pràctica del bloqueig de proveïdor (vendor lock-in), que com a risc genèric del núvol es desenvolupa al tema 59 i, com a criteri de compra, al tema 3; el que hi afegeix la sobirania és que un servei del qual no es pot sortir tampoc no es pot sotmetre a una altra llei, per molt que el contracte digui el contrari.
  5. Cost total i model pressupostari (capítol 2 vs capítol 6).
  6. Competències internes per operar-lo amb seguretat.
  7. Sobirania: qui hi pot accedir i sota quina llei.

La regla per defecte: pujar dades personals o corporatives (per exemple, un registre de queixes ciutadanes, amb dades de contacte i de l'assumpte) al núvol d'un proveïdor extern —per prestigiós que sigui el proveïdor— no és recomanable sense abans haver resolt els set criteris anteriors. El prestigi comercial no acredita ni la conformitat amb l'ENS ni la base jurídica de la transferència (RGPD): si el proveïdor no té una oferta certificada per al sector públic espanyol i sotmesa a una jurisdicció compatible, el risc per defecte és de seguretat i de conformitat legal, no un problema de rendiment ni de cost.

4.1 El catàleg de serveis al núvol del CCN

«Conforme amb l'ENS» no s'ha de creure: es comprova en una llista. La resposta espanyola a què puc contractar té dues peces, i no són el mateix.

El catàleg, el CPSTIC. El CPSTIC (Catàleg de Productes i Serveis de Seguretat de les Tecnologies de la Informació i la Comunicació) és la llista de referència de productes i serveis amb garanties de seguretat contrastades —per avaluació o certificació— i amb un PES (Procedimiento de Empleo Seguro) publicat. El desenvolupa la guia CCN-STIC-105, es consulta al portal del CCN i s'actualitza contínuament. Té tres apartats:

Apartat Per a què
Productes aprovats maneig d'informació classificada
Productes i serveis qualificats sistemes sotmesos a l'ENS, per categoria
Productes i serveis de conformitat i governança suport al compliment i a la gestió

Els serveis al núvol hi entren com una família pròpia de la taxonomia (CCN-STIC-140, annex G), amb els seus requisits fonamentals de seguretat; el procediment d'inclusió és la CCN-STIC-106, i el servei ha d'arribar-hi ja amb la conformitat ENS vigent. La conseqüència pràctica per a un plec: l'ENS exigeix productes i serveis certificats o del catàleg als sistemes de categoria ALTA, els valora als de categoria mitjana i no els demana als de bàsica → tema 66.

Els perfils de compliment específics. Són guies que tradueixen les mesures de l'ENS a un servei concret, de manera que l'organisme no hagi de reinterpretar-les proveïdor a proveïdor. Sobre la base de la CCN-STIC-823, el CCN n'ha publicat per als núvols que més contracta l'Administració espanyola —Azure, Office 365, AWS i Google Cloud— i, molt important per a qui no vol sortir de casa, un per a núvols privats i comunitaris (CCN-STIC-886), que és el que empara la infraestructura pròpia d'un ajuntament o d'un consorci.

El que no resol el catàleg. Un servei qualificat acredita seguretat tècnica, no sobirania: la conformitat ENS no diu res sobre qui opera el servei, des d'on, ni sota quina llei. Els criteris 2 i 7 de la llista anterior segueixen sent del contractant.


5. Mesures pràctiques per protegir la sobirania


6. La posició de Barcelona

La Mesura de digitalització oberta i els Barcelona Digital Standards fixen la posició municipal:


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 61

Xarxes Wi-Fi

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

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

Enunciat oficial. Xarxes Wi‑Fi: estàndards, arquitectura, seguretat i criteris de disseny, desplegament i administració.


1. Estàndards

IEEE 802.11 és la família d'estàndards de xarxa local sense fil, o WLAN (Wireless Local Area Network); Wi-Fi és la marca de la Wi-Fi Alliance, que certifica la interoperabilitat dels equips que la implementen. Els dos noms es fan servir indistintament, però no són el mateix: l'estàndard el fa l'IEEE i la certificació la dona l'Aliança.

Estàndard Nom comercial Bandes Velocitat màxima teòrica Novetat clau
802.11b — 2,4 GHz 11 Mbps
802.11a — 5 GHz 54 Mbps OFDM (Orthogonal Frequency-Division Multiplexing)
802.11g — 2,4 GHz 54 Mbps
802.11n Wi-Fi 4 2,4 i 5 GHz 600 Mbps MIMO, canals de 40 MHz
802.11ac Wi-Fi 5 5 GHz ~6,9 Gbps MU (Multi-User)-MIMO de baixada, 256-QAM (Quadrature Amplitude Modulation), canals de 80/160 MHz
802.11ax Wi-Fi 6 / Wi-Fi 6E 2,4 i 5 GHz / +6 GHz ~9,6 Gbps OFDMA (Orthogonal Frequency-Division Multiple Access), MU-MIMO en tots dos sentits, BSS (Basic Service Set) coloring, TWT (Target Wake Time; estalvi d'energia), 1024-QAM
802.11be Wi-Fi 7 2,4, 5 i 6 GHz ~46 Gbps canals de 320 MHz, 4096-QAM, MLO (Multi-Link Operation)

Altres estàndards de la família: 802.11i (seguretat, WPA2), 802.11e (QoS, WMM, Wi-Fi Multimedia), 802.11r (fast roaming), 802.11k (assistència en la selecció d'AP), 802.11v (gestió de la xarxa i direcció de clients), 802.11w (protecció de trames de gestió), 802.11s (mallat), 802.11ah (HaLow, IoT de llarg abast a sub-1 GHz), 802.11p (vehicular).

MIMO i OFDMA

MIMO (Multiple Input Multiple Output): utilitza múltiples antenes en transmissió i recepció per enviar diversos fluxos de dades simultanis pel mateix canal (spatial multiplexing), aprofitant la propagació multitrajecte per augmentar la capacitat i la velocitat de la xarxa i millorar-ne la fiabilitat, sense necessitat de més ample de banda ni més potència. Aquest és l'objectiu de MIMO i la resposta que es pregunta.

OFDMA (Wi-Fi 6): divideix el canal en RU (Resource Unit, unitats de recursos) i serveix diversos clients dins de la mateixa transmissió. Millora dràsticament l'eficiència en entorns d'alta densitat amb trànsit petit i freqüent —exactament el cas d'un edifici municipal o d'una wifi ciutadana.


2. Bandes i canals

Banda Canals no solapats Abast Interferències
2,4 GHz només 3 (1, 6, 11) a Europa amb canals de 20 MHz major (travessa millor les parets) moltes: Bluetooth, microones, telèfons, veïns
5 GHz ~19-25 segons normativa i amplada menor poques
6 GHz (Wi-Fi 6E/7) fins a 59 de 20 MHz menor encara mínimes, però només clients moderns

Les tres bandes són d'ús comú: el CNAF (Cuadro Nacional de Atribución de Frecuencias) les atribueix a aplicacions d'ús comú, de manera que s'hi pot emetre sense llicència individual de l'espectre, a canvi de suportar les interferències dels altres usuaris i de respectar-ne les condicions tècniques i els límits de potència radiada. És la diferència de fons amb la telefonia mòbil, que treballa en bandes d'ús privatiu concedides a un operador: a la wifi ningú no té l'espectre garantit, i per això el disseny es fa comptant amb la interferència (§5), no suposant que no n'hi haurà.

DFS (Dynamic Frequency Selection) i TPC (Transmit Power Control): obligatoris en part de la banda de 5 GHz per no interferir amb radars meteorològics i militars; poden provocar canvis de canal inesperats.

Amplada de canal: més amplada = més velocitat però menys canals disponibles i més interferència. En entorns densos és millor 20 o 40 MHz que 80 o 160.


3. Arquitectura

Una WLAN s'organitza en cel·les. Cada punt d'accés, o AP (Access Point), forma un BSS (Basic Service Set), la cel·la bàsica, que s'identifica per l'adreça MAC de la seva ràdio —el BSSID (Basic Service Set Identifier)—. El conjunt de cel·les que comparteixen el mateix nom de xarxa, l'SSID (Service Set Identifier), i entre les quals un client es pot moure sense perdre la sessió és un ESS (Extended Service Set). Qui es connecta veu un SSID; qui administra gestiona els BSS que hi ha al darrere, i és aquesta distinció la que fa possible tant la itinerància (§5) com que un mateix AP publiqui diversos SSID amb VLAN i polítiques diferents (§4).

3.1 Modes

Si ja hi ha cablatge estructurat a cada planta, l'actuació adient és fer un estudi de cobertura i connectar cada AP per cable a l'armari de planta corresponent (i per PoE), per donar connectivitat de dades a telèfons mòbils i altres dispositius sense sacrificar amplada de banda; el mesh es reserva per als punts on el cable no arriba. Una oficina petita no actua de gàbia de Faraday pel simple fet de ser petita; cal blindatge metàl·lic complet, que no és el cas habitual d'un edifici d'oficines.

3.2 La controladora Wi-Fi

La controladora WLAN és l'equip —físic, virtual o al núvol— que administra de manera centralitzada tot el conjunt de punts d'accés. L'AP hi delega les decisions de ràdio, de seguretat i d'itinerància i es queda amb la funció de radiar; d'aquí que en el model centralitzat se l'anomeni thin AP. No s'ha de confondre amb el punt d'accés: l'AP serveix una cel·la, la controladora governa totes.

Funcions de la controladora dins d'una xarxa sense fil —la pregunta d'examen:

En resum: centralitza la configuració, l'automatisme de ràdio, la seguretat i la itinerància de tot el conjunt d'AP.

3.3 Alimentació: PoE

PoE (Power over Ethernet, IEEE 802.3af/at/bt): que un punt d'accés estigui connectat a un commutador PoE significa que el commutador li subministra ALIMENTACIÓ ELÈCTRICA a través del mateix cable de xarxa que porta les dades, de manera que no cal cap presa de corrent al lloc on s'instal·la l'AP.

Estàndard Nom Potència al port
802.3af PoE 15,4 W
802.3at PoE+ 30 W
802.3bt tipus 3 PoE++ / 4PPoE 60 W
802.3bt tipus 4 90-100 W

Avantatges: flexibilitat d'ubicació (sostres, exteriors), menys obra elèctrica, i continuïtat: si el commutador té SAI (Sistema d'Alimentació Ininterrompuda), els AP continuen funcionant en un tall de llum. Cal dimensionar el pressupost de potència del commutador: 48 ports a 30 W són 1.440 W.


4. Seguretat

Mecanisme Estat
WEP (Wired Equivalent Privacy) trencat; no s'ha d'usar mai
WPA (Wi-Fi Protected Access; TKIP, Temporal Key Integrity Protocol) obsolet
WPA2 (Wi-Fi Protected Access 2)-Personal (PSK, Pre-Shared Key) AES (Advanced Encryption Standard)-CCMP (Counter-Mode Cipher-Block-Chaining Message-Authentication-Code Protocol); encara vàlid, però la clau és compartida per tothom
WPA2-Enterprise 802.1X + RADIUS + EAP: credencials individuals; l'estàndard corporatiu
WPA3 (Wi-Fi Protected Access 3)-Personal SAE (Simultaneous Authentication of Equals), que substitueix el PSK i resisteix els atacs de diccionari fora de línia; forward secrecy
WPA3-Enterprise 802.1X reforçat, amb mode de 192 bits per a entorns d'alta seguretat
OWE (Opportunistic Wireless Encryption) xifratge sense autenticació per a xarxes obertes: substitueix la wifi oberta en clar. Wi-Fi Enhanced Open
PMF (Protected Management Frames) / 802.11w protecció de les trames de gestió; obligatori a WPA3

802.1X: arquitectura d'autenticació amb tres elements — suplicant (el client), autenticador (l'AP o el commutador) i servidor d'autenticació (RADIUS). Mètodes EAP: EAP-TLS (certificat de client i de servidor, el més segur), PEAP (Protected Extensible Authentication Protocol)-MSCHAPv2 (usuari i contrasenya dins d'un túnel TLS), EAP-TTLS (Tunneled Transport Layer Security), EAP-FAST.

Bones pràctiques de seguretat wifi:


5. Disseny i desplegament

Fases:

  1. Requisits: usuaris i dispositius simultanis per zona, aplicacions (veu, vídeo, dades), cobertura exterior, velocitat mínima per client i disponibilitat.
  2. Estudi predictiu amb plànols i materials de construcció (Ekahau, iBwave, AirMagnet).
  3. Estudi de camp (site survey): el seu objectiu és avaluar la propagació real de la radiofreqüència a l'edifici i determinar la ubicació òptima dels punts d'accés, abans de desplegar-los. Tres tipus: passiu (escolta), actiu (amb associació) i espectral (detecció d'interferències no wifi).
  4. Disseny: nombre i ubicació dels AP, model d'antena, canals, potència, amplada de canal i relació senyal-soroll.
  5. Desplegament: cablatge, PoE, muntatge i configuració.
  6. Validació post-desplegament amb un nou estudi de camp.
  7. Operació: monitoratge, RRM, actualitzacions i optimització contínua.

Criteris de disseny:

Cel·les Wi-Fi solapades per capacitat Patró hexagonal de cel·les de cobertura, cadascuna amb el seu punt d'accés al centre, solapades amb les veïnes per permetre la itinerància. El solapament recomanat entre cel·les adjacents és del 15-20 %. AP AP AP AP solapament 15-20 %

Itinerància (roaming)

Un client es mou dins d'un ESS canviant de BSS sense perdre la sessió. La decisió la pren el client, no la xarxa: la controladora pot suggerir, però no obligar, i per això el problema típic és el client enganxat (sticky client) que continua parlant amb un AP llunyà mentre en té un de millor a sobre. Contra això no hi ha cap funció màgica; hi ha disseny: cel·les petites, potència ajustada i el solapament del 15-20 % de l'esquema.

Les tres esmenes que hi ajuden i que s'acostumen a confondre:

La diferència es nota justament on més molesta: sense 802.11r, cada canvi d'AP en una xarxa WPA2/WPA3-Enterprise torna a passar per l'autenticació completa contra el RADIUS, i aquesta pausa és prou llarga per tallar una trucada de veu; amb 802.11r el canvi és imperceptible. Per a dades i navegació, en canvi, la pausa passa desapercebuda: 802.11r es justifica per la veu i el vídeo, no per l'ofimàtica.


6. Wi-Fi pública i municipal

Barcelona Wifi és un dels desplegaments de wifi ciutadana més grans d'Europa, amb centenars de punts a equipaments i via pública.

Consideracions específiques:


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 62

Internet i els seus components

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

Enunciat oficial. Internet i els seus components: arquitectura, protocols, dominis i DNS.


1. Arquitectura d'Internet

Internet és una xarxa de xarxes: xarxes autònomes interconnectades que fan servir la família de protocols TCP (Transmission Control Protocol) / IP.

El model client-servidor és el patró sobre el qual està construït tot el que ve després: un client —el navegador, el client de correu, el resolutor DNS— inicia la conversa, i un servidor, permanentment a l'escolta en un port conegut, la processa i respon. Per això el servidor necessita adreça estable i publicada al DNS i el client no. L'alternativa és el model d'igual a igual (peer-to-peer), on cada node fa de client i de servidor alhora i no hi ha punt central. Tots els protocols d'aquest tema són client-servidor, i el que canvia és qui fa de client i quan: un servidor de correu és servidor davant del seu usuari i client davant del següent servidor.

Sistema autònom (AS, Autonomous System): conjunt de xarxes sota una mateixa administració i política d'encaminament, identificat per un ASN (Autonomous System Number).

Operadors i punts d'intercanvi: un ISP (Internet Service Provider, proveïdor de serveis d'Internet) és l'empresa que ven connectivitat —accés a l'usuari final, o trànsit cap a la resta de la xarxa—. S'ordenen en Tier 1 (arriben a tot Internet sense pagar trànsit a ningú), Tier 2 (fan peering, però compren trànsit a un Tier 1) i Tier 3 (només accés final). Els punts neutres d'intercanvi (IXP, Internet eXchange Point) —a Catalunya el CATNIX (CATalunya Neutral Internet eXchange); a Espanya ESPANIX— són la instal·lació neutra on operadors i sistemes autònoms s'intercanvien trànsit directament, reduint costos i latència. ISP i IXP no són el mateix, i el tribunal ho explota: l'ISP et ven el servei; l'IXP és el lloc on els ISP s'interconnecten, i no ven trànsit a ningú. Un acord de peering és, doncs, dues organitzacions que actuen com a ISP i AS intercanviant-se el trànsit típicament sense cost en un IXP —no una cessió d'adreces d'un altre ISP, ni un limitador de cabal, ni un servei de monitoratge—; s'oposa al trànsit (transit), que es paga i dona accés a tot Internet.

Governança: ICANN (Internet Corporation for Assigned Names and Numbers) coordina noms i números; IANA (Internet Assigned Numbers Authority) en fa l'assignació; els RIR (Regional Internet Registry) la reparteixen per continents —RIPE (Réseaux IP Européens) NCC (Network Coordination Centre) a Europa, APNIC (Asia Pacific Network Information Centre) a Àsia-Pacífic, i els seus homòlegs a Amèrica i l'Àfrica—; l'IETF (Internet Engineering Task Force) publica els estàndards com a RFC (Request For Comments).

Adreçament: les adreces IP públiques baixen per la cadena IANA → RIR → LIR/operador → usuari final. L'Ajuntament de Barcelona té adreçament públic sol·licitat al RIPE NCC, amb quota anual de manteniment (assignació PI (Provider Independent)). Per obtenir un rang estable i independent del proveïdor d'accés cal l'estatus de LIR (Local Internet Registry) i després el de sistema autònom (AS): així s'encamina directament amb altres AS per punts neutres com el CATNIX, en lloc de dependre d'un únic operador.

Adreces IPv4 i IPv6: una adreça IPv4 té 32 bits en quatre octets decimals (192.168.1.1); l'espai és d'uns 4.300 milions d'adreces, esgotat a la pràctica per IANA el 2011. IPv6 és la resposta: 128 bits en vuit grups hexadecimals (2001:db8::1), espai pràcticament inesgotable i sense necessitat de NAT (Network Address Translation). Les adreces privades (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) no s'encaminen per Internet i necessiten NAT per sortir-hi; les públiques són úniques al món. Les dues versions conviuen en doble pila (dual stack), que és la migració recomanada. El detall —classes, CIDR (Classless Inter-Domain Routing), subnetting i pla d'adreçament— és a TCP/IP v4 i MPLS.

Encaminament bàsic: un encaminador tria la sortida de cada paquet amb la seva taula d'encaminament, on cada entrada lliga un prefix de destinació amb el següent salt; guanya el prefix més específic, i si cap no encaixa s'aplica la ruta per defecte cap al proveïdor. Dins d'un AS omplen la taula els protocols interiors (IGP, Interior Gateway Protocol: OSPF, Open Shortest Path First; RIP, Routing Information Protocol), que trien pel camí més curt o més ràpid. Entre AS, l'únic protocol exterior (EGP, Exterior Gateway Protocol) d'Internet: BGP (Border Gateway Protocol, RFC 4271), de vector de camí, que anuncia cada prefix amb la llista d'AS travessats —així descarta bucles— i no tria pel camí més ràpid, sinó per política. Els atributs i la millor ruta són a TCP/IP v4 i MPLS.

Intranet: xarxa privada d'una organització que fa servir les mateixes tecnologies que Internet (TCP/IP, HTTP) però amb accés restringit als seus membres. En ser una infraestructura controlada per l'organització —a diferència d'Internet, pública i compartida entre milers d'operadors—, ofereix més predictibilitat de rendiment i funcionament. Es pot estendre entre seus amb túnels IP (VPN, Virtual Private Network) sense deixar de ser privada, i el seu adreçament ha de seguir estant planificat i sense duplicitats.


2. El model de capes

OSI (Open Systems Interconnection) (7 capes) TCP/IP (4 capes) Protocols Unitat
7 Aplicació · 6 Presentació · 5 Sessió Aplicació HTTP, DNS, SMTP (Simple Mail Transfer Protocol), FTP, SSH (Secure Shell), TLS (Transport Layer Security) missatge
4 Transport Transport TCP, UDP (User Datagram Protocol), QUIC segment / datagrama
3 Xarxa Internet IP, ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol), IPsec paquet
2 Enllaç · 1 Física Accés a la xarxa Ethernet, Wi-Fi, PPP (Point-to-Point Protocol) trama / bits

La correlació correcta: les capes 5, 6 i 7 d'OSI (sessió, presentació i aplicació) es corresponen amb la capa d'aplicació de TCP/IP; les capes 1 i 2 (física i enllaç), amb la d'accés a la xarxa; i les capes 3 i 4, una a una amb Internet i transport. Aquesta és la pregunta literal.

TCP vs UDP: TCP és orientat a connexió (encaixada de tres vies SYN, SYN-ACK, ACK), garanteix el lliurament i l'ordre amb confirmacions i retransmissions, i hi afegeix control de flux i de congestió — al preu de més sobrecàrrega. UDP és sense connexió i no garanteix res, però és mínim: per això se l'emporten el DNS, el DHCP (Dynamic Host Configuration Protocol), l'SNMP (Simple Network Management Protocol) i la veu i el vídeo en temps real, on retransmetre arriba tard. QUIC (RFC 9000) és transport xifrat sobre UDP: la base de HTTP/3.


3. Protocols d'aplicació

Protocol Port Funció
HTTP / HTTPS (HyperText Transfer Protocol Secure) 80 / 443 web; HTTP/2 multiplexa sobre TCP i HTTP/3 va sobre QUIC
DNS 53 (UDP i TCP) resolució de noms
SMTP 25, 587 (enviament), 465 (TLS) transferir el correu del client a un servidor i entre servidors; no serveix per descarregar-lo
POP3 (Post Office Protocol) 110, 995 (TLS) descarregar els missatges del servidor al client i tradicionalment esborrar-los del servidor: per a un únic dispositiu, sense sincronització
IMAP (Internet Message Access Protocol) 143, 993 (TLS) accés mantenint el correu al servidor, sincronitzat entre diversos dispositius: és el que cal per consultar-lo des de diversos equips
FTP / SFTP (SSH File Transfer Protocol) 21 / 22 fitxers. FTP és insegur: credencials en clar
SSH 22 accés remot xifrat
DHCP 67/68 configuració automàtica d'adreçament
NTP (Network Time Protocol) 123 hora, crítica per als registres i la signatura
LDAP / LDAPS (LDAP Secure) 389 / 636 serveis de directori
SNMP 161/162 gestió de xarxa → observabilitat
SIP / RTP (Real-time Transport Protocol) 5060/5061 · dinàmic telefonia IP

Mètodes HTTP: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, CONNECT. La llista és tancada, i la trampa recurrent és un verb plausible que no hi és: UPDATE i DOWNLOAD no existeixen. Codis d'estat: 1xx informatiu, 2xx èxit, 3xx redirecció, 4xx error del client (404 no trobat, 403 prohibit, 401 no autenticat) i 5xx error del servidor (500).

SIP (Session Initiation Protocol, RFC 3261): estàndard de l'IETF per establir, gestionar i alliberar sessions, usat en la majoria d'implementacions de ToIP (Telephony over IP). No és un protocol compacte: es defineix per capes —sintaxi, transport, transacció i usuari de transacció— i incorpora serveis de seguretat (autenticació, integritat, xifratge). RTP transporta la veu un cop establerta la sessió. Un desplegament de ToIP combina telèfons IP i softphones, gateways (o mediagateways) cap a la xarxa telefònica tradicional, call servers (centraleta IP), compressors de veu (còdecs) i encriptadors.

Quan la infraestructura IP no arriba. La telefonia IP dona per fet un cablatge estructurat en bon estat, amb PoE (Power over Ethernet) i QoS per prioritzar la veu. Si un edifici no reuneix aquests mínims —típicament els soterranis, on tampoc hi ha cobertura mòbil—, l'alternativa no és renunciar-hi, ni desplegar-hi igualment terminals IP, ni enllaçar per 4G/LTE (Long-Term Evolution): és reaprofitar el cablatge telefònic existent, desplegar-hi telefonia analògica i connectar-la a un mediagateway, que la converteix a IP i la integra a la mateixa centraleta (TS-TIC 2018 pràctica, p. 7 i 27).

Arquitectura del correu electrònic: el MUA (Mail User Agent, el client) lliura el missatge al seu MTA (Mail Transfer Agent) per SMTP; els MTA se'l reenvien entre si, també per SMTP i per tantes xarxes com calgui, fins al domini de destinació, on el MDA (Mail Delivery Agent) el diposita a la bústia. El destinatari hi accedeix al final i ja no amb SMTP, sinó amb POP3 o IMAP. Per això la funció pròpia de SMTP és transportar i reenviar: no xifra enllaços, ni filtra correu maliciós, ni gestiona agendes. La defensa bàsica contra la suplantació del domini són tres registres DNS: SPF (Sender Policy Framework) (RFC 7208: quins servidors poden enviar en nom del domini), DKIM (DomainKeys Identified Mail) (signatura criptogràfica del missatge) i DMARC (Domain-based Message Authentication, Reporting and Conformance) (política i informes que uneixen els dos anteriors).

DHCP (Dynamic Host Configuration Protocol, RFC 2131) evita configurar a mà cada equip: el servidor li cedeix (lease) una adreça per un temps limitat i li lliura també la màscara, la passarel·la per defecte i els servidors DNS —per això una avaria de DHCP es manifesta com «no hi ha Internet» encara que la xarxa funcioni—. La cessió es renova abans de caducar, i a un servidor, una impressora o un telèfon IP se'ls fa una reserva. L'intercanvi DORA (Discover, Offer, Request, Acknowledge) i l'agent de retransmissió per servir diverses VLAN (Virtual Local Area Network) són a TCP/IP v4 i MPLS.


4. El sistema de noms de domini (DNS)

Tradueix noms de domini llegibles per les persones en adreces IP i publica altres metadades del domini.

És una base de dades jeràrquica, distribuïda i replicada, amb delegació d'autoritat i memòria cau a tots els nivells.

4.1 Jerarquia

La jerarquia del DNSL'arrel es delega en els gTLD genèrics i els ccTLD territorials; un ccTLD com .cat es delega en un domini de segon nivell com barcelona.cat, que al seu torn es delega en un subdomini com www.. (arrel)13 conjunts de servidors,replicats per anycastes, cat, fr… (ccTLD)com, org, net… (gTLD)www (subdomini/host)barcelona.catdelegadelega

Nou gTLD: .barcelona és un gTLD de ciutat gestionat per l'Ajuntament, i .cat, el domini de la comunitat lingüística catalana, gestionat per la Fundació puntCAT —el primer TLD (Top-Level Domain) concedit a una comunitat cultural.

Qui gestiona un domini: tres papers que no s'han de barrejar. El registre (registry) opera el TLD i en manté la base de dades autoritativa —la Fundació puntCAT per al .cat, Red.es per al .es, l'Ajuntament per al .barcelona—; el registrador (registrar), acreditat, és l'empresa que ven el domini al públic; i el registrant és el titular. Com que la cadena és pública, la titularitat es pot consultar (§4.4): és la primera comprovació davant d'un web que imita l'estètica corporativa sense ser de l'organització.

4.2 Components

Pas a pas: es demana www.barcelona.cat → el resolutor pregunta al recursiu → si no ho té a la cau, aquest pregunta a un arrel, que el remet al .cat, que el remet als autoritatius de barcelona.cat, que retornen el registre A → el recursiu el desa mentre duri el TTL. Per això abaixar el TTL abans d'una migració fa que el canvi es propagui de seguida.

4.3 Tipus de registre

Registre Contingut
A adreça IPv4
AAAA adreça IPv6
CNAME (Canonical Name) àlies cap a un altre nom
MX servidors de correu, amb prioritat
NS (Name Server) servidors de noms autoritatius de la zona
SOA (Start of Authority) inici d'autoritat: servidor primari, correu de contacte, número de sèrie, temporitzadors
PTR (Pointer) resolució inversa (IP → nom)
TXT text lliure: SPF, DMARC, verificacions de propietat
SRV (Service) localització de serveis (host i port)
CAA (Certification Authority Authorization) quines autoritats de certificació poden emetre certificats per al domini
DNSKEY (DNS Key), RRSIG (Resource Record Signature), DS (Delegation Signer), NSEC/NSEC3 DNSSEC (DNS Security Extensions)

TTL (Time To Live): temps que un registre es pot conservar a la memòria cau.

Transferència de zona: la rèplica de la zona del primari cap als secundaris. AXFR (RFC 5936) en porta la còpia completa; IXFR (RFC 1995) només els canvis posteriors al número de sèrie que el secundari ja té —per a això serveix el número de sèrie del SOA, que s'incrementa cada cop que s'edita la zona—. Les dues s'han de restringir als secundaris autoritzats: una AXFR oberta regala l'inventari sencer de noms interns. (AXFR i IXFR no són inicials de res: són els noms que els RFC donen a aquests tipus de consulta, i per això no s'obren lletra per lletra.)

4.4 Seguretat del DNS

Whois / RDAP (Registration Data Access Protocol) publiquen les dades de registre d'un domini —titular, registrador, dates d'alta i caducitat, servidors de noms—; RDAP és el successor del whois, amb respostes estructurades. La informació és pública i la pot consultar qualsevol: no cal ser registrador ni anar al whois del TLD concret —el del .cat és el de la Fundació puntCAT, però qualsevol servei whois genèric hi arriba igual—. És l'eina per esbrinar qui hi ha al darrere d'un web que aparenta ser de l'organització sense ser-ho (TS-TIC 2021 pràctica, p. 22).


5. Altres components d'Internet

5.1 CDN (Content Delivery Network)

Xarxa de lliurament de contingut: infraestructura distribuïda de servidors que serveix el contingut des del punt més proper a l'usuari.

Punts de presència (PoP): les ubicacions distribuïdes geogràficament on la CDN allotja els seus servidors de vora (edge). La seva funció és emmagatzemar el contingut en memòria cau i servir-lo des del punt més proper a l'usuari final, cosa que redueix la latència, estalvia ample de banda a l'origen i millora la disponibilitat davant pics de demanda. Aquesta —i no «fer còpies de seguretat», ni «crear contingut», ni «fer de tallafocs»— és la resposta que es demana.

Funcions afegides: terminació TLS, compressió, WAF (Web Application Firewall) i protecció anti-DDoS.

5.2 Proxy i proxy invers

El proxy directe (forward proxy) se situa davant dels clients i controla la seva sortida a Internet; el proxy invers (reverse proxy) se situa davant dels servidors i rep les peticions externes i les reenvia als servidors interns, amagant-ne la topologia → arquitectures de seguretat on premise.

5.3 IoT

Internet de les coses: objectes físics amb sensors —que mesuren una magnitud: temperatura, soroll, CO₂, ocupació— i actuadors —que actuen sobre el món físic— connectats a la mateixa xarxa que la resta de serveis. Hi aporta connectivitat i protocols que no són els d'un navegador: LPWAN (Low-Power Wide-Area Network) de llarg abast i baix consum (LoRaWAN, NB (Narrowband)-IoT) o, per a curt abast, Bluetooth LE (Low Energy); i, per als missatges, MQTT (Message Queuing Telemetry Transport)*, l'estàndard de facto, de publicació-subscripció i molt lleuger. L'edge computing*** processa a prop de l'origen per reduir latència i volum cap al núvol.

La ingesta d'aquestes dades a la plataforma municipal —Sentilo— és a arquitectura de dades; la seva publicació, a dades obertes i reutilització.


Claus d'examen

Per recordar

Tema 63

Protocols, estructura i adreçament: TCP/IP v4 i MPLS

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

Enunciat oficial. Protocols, estructura i adreçament: TCP/IP v4 i MPLS.


1. L'estructura: la pila TCP/IP

TCP/IP (Transmission Control Protocol / Internet Protocol) és la família de protocols d'Internet, organitzada en 4 capes; el model OSI (Open Systems Interconnection) en té 7.

Capa TCP/IP Capes OSI Unitat de dades Adreça Protocols
Aplicació 5-7 missatge — HTTP, DNS, SMTP (Simple Mail Transfer Protocol), DHCP
Transport 4 segment (TCP) / datagrama (UDP) port TCP, UDP
Internet 3 paquet adreça IP IP, ICMP, protocols d'encaminament
Accés a la xarxa 1-2 trama adreça MAC Ethernet, Wi-Fi, PPP (Point-to-Point Protocol)

1.1 L'encapsulament

Cada capa afegeix la seva capçalera a les dades que rep de la de sobre i el receptor les retira en ordre invers: una mateixa dada viatja dins d'un segment, dins d'un paquet i dins d'una trama. La targeta de xarxa (NIC, Network Interface Card) és el component d'un ordinador que fa aquest encapsulament als extrems, tant a nivell 2 (Ethernet) com a nivell 3 (IP).

Encapsulació TCP/IP i on va l'etiqueta MPLSCada capa embolcalla la de sobre: baixant, la fila guanya una capçalera per l'esquerra i conserva tot el que ja hi havia. L'etiqueta MPLS va entre la capa 2 i la 3, i el FCS queda al final de la trama.AplicacióTransportInternetEnllaçDades d'aplicacióTCPDadesIPSegmentEthernetMPLSPaquetFCScàrrega útilcapçaleraMPLS (capa 2,5)cua de tramaMPLS: capa 2,5 · el FCS tanca la trama, fora de la càrrega útil

1.2 La trama Ethernet


2. Adreçament IPv4

Adreça IPv4: 32 bits, escrits en quatre octets decimals separats per punts. Es divideix en part de xarxa i part de host, delimitades per la màscara de subxarxa.

2.1 Classes (històric, però encara es pregunta)

Classe Primer octet Màscara per defecte Rang privat (RFC 1918, Request for Comments)
A 1–126 /8 (255.0.0.0) 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
B 128–191 /16 (255.255.0.0) 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
C 192–223 /24 (255.255.255.0) 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)
D 224–239 — multicast
E 240–255 — experimental

Altres rangs especials: 127.0.0.0/8 loopback · 169.254.0.0/16 enllaç local (APIPA, Automatic Private IP Addressing) · 100.64.0.0/10 CGNAT (Carrier-Grade NAT).

Tot el que no cau en un rang privat és públic, i el públic s'assigna: baixa del RIPE (Réseaux IP Européens) NCC (Network Coordination Centre), el registre regional europeu, amb quota anual —la cadena sencera és a arquitectura d'Internet—. El de l'Ajuntament de Barcelona és 212.15.224.0 – 212.15.255.255, i per això l'adreça 212.15.224.5 és pública mentre que 10.x, 172.16-31.x i 192.168.x no ho són mai.

2.2 CIDR i subnetting

CIDR (Classless Inter-Domain Routing) abandona les classes: la màscara s'expressa amb el nombre de bits a 1 (/24).

Prefix Màscara Adreces totals Hosts útils
/23 255.255.254.0 512 510
/24 255.255.255.0 256 254
/26 255.255.255.192 64 62
/28 255.255.255.240 16 14
/30 255.255.255.252 4 2 (enllaços punt a punt)
/31 255.255.255.254 2 2 (punt a punt)

Fórmula: hosts útils = 2^(32−prefix) − 2 (es resten l'adreça de xarxa i l'adreça de difusió).

Per dimensionar es va al revés: el prefix més llarg que encara doni prou hosts. Per a 300 màquines un /24 no arriba i un /23 sí; per a 50, un /26.

Quantes xarxes petites hi caben: un /n conté 2^(m−n) subxarxes /m. Un /19 són 32 xarxes /24 —és a dir, 32 «xarxes de classe C», que és com encara ho pregunta el tribunal—, i una classe C sencera té 256 adreces (254 útils). El mateix compte serveix per llegir un rang: de 212.15.224.0 a 212.15.255.255 el tercer octet pren 32 valors, i cada valor és un /24.

VLSM (Variable Length Subnet Mask): màscares de longitud variable, per assignar a cada subxarxa la mida que necessita.

2.3 Sumarització: com es calcula

Sumarització (supernetting o agregació): substituir diverses xarxes contigües per un únic anunci i reduir la taula d'encaminament. El prefix del resum és el nombre de bits inicials que totes comparteixen.

Exemple amb 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24 i 10.1.4.0/24: els dos primers octets són idèntics (16 bits) i el tercer val 1, 2, 3 i 4, que en binari només comparteixen els 5 bits de l'esquerra. La ruta sumaritzada més petita que les inclou totes és 10.1.0.0/21, de 10.1.0.0 a 10.1.7.255.

De l'exemple surt el que es pregunta: la ruta sumaritzada inclou adreces que no són nostres —també queden incloses i anunciades 10.1.5.0/24, 10.1.6.0/24 i 10.1.7.0/24, si l'enunciat ho permet— i per tant és sempre igual o més gran que la suma de les xarxes. Només surt bé amb un pla jeràrquic, amb les xarxes d'una seu contigües i alineades.

Quan l'enunciat prohibeix incloure subxarxes no llistades, un únic resum ampli no val i cal el prefix més llarg vàlid per a cada grup alineat: 10.22.12.0/23, 10.22.14.0/23, 10.22.16.0/23 i 10.22.18.0/23 no resumeixen en un sol /21 —no comença en un múltiple de 8 al tercer octet—, sinó en dos /22: 10.22.12.0/22 i 10.22.16.0/22.

Encavalcament: dues subxarxes s'encavalquen quan els rangs es toquen (10.1.0.0/16 i 10.1.5.0/24), i l'encaminament es torna imprevisible. La solució no és una ruta: és renumerar una de les dues o, en una fusió d'empreses, aïllar-les amb NAT als dos costats —origen en un tallafocs, destí a l'altre, perquè el problema és simètric.

2.4 La màscara wildcard

Màscara wildcard (o màscara comodí): la inversa bit a bit de la màscara de subxarxa, utilitzada a les llistes de control d'accés (ACL, Access Control List) —a Cisco, access-list ... permit <IP> <wildcard>— i a la configuració d'OSPF (Open Shortest Path First) i EIGRP (Enhanced Interior Gateway Routing Protocol). Un 0 vol dir «aquest bit ha de coincidir exactament» i un 1, «aquest bit és indiferent»: si l'adreça a comprovar coincideix en tots els bits fixats, hi ha match. Càlcul: wildcard = 255.255.255.255 − màscara. Canviar la wildcard sense canviar l'adreça eixampla o redueix el bloc que fa match, encara que l'IP de la sentència sigui la mateixa.

Màscara de subxarxa Wildcard
255.255.255.0 (/24) 0.0.0.255
255.255.0.0 (/16) 0.0.255.255
255.255.255.255 (host) 0.0.0.0
0.0.0.0 (qualsevol) 255.255.255.255

2.5 NAT

NAT (Network Address Translation): el procés que permet que els equips amb adreçament privat surtin a Internet amb una adreça IP pública, traduint les adreces d'origen (i, en el cas de PAT, també els ports) a la sortida i desfent la traducció a l'entrada.

Quan els dos extrems que s'han d'interconnectar tenen rangs privats que se solapen, cap dels dos pot encaminar cap a l'altre sense ambigüitat i no n'hi ha prou de traduir en un costat: cada organització fa NAT de les seves adreces d'origen al seu propi tallafoc, de manera que l'altra les vegi dins d'un rang que no col·lisiona amb el seu. Traduir el destí no resol el solapament de l'origen.

NAT no és un mecanisme de seguretat, encara que dificulti les connexions entrants no sol·licitades.

2.6 IPv6

128 bits, notació hexadecimal en vuit grups. No té NAT ni difusió (usa multicast i anycast). Autoconfiguració SLAAC (StateLess Address AutoConfiguration), i NDP (Neighbor Discovery Protocol) sobre ICMPv6 en lloc d'ARP. Adreces: globals unicast (2000::/3), enllaç local (fe80::/10), úniques locals (fc00::/7) i loopback (::1). Transició: doble pila.

El subnetting en IPv6 no es fa per estalviar adreces, sinó per organitzar, i les mides són fixes: /64 per a tota subxarxa amb hosts —els 64 bits de la dreta són l'identificador d'interfície, i és el que SLAAC necessita—, /48 per a una organització i /56 per a un client domèstic. Un /48 dona 65.536 subxarxes /64, i un /32 d'operador dona 65.536 /48, que es reparteixen pels bits del mig: 2a00:c140:0::/48, 2a00:c140:1::/48…


3. Els protocols de transport

3.1 TCP

TCP (Transmission Control Protocol): orientat a connexió i fiable. Numera els bytes, confirma el que arriba, retransmet el que es perd i els lliura en ordre.

L'establiment de la connexió és el three-way handshake, i és el primer que passa abans de qualsevol dada:

Pas Qui Indicadors Què fa
1 client SYN proposa el seu número de seqüència inicial
2 servidor SYN + ACK l'accepta i proposa el seu
3 client ACK el confirma; la connexió queda establerta

El tancament ordenat en són 4 (FIN, ACK, FIN, ACK) i RST l'avorta de cop. Aporta a més finestra lliscant (control de flux), finestra de congestió amb slow start i suma de comprovació.

3.2 UDP

UDP (User Datagram Protocol): sense connexió i no fiable. Capçalera de 8 bytes —ports, longitud i suma de comprovació— i res més: ni handshake, ni confirmacions, ni ordre. És el que volen la veu i el vídeo en temps real, on retransmetre arriba tard, i les consultes breus (DNS, DHCP, SNMP).

3.3 Els ports

Port: 16 bits que identifiquen l'aplicació dins de la màquina; el parell adreça IP + port és un socket. Els 0-1023 són els ben coneguts (22 SSH (Secure Shell), 53 DNS, 80 HTTP, 443 HTTPS, HTTP Secure), els 1024-49151 els registrats i els 49152-65535 els efímers que tria el client com a port d'origen.

3.4 Protocols auxiliars


4. Commutació de nivell 2

Una LAN commutada es munta amb tants commutadors com calgui als armaris de planta i un sol encaminador de sortida a l'exterior: posar-hi concentradors la deixa d'estar commutada, i un encaminador per armari és sobredimensionar el nivell 3. Si els llocs de treball porten telèfons IP o punts d'accés, el commutador ha de ser PoE (Power over Ethernet), que els alimenta pel mateix cable de xarxa; comptar elements decideix les preguntes d'aquest tipus, perquè un commutador PoE de 24 ports és un aparell i un de normal amb 24 injectors en són 25.

4.1 Com aprèn un commutador

Un commutador aprèn sol, i això explica què fa un equip acabat de treure de la caixa:

  1. Apunta la MAC d'origen de cada trama a la taula MAC (o taula CAM, Content Addressable Memory) amb el port per on ha arribat; l'entrada caduca si no es torna a veure.
  2. Per reenviar mira la MAC de destinació: si la té a la taula, l'envia només per aquell port.
  3. Si no la té —o si és difusió o multidifusió—, inunda la trama per tots els ports menys el d'entrada. És el unknown unicast flooding: un commutador nou, que encara no ha après res, ho reenvia tot a tot arreu.

D'aquí surten els dos dominis: el de col·lisió és cada port del commutador —un concentrador (hub) en té un de sol, i per això hi funciona el sniffer sense més—, i el de difusió és tot el commutador, o cada VLAN si n'hi ha. Només un encaminador, o un dispositiu de capa 3, trenca el de difusió.

A cada salt d'un router es reescriu la trama, no el paquet: com que un router no fa bridging entre les seves interfícies, les MAC d'origen i destinació canvien a cada interfície de sortida per les del nou salt, mentre que les IP d'origen i destinació es mantenen de cap a cap (llevat que hi hagi NAT). Un sniffer connectat entre dos routers només veu, per tant, les MAC d'aquell tram concret, encara que l'IP no hagi canviat.

4.2 VLAN

VLAN (Virtual Local Area Network, 802.1Q): segmentació lògica en dominis de difusió independents, amb trunk etiquetat entre commutadors. Comunicar dues VLAN demana encaminament.

4.3 STP i les seves variants

STP (Spanning Tree Protocol, 802.1D) evita els bucles a les topologies redundants bloquejant lògicament els enllaços sobrers i reactivant-los si cau el camí principal. En una arquitectura en anell de nivell 2 —típica en connectar els elements d'accés d'una seu— l'STP és el que impedeix la tempesta de difusió i el bucle infinit, a costa de tenir enllaços inactius. El va dissenyar Radia Perlman, autora de Interconnections: Bridges and Routers.

Variant Estàndard Arbres Convergència
STP 802.1D 1 per a tot 30-50 s
PVST+ (Per-VLAN Spanning Tree) Cisco 1 per VLAN 30-50 s
RSTP (Rapid Spanning Tree Protocol) 802.1w 1 per a tot segons
RPVST+ (Rapid PVST+) Cisco 1 per VLAN segons
MSTP (Multiple Spanning Tree Protocol) 802.1s 1 per grup de VLAN segons

La tria surt de les dues últimes columnes: RSTP si el que importa és recuperar-se de pressa, PVST+ si el que importa és repartir el trànsit entre VLAN, i RPVST+ quan es volen les dues coses —la variant recomanada als commutadors d'accés d'una seu amb diverses VLAN—.

Si malgrat tot es produeix un bucle de nivell 2, la possibilitat és desconnectar manualment un dels cables LAN (Local Area Network) de coure (RJ45, Registered Jack) redundants que es connecten a l'encaminador —mai el de WAN (Wide Area Network), que no forma part d'aquest domini de difusió— i deixar l'altre per no perdre la connectivitat.

4.4 Agregació d'enllaços

Agregació d'enllaços: diversos enllaços físics es presenten com un de sol, sumant ample de banda i aportant redundància.

Alternatives modernes a l'STP en CPD (Centre de Processament de Dades): stacking, MLAG (Multi-Chassis Link Aggregation Group, o vPC) i teixits de capa 3 amb EVPN (Ethernet VPN) /VXLAN (Virtual eXtensible LAN). Seguretat de port, 802.1X i NAC (Network Access Control) → temes 61 i 64.


5. Encaminament

5.1 Estàtic, dinàmic i distància administrativa

Encaminament estàtic: rutes escrites a mà. La ruta per defecte (0.0.0.0/0, la default gateway) és el cas més habitual i funciona entre fabricants diferents sense negociar res.

L'encaminador tria per prefix més llarg (10.1.1.0/24 guanya 10.0.0.0/8); a igualtat de prefix decideix la distància administrativa, i com més baixa, més fiable.

L'ordre importa i és el parany habitual: l'especificitat es mira abans que el tipus de ruta i que la distància administrativa. Si un equip està dins de 10.1.0.0/16 i un altre dins de 10.1.30.0/24, un ping a 10.1.30.34 va sempre pel /24, encara que el /16 s'hagi après per un camí que semblaria millor. Els codis de la taula d'OSPF només ordenen entre rutes del mateix prefix: O intra-àrea, O IA inter-àrea, i O E1 i O E2 per a les rutes redistribuïdes des de fora del domini OSPF.

Origen Distància administrativa
Connectada directament 0
Estàtica 1
eBGP 20
EIGRP intern 90
OSPF 110
RIP 120
iBGP 200

Redistribució: injectar les rutes d'un protocol dins d'un altre, cosa habitual quan es fusionen dues xarxes amb protocols diferents. Els dos riscos que es pregunten són els bucles d'encaminament —una ruta surt i torna a entrar pel mateix punt— i les rutes subòptimes, perquè les mètriques no es tradueixen entre protocols i cal assignar-ne una de nova. Es filtren amb llistes de prefixos i etiquetes (route tags).

5.2 Els protocols

Protocol Tipus Àmbit Mètrica Notes
RIP (Routing Information Protocol) vector de distància intern (IGP, Interior Gateway Protocol) salts (màx. 15) obsolet
OSPF estat d'enllaç intern (IGP) cost = ample de banda de referència / ample de banda de l'enllaç estàndard obert, àrees, àrea 0 troncal, algorisme Dijkstra (SPF, Shortest Path First)
EIGRP híbrid intern composta (ample de banda, retard) Cisco
BGP vector de camí extern (EGP, Exterior Gateway Protocol) atributs de política el protocol d'Internet; MP (Multiprotocol)-BGP transporta rutes de VPN (Virtual Private Network)

OSPF — el camí que forma per defecte: construeix la topologia completa de l'àrea i calcula amb Dijkstra el camí de cost mínim acumulat, on el cost de cada enllaç és inversament proporcional al seu ample de banda. És a dir, el camí més ràpid en ample de banda, no el de menys salts: aquesta és la diferència essencial amb RIP.

5.3 BGP: atributs i selecció de la millor ruta

BGP (Border Gateway Protocol) és el protocol entre sistemes autònoms. Un AS (Autonomous System) és un conjunt de xarxes amb política d'encaminament única, identificat per un número; eBGP és entre AS diferents i iBGP, dins del mateix. BGP no tria per velocitat: tria per política, i els atributs decideixen en aquest ordre:

Ordre Atribut Guanya Afecta
1 WEIGHT el més alt només l'encaminador local (Cisco)
2 LOCAL_PREF el més alt el trànsit de SORTIDA de tot l'AS
3 Ruta originada localment la pròpia —
4 AS_PATH el més curt el camí, i evita bucles
5 ORIGIN IGP < EGP < incomplet —
6 MED (Multi-Exit Discriminator) el més baix suggereix a l'AS veí per on entrar

Les dues conclusions que cauen: per triar per quin proveïdor SURT el nostre trànsit s'apuja el LOCAL_PREF de les rutes apreses d'aquell proveïdor —és un atribut intern, es propaga per iBGP i no surt de l'AS—, i per influir per on Entra només es pot suggerir, amb MED o allargant l'AS_PATH (prepending), perquè la decisió final és de l'altre.

BGP també és la defensa contra un DDoS volumètric (Distributed Denial of Service): un atac d'aquesta modalitat satura l'enllaç amb l'operador, de manera que qualsevol tallafoc, IPS (Intrusion Prevention System) o gestor d'ample de banda instal·lat a casa arriba tard, perquè el tub ja és ple abans. L'única solució que no consumeix l'ample de banda de sortida és que l'operador atregui el trànsit amb un anunci BGP específic i el netegi aigües amunt abans de lliurar-lo.

A la sortida de show ip bgp, * marca les rutes vàlides i > la millor, l'única que s'instal·la a la taula i s'anuncia als veïns. Una ruta amb el NEXT_HOP inaccessible no és vàlida i no es tria, encara que els atributs siguin millors: és l'error clàssic amb iBGP sense next-hop-self.

5.4 Redundància de la passarel·la

Si la passarel·la per defecte cau, la xarxa queda incomunicada encara que hi hagi un segon encaminador. La solució és que dos encaminadors comparteixin una IP virtual i els equips apuntin a aquesta:

5.5 Multicast

Multidifusió (multicast): un origen envia una sola còpia i la xarxa la duplica només on cal, construint un arbre de distribució cap als receptors. És el que fa falta per a televisió IP, videovigilància —una càmera que envia imatges als ordinadors d'una guàrdia urbana que en vigila els carrers— i difusió de vídeo: amb unidifusió l'origen enviaria una còpia per espectador i saturaria l'enllaç; amb difusió arribaria a qui no l'ha demanada. El grup és una adreça de classe D (224.0.0.0/4).

PIM (Protocol Independent Multicast) és com els encaminadors construeixen l'arbre. IGMP (Internet Group Management Protocol) n'és l'altra meitat: PIM construeix l'arbre entre encaminadors, però qui demana rebre un grup és el receptor, i ho fa amb IGMP contra l'encaminador de la seva xarxa. Sense aquesta senyalització l'arbre no sap fins on ha d'arribar. PIM-SM (Sparse Mode) parteix d'un arbre compartit amb arrel al RP (Rendezvous Point) i pot passar a l'arbre de camí més curt.

5.6 Convergència

Convergència: quan es produeix un tall entre encaminadors, els protocols triguen un temps a convergir —detectar la pèrdua, propagar el canvi, recalcular i instal·lar les rutes noves—, i en aquest interval hi ha pèrdua de trànsit o bucles temporals. Es redueix amb temporitzadors agressius i BFD (Bidirectional Forwarding Detection, fallides en mil·lisegons).


6. MPLS

MPLS (Multiprotocol Label Switching): els paquets es commuten segons una etiqueta de longitud fixa afegida a l'entrada de la xarxa, en lloc de consultar l'adreça IP de destinació a cada salt.

6.1 Conceptes

6.2 Avantatges

Enginyeria de trànsit —dirigir el trànsit per camins concrets, cosa que l'encaminament IP pur no permet—, QoS, VPN de nivell 3 i 2, convergència ràpida i independència del protocol transportat, d'aquí «multiprotocol».

6.3 MPLS L3VPN i MP-BGP

Els operadors combinen MPLS amb MP-BGP per oferir VPN de nivell 3 (L3VPN, Layer 3 VPN) que mantenen separat i aïllat el trànsit i l'adreçament de cada client sobre una infraestructura compartida. El mecanisme:

L2VPN (Layer 2 VPN) sobre MPLS, per transportar trames de nivell 2 en lloc de paquets IP: VPLS (Virtual Private LAN Service) emula un commutador multipunt i fa que diverses seus semblin al mateix segment LAN.

Alternativa actual: SD-WAN, o SD (Software-Defined) WAN, gestiona per programari diversos accessos (MPLS, internet, 5G) amb polítiques per aplicació, i sovint conviu amb MPLS en lloc de substituir-lo.

SR (Segment Routing): evolució del pla de control de MPLS que substitueix LDP i RSVP-TE per etiquetes distribuïdes pel propi protocol d'encaminament, sense estat per flux als nodes intermedis. Simplifica MPLS i facilita el pas cap a un entorn SDN (Software-Defined Networking), amb un controlador centralitzat que programa els camins.


7. Mitjans de transmissió i accessos WAN

7.1 Els mitjans

Mitjà Abast típic Capacitat Quan es tria
Parell trenat (coure, UTP, Unshielded Twisted Pair) 100 m 1-10 Gbit/s cablatge horitzontal fins al lloc de treball
Fibra multimode centenars de metres 10-100 Gbit/s troncals dins d'un edifici o d'un CPD
Fibra monomode desenes de km fins a Tbit/s amb multiplexació entre edificis i entre seus
Radioenllaç quilòmetres, amb visió directa centenars de Mbit/s quan l'obra civil no és viable
Mòbil 4G/5G cobertura de l'operador desenes-centenars de Mbit/s mobilitat i respatller d'accés

La fibra òptica és la resposta quan calen gran ample de banda i distància, i la monomode amb multiplexació arriba als valors més alts.

7.2 Xarxa pròpia o servei contractat

7.3 El càlcul que cau

Es barregen bits i bytes a propòsit: les línies es mesuren en bits per segon i els fitxers en bytes. 1 byte = 8 bits, i temps (s) = bits del fitxer / bits per segon.

I es barregen també els múltiples, que van de mil en mil: kbit/s → Mbit/s → Gbit/s → Tbit/s. Per comparar capacitats es passa tot a la mateixa unitat abans de mirar les xifres: 10.000 kbit/s són només 10 Mbit/s, menys que 100 Mbit/s; i 1.000 Tbit/s és un milió de vegades 1 Gbit/s.

Un fitxer de 7 MB (Megabyte) per una línia de 56 kbit/s: 7 · 8 = 56 Mbit, i 56.000.000 / 56.000 = 1.000 s, uns 17 minuts. Dividir «7 entre 56» i respondre 0,125 s és l'error que busca la pregunta. Per a veu sobre IP es multiplica: un canal amb el còdec G.711 gasta prop de 90 kbit/s amb capçaleres, i 10 trucades simultànies demanen prop d'1 Mbit/s garantit.


8. VPN IPsec

IPsec (Internet Protocol Security) xifra i autentica el trànsit IP, i és la resposta quan es demana confidencialitat i autenticació obligatòries entre seus o en una videoconferència entre organitzacions.

L'alternativa quan l'enllaç entre seus és de nivell 2 —fibra fosca o Ethernet metropolitana— és xifrar-lo a la mateixa capa 2 amb MACsec (802.1AE), que protegeix la trama sencera salt a salt; IPsec xifra el paquet IP i per això travessa qualsevol xarxa encaminada. Com s'aprofiten com a mesura de seguretat és a arquitectures de seguretat on premise; aquí són el transport.


9. QoS

Una xarxa suporta telefonia IP quan compleix dues condicions alhora, no una: ample de banda suficient perquè no es congestioni, i QoS (Quality of Service) perquè, quan es congestioni igualment, la veu passi davant. Ni redundar-la ni acostar les seus hi afegeix res: la redundància dona disponibilitat, no qualitat de la trucada.


10. Anàlisi i diagnòstic

Analitzador de protocols o sniffer: l'aparell o programari que captura els paquets que circulen per la xarxa i en permet l'anàlisi, descodificant els protocols capa per capa. És l'instrument adequat quan cal estudiar els paquets que es transmeten.

Què veu segons on es connecta: en un concentrador, tot, perquè hi ha un sol domini de col·lisió; en un port normal d'un commutador, només el seu propi trànsit, la difusió, la multidifusió i la unidifusió desconeguda, perquè la resta s'entrega només al port de destinació.

Altres eines: ping i traceroute (ICMP), nmap (ports), SNMP (Simple Network Management Protocol) → tema 21.


11. Disseny d'una xarxa corporativa


Claus d'examen


Per recordar

Tema 64

Gestió d'identitats

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. Gestió d'identitats.


1. Conceptes

IAM (Identity and Access Management): conjunt de polítiques, processos i tecnologies que garanteixen que les persones adequades tinguin l'accés adequat als recursos adequats, en el moment adequat i pels motius adequats.

La sigla té dues meitats: la gestió d'identitats, o IdM (Identity Management), s'ocupa de la identitat en si —crear-la, mantenir-la i donar-la de baixa—, i la gestió d'accessos (Access Management) decideix què pot fer un cop autenticada. Al voltant seu, sigles veïnes que no són sinònimes:

Sigla De què s'ocupa La diferència que cal saber dir
IdM el cicle de vida de la identitat i les seves dades és la meitat «identitat» de l'IAM
IAM identitat més autenticació i autorització és l'operació: deixar entrar o no
IGA (Identity Governance and Administration) aprovació, catàleg de rols, certificació d'accessos, segregació de funcions és el control i l'evidència: qui té què i qui ho va aprovar
PAM (Privileged Access Management) els comptes privilegiats no protegeix qualsevol identitat, sinó la que pot fer més mal
CIAM (Customer Identity and Access Management) identitats de clients, no d'empleats prioritza volum, autoservei i consentiment

Les tres A i una quarta:

Pregunta Mecanisme
Identificació qui dius que ets usuari, correu, DNI (Document Nacional d'Identitat)
Autenticació (Authentication) pots demostrar-ho? contrasenya, certificat, biometria, MFA (Multi-Factor Authentication)
Autorització (Authorization) què pots fer? rols, permisos, polítiques
Auditoria / Accounting què has fet? registres, traçabilitat

Factors d'autenticació — el factor és el que permet validar la identitat d'un usuari, i n'hi ha de tres categories:

  1. Alguna cosa que saps (knowledge): contrasenya, PIN (Personal Identification Number), pregunta secreta.
  2. Alguna cosa que tens (possession): targeta criptogràfica, telèfon amb OTP (One-Time Password), clau FIDO2 (Fast IDentity Online 2), certificat.
  3. Alguna cosa que ets (inherence): empremta, rostre, iris, veu.

S'hi afegeixen el lloc on ets i el que fas (biometria de comportament), però els tres clàssics són els que cauen.

Nivells d'assegurament (NIST SP (Special Publication) 800-63, Digital Identity Guidelines) — la sèrie que gradua la confiança en cada una de les tres A, amb 3 nivells cadascun (de menys a més exigent):

MFA / 2FA: combinació de factors de categories diferents. Contrasenya + pregunta secreta no és MFA: són dos factors de la mateixa categoria. Contrasenya + codi al mòbil sí que ho és, i targeta + PIN també —el caixer automàtic és l'exemple clàssic de doble factor.

No tots els segons factors valen igual, de més feble a més robust: SMS (Short Message Service) i trucada —vulnerables a l'intercanvi de SIM (Subscriber Identity Module)—; OTP de temps (TOTP, Time-based One-Time Password), que encara es pot teclejar en una pàgina falsa; notificació d'aprovació al mòbil, exposada a la fatiga d'MFA; i certificat o FIDO2/WebAuthn, els únics resistents a la suplantació de lloc (phishing) perquè la credencial va lligada criptogràficament al domini.

Principis d'autorització:

Models de control d'accés: DAC (Discretionary Access Control, discrecional, el propietari decideix) i MAC (Mandatory Access Control, obligatori, per etiquetes de classificació) són els clàssics; els que cauen a l'examen són RBAC i ABAC:

L'estàndard d'RBAC descriu quatre elements —persones usuàries, rols, permisos i sessions— i tres nivells acumulatius: el model pla, el jeràrquic (un rol n'hereta els permisos d'un altre) i el restringit, que és on viu la segregació de funcions: dos rols incompatibles que la mateixa persona no pot tenir alhora. El seu problema pràctic és l'explosió de rols: quan cada excepció en crea un de nou, el catàleg deixa de ser auditable, i és quan compensa passar a atributs.

Hi ha també PBAC (Policy-Based Access Control) i ReBAC (per relacions), de menys pes a l'examen.


2. El cicle de vida de la identitat

Tres moments, i els noms anglesos amb què apareixen als productes: alta (joiner) → canvis (mover) → baixa (leaver).


3. Serveis de directori

Directori: base de dades jeràrquica optimitzada per a la lectura, que emmagatzema informació d'usuaris, grups, equips i serveis. La comparació que cau: un directori es consulta moltíssim més del que es modifica i s'optimitza per llegir; una base de dades convencional ha de servir bé la lectura i l'escriptura alhora, amb transaccions. I el directori guarda objectes jeràrquics amb atributs, definits per un esquema, no taules relacionades.

X.500 és la sèrie d'estàndards de serveis de directori de l'ITU (International Telecommunication Union), del seu sector ITU-T de normalització. Les dades d'un directori X.500 s'estructuren en un arbre jeràrquic anomenat DIT (Directory Information Tree), en què cada node és una entrada identificada pel seu DN (Distinguished Name), format per la concatenació dels RDN (Relative Distinguished Names) des de l'arrel, i pertany a classes d'objecte que determinen quins atributs pot tenir. Aquesta estructura jeràrquica en arbre és la resposta a la pregunta d'examen: ni relacional, ni documental, ni no estructurada.

Nomenclatura: CN (nom comú), OU (unitat organitzativa), DC (component de domini), O (organització) — CN=Joana Puig,OU=Informatica,DC=bcn,DC=cat.

LDAP (Lightweight Directory Access Protocol, RFC (Request for Comments) 4510 a 4519, i 4511 per al protocol): la simplificació de X.500 que s'usa realment, sobre TCP (Transmission Control Protocol) i IP (Internet Protocol). Del model X.500 —definit en l'àmbit de l'OSI (Open Systems Interconnection)— hereta el DIT, el DN i l'esquema, però l'executa sobre TCP/IP i representa noms i filtres com a cadenes de text en comptes de la codificació ASN.1 (Abstract Syntax Notation One) pura. Tres dades que cauen:

És, a més, el denominador comú del sector: Active Directory, Novell/NetIQ eDirectory i Red Hat Directory Server són de fabricants diferents, però tots exposen LDAP, i és el que els fa interoperables.

Active Directory, o AD (Active Directory) DS (Domain Services): el servei de directori de Microsoft, basat en LDAP i Kerberos, que centralitza la identitat i les polítiques —usuaris, equips, grups— d'una xarxa basada en Windows. El seu magatzem és orientat a objectes, no relacional: l'esquema defineix classes —usuari, grup, equip, unitat organitzativa— i cada objecte n'és una instància amb els seus atributs i relacions; no depèn de cap gestor relacional. Sobre aquest magatzem ofereix alhora autenticació, inici de sessió únic, Kerberos i LDAP. Elements: boscos, arbres i dominis, unitats organitzatives (OU, Organizational Unit), controladors de domini, les directives de grup, o GPO (Group Policy Object), catàleg global i replicació multimestre. No s'ha de confondre amb SCCM (System Center Configuration Manager, avui ECM, Endpoint Configuration Manager): AD gestiona la identitat; SCCM/ECM desplega i inventaria programari i configuracions sobre els equips ja units al domini — és matèria de gestió d'endpoints, no d'identitats.

Kerberos: protocol d'autenticació de xarxa basat en tiquets i en un tercer de confiança (KDC, Key Distribution Center, amb el servei d'autenticació i el servei de concessió de tiquets). Ofereix autenticació mútua i inici de sessió únic. És extremament sensible a la sincronització horària: una desviació superior a 5 minuts per defecte fa fallar l'autenticació — d'aquí la criticitat del NTP (Network Time Protocol).

Altres directoris: OpenLDAP, FreeIPA, Samba AD i Microsoft Entra ID, que no és un AD al núvol: no fa Kerberos ni GPO, sinó protocols web.


4. Federació i protocols moderns

Federació d'identitats: permet que un usuari s'autentiqui al seu proveïdor d'identitat (IdP) i accedeixi a serveis d'altres organitzacions (SP) sense credencials noves.

El flux de federació IdP–SPEl proveïdor de servei no comprova mai la contrasenya: la delega, i el que accepta com a prova és l'assertion que li torna el proveïdor d'identitat.IdPproveïdor d'identitatSPproveïdor de serveiUsuari1. petició2. redirecció3. autenticació4. assertion

Protocol Naturalesa Format Ús típic
SAML 2.0 (Security Assertion Markup Language) autenticació i federació XML (eXtensible Markup Language; assercions signades) SSO web empresarial i entre administracions; intercanvi entre IdP i SP mitjançant assertions d'autenticació, atribut i autorització
OAuth 2.0 autorització delegada, no autenticació JSON (JavaScript Object Notation; JWT habitualment) permetre que una aplicació accedeixi a recursos en nom de l'usuari, mitjançant tokens d'accés amb àmbits (scopes)
OIDC (OpenID Connect) capa d'autenticació sobre OAuth 2.0 JSON / JWT (ID Token) inici de sessió modern a aplicacions web i mòbils
FIDO2 / WebAuthn autenticació sense contrasenya criptografia de clau pública claus de seguretat, biometria del dispositiu, passkeys
SCIM aprovisionament d'usuaris JSON sincronització d'altes i baixes entre sistemes

SAML enfront de JWT — la comparació que cau, i la clau és què defineix cadascun:

Protocols d'autenticació i autorització de xarxa: RADIUS (Remote Authentication Dial-In User Service), TACACS+ (Terminal Access Controller Access-Control System, Plus), 802.1X, Kerberos, LDAP i OAuth. Compte: SMTP (Simple Mail Transfer Protocol) no autentica ni autoritza —és de correu—, i DNS (Domain Name System) tampoc: són les distractores habituals de la pregunta «quin d'aquests no és una opció per a autenticació o autorització».


5. Components d'una solució IAM

Una solució d'IAM no és un producte sinó un conjunt de peces que resolen problemes diferents.

5.1 Inici de sessió únic (SSO)

SSO (Single Sign-On): una sola autenticació dona accés a totes les aplicacions a què la persona ja tingui dret, sense tornar a demanar credencials. El mecanisme és sempre el mateix: qui s'autentica ho fa una vegada davant d'un únic punt —el directori o l'IdP—, que obre una sessió i, a partir d'aquí, emet a cada aplicació una prova d'identitat —un tiquet de Kerberos, una asserció de SAML, un token d'OIDC— que aquella aplicació accepta en comptes de verificar res.

Tres confusions que el tribunal explota:

Modalitats: SSO d'empresa dins del domini (Kerberos), SSO web i SSO federat entre organitzacions. El que costa: concentra el risc —el compromís de l'IdP ho compromet tot, i per això és on s'apliquen l'MFA i les polítiques més dures— i obliga a resoldre el tancament de sessió únic.

5.2 Gestió de l'accés privilegiat (PAM)

PAM (Privileged Access Management): la disciplina que custodia i vigila els comptes que poden fer més mal. És una capa a part, i no un IAM més estricte, perquè aquests comptes no encaixen en el cicle de vida normal: sovint no pertanyen a ningú, no cauen amb una baixa i deixen poca traça.

Què és un compte privilegiat: l'administrador de domini i el local, el root d'Unix, els comptes d'administració d'aplicacions i de bases de dades, els comptes de servei, les claus i secrets de desplegament i els comptes d'emergència (break glass).

Les funcions que es pregunten:

Productes habituals: CyberArk, BeyondTrust, Delinea i HashiCorp Vault.

5.3 La resta de peces

Contrasenyes — recomanacions actuals (NIST SP 800-63B i CCN, Centre Criptològic Nacional): longitud mínima elevada (12-15 caràcters o més) i frases de pas; comprovació contra llistes de contrasenyes compromeses; no forçar la rotació periòdica sense indici de compromís, perquè indueix contrasenyes pitjors; no exigir regles de composició arbitràries; i eliminar les preguntes de seguretat. El destí és l'autenticació sense contrasenya (FIDO2/passkeys).


6. Identitat al sector públic

La frontera d'aquest apartat. La identitat del ciutadà davant l'Administració —sistemes d'identificació i de signatura de la Llei 39/2015, Cl@ve, idCAT, DNIe, apoderaments i funcionari habilitat— és matèria del tema 69; els certificats qualificats i l'EUDI (European Digital Identity) Wallet, del tema 68. Aquí, la identitat corporativa.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 65

Gestió d'incidents de ciberseguretat

Enunciat oficial. Gestió d'Incidents de Ciberseguretat.


1. Conceptes


2. Tipus d'atac i codi maliciós

Codi maliciós (malware), classificat sobretot per la seva capacitat de propagar-se:

DDoS (Distributed Denial of Service, denegació de servei distribuïda): una botnet executa milers de peticions simultànies contra un servei fins a fer-lo inaccessible per a les persones usuàries legítimes. Es diferencia del DoS (Denial of Service, denegació de servei) d'un sol origen precisament per ser distribuït des d'una xarxa de màquines compromeses.

Tècniques d'atac que no són codi maliciós. La majoria d'incidents comencen per una d'aquestes, i el que el tribunal demana és distingir-les entre elles:


3. El cicle de vida segons NIST

NIST SP 800-61 (SP: Special Publication) — Computer Security Incident Handling Guide. Quatre fases, en cicle:

Cicle de vida d'un incident segons NIST SP 800-61Quatre fases que tornen a començar: el que s'aprèn de l'activitat posterior és el que millora la preparació. Dins del cicle, la contenció torna a la detecció quan apareixen indicis nous.si hi ha indicis nous1. Preparació2. Detecció i anàlisi3. Contenció, eradicació i recuperació4. Activitat posterior

  1. Preparació: polítiques i pla de resposta, equip (CSIRT) i rols, eines, formació, inventari d'actius, línies base de comportament normal, canals de comunicació segurs i simulacres. És la fase que més determina l'èxit i la que més s'omet.
  2. Detecció i anàlisi: fonts de detecció (SIEM, EDR, IDS/IPS, usuaris, tercers, CERT), triatge, classificació i priorització, anàlisi de l'abast, documentació i notificació inicial.
  3. Contenció, eradicació i recuperació: contenció a curt termini (aïllar) i a llarg termini (mesures provisionals per continuar operant), eradicació de la causa i dels artefactes, i recuperació dels sistemes a producció amb monitoratge reforçat.
  4. Activitat posterior: lliçons apreses, informe final, actualització de procediments i controls, i mètriques.

Alternativa — el model de SANS (SysAdmin, Audit, Network, and Security): preparació, identificació, contenció, eradicació, recuperació i lliçons apreses (sis fases). És el mateix cicle amb la detecció i la resposta desglossades.


4. El cicle segons ISO/IEC 27035

La norma ISO/IEC 27035 —Gestió d'incidents de seguretat de la informació, publicada per la ISO i la IEC (International Electrotechnical Commission)— estructura la gestió en cinc fases:

  1. Planificar i preparar (Plan and prepare).
  2. Detecció i informe (Detection and reporting).
  3. Avaluació i decisió (Assessment and decision).
  4. Respostes (Responses): contenció, eradicació, recuperació i, si escau, anàlisi forense.
  5. Lliçons apreses (Lessons learnt).

La darrera fase de la gestió d'un incident de seguretat segons la ISO/IEC 27035 és la de lliçons apreses. Aquesta és la resposta literal a la pregunta d'examen. És la fase que tanca el cicle i que alimenta la millora contínua: sense ella, l'organització repeteix el mateix incident.


5. Classificació i priorització

Criteris: impacte (nombre d'usuaris i sistemes afectats, criticitat del servei, dades compromeses, pèrdua econòmica, dany reputacional) i urgència (propagació, finestra d'actuació).

Taxonomia del CCN-CERT i de la Guia Nacional de Notificació i Gestió de Ciberincidents, amb cinc nivells de perillositat: crític, molt alt, alt, mitjà i baix, i una taxonomia de tipus: contingut abusiu, codi maliciós, obtenció d'informació, intent d'intrusió, intrusió, disponibilitat, compromís de la informació, frau, vulnerable i altres.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge): el catàleg més conegut que classifica les tàctiques i tècniques de ciberatac, organitzat en tàctiques (l'objectiu de l'adversari: accés inicial, execució, persistència, escalada de privilegis, evasió de defenses, accés a credencials, descobriment, moviment lateral, recol·lecció, comandament i control, exfiltració, impacte) i tècniques i subtècniques (com ho fa). És la resposta a la pregunta sobre el catàleg de tàctiques i tècniques d'atac.

Altres marcs: Cyber Kill Chain de Lockheed Martin (reconeixement, armament, lliurament, explotació, instal·lació, comandament i control, accions sobre l'objectiu), Diamond Model, CVE (Common Vulnerabilities and Exposures) i CVSS (Common Vulnerability Scoring System: identificació i puntuació de vulnerabilitats), CWE (Common Weakness Enumeration: tipus de debilitat), STIX (Structured Threat Information eXpression) / TAXII (Trusted Automated eXchange of Indicator Information) per a l'intercanvi d'intel·ligència, i TLP (Traffic Light Protocol: semàfor per a la compartició d'informació).


6. Organització de la resposta

La resposta la sostenen dues unitats que es confonen amb facilitat i que convé separar des del principi: el SOC vigila i el CSIRT respon. El SOC és una funció contínua de monitoratge que mira què està passant ara i escala el que sembla un incident; el CSIRT és l'equip que se'n fa càrrec un cop l'incident està declarat i el condueix fins al tancament i les lliçons apreses. En una organització petita les fa la mateixa gent, però són funcions diferents: es pot tenir SOC sense CSIRT (es detecta i ningú no sap què fer després) i CSIRT sense SOC (es respon només quan algú avisa, perquè no hi ha vigilància pròpia).

Primera notificació interna, davant una sospita d'incident: no es fa directament al DPD ni a l'autoritat de control, sinó pels canals interns establerts (per exemple el SAU — Servei d'Atenció a l'Usuari) al servei o rol responsable de seguretat, que avalua i documenta l'incident en un informe per al responsable executiu del tractament afectat. Només si l'avaluació ho confirma intervenen, ja, el DPD i —dins del termini de 72 hores— l'autoritat de control (secció 7).


7. Obligacions de notificació

Aquest és el punt on més es concentra la normativa i les preguntes:

Àmbit Norma A qui Termini
Dades personals RGPD, art. 33 autoritat de control (APDCAT (Autoritat de Protecció de Dades de Catalunya) per a l'Ajuntament de Barcelona) sense dilació indeguda i, de ser possible, en 72 hores des que se'n té constància; si es fa més tard, cal justificar-ne el retard. No cal notificar si és improbable que suposi un risc per als drets i llibertats
Dades personals amb alt risc RGPD, art. 34 als interessats sense dilació indeguda, en llenguatge clar i senzill. No cal si les dades eren inintel·ligibles (xifrades), si s'han pres mesures que eliminen l'alt risc, o si suposa un esforç desproporcionat (llavors, comunicació pública)
Sector públic ENS, art. 33 CCN-CERT segons la categoria i la perillositat, per la plataforma LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas); els incidents de nivell alt, molt alt i crític s'han de notificar
Serveis essencials i digitals RDL 12/2018 (Real Decreto-Ley) i NIS2 (Network and Information Security, Directiva europea 2022/2555) CSIRT de referència i autoritat competent alerta primerenca en 24 hores i notificació en 72 hores amb el règim NIS2
Infraestructures crítiques Llei 8/2011 CNPIC (Centro Nacional de Protección de Infraestructuras Críticas) segons pla
Delicte Codi penal / LECrim Forces i Cossos de Seguretat, Ministeri Fiscal quan escaigui

L'obligació de notificar del sector públic no neix aquí: és l'Esquema Nacional de Seguretat qui la imposa, amb la categoria del sistema i la perillositat de l'incident com a criteris i amb la seva Instrucció Tècnica de Seguretat de notificació d'incidents com a detall. Aquest tema en descriu el procediment de resposta; el marc normatiu que l'obliga és allà.

El responsable ha de DOCUMENTAR totes les violacions de seguretat, les notifiqui o no, amb els fets, els efectes i les mesures correctores (RGPD, art. 33.5). Aquest registre és el que l'autoritat demanarà primer.

Contingut mínim de la notificació (RGPD, art. 33.3): naturalesa de la violació i, si és possible, categories i nombre aproximat d'interessats i de registres afectats; dades de contacte del DPD; conseqüències probables; i mesures adoptades o propostes, incloent-hi les de mitigació.

Escenari d'examen: es produeix un incident de ciberseguretat que afecta dades personals i pot suposar un risc per als drets i llibertats. La resposta correcta és notificar-ho a l'autoritat de control en un màxim de 72 hores i, si el risc és alt, comunicar-ho també als interessats sense dilació indeguda, a més de documentar-ho internament.


8. Anàlisi forense i lliçons apreses

8.1 Anàlisi forense

Objectiu: determinar què ha passat, com, quan, qui i quin ha estat l'abast, preservant les evidències amb valor probatori.

Principis:

Eines: Autopsy/Sleuth Kit, FTK (Forensic Toolkit), EnCase, Volatility (memòria), Wireshark, Velociraptor, KAPE (Kroll Artifact Parser and Extractor), plaso/log2timeline.

8.2 Lliçons apreses

És la fase que tanca el cicle en els dos models —la quarta del NIST i la cinquena i última de la ISO/IEC 27035— i la que més sovint s'omet, perquè arriba quan el servei ja torna a funcionar i sembla que no queda feina. Es materialitza en dues coses: una reunió de revisió posterior a l'incident, convocada dies després del tancament i no mesos, amb tots els rols que hi van intervenir; i un informe final que respon sempre les mateixes preguntes.

El resultat útil no és el document: és el canvi als controls, als procediments i a la formació, i les mètriques que permeten comprovar que la millora existeix —MTTD (Mean Time To Detect, temps mitjà de detecció), MTTR (Mean Time To Respond, temps mitjà de resposta o de contenció), nombre d'incidents per categoria i percentatge d'incidents reincidents—. Un incident que torna amb la mateixa causa arrel és la prova que aquesta fase no s'ha fet.


9. Prevenció i intel·ligència d'amenaces

Tot el que hi ha en aquest apartat actua abans que hi hagi incident, i per tant s'ordena amb el risc: el risc és el marc previ i l'incident és el risc materialitzat. La identificació, l'avaluació i el tractament del risc —i els registres i propietaris que en resulten— es desenvolupen a gestió del risc en ITIL v4; aquí, les mesures concretes de prevenció i intel·ligència.

  1. Atacs deliberats — programari maliciós, accés no autoritzat, abús de privilegis.
  2. Compromís i/o pèrdua d'informació — publicació d'informació o credencials; informació extraviada.
  3. Saturació i/o pèrdua de serveis essencials — sistemes inhabilitats o saturats.
  4. Coacció, extorsió o corrupció — persuasió il·legítima, intimidació, suborn.
  5. Informació errònia o corrupta — contingut mal organitzat o no vàlid.

Dues cauteles. És un top 5 d'un catàleg més gran —remet al Catàleg d'amenaces de l'Agència—, així que una amenaça absent no és falsa per això; i l'ordre canvia amb el període: al 2S del 2020 encapçalava el compromís i/o pèrdua d'informació. «Quina encapçala» exigeix saber el període.


10. Marc de referència

NIST CSF 2.0 (Cybersecurity Framework 2.0), amb sis funcions: GOVERN (Govern), IDENTIFICAR, PROTEGIR, DETECTAR, RESPONDRE i RECUPERAR. La funció Govern és la novetat de la versió 2.0.

NIST SP 800-184 — guia de recuperació davant esdeveniments de ciberseguretat.

ISO/IEC 27001 i 27002 (sistema de gestió i controls de seguretat de la informació), ISO/IEC 27035 (gestió d'incidents, apartat 4) i ISO/IEC 27037 (identificació, recollida i preservació de l'evidència digital, apartat 8) són les normes de la família que aquest tema desenvolupa.

La ISO 22301 (continuïtat de negoci) no: aquí només s'anomena, perquè la recuperació posterior a un incident greu s'emmarca en el pla de continuïtat, que es desenvolupa a DRP i BCP.


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 66

L'Esquema Nacional de Seguretat (ENS)

Enunciat oficial. L'Esquema Nacional de Seguretat (E.N.S).

Norma: ENS — Reial decret 311/2022, de 3 de maig, pel qual es regula l'Esquema Nacional de Seguretat. Substitueix el RD (Reial Decret) 3/2010. Habilitació legal: Llei 40/2015, art. 156.


1. Objecte i àmbit

Objecte (ENS, art. 1): establir la política de seguretat en la utilització de mitjans electrònics en l'àmbit de la Llei 40/2015, i està constituït pels principis bàsics i requisits mínims que garanteixin adequadament la seguretat de la informació tractada i dels serveis prestats, per assegurar l'accés, la confidencialitat, la integritat, la traçabilitat, l'autenticitat, la disponibilitat i la conservació de les dades, informacions i serveis utilitzats en mitjans electrònics.

Àmbit (ENS, art. 2): totes les administracions públiques —AGE (Administració General de l'Estat), comunitats autònomes i entitats locals— i el sector públic institucional; és a dir, tot el sector públic. I, a més, els proveïdors i els sistemes de les entitats del sector privat que prestin serveis o proveeixin solucions al sector públic, que n'han d'acreditar la conformitat.

Tres límits de l'àmbit que el tribunal converteix en distractors: no hi ha cap llindar de població que eximeixi un ajuntament; la ciutadania no hi està mai subjecta; i una empresa privada no queda obligada per tractar dades sensibles —això és el RGPD— sinó per prestar servei a l'Administració. Queden fora els sistemes que tracten informació classificada, regits per la seva normativa específica (ENS, art. 3).

Les dimensions de la seguretat són cinc: confidencialitat, integritat, traçabilitat, autenticitat i disponibilitat (C, I, T, A, D). L'article 1 esmenta a més l'accés i la conservació entre les garanties de l'esquema, però no són dimensions valorables: no reben nivell i no compten per fixar la categoria.

Pregunta d'examen: quan es demana quin concepte correspon a una de les dimensions de seguretat que estableix l'ENS, la resposta és una d'aquestes: disponibilitat, autenticitat, integritat, confidencialitat o traçabilitat. No ho són la «resiliència», la «privadesa», la «no-repudi» com a tal ni la «robustesa».


2. Els principis bàsics (ENS, art. 5 a ENS, art. 11)

Són sis, no set. L'art. 5 els enumera i els articles 6 a 11 els desenvolupen, un per article. Els requisits mínims i la proporcionalitat no hi són: van a l'apartat 3, i confondre'ls és el que fa fallar la pregunta de «quin dels següents és un principi bàsic».

  1. La seguretat com un procés integral (ENS, art. 6): està constituïda per tots els elements humans, materials, tècnics, jurídics i organitzatius; es concedirà la màxima importància al personal i s'evitaran actuacions puntuals o tractaments conjunturals.
  2. Gestió de la seguretat basada en els riscos (ENS, art. 7): l'anàlisi i gestió de riscos és part essencial del procés de seguretat i s'ha de mantenir permanentment actualitzada.
  3. Prevenció, detecció, resposta i conservació (ENS, art. 8): les mesures han de garantir la prevenció d'incidents, la seva detecció, la resposta i la recuperació, i la conservació de la informació.
  4. Existència de línies de defensa (ENS, art. 9): estratègia de protecció en profunditat, amb múltiples capes, de manera que quan una es vegi compromesa n'hi hagi una altra que permeti guanyar temps, reduir la probabilitat i reaccionar.
  5. Vigilància contínua i reavaluació periòdica (ENS, art. 10): permet detectar activitats anòmales i mesurar l'evolució de l'estat de seguretat.
  6. Diferenciació de responsabilitats (ENS, art. 11): s'han de diferenciar el responsable de la informació, el responsable del servei, el responsable de la seguretat i el responsable del sistema.

La regla de segregació, i la seva excepció (ENS, art. 13.3): la regla general és que el responsable de la seguretat ha de ser distint del responsable del sistema, sense dependència jeràrquica entre tots dos. Però la incompatibilitat no és absoluta: en situacions excepcionals en què la manca justificada de recursos ho exigeixi, les dues funcions poden recaure en la mateixa persona —o en persones amb relació jeràrquica— sempre que s'apliquin mesures compensatòries que en garanteixin la finalitat, documentades a la Declaració d'Aplicabilitat.

Respondre «mai, sota cap concepte» és el distractor, no la norma. I una dependència jeràrquica del responsable del sistema cap al de seguretat no preserva el principi: és justament el que l'article vol evitar.

Compte amb la norma que cita l'enunciat. Sota el RD 3/2010 (art. 10, «funció diferenciada») la parella que s'havia de separar era responsable del servei i responsable de la seguretat; sota el RD 311/2022 la parella exigida és seguretat i sistema.


3. Els requisits mínims (ENS, art. 12)

La política de seguretat s'ha d'establir d'acord amb quinze requisits mínims. No són principis: són el que cal fer per complir-los, i els articles 13 a 27 en desenvolupen un cadascun.

a) Organització i implantació del procés de seguretat b) Anàlisi i gestió dels riscos c) Gestió de personal d) Professionalitat e) Autorització i control dels accessos f) Protecció de les instal·lacions g) Adquisició de productes de seguretat i contractació de serveis de seguretat h) Mínim privilegi i) Integritat i actualització del sistema j) Protecció de la informació emmagatzemada i en trànsit k) Prevenció davant altres sistemes d'informació interconnectats l) Registre d'activitat i detecció de codi maliciós m) Incidents de seguretat n) Continuïtat de l'activitat o) Millora contínua del procés de seguretat

Els requisits mínims s'han de satisfer sempre, i el criteri per aplicar-los és la proporcionalitat: es despleguen segons la categoria del sistema i el nivell de cada dimensió, de manera que l'esforç sigui proporcional al perjudici que caldria evitar (ENS, art. 28, «compliment dels requisits mínims»).


4. La política de seguretat i els rols

Política de seguretat de la informació (ENS, art. 12 i annex III): és el document de més alt nivell que estableix el conjunt de directrius que regeixen la manera en què una organització gestiona i protegeix la informació i els serveis. Ha de ser aprovada per l'òrgan superior competent —al món local, el Ple o l'òrgan de govern— i ha de contenir:

Els quatre rols (ENS, art. 11, el principi, i ENS, art. 13, l'organització del procés de seguretat):

Rol Responsabilitat
Responsable de la informació determina els requisits de la informació tractada: en fixa els nivells de seguretat en cada dimensió
Responsable del servei determina els requisits dels serveis prestats: en fixa els nivells de seguretat
Responsable de la seguretat determina les decisions per satisfer els requisits de seguretat de la informació i dels serveis; supervisa la implantació de les mesures, monitora l'estat de seguretat i promou la formació. Ha de ser distint del responsable del sistema, tret de l'excepció de l'art. 13.3
Responsable del sistema desenvolupa la forma concreta d'implementar la seguretat al sistema i en supervisa l'operació diària; pot acordar la suspensió del maneig d'informació o la prestació d'un servei si detecta deficiències greus

Qui proposa i qui aprova: el responsable de la informació i el del servei fixen requisits (què cal protegir i amb quin nivell); el responsable de la seguretat decideix i proposa les mesures que els satisfan —també les físiques, com el control d'accés a les instal·lacions, als llocs de treball i als sistemes centrals—; el responsable del sistema les implanta. Dins l'organització TIC (Tecnologies de la Informació i la Comunicació), aquesta funció recau en una àrea de seguretat diferenciada de les àrees d'operacions, de serveis generals i de suport a persones usuàries: aquestes executen, l'àrea de seguretat defineix i proposa.

Comitè de seguretat de la informació: òrgan col·legiat que coordina la seguretat entre les diferents àrees, resol conflictes de requisits i eleva les decisions a l'òrgan de govern.

El DPD (delegat de protecció de dades) (RGPD) no és el responsable de la seguretat de l'ENS: són figures diferents i complementàries, encara que han de col·laborar estretament. El DPD supervisa el compliment de la protecció de dades; no decideix les mesures de seguretat ni n'assumeix la responsabilitat.

4.1 La jerarquia normativa: d'objectius a procediments

De les dimensions de seguretat (els objectius, resumides de vegades amb l'acrònim CIA (Confidencialitat, Integritat i Disponibilitat)) es deriva la política de seguretat; d'aquesta, la normativa; i d'aquesta, els procediments i els plans que la porten al dia a dia. És la mateixa jerarquia que estructura el marc organitzatiu de l'annex II (ENS, annex II, apartat 3):

Jerarquia normativa de la seguretat: d'objectius a procedimentsQuatre nivells, cadascun concretant l'anterior: els objectius o dimensions de seguretat, la política de seguretat aprovada per l'òrgan superior competent, la normativa que en regula l'ús correcte, i els procediments i el procés d'autorització que diuen com fer cada tasca i qui l'autoritza.Objectius(dimensions deseguretat)Política de seguretat — org.1Normativa de seguretat — org.2Procediments i plans — org.3 / org.4


5. Categorització dels sistemes (ENS, art. 40 i annex I)

5.1 Els nivells de les dimensions

Per a cada dimensió (confidencialitat, integritat, traçabilitat, autenticitat i disponibilitat) s'assigna un nivell: BAIX, MITJÀ o ALT, segons el perjudici que causaria un incident:

Si una dimensió no es veu afectada, no rep nivell.

5.2 La categoria del sistema

La categoria del sistema es determina a partir de la valoració de les dimensions de seguretat, amb aquesta regla:

És la dimensió més exigent la que arrossega tot el sistema. Aquesta és la regla que es pregunta.

La categoria determina quines mesures de l'annex II són exigibles i amb quin reforç.


6. Les mesures de seguretat (annex II)

Les mesures es divideixen en tres grups — pregunta literal i repetida (2023 i 2025):

Grup Codi Contingut
Marc organitzatiu org conjunt de mesures relacionades amb l'organització global de la seguretat; en són quatre: política de seguretat, normativa de seguretat, procediments de seguretat i procés d'autorització
Marc operacional op mesures per protegir l'operació del sistema com a conjunt integral de components per a un fi: planificació, control d'accés, explotació, recursos externs, serveis al núvol, continuïtat i monitoratge
Mesures de protecció mp mesures que se centren a protegir actius concrets segons la seva naturalesa i la qualitat exigida

Subgrups del marc operacional (op): op.pl planificació · op.acc control d'accés · op.exp explotació · op.ext recursos externs · op.nub serveis al núvol · op.cont continuïtat del servei · op.mon monitoratge del sistema.

Subgrups de les mesures de protecció (mp): mp.if instal·lacions i infraestructures · mp.per gestió del personal · mp.eq equips · mp.com comunicacions · mp.si suports d'informació · mp.sw aplicacions informàtiques · mp.info informació · mp.s serveis.

Aplicació de les mesures: cada mesura indica per a quina categoria és exigible (n.a. no aplicable, aplica, = igual que el nivell anterior, + reforç, ++ reforç addicional) i, en algunes, en funció del nivell de la dimensió afectada. També hi ha mesures de reforç (R) al final de cada mesura.

L'exigència creix amb el nivell, i és gradual. El cas que ha caigut és el mecanisme d'autenticació (op.acc.5): a categoria BÀSICA pot bastar un sol factor —una contrasenya robusta—, i és a partir del nivell MITJÀ que cal un segon factor, reforç que es manté a ALT. Com més amunt la categoria, més exigència, mai menys.

Perfils de compliment específics (ENS, art. 30): permeten adaptar l'ENS a col·lectius o tipus d'entitat. N'hi ha per a entitats locals de població reduïda, per a serveis al núvol i per a altres sectors. Simplifiquen la implantació sense reduir la seguretat exigible.

La contractació pública i les empreses licitadores (ENS, art. 2.3): els plecs dels contractes del sector públic han d'incloure els requisits per assegurar la conformitat amb l'ENS dels sistemes dels contractistes —com la presentació de la Declaració o Certificació de Conformitat—, i aquesta cautela s'estén a la cadena de subministrament d'aquests contractistes segons ho justifiqui l'anàlisi de riscos. És la mesura op.ext.3, protecció de la cadena de subministrament (exigible només a categoria ALTA): estimar el risc que introdueix un proveïdor extern i preveure'l al pla de continuïtat.

Aquesta obligació contractual no s'ha de confondre amb la LCSP (Llei de Contractes del Sector Públic): la LCSP regula el procediment de licitació → tema 3; l'ENS hi afegeix l'exigència de seguretat al proveïdor. I dins d'un procediment de concurs, la fase de recepció d'ofertes és, ella mateixa, un tractament d'informació: noms de persones licitadores i les seves qualificacions, rebuts abans de l'obertura pública, comprometen la confidencialitat —no la integritat (que no es modifiquin), ni la disponibilitat (que s'hi pugui accedir), ni la traçabilitat (qui hi ha accedit)—, perquè el que està en joc és que no es coneguin abans d'hora.


7. Auditoria de la seguretat (ENS, art. 31 i annex III)

Regla que es pregunta literalment:

Declaració i certificació de conformitat (ENS, art. 38 i Instrucció tècnica de seguretat de conformitat):


8. Altres previsions


9. Relació amb altres marcs


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 67

El Reglament General de Protecció de Dades (RGPD)

Enunciat oficial. El Reglament General de Protecció de Dades (RGPD).

Conceptes, principis, bases de licitud, drets i obligacions es desenvolupen al tema 16.2 del bloc comú, que cal estudiar sencer. Aquí s'hi afegeix la vessant tècnica i institucional, i el que ha caigut a les proves específiques.


1. Marc i estructura


2. Definicions clau (art. 4)

El tema 16.2 del bloc comú ja desenvolupa les definicions de l'RGPD, art. 4 més corrents —dada personal, tractament, responsable, encarregat, pseudonimització, perfils—; aquí, les que hi falten i han caigut a examen:

I les tres categories especials que l'RGPD, art. 9 prohibeix tractar però no defineix: les defineix l'art. 4, i és d'aquí que se'n pregunta la lletra.


3. Autoritats de control

**Definició del <abbr title="RGPD, art. 51.

Característiques que estableix el RGPD:

A Espanya i a Catalunya:

Autoritat Àmbit
AEPD (Agència Espanyola de Protecció de Dades) estatal, administració independent; competent amb caràcter general
APDCAT (Autoritat de Protecció de Dades de Catalunya) institucions públiques de Catalunya, Administració de la Generalitat, ens locals catalans i entitats que en depenen. És la competent per a l'Ajuntament de Barcelona
AVPD (Agencia Vasca de Protección de Datos) i CTPDA (Consejo de Transparencia y Protección de Datos de Andalucía) equivalents al País Basc i a Andalusia
CEPD (Comitè Europeu de Protecció de Dades) / EDPB (European Data Protection Board) garanteix l'aplicació coherent del RGPD i resol conflictes entre autoritats
SEPD (Supervisor Europeu de Protecció de Dades) / EDPS (European Data Protection Supervisor) supervisa les institucions de la UE

4. El DPD (delegat de protecció de dades)

Obligatorietat (RGPD, art. 37): sempre que el tractament el faci una autoritat o organisme públic, llevat dels tribunals en l'exercici de la funció judicial —independentment de la mida—; també quan l'activitat principal exigeixi una observació habitual i sistemàtica a gran escala o el tractament a gran escala de categories especials de dades.

Designació (RGPD, art. 37.5 a .7): es tria atenent a les qualitats professionals i als coneixements especialitzats del dret i la pràctica en protecció de dades, sense exigir titulació concreta. Pot ser intern o extern indistintament: el reglament admet que formi part de la plantilla del responsable o de l'encarregat o que exerceixi les funcions en el marc d'un contracte de serveis —sí que hi entra, precisament per deixar les dues portes obertes—. Les dades de contacte s'han de publicar i comunicar a l'autoritat de control.

Posició i garanties (RGPD, art. 38): ha de participar de manera adequada i oportuna en totes les qüestions de protecció de dades; no rep instruccions sobre l'exercici de les seves funcions ni pot ser destituït o sancionat per exercir-les; rendeix comptes directament al més alt nivell jeràrquic del responsable o l'encarregat.

Punt de contacte dels interessats (RGPD, art. 38.4): les persones interessades es poden dirigir al DPD per a totes les qüestions relatives al tractament de les seves dades i a l'exercici dels seus drets. Si algú considera que la seva sol·licitud d'accés, rectificació, oblit, limitació o oposició no s'ha atès correctament, s'adreça al DPD, no al responsable (que a l'Ajuntament és l'Alcaldia) ni directament a l'APDCAT.

Funcions (RGPD, art. 39): informar i assessorar el responsable, l'encarregat i el personal; supervisar el compliment del Reglament; assessorar sobre l'AIPD i supervisar-ne l'execució; cooperar amb l'autoritat de control i actuar-hi com a punt de contacte. El DPD no és el responsable del tractament: assessora i supervisa, però no n'assumeix la responsabilitat.


5. Les avaluacions d'impacte (AIPD/DPIA — Data Protection Impact Assessment)

El nom fidel —el del reglament, l'AEPD i l'APDCAT— és avaluació d'impacte relativa a la protecció de dades; l'abreujada «d'impacte de protecció de dades» circula, però no és la de la norma.

Quan és obligatòria (RGPD, art. 35): quan sigui probable que un tipus de tractament, en particular si utilitza noves tecnologies, comporti un alt risc per als drets i llibertats de les persones físiques, tenint en compte la naturalesa, l'abast, el context i les finalitats. També quan el tractament figuri a la llista que publica l'autoritat de control, o quan el responsable decideixi fer-la discrecionalment arran d'una anàlisi de riscos prèvia.

En tot cas és necessària quan hi ha:

a) avaluació sistemàtica i exhaustiva d'aspectes personals basada en tractament automatitzat, inclosa l'elaboració de perfils, sobre la qual es basin decisions que produeixin efectes jurídics o afectin significativament de manera similar; b) tractament a gran escala de categories especials de dades (RGPD, art. 9) o de dades relatives a condemnes i infraccions penals; c) observació sistemàtica a gran escala d'una zona d'accés públic.

El moment: abans del tractament i com més aviat possible dins del disseny, perquè les conclusions es puguin incorporar. Tres formulacions equivalents del mateix: prèviament a l'inici del tractament, prèviament a la inscripció al registre d'activitats i amb caràcter d'auditoria prèvia. Feta amb el sistema ja en marxa, arriba quan ja no es pot canviar res.

Contingut mínim (RGPD, art. 35.7), quatre punts: descripció sistemàtica de les operacions i les finalitats; avaluació de la necessitat i la proporcionalitat; avaluació dels riscos per als drets i llibertats; i mesures previstes per afrontar-los, amb les garanties i els mecanismes que demostrin la conformitat.

Requisits del procediment: cal l'assessorament del DPD, es pot recollir l'opinió dels interessats i cal revisar-la quan canviï el risc. Un alt risc residual que el responsable no pugui mitigar obliga a la consulta prèvia a l'autoritat de control (RGPD, art. 36), que respon en vuit setmanes (prorrogables sis més).

Decisió d'AIPD i consulta prèviaDues decisions en cadena. La segona només es planteja si l'AIPD deixa un risc alt que no s'ha pogut mitigar: la consulta prèvia no és un tràmit d'inici, és el que queda quan la mitigació no ha arribat.AIPD (fase de disseny)Tractament d'alt risc?Consulta prèvia8+6 setmanesFiFiRisc residual alt?SíNoSíNo

Llistes i eines: l'APDCAT i l'AEPD publiquen cadascuna la seva llista de tractaments que requereixen AIPD i eines de suport —Gestiona EIPD (Evaluaciones de Impacto en Protección de Datos) i Facilita, de l'AEPD.

Determinació estimativa de l'impacte: ni el <abbr title="RGPD, art. 51.


6. Responsable i encarregat

La distinció fonamental:

El proveïdor de serveis TIC (Tecnologies de la Informació i la Comunicació) —el que allotja, manté o desenvolupa— és normalment encarregat; l'Administració, responsable, i la responsabilitat davant l'interessat i davant l'autoritat continua sent seva.

A l'Ajuntament de Barcelona (Instrucció de protecció de dades GM_2019_17437): el responsable és l'Alcaldia; cada tractament del Registre de Tractaments té assignada una gerència designada responsable executiva, que és qui el crea i en garanteix el compliment ordinari i qui designa els referents de protecció de dades de la unitat; i el DPD ho supervisa amb independència. Els papers no s'acumulen: el DPD no pot ser alhora responsable —seria jutge i part—, i que una gerència executi el tractament no desplaça la responsabilitat de l'Alcaldia.

El contracte de l'RGPD, art. 28 és obligatori i per escrit (o en forma electrònica) i fixa l'objecte, la durada, la naturalesa i la finalitat del tractament, el tipus de dades, les categories d'interessats i les obligacions i drets del responsable. L'encarregat s'hi compromet, com a mínim, a tractar les dades únicament seguint instruccions documentades, a garantir-ne la confidencialitat, a adoptar les mesures de seguretat de l'RGPD, art. 32, a no subcontractar sense autorització prèvia, a assistir el responsable en els drets dels interessats i en la seguretat, les bretxes, l'AIPD i la consulta prèvia, a suprimir o retornar dades i còpies en acabar, i a permetre'n les auditories.

Subcontractació a un tercer (RGPD, art. 28.2 i .4): cal l'autorització prèvia (específica o general) del responsable, un contracte d'encàrrec amb el subencarregat que li imposi les mateixes obligacions, i que aquest ofereixi garanties suficients de seguretat. El consentiment de la persona interessada no és un requisit: la relació és entre responsable, encarregat i subencarregat, i la persona titular hi és aliena.

Responsables conjunts (RGPD, art. 26): quan dos o més determinen conjuntament finalitats i mitjans, i han de repartir-se les responsabilitats de manera transparent. I si l'encarregat arriba a determinar-les pel seu compte, es converteix en responsable (RGPD, art. 28.10) i respon com a tal.


7. Seguretat i bretxes

Violació de la seguretat de les dades personals (RGPD, art. 4.12): tota violació de la seguretat que ocasioni la destrucció, pèrdua o alteració accidental o il·lícita de dades personals, o bé la comunicació o l'accés no autoritzats a aquestes dades.

Incident i violació no són sinònims, i la relació va en un sol sentit, de gènere a espècie: un incident de seguretat és qualsevol esdeveniment que afecti la seguretat de la informació —una caiguda del servei, una intrusió sense dades personals—, i la violació (o bretxa) és el subconjunt d'incidents en què s'han compromès dades de caràcter personal. No cal que hi hagi fuga: n'hi ha prou amb la pèrdua de disponibilitat. Només les violacions disparen els deures de notificació que segueixen.


8. Règim sancionador

Multes administratives (RGPD, art. 83):

A Espanya, les administracions públiques no reben multa (LOPDGDD, art. 77): l'autoritat dicta una resolució que declara la infracció amb les mesures i el termini per esmenar-la, la notifica al responsable i al seu superior jeràrquic, la comunica al Defensor del Poble o al Síndic de Greuges, la publica al butlletí oficial i pot proposar actuacions disciplinàries.

Prescripció (LOPDGDD, art. 72–LOPDGDD, art. 74): infraccions molt greus 3 anys, greus 2 anys, lleus 1 any.


9. Punts de contacte amb la vessant tècnica


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 68

Certificats digitals i autenticació electrònica

Enunciat oficial. Certificats digitals i autentificació electrònica. eIDAS 2.0, idCAT, T-CAT.


1. Fonaments criptogràfics

Criptografia simètrica: la mateixa clau xifra i desxifra. Ràpida i eficient per a grans volums. Algorismes: AES (Advanced Encryption Standard; 128/192/256), ChaCha20; obsolets: DES, 3DES, RC4 (Rivest Cipher 4). Problema: la distribució de la clau.

Criptografia asimètrica o de clau pública: parell de claus matemàticament relacionades —clau privada (secreta, només la té el titular) i clau pública (que es pot difondre)—. El que es xifra amb una només es pot desxifrar amb l'altra. Algorismes: RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography)/ECDSA (Elliptic Curve Digital Signature Algorithm)/EdDSA, Diffie-Hellman (intercanvi de claus). És molt més lenta que la simètrica.

Les dues aplicacions oposades —cal no confondre-les:

Objectiu Es xifra amb Es desxifra amb Garanteix
Confidencialitat la clau PÚBLICA del destinatari la clau privada del destinatari només ell pot llegir-ho
Signatura electrònica la clau PRIVADA del signant la clau pública del signant autenticitat, integritat i no-repudi

El tipus de xifratge que s'utilitza principalment en la signatura electrònica per garantir l'autenticitat del signant és el CRIPTOGRAFIA ASIMÈTRICA o DE CLAU PÚBLICA: el signant xifra amb la seva clau privada el resum del document, i qualsevol pot verificar-ho amb la seva clau pública. Com que només ell té la clau privada, queda acreditat que ha estat ell. Aquesta és la resposta a la pregunta d'examen.

Funció resum (hash): funció unidireccional que produeix una empremta de longitud fixa d'un missatge. Propietats: resistència a la preimatge i a col·lisions. SHA-2 (SHA-256, SHA-384, SHA-512) i SHA-3 són els vigents; MD5 (Message Digest 5) i SHA-1 estan trencats i no s'han d'usar.

Com funciona realment una signatura: es calcula el hash del document, es xifra el hash amb la clau privada del signant (això és la signatura) i s'adjunta al document juntament amb el certificat. El verificador recalcula el hash, desxifra la signatura amb la clau pública i compara. Si coincideixen: el document no s'ha alterat i l'ha signat el titular de la clau.

Signatura i verificació amb clau asimètricaEl signant resumeix el document en un hash i el xifra amb la seva clau privada: això és la signatura. El verificador la desxifra amb la clau pública del signant i compara el resultat amb el hash que ell mateix ha recalculat.SignantVerificadorcompara amb el hashrecalculatdesxifra amb clauPÚBLICA del signantDocumentHashSignaturaxifra amb clauPRIVADA del signant

Criptografia híbrida: el que fan realment TLS (Transport Layer Security) i S/MIME (Multipurpose Internet Mail Extensions) — asimètrica per acordar una clau de sessió, i simètrica per xifrar les dades.

Criptografia postquàntica, PQC (Post-Quantum Cryptography): els algorismes asimètrics actuals seran trencables per ordinadors quàntics. El NIST ha estandarditzat ML-KEM (Kyber), ML-DSA (Dilithium) i SLH-DSA (SPHINCS+) —SLH (Stateless Hash-Based), DSA (Digital Signature Algorithm)—. Risc actual: «recol·lecta ara, desxifra després».


2. Certificats digitals i PKI

Certificat digital: document electrònic signat per una autoritat de certificació que vincula una clau pública amb la identitat del seu titular, i que en garanteix l'autenticitat.

Estàndard: X.509 v3. Contingut: versió, número de sèrie, algorisme de signatura, emissor (CA), període de validesa, subjecte (titular), clau pública, extensions (ús de la clau, noms alternatius, punts de distribució de CRL (Certificate Revocation List), accés OCSP (Online Certificate Status Protocol), polítiques) i signatura de la CA.

PKI (Public Key Infrastructure) — components:

Component Funció
AC (Autoritat de Certificació) / CA (Certification Authority) emet, renova i revoca els certificats; és l'arrel de confiança
AR (Autoritat de Registre) / RA (Registration Authority) verifica la identitat del sol·licitant abans de l'emissió. És el punt on es fa la comprovació presencial o equivalent
Repositori publica certificats i llistes de revocació
VA / Autoritat de Validació comprova en temps real la vigència d'un certificat
Jerarquia de confiança CA arrel (fora de línia i molt protegida) → CA subordinades → certificats finals
HSM (Hardware Security Module) mòdul de maquinari que custodia les claus privades sense que en surtin mai

Revocació: CRL (llista publicada periòdicament) i OCSP (consulta en temps real, amb OCSP stapling per eficiència). Un certificat es revoca per compromís de la clau, canvi de dades o cessament del vincle.

Serveis de validació: a Catalunya, el PSIS (Plataforma de Serveis d'Identificació i Signatura) / Validador del Consorci AOC (Administració Oberta de Catalunya) és el servei que permet a les administracions validar certificats i signatures de múltiples prestadors sense haver d'integrar-los un a un. És la resposta quan es demana un servei de validació de certificats i signatures de confiança. A l'Estat, la plataforma @firma i Valide.

Autenticar-se amb un certificat, no només signar: un certificat també és el mecanisme habitual per autenticar-se davant un servidor, típicament amb TLS mutu: en la negociació, el client demostra que posseeix la clau privada corresponent al certificat que presenta, sense signar cap document. És així com un navegador amb el DNIe o un certificat instal·lat identifica l'usuari davant una seu electrònica.

Autenticar ≠ signar: autenticar-se prova qui ets en el moment de la connexió —una prova efímera, lligada a la sessió—; signar genera una evidència permanent, vinculada a un document concret, amb valor probatori i no-repudi. Per això molts certificats (com el DNIe) separen la clau d'autenticació de la clau de signatura: la primera es fa servir amb poca fricció; la segona exigeix un control més estricte en cada ús perquè les seves conseqüències jurídiques són majors.


3. eIDAS: el marc jurídic europeu

eIDAS — Reglament (UE) 910/2014 (UE: Unió Europea), relatiu a la identificació electrònica i els serveis de confiança per a les transaccions electròniques al mercat interior. És l'estàndard europeu que regula la identificació electrònica i els serveis de confiança en sistemes TIC, i és la resposta a la pregunta d'examen sobre quin estàndard europeu ho regula.

Dos blocs:

  1. Identificació electrònica (eID): reconeixement mutu obligatori entre estats membres dels sistemes d'identificació notificats de nivell Substancial o Alt. Tres nivells de seguretat, els criteris dels quals fixa el Reglament d'execució (UE) 2015/1502:
Nivell El que el distingeix
Baix verificació d'identitat feble; un sol factor d'autenticació
Substancial verificació robusta (presencial o equivalent); dos factors d'autenticació, o un de sol amb protecció addicional
Alt verificació presencial o amb document d'identitat electrònic; dispositiu criptogràfic amb protecció contra la duplicació
2. Serveis de confiança: signatura electrònica, segell electrònic, segell de temps, lliurament electrònic certificat, autenticació de llocs web i preservació. Poden ser qualificats o no qualificats; els qualificats els presta un prestador qualificat de serveis de confiança, un QTSP (Qualified Trust Service Provider), supervisat i inclòs a la llista de confiança (Trusted List), i gaudeixen de presumpció legal.

Obligacions del prestador qualificat i règim del certificat qualificat (arts. 20, 24 i 28 eIDAS):

Els tres nivells de signatura electrònica — pregunta segura:

Nivell Definició Efecte
Signatura electrònica simple dades en format electrònic annexes a altres dades electròniques o associades de manera lògica amb elles, que el signant utilitza per signar no se li poden negar efectes jurídics només per ser electrònica
Signatura electrònica AVANÇADA compleix quatre requisits: a) està vinculada al signant de manera única; b) permet la identificació del signant; c) s'ha creat utilitzant dades que el signant pot utilitzar, amb un alt nivell de confiança, sota el seu control exclusiu; d) està vinculada amb les dades signades de manera que qualsevol modificació ulterior sigui detectable admissible; no té presumpció plena
Signatura electrònica QUALIFICADA signatura avançada creada mitjançant un dispositiu qualificat de creació de signatura, un QSCD (Qualified Signature Creation Device), i basada en un certificat qualificat de signatura té l'efecte jurídic EQUIVALENT a la signatura manuscrita i es reconeix en tots els estats membres

Signatura vs segell: la signatura electrònica és de persones físiques; el segell electrònic és de persones jurídiques i garanteix l'origen i la integritat del document. L'Administració fa servir el segell d'òrgan per a l'actuació automatitzada (Llei 40/2015, art. 42).

Formats de signatura: CAdES (binari, sobre CMS, Cryptographic Message Syntax), XAdES (XML, eXtensible Markup Language), PAdES (PDF) i ASiC (contenidor). Perfils de longevitat: -T (amb segell de temps), -LT (Long Term, amb la informació de validació) i -LTA (Long Term Archive) o -A (arxiu, amb segells encadenats) → tema 44.

Segell de temps qualificat: acredita la data i l'hora i gaudeix de presumpció d'exactitud i d'integritat de les dades en aquell instant.


4. eIDAS 2 i la cartera europea d'identitat digital

eIDAS 2 — Reglament (UE) 2024/1183, que modifica el 910/2014 i estableix el marc europeu d'identitat digital.

La novetat central és l'EUDI Wallet (European Digital Identity Wallet): la cartera d'identitat digital europea que cada estat membre ha d'oferir als seus ciutadans, residents i empreses, de manera gratuïta i voluntària, i que ha de permetre:

El reglament que incorpora el concepte d'EUDI (European Union Digital Identity) i que proporciona a la ciutadania de la Unió una cartera d'identitat digital és eIDAS 2, el Reglament (UE) 2024/1183. Aquesta és la resposta literal a la pregunta d'examen.

Obligacions: els estats han d'oferir la cartera; els serveis privats de sectors regulats (banca, transport, energia, telecomunicacions, plataformes molt grans) han d'acceptar-la quan es requereixi autenticació forta del client. Terminis d'aplicació escalonats.

Altres serveis de confiança nous que hi afegeix eIDAS 2 (no existien al 910/2014 original): atestacions electròniques d'atributs, qualificades o no —diplomes, permisos, partides de naixement en format electrònic verificable—, i registres electrònics qualificats (llibres majors), que estableixen una presumpció legal d'ordre cronològic i integritat de les dades. El marc d'arquitectura i referència, l'ARF (Architecture and Reference Framework), en defineix la implementació tècnica de la cartera. Els certificats qualificats d'autenticació de llocs web, o QWAC (Qualified Website Authentication Certificate), en canvi, ja existien al Reglament de 2014 (art. 3.39 i 45-47); eIDAS 2 no els crea, només ajusta el seu règim.


5. idCAT, T-CAT i els prestadors qualificats

Els sistemes concrets d'identificació i signatura del ciutadà —Cl@ve, el DNIe, el certificat de la FNMT (Fábrica Nacional de Moneda y Timbre), idCAT Mòbil— i el seu ús en el procediment administratiu (quan cal identificar-se, quan cal signar, l'actuació automatitzada amb segell d'òrgan o CSV (Codi Segur de Verificació)) es desenvolupen als temes Sistemes d'identificació i signatura electrònica del ciutadà i Administració electrònica i serveis digitals. Aquí, el fonament tècnic que aquells apliquen, i els dos sistemes que l'enunciat d'aquest tema anomena expressament.

Sistema Què és Nivell
idCAT certificat digital qualificat de ciutadà emès pel Consorci AOC com a entitat de registre del CATCert / Agència Catalana de Certificació, avui integrada a l'AOC. Certificat de programari, per a identificació i signatura qualificat
T-CAT certificat qualificat del PERSONAL al servei de les administracions públiques catalanes, en targeta criptogràfica amb el seu lector; identifica la persona i el seu vincle amb l'organització i el càrrec qualificat, en dispositiu segur
T-CAT P la variant en programari (fitxer), sense targeta qualificat

Prestadors qualificats a Catalunya i Espanya: Consorci AOC (idCAT, T-CAT), FNMT-RCM (Real Casa de la Moneda), ANF AC, Camerfirma, Firmaprofesional, Izenpe, Uanataca.

Marc normatiu espanyol: la Llei 6/2020, reguladora de determinats aspectes dels serveis electrònics de confiança, complementa eIDAS a Espanya. La Llei 59/2003 de signatura electrònica va quedar derogada en la major part.


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 69

Sistemes d'identificació i signatura electrònica del ciutadà

Sense esquema, expressament

Enunciat oficial. Sistemes de identificació i signatura electrònica per part del ciutadà davant la administració. Nivells de identificació.

Els fonaments criptogràfics, els certificats, la PKI (Public Key Infrastructure) i el detall d'eIDAS són al tema 68. Aquí es tracta l'aplicació concreta a la relació del ciutadà amb l'Administració.


1. La distinció fonamental: identificació ≠ signatura

Aquest és el nucli del tema i la pregunta que es repeteix a cada convocatòria.

Identificació Signatura
Què acredita qui ets la teva voluntat sobre un contingut concret
Article Llei 39/2015, art. 9 Llei 39/2015, art. 10 i Llei 39/2015, art. 11
Quan cal per a tota actuació davant l'Administració només per als actes de voluntat de l'art. 11.2
Analogia ensenyar el DNI (Document Nacional d'Identitat) signar el paper

Llei 39/2015, art. 11.2 — els casos en què SÍ que cal signatura:

«Con carácter general, para realizar cualquier actuación prevista en el procedimiento administrativo, será suficiente con que los interesados acrediten previamente su identidad a través de cualquiera de los medios de identificación previstos en esta Ley. Las Administraciones Públicas sólo requerirán a los interesados el uso obligatorio de firma para: a) Formular solicitudes. b) Presentar declaraciones responsables o comunicaciones. c) Interponer recursos. d) Desistir de acciones. e) Renunciar a derechos.»

Cinc supòsits, i cap més. Per a tot el que no hi sigui —consultar l'estat d'un expedient, accedir a la carpeta ciutadana, aportar documentació complementària a un expedient ja iniciat, formular al·legacions dins d'un tràmit obert, obtenir una còpia— n'hi ha prou amb la identificació.

Formulació de la pregunta d'examen: «per quin tipus d'actuacions del procediment administratiu NO requereixen les administracions públiques l'ús obligatori de signatura?» → totes les que no siguin sol·licituds, declaracions responsables o comunicacions, recursos, desistiments i renúncies.

Regla mnemotècnica: la signatura només cal quan inicies, impugnes o renuncies.


2. Sistemes d'identificació admesos (Llei 39/2015, art. 9)

Les administracions han de verificar la identitat dels interessats mitjançant la comprovació del nom i cognoms o denominació o raó social, segons consti al DNI, NIE (Número d'Identitat d'Estranger) o document equivalent.

Sistemes admesos:

a) Sistemes basats en certificats electrònics qualificats de SIGNATURA electrònica expedits per prestadors inclosos a la «Llista de confiança de prestadors de serveis de certificació» — el cas del DNIe, l'idCAT o el certificat de la FNMT (Fábrica Nacional de Moneda y Timbre). b) Sistemes basats en certificats electrònics qualificats de SEGELL electrònic — per a persones jurídiques i entitats sense personalitat. c) Sistemes de CLAU CONCERTADA i qualsevol altre sistema que les administracions considerin vàlid, en els termes i condicions que s'estableixin, sempre que comptin amb un REGISTRE PREVI com a usuari que permeti garantir la seva identitat, amb comunicació prèvia a la Secretaria General d'Administració Digital (declaració responsable de compliment i dos mesos d'espera abans d'entrar en vigor).

El punt clau de la lletra c) és el registre previ: el que dona valor a un sistema de clau concertada com Cl@ve PIN (Personal Identification Number) o idCAT Mòbil és que la identitat s'ha verificat abans, presencialment o per un mitjà equivalent.

Principi: els sistemes d'identificació admesos per a la signatura serveixen també per a la identificació (Llei 39/2015, art. 10.2). El revers no és cert: no tot sistema d'identificació serveix per signar.

Interoperabilitat amb l'AGE (Llei 39/2015, art. 9.4): l'acceptació d'un d'aquests sistemes per l'AGE (Administració General de l'Estat) serveix per acreditar la identificació electrònica de l'interessat davant totes les administracions públiques, salvant prova en contra. Per això Cl@ve —acceptat per l'AGE— val per fer tràmits amb qualsevol administració, i no només amb la que el va emetre.


3. Sistemes de signatura admesos (Llei 39/2015, art. 10)

Principi general (art. 10.1) —la formulació literal que ha caigut a examen: «els interessats podran signar a través de qualsevol mitjà que permeti acreditar l'autenticitat de l'expressió de la seva voluntat i consentiment, així com la integritat i la inalterabilitat del document». Els distractors habituals hi afegeixen una exigència d'exclusivitat («emesos exclusivament per l'administració») que la llei no fa.

Concreció (art. 10.2) —els sistemes que es consideren vàlids a efectes de signatura quan la relació és electrònica:

a) Sistemes de signatura electrònica qualificada i avançada basats en certificats electrònics qualificats de signatura expedits per prestadors de la llista de confiança. b) Sistemes de segell electrònic qualificat i de segell avançat basats en certificats qualificats de segell. c) Qualsevol altre sistema que les administracions considerin vàlid, en els termes i condicions que s'estableixin, sempre que compti amb un registre previ com a usuari que permeti garantir la seva identitat, amb comunicació prèvia a la SGAD (Secretaria General d'Administració Digital).

Signatura no criptogràfica amb valor jurídic: la lletra c) empara els sistemes de signatura amb clau concertada (per exemple, signar amb Cl@ve o amb idCAT Mòbil), en què el que acredita la voluntat és la combinació d'identificació prèvia registrada, autenticació en el moment i evidència d'acceptació conservada per l'Administració.

Signatura biomètrica o manuscrita digitalitzada: s'usa en atenció presencial (tauletes de signatura). Ha de complir els requisits de la signatura avançada —vincle únic amb el signant, control exclusiu i detecció de modificacions— i el tractament de dades biomètriques és de categoria especial (RGPD, art. 9), amb les exigències que això comporta.


4. Els nivells d'identificació

Marc europeu — eIDAS: els sistemes d'identificació electrònica notificats es classifiquen en tres nivells de seguretat, definits pel Reglament d'execució (UE) 2015/1502 (UE: Unió Europea):

Nivell Grau de confiança Requisits
BAIX grau limitat de confiança en la identitat declarada redueix el risc d'ús indegut o alteració de la identitat; verificació d'identitat feble; un sol factor
SUBSTANCIAL grau substancial redueix substancialment el risc; verificació d'identitat robusta (presencial o equivalent) i autenticació de dos factors, o un factor amb protecció addicional
ALT grau alt impedeix l'ús indegut o l'alteració de la identitat; verificació presencial o amb document d'identitat electrònic, i dispositiu criptogràfic amb protecció contra la duplicació

Cada nivell s'avalua sobre quatre elements: inscripció (sol·licitud, verificació de la identitat), gestió del mitjà d'identificació (característiques, emissió, lliurament, activació, suspensió, renovació), autenticació i gestió i organització del prestador.

Reconeixement mutu: un estat membre està obligat a reconèixer els mitjans d'identificació notificats d'un altre estat quan siguin de nivell igual o superior al que exigeix per als seus propis serveis en línia del sector públic, sempre que aquest nivell sigui substancial o alt.

Correspondència pràctica:

Sistema Nivell
Usuari i contrasenya simple sense registre presencial baix
Cl@ve PIN, Cl@ve Permanent, idCAT Mòbil substancial
DNIe, certificat qualificat en dispositiu segur, T-CAT alt

Correspondència amb l'ENS: la mesura op.acc.5 mecanisme d'autenticació exigeix, segons la categoria del sistema, requisits creixents; a categoria ALTA cal doble factor i no n'hi ha prou amb contrasenya. La categoria del servei determina, doncs, el nivell d'identificació exigible al ciutadà.

Principi de proporcionalitat: s'ha d'exigir el nivell adequat al risc del tràmit, ni més ni menys. Exigir certificat qualificat per consultar l'estat d'un expedient és una barrera injustificada; acceptar usuari i contrasenya per a una declaració tributària, una temeritat.


5. Assistència, representació i habilitació


6. Els sistemes disponibles per al ciutadà

Sistema Naturalesa Ús
DNIe 3.0/4.0 certificat qualificat en xip, amb doble interfície NFC (Near Field Communication) contactless (permet fer-lo servir amb el mòbil sense lector) identificació i signatura, nivell alt
Certificat FNMT de persona física certificat qualificat de programari identificació i signatura
Cl@ve PIN clau concertada d'un sol ús, amb registre previ identificació i signatura per a molts tràmits
Cl@ve Permanent usuari i contrasenya amb registre previ i reforç OTP (One-Time Password) ídem
idCAT certificat qualificat del Consorci AOC identificació i signatura
idCAT Mòbil clau concertada per SMS (Short Message Service) amb registre previ el més usat a Catalunya per la seva senzillesa
EUDI (European Union Digital Identity) Wallet cartera europea d'identitat digital (eIDAS 2) futur: identificació, atributs i signatura qualificada gratuïta → tema 68

Obtenció: el registre previ es fa presencialment a una oficina de registre (OAC (Oficina d'Atenció al Ciutadà), oficines de la Generalitat, de la Seguretat Social o de l'AEAT (Agència Estatal d'Administració Tributària)), amb vídeoidentificació o amb un certificat que ja es tingui.

El detall criptogràfic del DNIe —l'algorisme de hash, el xifrat simètric i asimètric, la derivació de claus de sessió— és de tema 68; aquí només què és i per a què serveix.


7. Bretxa digital i garanties


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 70

Arquitectures de seguretat on-premise

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

Enunciat oficial. Arquitectures de seguretat on-premise.


1. Principis de disseny

1.1 Tipologia de mesures segons el moment d'actuació

La ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 27002:2022 classifica cada control per tipus, segons quan actua respecte de l'incident: preventiu (l'evita), detectiu (l'identifica) i correctiu (el repara després). L'examen fa servir una versió ampliada amb dos matisos intermedis:

Tipus Moment Exemple
Preventiva abans, evita l'incident controlar els accessos i les autenticacions
Reductiva abans, limita l'impacte per endavant executar còpies de seguretat periòdiques
Detectiva durant, l'identifica programari de detecció de virus
Repressiva durant, l'atura en curs bloquejar temporalment una adreça de xarxa
Correctiva després, el repara restaurar des d'una còpia de seguretat

2. El model perimetral clàssic

El model perimetral clàssicUna cadena de capes entre Internet i la xarxa interna. El model dona per fet que el perill és a fora, que és exactament el que li retreu el model de confiança zero.DMZ: web, correu, DNSextern, proxy inversTallafoc internInternetIPS / Filtratge web / ProxyTallafoc perimetral / NGFWEncaminador defrontera + antiDDoSXarxa internasegmentació per zones: usuaris ·servidors · gestió · IoT/OT · convidats

Zones de seguretat: externa (Internet), DMZ (Demilitarized Zone, zona desmilitaritzada; serveis publicats, mai amb dades sensibles), interna (usuaris i servidors), zona de gestió (fora de banda, sense sortida a Internet) i zones especials (IoT, industrial/OT (Operational Technology, tecnologia operacional), convidats, laboratori).

La DMZ és el patró fonamental: una xarxa perimetral que s'ubica entre la intranet i Internet, allotja els serveis accessibles des de l'exterior i està separada tant d'Internet com de la xarxa interna per controls, de manera que un compromís d'un servei publicat no dona accés directe a la xarxa interna.

S'hi entra pels dos costats. Les connexions a la DMZ estan permeses tant des d'Internet com des de la intranet, i totes dues es controlen i supervisen mitjançant tallafocs. Els servidors publicats van dins de la DMZ, no en una xarxa a continuació: posar-los darrere seria deixar-los a la xarxa interna, que és justament el que la DMZ evita.

Límit del model: el perímetre s'ha dissolt —núvol, mobilitat, teletreball, proveïdors—. D'aquí el Zero Trust (secció 6).


3. Controls de xarxa

3.1 Tallafocs

Generació Capacitat
Filtratge de paquets regles per IP (Internet Protocol), port i protocol; sense estat
Amb estat (stateful) segueix l'estat de les connexions
Passarel·la d'aplicació (proxy) inspecciona el protocol d'aplicació
NGFW (Next-Generation Firewall) identificació d'aplicacions independentment del port, identitat d'usuari, IPS integrat, inspecció TLS (Transport Layer Security), filtratge d'URL (Uniform Resource Locator) i antimalware, i intel·ligència d'amenaces
WAF (Web Application Firewall) específic per a aplicacions web: protecció contra OWASP (Open Web Application Security Project) Top 10 (injecció, XSS (Cross-Site Scripting, substituint la X per «Cross»), etc.)

Regles: denegació per defecte al final, ordre significatiu, documentació de cada regla amb propietari i justificació, i revisió periòdica per eliminar regles obsoletes —la font més freqüent de forats.

3.2 IDS i IPS

3.3 Proxies

3.4 Segmentació

3.5 Accés remot


4. Seguretat de sistemes i dades


5. Detecció i resposta

L'arquitectura descrita alimenta aquesta capa amb els seus registres i controls (§4); els rols, l'organització i l'operativa de detecció i resposta es desenvolupen al tema 65.


6. Zero Trust

NIST SP (Special Publication) 800-207 — Zero Trust Architecture. Premissa: no es concedeix confiança implícita a cap actiu o compte d'usuari basant-se únicament en la seva ubicació física o de xarxa ni en la propietat de l'actiu.

Els set principis del NIST:

  1. Totes les fonts de dades i serveis de còmput es consideren recursos.
  2. Tota la comunicació és segura, independentment de la ubicació de la xarxa.
  3. L'accés a recursos individuals es concedeix per sessió.
  4. L'accés es determina mitjançant polítiques dinàmiques, incloent-hi l'estat observable de la identitat, l'aplicació i l'actiu sol·licitant, i pot incloure altres atributs de comportament i d'entorn.
  5. L'organització monitora i mesura la integritat i la postura de seguretat de tots els actius propis i associats.
  6. L'autenticació i l'autorització de recursos són dinàmiques i s'apliquen estrictament ABANS de permetre l'accés.
  7. L'organització recull tanta informació com pot sobre l'estat actual dels actius, la infraestructura i les comunicacions, i la utilitza per millorar la seva postura.

Components lògics: PDP (punt de decisió de política, amb el motor de polítiques i l'administrador de polítiques) i PEP (Policy Enforcement Point, punt d'aplicació de la política).

Implicació pràctica: es passa de «si ets dins de la xarxa, ets de confiança» a «cada petició s'autentica, s'autoritza i es xifra, i la confiança es reavalua contínuament». La identitat és el nou perímetre → tema 64.


7. Arquitectura i sector públic


Claus d'examen


Per recordar

Fonts d'aquest tema

Tema 71

Arquitectures de seguretat al Cloud

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

Enunciat oficial. Arquitectures de seguretat al Cloud.


1. El model de responsabilitat compartida

Principi rector de tota la seguretat al núvol: la responsabilitat es reparteix entre proveïdor i client segons el model de servei.

IaaS PaaS SaaS
Dades i classificació client client client
Identitats i accessos client client client
Configuració de l'aplicació client client client
Aplicació client client proveïdor
Sistema operatiu i middleware client proveïdor proveïdor
Virtualització, servidors, xarxa, CPD (Centre de Procés de Dades) proveïdor proveïdor proveïdor

Model de responsabilitat compartidaTres columnes IaaS, PaaS i SaaS. La franja de client creix de baix cap a dalt segons el model; la franja de proveïdor ocupa la resta.IaaSPaaSSaaS0255075100Model de serveiPart de la pila que gestiona cadascú (%)proveïdorclientclient: dades, identitats, config · proveïdor: infraestructura, i el que no és del client

Regla: el proveïdor és responsable de la seguretat DEL núvol; el client, de la seguretat EN el núvol. En tots els models, les dades, les identitats i la configuració són sempre del client, i la responsabilitat jurídica com a responsable del tractament no es delega mai (RGPD).

Conseqüència pràctica: la causa número u dels incidents al núvol no és una vulnerabilitat del proveïdor, sinó la configuració incorrecta del client —cubells d'emmagatzematge públics, grups de seguretat oberts, claus a repositoris, permisos excessius.


2. Els quatre C

Model de seguretat en capes concèntriques per a aplicacions natives al núvol: Cloud → Cluster → Container → Code. La capa Cloud és la que aquest tema desenvolupa (apartats 3 a 7: identitat, dades, xarxa, eines i operació); les capes Cluster, Container i Code —pròpies de l'orquestració de contenidors— es desenvolupen a tic/aplicaciones-nativas-en-la-nube, apartat 6.


3. Identitat: el nou perímetre


4. Protecció de les dades


5. Seguretat de la xarxa al núvol


6. Les categories d'eines de seguretat al núvol

Aquest és el bloc de sigles que cau a l'examen:

Sigla Nom Què fa
CASB Cloud Access Security Broker punt de control situat entre els usuaris i els serveis al núvol que dona visibilitat sobre quins serveis s'utilitzen realment —inclòs el shadow IT (Information Technology)—, aplica les polítiques de seguretat i de compliment corporatives sobre l'ús d'aplicacions SaaS, protegeix les dades (DLP, xifratge, control de compartició) i detecta amenaces i comportaments anòmals
CSPM Cloud Security Posture Management detecta i corregeix configuracions incorrectes i desviacions de compliment a la infraestructura del núvol
CWPP Cloud Workload Protection Platform protecció de càrregues de treball: màquines virtuals, contenidors i funcions
CIEM Cloud Infrastructure Entitlement Management gestió i reducció de permisos excessius
CNAPP Cloud-Native Application Protection Platform plataforma que integra CSPM + CWPP + CIEM i seguretat del codi
SASE Secure Access Service Edge convergència de xarxa (SD: Software-Defined; WAN: Wide Area Network; juntes, SD-WAN) i seguretat com a servei (SWG, CASB, ZTNA, FWaaS) al núvol
SSE Security Service Edge la part de seguretat del SASE, sense la xarxa
ZTNA Zero Trust Network Access accés a l'aplicació concreta, no a la xarxa; substitueix la VPN
SWG Secure Web Gateway proxy de sortida al núvol

Els avantatges principals d'un CASB —la pregunta d'examen: proporcionar visibilitat i control centralitzats sobre l'ús dels serveis al núvol per part de l'organització, incloent-hi la detecció del shadow IT (aplicacions SaaS usades sense aprovació), l'aplicació uniforme de les polítiques de seguretat i de protecció de dades sobre múltiples serveis SaaS, i la detecció d'usos anòmals o de risc. És exactament la resposta quan l'escenari diu que cal millorar la visibilitat i el control sobre l'ús que fan les persones usuàries de les aplicacions i els serveis al núvol.

Els quatre pilars del CASB: visibilitat, compliment, seguretat de les dades i protecció davant amenaces.

Modes de desplegament del CASB: API (Application Programming Interface; fora de banda, sobre el servei SaaS, sense afectar el trànsit), proxy directe (a l'endpoint o a la xarxa) i proxy invers (per a dispositius no gestionats, integrat amb l'IdP).


7. Operació segura


8. Compliment al sector públic


9. Errors habituals

  1. Assumir que el proveïdor ho protegeix tot: el model és compartit.
  2. Emmagatzematge exposat públicament per configuració per defecte mal entesa.
  3. Credencials i claus al codi o a repositoris públics.
  4. Permisos excessius i rols amb comodins.
  5. Manca de registre o registres no centralitzats ni protegits.
  6. Comptes sense MFA, especialment els administratius.
  7. Un únic compte per a tot, sense separació d'entorns.
  8. Recursos orfes sense propietari ni actualització.
  9. No provar la recuperació.
  10. Shadow IT: serveis contractats fora del control de TI (Tecnologies de la Informació), sense contracte d'encarregat ni avaluació de riscos.

Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 72.1

Prevenció de riscos laborals: la Llei 31/1995

Enunciat oficial. Llei 31/1995, de 8 de novembre, de prevenció de riscos laborals: objecte, àmbit d'aplicació i definicions. Política en matèria de prevenció de riscos per protegir la seguretat i la salut en el treball. Drets i obligacions. Consulta i participació del personal.


Aquest tema és una meitat. El programa oficial ho diu tot en un sol epígraf, el 72. Aquesta casa el parteix en dos temes perquè són dues matèries que no comparteixen ni una paraula, i cadascun es queda el seu tros literal de l'enunciat: junts són l'epígraf sencer (norma C-34). L'altra meitat és barcelona/reglamento-de-uso-del-catalan.

Norma: LPRL — Llei 31/1995, de 8 de novembre. Desplegament reglamentari principal: RD 39/1997 (Reglament dels serveis de prevenció). Fonament constitucional: art. 40.2 de la CE (Constitució Espanyola), que encomana als poders públics vetllar per la seguretat i higiene en el treball.

1. Objecte, àmbit d'aplicació i caràcter de la llei

Objecte (LPRL, art. 2): promoure la seguretat i la salut dels treballadors mitjançant l'aplicació de mesures i el desenvolupament de les activitats necessàries per a la prevenció de riscos derivats del treball. Estableix els principis generals relatius a la prevenció dels riscos professionals per a la protecció de la seguretat i de la salut, l'eliminació o disminució dels riscos derivats del treball, la informació, la consulta, la participació equilibrada i la formació dels treballadors.

Caràcter: les seves disposicions són de dret necessari mínim indisponible; es poden millorar per conveni col·lectiu, mai empitjorar.

Àmbit d'aplicació (LPRL, art. 3): s'aplica tant en l'àmbit de les relacions laborals regulades per l'Estatut dels Treballadors com en el de les relacions de caràcter administratiu o estatutari del PERSONAL AL SERVEI DE LES ADMINISTRACIONS PÚBLIQUES, amb les peculiaritats que s'hi preveuen. Per tant, s'aplica plenament al personal funcionari municipal —és aquest article, i no cap disposició addicional, el que ho estableix.

Exclusions i particularitats: policia, seguretat i resguard duaner, serveis operatius de protecció civil i peritatge forense en casos de greu risc, catàstrofe i calamitat pública; la llei els inspira però se'n regeixen per la seva normativa específica. Els centres i establiments militars i els establiments penitenciaris tenen adaptacions. En queda exclosa la relació laboral especial del servei de la llar familiar, si bé el titular de la llar té l'obligació de cuidar que el treball es faci en les degudes condicions de seguretat i higiene.

2. Definicions (LPRL, art. 4) — literals

Terme Definició legal
Prevenció el conjunt d'activitats o mesures adoptades o previstes en totes les fases d'activitat de l'empresa amb la finalitat d'evitar o disminuir els riscos derivats del treball
Risc laboral la possibilitat que un treballador pateixi un determinat dany derivat del treball. Per qualificar-ne la gravetat es valoraran conjuntament la probabilitat que es produeixi el dany i la seva severitat
Danys derivats del treball les malalties, patologies o lesions patides amb motiu o ocasió del treball
Risc laboral greu i imminent aquell que resulti probable racionalment que es materialitzi en un futur immediat i pugui suposar un dany greu per a la salut dels treballadors
Processos, activitats, operacions, equips o productes potencialment perillosos aquells que, en absència de mesures preventives específiques, originin riscos per a la seguretat i la salut
Equip de treball qualsevol màquina, aparell, instrument o instal·lació utilitzada en el treball
Condició de treball qualsevol característica del treball que pugui tenir una influència significativa en la generació de riscos per a la seguretat i la salut
EPI (Equip de protecció individual) qualsevol equip destinat a ser portat o subjectat pel treballador perquè el protegeixi d'un o diversos riscos

Compte amb la distinció: risc = possibilitat de patir un dany; perill = font potencial de dany; dany = la lesió o malaltia efectivament patida.

3. Política de prevenció (LPRL, art. 5 a LPRL, art. 13)

Objecte de la política (LPRL, art. 5): la promoció de la millora de les condicions de treball dirigida a elevar el nivell de protecció de la seguretat i la salut dels treballadors. S'ha d'articular mitjançant l'ordenació de les actuacions dels poders públics, la participació d'empresaris i treballadors a través de les seves organitzacions representatives, i el foment de la formació en matèria preventiva a tots els nivells educatius.

Òrgans i institucions:

Composició — pregunta literal: està integrada per un representant de cadascuna de les comunitats autònomes i pel mateix nombre de membres de l'AGE (Administració General de l'Estat) i, paritàriament amb tots els anteriors, per representants de les organitzacions empresarials i sindicals més representatives. És a dir, composició quadripartida i paritària: administracions (estatal i autonòmiques) d'una banda, i organitzacions empresarials i sindicals de l'altra, amb el mateix pes.

La seva Secretaria l'exerceix l'INSST. Adopta les seves normes de funcionament intern i pot funcionar en Ple, en Comissió Permanent o en grups de treball.

4. Drets i obligacions

El dret bàsic (LPRL, art. 14) — literal

«Los trabajadores tienen derecho a una protección eficaz en materia de seguridad y salud en el trabajo. El citado derecho supone la existencia de un correlativo deber del empresario de protección de los trabajadores frente a los riesgos laborales. […] los derechos de información, consulta y participación, formación en materia preventiva, paralización de la actividad en caso de riesgo grave e inminente y vigilancia de su estado de salud […] forman parte del derecho de los trabajadores a una protección eficaz.»

Els drets que integren el dret a una protecció eficaç són, doncs: INFORMACIÓ, CONSULTA I PARTICIPACIÓ, FORMACIÓ en matèria preventiva, PARALITZACIÓ de l'activitat en cas de risc greu i imminent, i VIGILÀNCIA DE L'ESTAT DE SALUT. Aquesta és la resposta literal a la pregunta d'examen.

Altres regles de l'art. 14: l'empresari ha de garantir la seguretat i la salut en tots els aspectes relacionats amb el treball; el cost de les mesures NO ha de recaure en cap cas sobre els treballadors; l'empresari ha de desenvolupar una acció permanent de seguiment de l'activitat preventiva.

Els nou principis de l'acció preventiva (LPRL, art. 15) — l'ordre importa

Els nou principis de l'acció preventiva, en ordreL'ordre és el de la llei i importa: no es passa al següent fins que el anterior no és possible.a) Evitar els riscosb) Avaluar els que no es puguin evitarc) Combatre'ls a l'origend) Adaptar el treball a la personae) Tenir en compte l'evolució de la tècnicaf) Substituir el que sigui perillósg) Planificar la prevencióh) Anteposar la protecció col·lectiva a la individuali) Donar les instruccions degudes a les persones treballadores

a) Evitar els riscos. b) Avaluar els riscos que no es puguin evitar. c) Combatre els riscos en el seu origen. d) Adaptar el treball a la persona, en particular pel que fa a la concepció dels llocs de treball, l'elecció dels equips i els mètodes de treball i de producció, amb vista, en particular, a atenuar el treball monòton i repetitiu i a reduir-ne els efectes en la salut. e) Tenir en compte l'evolució de la tècnica. f) Substituir el que sigui perillós pel que comporti poc perill o cap. g) Planificar la prevenció, buscant un conjunt coherent que hi integri la tècnica, l'organització del treball, les condicions de treball, les relacions socials i la influència dels factors ambientals. h) Adoptar mesures que anteposin la protecció COL·LECTIVA a la INDIVIDUAL. i) Donar les degudes instruccions als treballadors.

Dues idees que cauen: primer evitar, després avaluar; i la protecció col·lectiva té prioritat sobre l'individual (l'EPI és l'últim recurs).

Obligacions de l'empresari

La llei obliga a tenir-ho preparat i no diu com s'actua; això ho posa la pràctica de primers auxilis amb la conducta PAS (Protegir, Avisar, Socórrer), i l'ordre és tota la resposta: primer protegir el lloc —evitar una segona víctima, i la primera candidata és qui socorre—, després avisar els serveis d'emergència (112) i socórrer l'accidentat només llavors. Socórrer sense protegir és com es multipliquen les víctimes, i per això els distractors juguen amb l'ordre i no amb les paraules. - Risc greu i imminent (LPRL, art. 21): informar el més aviat possible; adoptar mesures perquè els treballadors puguin interrompre l'activitat i abandonar el lloc; i el dret dels treballadors a paralitzar l'activitat i a no reprendre-la mentre persisteixi el risc. Els representants dels treballadors poden acordar la paralització per majoria dels seus membres si l'empresari no adopta les mesures. - Vigilància de la salut (LPRL, art. 22): l'empresari ha de garantir als treballadors la vigilància periòdica de l'estat de salut en funció dels riscos. És VOLUNTÀRIA per al treballador, i només és obligatòria —previ informe dels representants— en tres supòsits: quan sigui imprescindible per avaluar els efectes de les condicions de treball sobre la salut, quan calgui verificar si l'estat de salut del treballador pot constituir un perill per a ell mateix, per als altres treballadors o per a terceres persones, o quan estigui establert en una disposició legal per a la protecció de riscos específics i activitats d'especial perillositat. S'ha de fer respectant el dret a la intimitat i a la dignitat i la confidencialitat de tota la informació; l'accés a la informació mèdica de caràcter personal es limita al personal mèdic, i no es pot facilitar a l'empresari, a qui només s'informa de les conclusions d'aptitud. - Documentació (LPRL, art. 23) i coordinació d'activitats empresarials (LPRL, art. 24). - Protecció de treballadors especialment sensibles (LPRL, art. 25), protecció de la maternitat (LPRL, art. 26), menors (LPRL, art. 27) i relacions de treball temporals i ETT (Empresa de Treball Temporal) (LPRL, art. 28).

Obligacions dels treballadors (LPRL, art. 29)

Correspon a cada treballador vetllar, segons les seves possibilitats i mitjançant el compliment de les mesures de prevenció, per la seva pròpia seguretat i salut i per la d'aquelles altres persones a les quals pugui afectar la seva activitat professional. En particular:

  1. Usar adequadament màquines, aparells, eines, substàncies perilloses, equips de transport i, en general, qualssevol altres mitjans.
  2. Utilitzar correctament els mitjans i equips de protecció facilitats.
  3. No posar fora de funcionament i utilitzar correctament els dispositius de seguretat.
  4. Informar immediatament el seu superior jeràrquic directe i els treballadors designats o el servei de prevenció sobre qualsevol situació que consideri que pot presentar un risc.
  5. Contribuir al compliment de les obligacions establertes per l'autoritat competent.
  6. Cooperar amb l'empresari perquè aquest pugui garantir unes condicions de treball segures.

L'incompliment d'aquestes obligacions té la consideració d'incompliment laboral o de falta, segons el règim aplicable.

5. Organització de la prevenció (LPRL, art. 30 a LPRL, art. 32bis)

Modalitats d'organització, aplicables igual a l'empresa privada que a una entitat local (RD 39/1997): assumpció personal per l'empresari (només en empreses de menys de 10 treballadors i sense activitats de l'annex I), designació de treballadors, servei de prevenció propi, servei de prevenció mancomunat i servei de prevenció aliè.

Servei de prevenció propi obligatori: empreses de més de 500 treballadors, o de 250 a 500 si desenvolupen activitats de l'annex I, o quan ho decideixi l'autoritat laboral.

Especialitats o disciplines preventives (quatre): seguretat en el treball, higiene industrial, ergonomia i psicosociologia aplicada i medicina del treball.

6. Consulta i participació (LPRL, art. 33 a LPRL, art. 40)

Consulta (LPRL, art. 33): l'empresari ha de consultar els treballadors, amb la deguda antelació, l'adopció de les decisions relatives a: la planificació i organització del treball i la introducció de noves tecnologies; l'organització i el desenvolupament de les activitats de protecció i prevenció; la designació de treballadors i el recurs a un servei de prevenció aliè; els procediments d'informació i documentació; el projecte i l'organització de la formació; i qualsevol altra acció que pugui tenir efectes substancials sobre la seguretat i la salut.

Delegats de prevenció (LPRL, art. 35): són els representants dels treballadors amb funcions específiques en matèria de prevenció de riscos en el treball. Es designen PER I ENTRE ELS REPRESENTANTS DEL PERSONAL (delegats de personal o membres del comitè d'empresa o junta de personal) —a l'Ajuntament, doncs, entre els representants sindicals del personal municipal, no per elecció directa dels treballadors.

Escala (LPRL, art. 35.2):

Treballadors Delegats de prevenció
De 50 a 100 2
De 101 a 500 3
De 501 a 1.000 4
De 1.001 a 2.000 5
De 2.001 a 3.000 6
De 3.001 a 4.000 7
De 4.001 en endavant 8

A les empreses de fins a 30 treballadors el delegat de prevenció és el delegat de personal; de 31 a 49, n'hi ha un, elegit pels i entre els delegats de personal.

Competències i facultats (LPRL, art. 36): col·laborar amb la direcció en la millora de l'acció preventiva; promoure i fomentar la cooperació dels treballadors; ser consultats amb caràcter previ; exercir una labor de vigilància i control sobre el compliment de la normativa. Poden acompanyar els tècnics en les avaluacions i els inspectors de treball, tenir accés a la informació i documentació, ser informats dels danys produïts, rebre informació dels òrgans encarregats de la protecció, fer visites als llocs de treball, recaptar mesures de l'empresari i proposar al comitè d'empresa la paralització de l'activitat en cas de risc greu i imminent. El temps utilitzat és crèdit horari retribuït.

Comitè de Seguretat i Salut (LPRL, art. 38): òrgan PARITARI i COL·LEGIAT de participació destinat a la consulta regular i periòdica de les actuacions de l'empresa en matèria de prevenció de riscos. Es constitueix a totes les empreses o centres de treball que comptin amb 50 o més treballadors. Està format pels delegats de prevenció, d'una banda, i per l'empresari i/o els seus representants en NOMBRE IGUAL al dels delegats, de l'altra. Es reuneix trimestralment i sempre que ho sol·liciti alguna de les representacions. Entre les seves facultats (LPRL, art. 39) hi ha la de conèixer i analitzar els danys produïts a la salut o a la integritat física dels treballadors, en qualsevol moment i no només arran d'un accident.

Sigil professional (LPRL, art. 37.3): els delegats de prevenció estan subjectes al deure de sigil respecte de la informació a què accedeixin.

7. Responsabilitats (LPRL, art. 42 a LPRL, art. 54)

L'incompliment pot generar responsabilitat administrativa (infraccions lleus, greus i molt greus del RDL 5/2000 —Reial Decret Legislatiu—, que aprova el text refós de la LISOS (Llei sobre Infraccions i Sancions en l'Ordre Social)), penal, civil i de Seguretat Social (recàrrec de prestacions del 30 % al 50 %). Les responsabilitats administrativa, penal i civil són compatibles, però no es poden sancionar dos cops els mateixos fets amb el mateix fonament (principi non bis in idem).

A les administracions públiques, en lloc de sanció administrativa s'aplica el procediment d'imposició de mesures correctores (LPRL, art. 45.1, paràgraf tercer), amb responsabilitat disciplinària del personal responsable.

8. Riscos del lloc de treball TIC

Els riscos rellevants per a un lloc de les TIC (Tecnologies de la Informació i la Comunicació), d'oficina i de PVD (pantalla de visualització de dades), regulats pel RD 488/1997:


Claus d'examen

Per recordar

Fonts d'aquest tema

Tema 72.2

El Reglament d'ús de la llengua catalana de l'Ajuntament de Barcelona

Sense esquema, expressament

Enunciat oficial. El Reglament d'ús de la llengua catalana de l'Ajuntament de Barcelona.


Aquest tema és una meitat. El programa oficial ho diu tot en un sol epígraf, el 72. Aquesta casa el parteix en dos temes perquè són dues matèries que no comparteixen ni una paraula, i cadascun es queda el seu tros literal de l'enunciat: junts són l'epígraf sencer (norma C-34). L'altra meitat és barcelona/prevencion-de-riesgos-laborales.

Norma: Reglament d'ús de la llengua catalana. Marc superior: art. 3 de la Constitució espanyola, EAC, art. 6 (el català és la llengua pròpia de Catalunya i és, com el castellà, llengua oficial; l'aranès és oficial a Catalunya), EAC, art. 33 i EAC, art. 34 (drets lingüístics), i la Llei 1/1998 (Llei 1/1998, de política lingüística).

1. Àmbit d'aplicació i principis

Àmbit d'aplicació (Reglament, art. 1): abasta l'Ajuntament de Barcelona i els organismes i entitats que en depenen. També hi queden subjectes les empreses que gestionen indirectament serveis locals (per concessió o una altra forma de gestió indirecta), que ho han de preveure en els plecs i contractes, i les empreses amb un concert o conveni de col·laboració amb l'Ajuntament, o beneficiàries d'ajuts o subvencions, que han d'emprar almenys el català en la retolació, els avisos i la documentació adreçats al públic quan estiguin vinculats a l'objecte de l'ajut o el conveni.

2. Ús en l'organització municipal i relacions amb els administrats

3. Relacions institucionals (Reglament, arts. 9 a 11)

4. Selecció, provisió i formació del personal (Reglament, arts. 19 a 22)

5. Sistemes d'informació

Aquest és el punt de contacte amb la vessant TIC (tecnologies de la informació i la comunicació) del temari:

6. Compliment i seguiment (Reglament, arts. 23 i 24)

7. Impuls institucional, toponímia i empreses (Reglament, arts. 25 a 29)

L'últim capítol no regula com parla l'Ajuntament cap endins, sinó què fa l'Ajuntament perquè es parli català a la ciutat. És la diferència que el temari pregunta: els capítols anteriors són ús, aquest és foment.


Per recordar

Fonts d'aquest tema