Qualità di un software (parte 2)

Metodi per svolgere la valutazione

Come abbiamo visto nell’articolo precedente, quando si parla di qualità del software bisogna tenere in considerazione sia gli aspetti relativi al prodotto stesso sia quelli relativi al processo di produzione adottato durante lo sviluppo. Questi aspetti sono complementari tra loro e permettono di valutare in modo completo un sistema software. Ovviamente, non sempre ha senso fare una valutazione completa ed approfondita, ma è necessario identificare, caso per caso, il livello di analisi necessario. In particolare, l’analisi dovrà essere svolta tanto più in profondità quanto più il sistema sviluppato è importante per l’azienda e quanto più a lungo si prevede di utilizzare tale sistema. Infatti, la valutazione della qualità richiede delle competenze specifiche che vanno al di là di quelle di uno sviluppatore software o di un project manager, richiedendo una profonda conoscenza dei processi di produzione e dei sistemi di valutazione.

Il fattore tempo è uno degli aspetti fondamentali da considerare per valutare la qualità di un sistema. Questo perché la qualità è tanto più importante quanto più a lungo si prevede di utilizzare un sistema software. Infatti, quando si parla di qualità del software, si deve tenere in considerazione che un prodotto/servizio software non è un oggetto materiale che ha una vita indipendente ma dipende da una miriade di altri sistemi software e hardware che cambiano nel tempo. Quindi, lo sviluppo di un sistema software non può mai essere considerato concluso ma deve essere continuamente adattato ai cambiamenti dell’ambiente in cui deve operare. Si pensi, ad esempio, agli aggiornamenti del sistema operativo, del browser, dell’hardware, ecc. Tali cambiamenti possono rendere il sistema sviluppato non più utilizzabile. Per tanto, quando si sviluppa un sistema software è necessario considerare la sua manutenzione per il tempo in cui è previsto il suo utilizzo. In caso contrario, il sistema diventerà inutilizzabile in un tempo più o meno breve. Si può paragonare un sistema software ad un’automobile, se non si fa manutenzione periodicamente, l’auto è destinata a diventare inutilizzabile in un tempo molto breve, vanificando l’investimento iniziale.

Considerando la qualità del prodotto software, si possono valutare due punti di vista:

• esterno: questa prospettiva permette di valutare se il sistema sviluppato è in grado di adempiere agli scopi per cui è stato progettato, quindi se è in grado di soddisfare le necessità del cliente. La valutazione di questo aspetto è un compito che deve essere svolto dall’utilizzatore del sistema, che è l’unico in grado di valutarne il comportamento (caratteristiche, prestazioni, usabilità, ecc.). Per fare ciò non sono necessarie conoscenze relative allo sviluppo software ma relative al dominio applicativo. Questo tipo di valutazione deve essere svolto per un qualunque sistema software ma, per essere veramente efficace, è necessario che sia svolto non solo alla fine del progetto ma anche durante le fasi di sviluppo intermedie per permettere al team di sviluppo di utilizzare i risultati di tali analisi per modificare il sistema in modo opportuno. Infatti, un’analisi svolta solamente alla fine del progetto, non sarà in grado di fornire elementi in tempo utile per migliorare lo sviluppo;
• interno: questa prospettiva, invece, è legata agli aspetti più strettamente informatici tra cui la definizione dell’architettura software, lo sviluppo degli algoritmi, la scrittura del codice, ecc. In questo caso, viene valutato come il sistema è stato sviluppato e la difficoltà di modificarlo/estenderlo in futuro. La valutazione di questo aspetto deve essere effettuata da un esperto e può essere fatta solamente avendo a disposizione diversi tipi di documenti creati dal team di sviluppo (descrizione dei requisiti, documenti di analisi ed architettura, ecc.), a seconda del livello di profondità dell’analisi. In ogni caso, però, è necessario l’accesso al codice sorgente per poter effettuare una qualunque analisi. Anche in questo caso, svolgere l’analisi alla fine di un progetto è utile per conoscere il livello di qualità del prodotto finito ma poter effettuare queste analisi durante lo sviluppo permetterebbe al team di sviluppo di utilizzare i risultati per migliorare il prodotto prima che sia ultimato.

L’analisi della qualità del processo software è un’attività che può essere svolta in tempi diversi con obiettivi diversi, tra cui:

• analisi di un progetto in corso: in questo caso, l’obiettivo dell’analisi consiste nel verificare le modalità di sviluppo di un prodotto/servizio specifico valutando l’adeguatezza della metodologia utilizzata in relazione allo specifico contesto in cui avviene. Inoltre, si valuta come la metodologia scelta è applicata nel progetto e come viene gestita dal team. Questo tipo di valutazione deve essere effettuata da un esperto in stretta collaborazione con il team perché è necessario investigare in dettaglio le modalità di sviluppo adottate. Questo tipo di attività può essere piuttosto invasivo e richiede molto tempo sia per il valutatore che per il team di sviluppo. I risultati di tale valutazione, però, permettono di comprendere meglio le modalità di sviluppo impiegate aumentando il livello di fiducia del cliente nel team di sviluppo;
• analisi della capacità di un team: in questo caso, l’obiettivo dell’analisi consiste nel valutare la capacità di un team di sviluppo di produrre sistemi software indipendentemente dal progetto specifico. Tutto ciò attraverso la valutazione della gestione della conoscenza all’interno del team, la gestione del codice e dei difetti, ecc. Inoltre, viene valutato come viene gestita la qualità del codice e come tali informazioni vengono utilizzate all’interno del team di sviluppo. Anche questo tipo di valutazione deve essere effettuata da un esperto in stretta collaborazione con il team. Questo tipo di valutazione è la più difficile da svolgere perché richiede una profonda analisi dei processi aziendali e di sviluppo adottati dal team. Inoltre, è richiesta la collaborazione non solo del team di sviluppo ma anche del management per comprendere meglio le attività che sono complementari allo sviluppo software, come la gestione della manutenzione di un sistema complesso.

Tutte queste analisi sono utili in diversi contesti e possono essere utilizzate per valutare i diversi aspetti di un sistema software. Gli scenari possibili sono innumerevoli ma quello più frequente è uno: lo sviluppo di un sistema commissionato da una azienda non software.

Le analisi che possono essere eseguite in questo contesto sono di diverso tipo, come illustrato precedentemente, a seconda del livello di importanza del sistema in sviluppo e del suo tempo di vita previsto.

In ogni caso, risulta sempre necessaria una analisi della qualità esterna del sistema che può essere fatta agevolmente anche senza una conoscenza informatica valutando il comportamento del sistema dal punto di vista dell’utente. Questa attività, però, dovrebbe essere effettuata diverse volte durante lo sviluppo (anche considerando la specifica metodologia adottata) per fornire al team elementi utili a migliorare il sistema prima che ciò richieda una riscrittura massiccia del codice con relativi ritardi nella consegna ed incrementi dei costi. Una valutazione minima dovrebbe consistere in tre analisi: una nelle prime fasi di sviluppo in cui sono disponibili le prime funzionalità per identificare immediatamente eventuali incomprensioni; una a circa metà del progetto per valutare lo stato di avanzamento ed il recepimento delle raccomandazioni identificate nella prima analisi; una alla fine del progetto per effettuare una valutazione complessiva del sistema.

I livelli successivi di analisi non sono strettamente necessari ma permettono di avere informazioni più complete relativamente alla qualità del sistema sviluppato. Il passo successivo, infatti, consiste nell’analisi della qualità interna del codice fatta da un esperto che permette di valutare la struttura del codice e la difficoltà di manutenzione. Questo è un aspetto molto importante perché, a parità di funzionalità e prestazioni visibili dall’utente finale, il codice può essere scritto in modi molto diversi tra loro con un impatto notevole sulla manutenzione e sulla presenza di difetti. Quindi, questa valutazione risulta essenziale se si pianifica di utilizzare il sistema per un periodo medio-lungo in cui sarà necessario apportare delle modifiche. Visto che per valutare questi aspetti è necessario avere accesso al codice e alla documentazione tecnica prodotta dal team di sviluppo, questo tipo di attività deve essere necessariamente prevista contrattualmente.

L’analisi del processo di sviluppo è un passo ulteriore di analisi che assume maggiore importanza nel caso si preveda di mantenere il sistema per un lungo periodo di tempo e si prevede di instaurare un rapporto di collaborazione a lungo termine con il produttore del software. Questo permette all’azienda di verificare l’adeguatezza del processo di sviluppo alle esigenze aziendali nel lungo periodo.

L’analisi della capacità di un team è il passo più avanzato ma risulta utile solamente nel caso in cui si prevede di instaurare una collaborazione duratura con un produttore software per lo sviluppo di diversi progetti di particolare importanza e lunga vita.

Riassumendo, si possono definire 4 livelli di valutazione della qualità di un sistema software:

1. Analisi della qualità esterna: utile in tutti i casi e facilmente valutabile dal committente senza nessuna conoscenza informatica specifica.
2. Analisi della qualità interna: utile se il sistema è critico e/o deve essere utilizzato per molto tempo; valutabile da un esperto.
3. Analisi di un progetto specifico: utile se il sistema è critico e/o deve essere utilizzato per molto tempo; valutabile da un esperto e richiede la collaborazione del team di sviluppo.
4. Analisi della capacità di un team: utile se si prevede di utilizzare un unico fornitore per sviluppare diversi sistemi critici e/o con una lunga vita; valutabile da un esperto e richiede la collaborazione dell’azienda produttrice.

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.