Qualità del software

Per qualità del software si intende la misura in cui un prodotto software soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia alla sua struttura interna. Gran parte della ricerca nel campo dell'ingegneria del software è dedicata, direttamente o indirettamente, al tema della qualità. In particolare, si è cercato di stabilire chiaramente cosa si intenda per qualità del software, definendo un insieme di parametri di qualità significativi; di realizzare tecniche per misurare tali parametri rispetto a un dato sistema software; di sviluppare tecnologie (per esempio linguaggi di programmazione) e metodologie (per esempio di analisi e progettazione) che facilitino la realizzazione di software di qualità.

Classificazione dei parametri

Tradizionalmente, i parametri (o fattori) rispetto a cui si può misurare o definire la qualità del software vengono classificati in due famiglie: parametri esterni e parametri interni. I primi si riferiscono alla qualità del software così come è percepita dai suoi utenti, e includono correttezza, affidabilità, robustezza, efficienza, usabilità, ecocompatibilità. I secondi si riferiscono alla qualità del software così come è percepita dagli sviluppatori, e includono verificabilità, manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità, leggibilità, modularità. Generalmente esiste una correlazione fra questi due aspetti (banalizzando: il software mal scritto tende anche a funzionare male).

Correttezza

Un programma o sistema software si dice corretto se si comporta esattamente secondo quanto previsto dalla sua specifica dei requisiti. In termini più informali, un sistema è corretto se fa esattamente quello che è stato progettato per fare. Nell'ingegneria del software "classica" (anni sessanta-anni settanta), lo sviluppo di software corretto veniva universalmente considerato l'obiettivo predominante, a cui praticamente tutti gli altri parametri di qualità erano finalizzati. Molti moderni modelli di sviluppo software, viceversa, escludono la possibilità di sviluppare rispetto a una specifica stabilita a priori in modo definitivo e non ambiguo, e quindi, indirettamente, negano alla correttezza un valore pratico significativo. In ogni caso, la correttezza è una qualità assoluta (un sistema è corretto o non lo è) e sostanzialmente impossibile da misurare (verificare); non è possibile stabilire con certezza che un sistema sia corretto.

Nelle metodologie di sviluppo e progettazione agili, si parla piuttosto di "soddisfazione del cliente", intendendo con questo che i requisiti iniziali potrebbero essere stati modificati, ma con il consenso e a piena soddisfazione del committente.

Affidabilità

Un sistema è tanto più affidabile quanto più raramente, durante l'uso del sistema, si manifestano malfunzionamenti. Una definizione più specifica, ma non universalmente riconosciuta, è basata sul concetto di MTBF (Mean Time Between Failure, il tempo medio che intercorre fra due fallimenti successivi). In termini invece più vaghi (ma probabilmente più significativi), si può anche dire che l'affidabilità è la misura in cui l'utente può "fidarsi" del software; questa definizione tiene conto, in particolare, del fatto che malfunzionamenti gravi si considerano solitamente più influenti, nella valutazione dell'affidabilità, di errori minori. In questo senso, il modo in cui si intende il termine affidabilità può variare in funzione del tipo di utente (per esempio della sua capacità di adattarsi) e del tipo di applicazione (per esempio in funzione della sua criticità).

Poiché l'affidabilità è concettualmente misurabile (una volta specificato un particolare modello, per esempio MTBF o una variante pesata in funzione della gravità dei fallimenti), questo parametro viene spesso considerato la controparte "realistica" della correttezza.

L'industria del software moderna, su applicazioni non critiche, tende a considerare economicamente vantaggioso il rilascio di prodotti con un tasso iniziale di malfunzionamenti piuttosto elevato, ma dotati di meccanismi di caricamento periodico di patch (per esempio via Internet) attraverso cui gli errori vengono corretti via via che vengono trovati dall'utenza e segnalati al produttore.

Controesempi di software affidabile (o chiari esempi di software inaffidabile).

Il Therac-25 era una strumentazione medica usata agli inizi degli anni ottanta per trattare il cancro. L'unicità dell'apparecchiatura a quel tempo era il software, che monitorava la dose di radiazioni da emettere nel trattamento. Purtroppo un errore nel software causò l'emissione di dosi letali. L'errore si verifica così infrequentemente che morirono diverse persone prima di rendersi conto del problema.

Robustezza

In termini generali, la robustezza di un sistema è la misura in cui il sistema si comporta in modo ragionevole in situazioni impreviste, non contemplate dalle specifiche. Situazioni di questo tipo in genere riguardano errori ed eccezioni di varia natura (dati di input scorretti, fallimenti di componenti software o hardware esterni al sistema e interagenti con esso, e così via). Anche in questo caso, l'idea intuitiva della robustezza implica certamente considerazioni di valore sugli effetti dannosi che il sistema o l'utente subiscono se il sistema reagisce in modo "irragionevole" a situazioni impreviste.