Gestió de la Qualitat del Programari

7 preguntas de exámenes anteriores · 13 min · 3 hermanas, de otra categoría

Versiones que desarrolla: ISO/IEC 25010 2011 (superada) · ISO/IEC 25010 2023 (vigente)

Elaboración propia: la fuente es de pago y no se reproduce

Enunciat oficial. Gestió de la Qualitat del Programari.

1. Concepte

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

Dues vessants:

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

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

Assegurament vs control — la distinció clau:

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

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

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

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

3. Aspectes fonamentals al llarg del cicle de vida

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

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

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

4. Normes de qualitat del producte

ISO/IEC 25000 (SQuaRE)

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

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

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

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

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

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

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

Altres

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

ISO/IEC 14764: tipus de manteniment

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

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

5. Models de maduresa

CMMI

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

Afirmacions certes sobre CMMI —el que es pregunta—:

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

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

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

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

6. Tècniques i eines

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

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

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

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

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

Mètriques de producte:

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

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

7. Pràctiques de construcció

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

8. Al sector públic

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

Claus d'examen

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

Per recordar

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

Practicar este tema