Per analizzare le qualità dei prodotti software bisogna prima capire gli elementi che lo compongono perché è l’insieme delle loro singole caratteristiche a determinarne la qualità totale. Ecco perché, quando si parla di qualità, la specifica dei requisiti è il primo elemento da considerare, poi si passa all’architettura ed infine alla documentazione ed al codice.
Per una corretta valutazione è necessaria una valida struttura documentale, che deve comprendere almeno i seguenti strumenti: riesami periodici, verifiche statiche e dinamiche, validazione o test del sistema, audit completo.
È poi importante avere un approccio che permetta di valorizzare tre aspetti della qualità:
- interna: le caratteristiche “strutturali” del prodotto;
- esterna: la capacità del software di soddisfare le richieste che gli vengono girate in determinate condizioni;
- in uso: misura con cui un prodotto soddisfa le esigente di un determinato utente.
=> Leggi come si realizza un prodotto software
Alcuni requisiti di qualità sono difficili da esplicitare in maniera “non ambigua” e possono essere difficili da valutare a priori, e/o direttamente. Per questi requisiti si può far fronte solo ad una misurazione indiretta. In sostanza in un software non va ricercata la qualità come fosse una caratteristica propria del prodotto, ma le espressioni, le caratteristiche, le manifestazioni e gli impatti della stessa.
Per rendere univoco e confrontabile, quindi oggettivabile, l’insieme di queste caratteristiche (la qualità), si fa ricorso ad un insieme di attributi inseriti in schemi di riferimento, che danno vita ad alcuni modelli standard.
I modelli seguono, in genere, uno schema ben preciso: prima descrivono delle caratteristiche (o proprietà), poi determinano queste in funzione di una serie di attributi (misurabili o quantificabili), poi si sviluppa un rating in funzione del grado di aderenza di ogni attributo al prodotto in oggetto.
I primi modelli di qualità del software sono stati sviluppati sul finire degli anni ‘70 (da McCall e da Boehm), alcuni dei principi espressi da questi modelli sono ritenuti tutt’ora validi, tanto da essere ripresi nelle norme ISO sulla qualità del software.
=> Vai alla Guida di PMI.it sul Progetto Aziendale
Con il passare degli anni l’evoluzione dei processi e delle esigenze, ha portato la ISO ad emettere norme in grado di definire un modello di qualità del software, utile in vari contesti:
- ISO/IEC 9126-1 – Definisce 6 caratteristiche di qualità principali (astratte) e 27 sottocaratteristiche misurabili attraverso delle metriche, fornite in 3 technical reports (ISO/IEC 9126-2, 3 e 4).
- ISO/IEC 9241 – Definisce le caratteristiche di qualità di un software “usabile”.
- ISO 12119 – Definisce le caratteristiche di qualità di un software “Commercial off the shelf” (COTS).
La ISO ha anche pubblicato una norma, la 14598, che guida alla valutazione della qualità del software, definita secondo i criteri della 9126.
Dunque la qualità di un prodotto software si misura, sulle sue funzionalità e sulla base della coerenza/appartenenza di un determinato attributo. Rinnovando la lezione di McCall e Boehm, i parametri rispetto cui si misurano 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 dagli utenti, mentre i secondi si riferiscono alla qualità del software così come è percepita dagli sviluppatori.
Ovviamente parametri interni ed esterni sono in stretta correlazione, un software mal scritto non può che dare risultati poco soddisfacenti una volta usato dagli utenti.
Il grafico seguente, tratto dal modello di McCall, mostra la relazione tra le caratteristiche del prodotto software viste dall’utente e quelle viste dallo sviluppatore.
Vista utente
Correttezza: non è una qualità misurabile, ma è un valore assoluto: è la capacità di un programma o di un software di comportarsi come previsto.
Affidabilità: è la capacità di mantenere fissati livelli di prestazione in date condizioni. In pratica un sistema è tanto più affidabile quanto più raramente si manifestano malfunzionamenti o guasti. L’affidabilità è misurabile, ma per misurarla bisogna definire un modello di riferimento. Questo perché in alcuni contesti l’affidabilità può essere misurata semplicemente contando il numero di guasti per periodo (la distribuzione dei malfunzionamenti si chiama anche maturità), mentre in altri contesti risulta più utile verificare il tipo di malfunzionamento (ad esempio in funzione dell’impatto su un sistema o un’azione).
Negli ultimi anni, l’industria del software, principalmente per motivi di competizione su tempi e costi, è orientata ad immettere sul mercato prodotti il cui tasso di affidabilità risulta “non ottimizzato” per i bisogni dell’utente. Ovviamente questa prassi è accettabile solo su applicazioni non critiche quali giochi o applicazioni di intrattenimento, per permettere l’evoluzione di questi progetti si rilasciano periodicamente delle patch.
Efficienza: è il rapporto tra il livello di prestazione raggiunto e l’ammontare di risorse usate per raggiungerlo. Un sistema informatico, quindi, è efficiente se usa memoria e tutte le altre risorse in modo accettabile rispetto ai servizi che svolge. Dal punto di vista ingegneristico, l’efficienza in ambito IT è difficilmente, a meno di casi particolari, considerata un parametro da sviluppare.
Nelle prime fasi del progetto, questo approccio ha però una forte componente di rischio in quanto una rielaborazione del sistema in funzione dell’efficienza può essere fortemente critica (per tempi e costi). I principali modelli di verifica dell’efficienza sono basati su simulazioni o su prove effettuate con i rilasci intermedi .
=> Leggi: Il ciclo di vita del software e i modelli di sviluppo
Integrità: è un fondamentale parametro di sicurezza, oggi sempre più significativo, può riguardare l’intero sistema o una sua parte.
Usabilità: è semplicemente la facilità d’uso di un programma o sistema. È quindi da considerarsi una qualità soggettiva, in quanto dipendente sia dal contesto d’uso che dalle capacità dell’utente. Al fine di rendere confrontabili diversi progetti, l’ISO ha sviluppato la norma 9241 che misura l’ergonomicità dell’iterazione tra uomo e sistemi. Sempre secondo L’ISO l’usabilità si può intendere come una combinazione di efficacia (capacità di raggiungere un obiettivo), efficienza (quindi buon uso delle risorse), impegno dell’utente (in primis carico mentale).
Manutenibilità: un prodotto è manutenibile se è facilemente ripristinabile e, in generale, è facile apportarvi modifiche. L’importanza di questa qualità è dovuta alle esigenze attuali per cui, soprattutto in determinati contesti, non è sufficiente affinare l’affidabilità del prodotto, in quanto è necessario apportare modifiche ed implementazioni di funzionalità e prestazioni.
Distinguiamo diversi tipi di manutenzione:
- correttiva, o su guasto;
- preventiva, sia adattiva (per adattare il sistema a nuove condizioni) che perfettiva (per migliorare o arricchire il prodotto).
In sostanza una buona manutenibilità è un requisito fondamentale per creare prodotti con una buona longevità.
Testabilità: è un requisito importante ma non assoluto, nonostante si trovino molte stime sull’impatto i una buona/cattiva testabilità sulle performance e sul valore del prodotto, queste sono fonte di molte diatribe e discordanze, ciò che possiamo asserire con sicurezza è che la testabilità è un requisito da considerare già in fase di progetto. La quantità generale e la qualità delle risorse da riservare per l’impostazione di questo requisito sono da basarsi su una analisi dei rischi e dei costi connessi.
=> Leggi come verificare la Fattibilità del progetto
Flessibiltà: è la potenziale adattabilità del prodotto alle diverse condizioni (d’uso, di mercato…).
Portabilità: è una caratteristica di respiro più ampio, che riguarda, in ambito IT, direttamente i prodotti quanto i loro output quanto, ancora, i documenti generati in genere e considera cambiamenti software e/o hardware. Secondo la ISO 9126 la adattabilità è una sottocaratteristica della portabilità.
Riusabilità: secondo la definizione del glossario IEEE, indica il grado con cui un modulo o un’altra componente software possa essere usato in più di un programma o sistema software. Dal punto di vista del cliente il riuso è un parametro di adattabilità. Per le aziende di sviluppo, invece, è una caratteristica utile ad ottenere una serie di vantaggi (riduzione dei tempi di progettazione e del time to market, ottimizzazione degli investimenti e delle risorse, etc.).
In generale la possibilità di riusare il software è legata ad alcune delle caratteristiche proprie del prodotto e richiede una specifica impostazione organizzativa e metodologica. Alcune difficoltà del riuso sono legate alla natura del prodotto software la cui descrizione delle caratteristiche funzionali e di qualità sono anche soggettive, senza considerare la particolare strutturazione delle attività di revisione e aggiornamento ed il fatto che spesso i clienti del prodotto hanno un ruolo attivo nel processo produttivo, rendendo meno agevole questa pratica.
Interoperabilità: capacità di interagire con altri sistemi software.
Altri parametri fondamentali da considera come misura della qualità sono la soddisfazione (puramente soggettivo e quindi di difficile quantificazione) e la robustezza.
La robustezza, in particolare, è un concetto di introduzione relativamente nuova nelle logiche di progettazione, il punto di partenza della logica robusta è che per un prodotto non è sufficiente lavorare bene, se non è in grado di garantire un buono standard di prestazioni in condizioni critiche.
Nel mondo informatico la situazione critica, può nascere da una condizione imprevista o non contemplata nelle specifiche, come da una condizione limite delle risorse disponibili al sistema, o da un uso errato del sistema.
