Qualità di un software

Il prof. Alberto Sillitti, professore ordinario presso la Facoltà di Informatica ed Ingegneria della Innopolis University (Federazione Russa), spiega tutto quello che c’è da sapere sulla qualità del software. Il prof. Sillitti svolge attività di ricerca nel campo della qualità del software nel contesto di sistemi software complessi (cyber-physical systems, smart city, impresa 4.0, ecc.) in collaborazione con diverse realtà industriali internazionali, PMI e start-up. Inoltre collabora con importanti aziende dell’Alto Adige in cui svolge attività di consulenza come Innovation Manager ed esperto nello sviluppo e valutazione della qualità del software.

Dal punto di vista del produttore e dell’utilizzatore

Il software fa parte ormai della nostra vita di tutti i giorni ed è una componente fondamentale di quasi tutti i prodotti e i servizi che utilizziamo quotidianamente. Nonostante questa presenza costante, la maggior parte delle persone non comprende a fondo i suoi meccanismi che, spesso, sono molto complessi.

Quando si parla di qualità del software si fa spesso solo riferimento ai difetti (“bug”). Questo aspetto, però, nonostante sia molto importante, permette di valutare solo una piccola parte della qualità di un prodotto software che non tiene in considerazione la qualità del codice, vale a dire quanto il sistema sviluppato sia scritto bene e facile da modificare/estendere in futuro. Questi aspetti interni del software sono molto più difficili da valutare ma hanno un impatto considerevole sui costi di sviluppo e di manutenzione di un sistema e, quindi, sul costo per l’utente finale. Per tanto, quando si commissiona lo sviluppo di un sistema software che si prevede di utilizzare per molto tempo è opportuno non solo valutare i bug ma anche il codice stesso in modo da minimizzare i tempi e i costi per le future modifiche e/o estensioni del sistema. Quindi, conoscere in modo più approfondito i diversi aspetti della qualità del software è un requisito fondamentale per poter valutare in modo più completo un sistema.

In questa serie di articoli parleremo di uno degli aspetti più complessi del software: la qualità. Questo è il primo articolo della serie ed introdurremo la qualità del software sia dal punto di vista del produttore che da quello dell’utilizzatore di un sistema; nel secondo, ci occuperemo della valutazione della qualità; nel terzo, analizzeremo un caso di studio reale.

Esistono innumerevoli definizioni di qualità ma una delle più semplici e più utilizzate nella pratica prende in considerazione la capacità del software di svolgere il compito per cui è stato progettato. Questa definizione prende in considerazione la qualità esterna del software, vale a dire la qualità percepita dall’utente considerando il software come una scatola chiusa a cui si forniscono dati e da cui si ottengono risultati, senza dover analizzarne il funzionamento interno. Questa definizione di qualità permette all’utente di valutare un prodotto senza conoscere il funzionamento interno e senza richiedere competenze informatiche, sono sufficienti le conoscenze relative al dominio applicativo, vale a dire quali risultati ci si aspetta di ottenere in base ai dati forniti. Da questo punto di vista è possibile valutare diversi aspetti della qualità del software che comprendono ad esempio:

• difettosità: riguarda i difetti presenti all’interno del codice che fanno in modo che il sistema non svolga correttamente i suoi compiti;
• prestazioni: riguarda la velocità di esecuzione delle attività del sistema e l’utilizzo delle risorse (ad esempio la memoria richiesta);
• facilità di utilizzo: riguarda l’interazione uomo-macchina e come le informazioni sono scambiate con l’utente.

Ognuno di questi aspetti può essere valutato in modi molto diversi tra loro. Per esempio, la difettosità può essere valutata come numero di difetti rilevati, come tempo di inattività del sistema a causa dei difetti, come tempo richiesto per la correzione dei difetti, ecc. Ognuna di queste modalità di valutazione ha degli obiettivi specifici e nessuna, presa singolarmente, può fornire una valutazione completa ed affidabile di un sistema software. Per tanto, è opportuno effettuare valutazioni che tengano in considerazione tutti gli aspetti che risultano importanti in una specifica situazione.

Oltre alla qualità esterna percepita dall’utente, ci sono altre definizioni di qualità che prendono in considerazione la struttura interna del software. In questo caso, viene analizzato il codice scritto dagli sviluppatori valutando aspetti molto diversi dai precedenti come i seguenti:

• complessità: prende in considerazione la difficoltà di scrittura del codice e, in particolare, degli algoritmi scelti;
• modularità: analizza quanto una porzione di codice sia dipendente da altro codice;
• riusabilità: analizza quanto una porzione di codice sia riutilizzabile in altri sistemi in futuro;
• leggibilità: analizza quanto sia difficile per uno sviluppatore capire il funzionamento di una porzione di codice;
• manutenibilità: prende in considerazione diversi aspetti, tra cui anche i precedenti, e valuta quanto sia difficile modificare il codice per correggere difetti, aggiungere o modificare funzionalità, ecc.

Anche in questo caso, ciascuno degli aspetti elencati può essere valutato in molti modi. Ad esempio, la leggibilità può essere valutata considerando la lunghezza del codice richiesto per implementare una specifica funzionalità, la quantità di commenti inseriti, ecc.

Sia la qualità interna che esterna, però, sono misurabili solo quando il prodotto, e quindi il codice, è già stato sviluppato (anche solo parzialmente). Per questo motivo, si è reso necessario valutare non solo il prodotto ma anche il processo di produzione per poter offrire una serie di elementi su cui basare l’affidamento di un incarico di sviluppo software.

La valutazione del processo di produzione non garantisce la qualità del prodotto finale ma fornisce degli elementi che permettono di valutare la capacità di una azienda di produrre software di qualità. A questo scopo, sono nate metodologie per la valutazione del processo di produzione del software, la prima e, forse, anche la più conosciuta è il Capability Maturity Model Integration (CMMI). Questa metodologia è stata progettata per valutare la capacità di una azienda di organizzarsi e di seguire delle pratiche di sviluppo software consolidate, in modo da garantire un livello pressoché costante di qualità dei sistemi software prodotti. Tale approccio è stato sviluppato negli anni ’80 per far fronte alle necessità di acquisizione software del Dipartimento della Difesa degli Stati Uniti e, quindi, è stato pensato per aziende di grandi dimensioni e per lo sviluppo di sistemi software con caratteristiche molto lontane dagli ambienti aziendali attuali.

Per questi motivi, il CMMI ed altri approcci simili, non si adattano bene al contesto attuale in cui operano la maggior parte delle aziende. Oggi il mercato richiede di produrre sistemi in tempi molto stretti e di modificarli continuamente per andare incontro alle esigenze del business che sono in continuo cambiamento. Per questi motivi, i processi di produzione del software hanno subito cambiamenti radicali negli ultimi 20 anni ma le metodologie di valutazione della qualità del processo di produzione faticano ad adeguarsi alla velocità di tali cambiamenti. Inoltre, le procedure richieste per una certificazione del processo di produzione del software sono molto complesse e richiedono un investimento notevole di risorse che solo poche aziende in specifici domini applicativi (ad esempio nei settori aerospaziali, nei trasporti, nella produzione di energia, ecc.) possono permettersi di affrontare. La maggior parte delle aziende, però, si rivolge a mercati diversi in cui il processo di sviluppo adottato è difficilmente certificabile ma è in grado di rispondere meglio alle esigenze del mercato. Alcune delle metodologie di sviluppo più comunemente adottate oggi sono dette “agili” e comprendono diverse metodologie specifiche come SCRUM, Kanban, extreme programming (XP), ecc.

Sia per la qualità del prodotto che del processo software esistono dei punti di riferimento che sono codificati all’interno di diversi standard internazionali come:

• ISO/IEC 25000 - System and Software Quality Requirements and Evaluation (SQuaRE)
• ISO/IEC 33001 - Information Technology -- Process Assessment

Tali standard sono piuttosto complessi e la loro applicazione completa non è sempre possibile e/o utile in tutti i contesti. Un sistema di controllo di un aereo è molto diverso da una app per un cellulare, quindi i processi di sviluppo devono necessariamente essere diversi e devono essere valutati in modo diverso.

Per questi motivi, la valutazione della qualità di un sistema software è una attività complessa che deve essere adattata allo specifico contesto applicativo ed alle esigenze dell’utente.

Sulla persona

Alberto Sillitti collabora con importanti aziende dell’Alto Adige in cui svolge attività di consulenza come Innovation Manager ed esperto nello sviluppo e valutazione della qualità del software. Ricopre il ruolo di professore ordinario presso la Facoltà di Informatica ed Ingegneria della Innopolis University (Federazione Russa) dove svolge attività di ricerca nel campo della qualità del software nel contesto di sistemi software complessi (cyber-physical systems, smart city, industry 4.0, ecc.) in collaborazione con diverse realtà industriali internazionali, PMI e start-up.