qualità

Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.

Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l'abbiamo fatto male noi.

Perché, a volte, il software è fatto male? In alcuni casi, per l'incompetenza di chi lo sviluppa, problema in genere superabile con un'adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c'è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.

Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch'esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.

Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.

Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.

Deve essere installato e funzionare. Se lo è,
deve avere sufficienti prestazioni, ed essere sicuro. Se lo è,
deve essere usabile. Se lo è,
deve essere utile. Se lo è,
può avere successo.

Rappresentata come una piramide, questa scala di livelli di qualità del software è analoga alla piramide di Maslow sul soddisfacimento dei bisogni degli esseri umani.

Per Maslow, innanzitutto vanno soddisfatti i bisogni primari (cibo, temperatura ecc.). Soddisfatti questi, vanno soddisfatti i bisogni di sicurezza personale. Poi i bisogni legati alle relazioni e all'affettività. Poi i bisogni legati al riconoscimento e alla stima. Infine quelli legati alla realizzazione del proprio potenziale.

Se un livello precedente non viene soddisfatto, vengono compromessi i livelli successivi (ad esempio, se non si ha cibo sufficiente, l'attenzione alla sicurezza personale può diminuire).

L'analogia tra la scala dei bisogni di Maslow e i livelli di qualità del software è descritta in modo brillante da Gojko Adzic.

CAST è la Conference of the Association for Software Testing. Conferenza annuale, che nel 2012 si è tenuta a San Jose, USA, dal 16 al 18 luglio.

I video della conferenza CAST2012 sono disponibili su YouTube. Interessante in particolare la keynote di Elisabeth Hendrickson, The Thinking Tester Evolved.

Sempre da CAST2012, da seguire l'intervento Software Metrics: Threats to Validity di Cem Kaner sulla validità delle metriche usate nell'ingegneria del software, ed in particolare nel testing.

Lord Kelvin: "Se non si può misurare, non si può migliorare".

Tom DeMarco, in Controlling Software Projects (1986): "Non si può tenere sotto controllo ciò che non si riesce a misurare".

Phillip G. Armour, su Communications of the ACM, June 2012, rovescia il punto di vista: "Se non si migliorano le cose, è difficile misurarle bene; sotto alcuni aspetti, non possiamo misurare ciò che non controlliamo".

Alcuni esempi illuminanti di misurazioni dubbie citate nell'articolo: durata, produttività, costo, qualità dei progetti software.

"Più di metà degli apparecchi medici venduti in America (il maggior mercato di strumenti medici) è basata su software, spesso su molto software. Il software di un pace-maker può contenere oltre 80.000 righe di codice, un infusore di farmaci 170.000, e un apparato per la risonanza magnetica oltre 7 milioni di righe di codice."

L'affidabilità di questo software è ovviamente critica. Uno studio condotto su apparati venduti negli USA dal 1999 al 2005 ha scoperto che un terzo di tali apparati sono stati tolti dal servizio per problemi legati al software.

Una strada per rendere il software medico più affidabile potrebbe essere l'open source, per permettere una migliore visibilità e la possibilità di esaminare il codice. Purtroppo, i regolamenti di approvazione del software stabiliti dagli enti di validazione (come la FDA, la Food and Drug Administration degli USA) sono fatti in modo da scoraggiare il ricorso alle pratiche collaborative tipiche dell'open source.

"When code can kill or cure", The Economist, Technology Quarterly, June 2nd 2012.