Powered by

Il modello SERVQUAL applicato allo sviluppo del software
I Gap da colmare per realizzare software di successo

Ercole Colonese, Consulente di Direzione ed IT, socio Aicq-ci e membro del Sottocomitato Qualità del Software e dei Servizi IT

Il modello SERVQUAL è stato messo a punto da Valerie A. Zeithaml, A. Parasuraman e Leonard L. Berry per valutare la qualità di un servizio erogato rispetto alle esigenze del cli-ente; aiuta quindi ad individuare le aree di potenziale miglioramento. In questo articolo si presenta la trasposizione del modello nello sviluppo del software; si applica cioè alla realizzazione di un prodotto invece che di un servizio, come indirizzato dal modello originale. La tecnica proposta permette di valutare gli scostamenti ("gap") tra la qualità del prodotto richiesto (e quindi atteso) dal cliente e quella percepita a fronte del pro-dotto realizzato. I gap proposti sono 5 quanto quelli del modello originale, ma con una di-versa interpretazione legata alle singole fasi del ciclo di vita del software. Per la valutazione dei singoli gap si utilizza un questionario da sottoporre al cliente all’inizio del progetto ed al suo temine; il primo questionario aiuta a rilevare le esigenze, il secondo a valutare il grado di soddisfacimento delle stesse. Il modello è stato sperimentato presso un gruppo di piccole e medie imprese informatiche italiane che hanno permesso la sua messa a punto; in seguito, non è stato divulgato nell’ambiente dello sviluppo software per vari motivi. Il presente articolo vuole essere un’occasione per condividere il modello con il mondo dello sviluppo software

Il modello SERVQUAL nasce negli anni ’80 per fornire alle aziende di servizi un metodo empirico e di riferimento per valutare e migliorare la qualità dei servizi erogati. Il modello si basa sulla capacità di valutare oggettivamente la percezione che gli utenti hanno del servizio ricevuto e del servizio atteso. La differenza (gap) tra le due percezioni determina la valutazione della qualità del servizio erogato. Il gap permette quindi di misurare quanto la qualità del servizio erogato si avvicini (o si allontani) da quella attesa dagli utenti cui è destinato. La qualità del servizio erogato dipende, a sua volta, dalla capacità del fornitore di interpretare le esigenze degli utenti e di trasformarle nella progettazione del sevizio che sarà erogato. Ad incidere sulla percezione che gli utenti hanno della qualità del servizio atteso contribuiscono, oltre alle proprie necessità, altri fattori come le comunicazioni esterne (pubblicità), l’esperienza altrui (passaparola) e l’esperienza diretta precedente. La metodologia permette di quantificare lo scostamento dei vari fattori menzionasti sopra rispetto ai valori attesi. Il modello originale specifica cinque dimensioni della qualità dei servizi con cui effettuare le misurazioni e suggerisce dei questionari per rilevarle. Successivamente sono state aggiunte altre caratteristiche dei servizi; il modello attuale prevede: aspetti tangibili, affidabilità, reattivi-tà, competenza, cortesia, credibilità, sicurezza, accessibilità, comunicazione e conoscenza delle esigenze del cliente.

Il modello applicato al contesto dello sviluppo software
Il modello originale è stato modificato e sperimentato dall’autore nel contesto dello sviluppo software con il coinvolgimento di un gruppo di piccole e medie imprese informatiche. Esso risulta essere quindi totalmente originale ed è mostrato nella figura che segue.

Nella figura si evidenzia la distinzione l’ambito delle responsabilità del cliente da quelle del fornitore; le linee tratteggiate indicano gli scostamenti (gap) che permettono di misurare la qualità nei diversi momenti del ciclo di vita.
I cinque scostamenti si riferiscono ai seguenti elementi tipici di un progetto software:
Gap 1: Scostamento tra la qualità attesa dal cliente e quella percepita dai responsabili del progetto.
Gap 2: Scostamento tra la qualità percepita dai responsabili del progetto e quella definita nelle specifiche del prodotto.
Gap 3: Scostamento tra la qualità espressa nelle specifiche del prodotto e quella effettivamente sviluppata.
Gap 4: Scostamento tra la qualità sviluppata nel prodotto e quella dichiarata.
Gap 5: Scostamento tra la qualità attesa e quella percepita in fase di collaudo o in esercizio.
L’interpretazione del modello e dei gap è intuitiva a chi si occupa di sviluppo software. L’ingegneria del software ed i vari modelli di qualità (ISO 9001, ISO 9126, CMMI, ecc.) pongono tutti l’accento sull’interpretazione delle reali esigenze e sulla capacità di tradurli in requisiti prima, in specifiche di disegno poi, e nel prodotto finale al termine del ciclo di sviluppo. Il presente modello mette in luce tali elementi in uno schema nuovo e fornisce metodi e metriche per valutarne il livello di qualità durante il ciclo di vita ed al suo termine.

Qualità
Qualità attesa
La “qualità attesa” rappresenta l’insieme delle necessità reali del cliente espresse dalle funzioni di business, da vincoli, leggi e normative, ecc. Essa rappresenta l’elemento fondamentale per il cliente, la necessità di investire in un progetto realizzativo. Può essere in parte esplicita ed in parte no. La parte esplicita è generalmente rappresentata dai requisiti funzionali e prestazionali, anche se, spesso, questi ultimi non sono esplicitati in maniera completa e chiara. Gli elementi meno espliciti si riferiscono anche ai limiti e vincoli imposti al sistema, alle leggi e normative cui sottostare, agli standard di mercato da rispettare, ecc. La parte non esplicita, e più difficile da definire, riguarda il contesto culturale e operativo al quale la soluzione finale è rivolta.
In breve, possiamo definire come qualità attesa “tutto ciò che il cliente si aspetta dalla soluzione finale”. Essa potrà anche non essere stata completamente e chiaramente esplicitata dal cliente ma, sicuramente, lo è nella sua mente e, quindi, nelle sue aspettative. Ad essa il cliente farà riferimento per valutare l’adeguatezza della soluzione finale realizzata.
Nella figura sono mostrati tre elementi che contribuiscono a creare la qualità attesa: gli standard di mercato, le esigenze di business ed il contesto culturale ed operativo.
E’ facile intuire, quindi, quanto sia importante per il progetto capire esattamente “cosa” si debba realizzare. La comprensione delle esigenze e del contesto, e la sua traduzione in requisiti completi, chiari e condivisi, è il primo problema da affrontare e risolvere; il primo anello della catena da realizzare! Si parla di problema in quanto lo è nella maggior parte dei progetti.
Il modello proposto definisce un questionario che aiuta a rilevare “la qualità attesa”.
Qualità percepita dal cliente
Il termine “percepita” indica già di per sé un’ambiguità e, quindi, un elemento di criticità. La “qualità percepita” rappresenta infatti la percezione che il cliente – nella veste degli utenti finali, dello sponsor e del responsabile del progetto – ha della soluzione finale realizzata. Si tratta, in sintesi, della valutazione effettuata tramite il collaudo di accettazione. La percezione è quindi influenzata dal metro di giudizio dei partecipanti al collaudo. Tale valutazione, altrettanto soggettiva, è anche data dagli unteti finali del prodotto in esercizio.
La soggettività è influenzata da diversi fattori, alcuni espliciti e chiaramente identificabili, ed altri maggiormente legati all’esperienza personale dei singoli. I fattori che possono mitigare la soggettività del giudizio sono sicuramente i requisiti espliciti e cioè definiti, documentati, concordati ed aggiornati durante lo svolgimento del progetto. Questi rappresentano quindi un primo importante elemento di controllo della qualità come accennato nel punto precedente. La corretta gestione dei requisiti è infatti una “best practice” inclusa in tutti i modelli di eccellenza (ISO 9001, CMMI, ecc.).
La parte più soggettiva, e quindi più critica dal punto di vista gestionale, è quella relativa al contesto nel quale il prodotto finale sarà adoperato. Esso è composto da persone con esperienza, necessità, modalità operative, abitudini, preferenze diverse. Ciascun utente finale ha una personale “visione/aspettativa” della soluzione ed un suo proprio “metro di giudizio”. Una stessa soluzione, infatti, acquista una diversa valenza a seconda del contesto nel quale è valutata. Il contesto determina perciò il metro di giudizio è dovrà essere attentamente preso in esame all’inizio del progetto. Esso è uno dei tre elementi che determinano la qualità attesa descritta nel punto precedente.
Un ulteriore elemento di valutazione è data dal raggiungimento degli obiettivi attesi dalla direzione come ritorno dell’investimento nel progetto. Agli obiettivi tradizionalmente indicati come tali -  rispetto dei tempi di consegna, contenimento dei costi entro il budget e aderenza completa ai requisiti – si aggiungono altri obiettivi come, ad esempio, “migliorare la produttività dell’organizzazione”, “ridurre i tempi di alcuni processi di business”, “ridurre i costi medi di alcune transazioni di business”, “produrre informazioni puntuali per le decisioni strategiche ”, ecc. Si tratta, come si vede, di requisiti che non sempre sono documentati, concordati e, quindi, inclusi nella progettazione. 
La soluzione finale, in sintesi, ha una sua “qualità percepita” risultato della valutazione nel contesto finale di utilizzo. Il modello ISO 9126 chiama tale caratteristica “qualità in uso”.
Il modello proposto suggerisce di rilevare la qualità percepita, al termine del progetto, con lo stesso questionario utilizzato per rilevare la qualità attesa all’inizio del ciclo di vita. Le domande, in questo caso, sono poste in termini di “valutazione” invece che di “aspettativa. 

Qualità percepita dai responsabili del progetto
La qualità, così come percepita dai vari componenti del gruppo di progetto, rappresenta, di volta in volta, cosa “pensano di aver capito” i singoli attori relativamente alle esigenze del cliente. Essi hanno una percezione delle esigenze del cliente basata sui diversi dati di input acquisiti (interviste, conversazioni, presentazioni, documentazione, ecc.). A queste si aggiungono spesso interpretazioni dettate più da esigenze interne del fornitore che non del cliente (esempio, interesse a fornire una soluzione preesistente a minor costo, necessità di chiudere la trattativa nel più breve tempo possibile, ecc.). All’attività di raccolta ed analisi delle esigenze del cliente partecipano più persone del fornitore: commerciale, analista, capo progetto. Anche la direzione tecnica ha contatti con il cliente e riceve, più o meno esplicitamente e più o meno formalmente, richieste, raccomandazioni, vincoli ecc. Questi possono essere espressi in termini di requisiti funzionali o prestazionali ad alto livello, obiettivi di business, strategie aziendali, piani e programmi operativi, ecc.
Ogni attore partecipante alla fase iniziale di analisi acquisisce una propria percezione delle esigenze del cliente: quella della direzione tecnica sarà di livello più alto e necessariamente diversa da quella maturata dagli analisti che si concentreranno maggiormente sugli aspetti funzionali. E sarà anche diversa da quella percepita dal capo progetto che tenderà a vedere maggiormente gli aspetti organizzativi, di tempificazione e legati ai costi del progetto. Tutti questi aspetti non sempre saranno inclusi in maniera chiara ed esaustiva nei requisiti prestazionali, importanti, invece, per i progettisti che disegneranno una soluzione architetturale ed applicativa del sistema legata alla loro percezione. Quest’ultima, infine, sarà tradotta dai programmatori nel software sviluppato e che contrasterà, spesso, con la percezione che ne avranno gli addetti al test.
Più attori e più percezioni di uno stesso elemento fondamentale: le esigenze del cliente. Nasce quindi perentoria la necessità, da parte dei responsabili, di gestire tali diversità di percezione in maniera opportuna - sistematica e consistente - per garantire una qualità finale il più possibile vicina a quella attesa. Il problema è ben noto al mondo dello sviluppo software e sono disponibili modelli efficaci al riguardo. La “gestione dei requisiti” e lo “sviluppo dei requisiti” sono best practice cui fare esplicito riferimento.
Il modello proposto suggerisce di utilizzare il questionario iniziale come lista di controllo per verificare la corretta comprensione delle esigenze del cliente nelle prime fasi del ciclo di vita.
Qualità realizzata
La “qualità realizzata” è quella che deriva dal progetto di sviluppo. Essa è valutabile in base alle metriche adoperate e stabilite nel piano della qualità del progetto. La valutazione della qualità finale del prodotto software misura quindi quanto siano stati raggiunti gli obiettivi di qualità stabiliti. E’ bene ribadire, a questo punto, quanto sia importante stabilire obiettivi di qualità che rispecchino le reali esigenze del cliente, che siano misurabili e che vi si associno valori raggiungibili. E’ altrettanto importante stabilire un processo che ne garantisca il controllo durante l’intero ciclo di vita evitando di scoprire a fine progetto che tali obiettivi siano stati raggiunti solo in parte.
Il modello proposto suggerisce di utilizzare il questionario iniziale come lista di controllo per verificare la corretta comprensione e sviluppo delle esigenze del cliente durante l’intero ciclo di vita.
Qualità dichiarata
La “qualità dichiarata” rappresenta gli impegni presi relativamente alla realizzazione della soluzione. Tali impegni sono generalmente quelli espressi come obiettivi del progetto: tempi, costi e qualità. Essi sono formalizzati nel contratto e poi dettagliati nei piani di progetto. Un primo elemento di ambiguità è generato dal termine “qualità”. Esso, infatti, è più o meno condiviso tra cliente e fornitore a seconda del livello di dettaglio, completezza e chiarezza cui si giunge nella formalizzazione. Si è già detto, a proposito della qualità attesa, quanto sia importante chiarire l’insieme delle caratteristiche del prodotto e del suo utilizzo ai fini della sua accettazione finale.
L’incompletezza e la scarsa chiarezza nella definizione delle aspettative del cliente portano spesso a definire contratti altrettanto incompleti e ambigui. E ciò potrebbe anche essere comprensibile in un momento iniziale in cui i requisiti sono realmente poco chiari a tutti, cliente compreso. Tale indeterminazione deve essere però drasticamente ridotta nelle prime fasi del progetto ed esplicitata nei documenti prodotti e condivisi: documento dei requisiti, piano di progetto, piano di qualità. Questi tre documenti rappresentano, infatti, una formalizzazione dettagliata degli impegni assunti e, quindi, descrivono la “qualità dichiarata” del progetto. Ad essa si farà esplicito riferimento in fase di valutazione della soluzione finale ai fini della sua accettazione. Occorre inoltre prevedere una corretta gestione delle modifiche in corso d’opera in quanto le attese possono cambiare anche di molto lungo il progetto. La qualità dichiarata, al pari di quella attesa, è dunque dinamica e va gestita di conseguenza.
La qualità dichiarata sarà inoltre utile ai fini dell’esito positivo del collaudo di accettazione in base alla sua capacità di descrivere le “aspettative” reali del cliente e dei suoi utenti finali così come concordata durante il corso del progetto. Requisiti completi e chiari, piani di progetto realistici e obiettivi raggiungibili sono elementi cui nessun progetto può rinunciare.    
Scostamenti
Gap 1: Scostamento tra la qualità attesa dal cliente e quella percepita dai responsabili del progetto
“Qualità dei requisiti” è  il nome dato al gap e rappresenta il divario che si crea quando la nostra interpretazione dei requisiti si discosta dalla reale esigenza del cliente. Qui il termine requisiti è inteso nella sua accezione più generale ed include i requisiti veri e propri, funzionali e prestazionali, ma anche i vincoli ed i limiti, gli standard e le condizioni al contorno, il contesto di riferimento, culturale e operativo. Quanto minore è tale divario tanto più basso sarà il rischio di realizzare un prodotto che non soddisfi il cliente e non incontri la qualità attesa. Capire i reali bisogni è condizione necessaria ed imprescindibile per il successo del progetto.
Il processo che permette di gestire il gap 1 è noto come “ingegneria dei requisiti” e quindi non ci dilunghiamo più di tanto su di esso; ricordiamo solo che esso prevede le fasi di raccolta ed analisi dei requisiti, definizione delle priorità, documentazione e condivisione con il cliente, gestione delle modifiche in corso d’opera. Per ridurre il gap è bene condividere con il cliente i requisiti iniziali e le successive modifiche.
La ricerca effettuata dall’autore in questo campo ha permesso di formulare il questionario da sottoporre ai clienti relativamente alle loro aspettative; queste si possono riassumere in tre elementi principali: “certezza della bontà della soluzione”, “certezza dei costi” e “certezza dei tempi di realizzazione”. Si tratta degli obiettivi tipici di ogni progetto: rispetto dei tempi di consegna, contenimento dei costi nei budget stabiliti e qualità della soluzione realizzata. Questi elementi si traducono in altrettante caratteristiche richieste al fornitore cui si affida il progetto: “competenza, affidabilità e flessibilità”. Esse identificano i soggetti inclusi a pieno titolo tra i fornitori qualificati: partner cui affidare i progetti più importanti.
Il questionario proposto è stato progettato a tal fine.
Prospettiva del cliente
La ricerca effettuata dall’autore in questo campo ha portato a formulare il questionario da sottoporre ai clienti relativamente alle loro aspettative; queste si possono riassumere in tre elementi principali: “certezza” della soluzione, dei costi e dei tempi di realizzazione. Si tratta degli obiettivi tipici di ogni progetto: rispetto dei tempi di consegna, contenimento dei costi nei budget stabiliti e qualità della soluzione realizzata. Questi elementi si traducono in altrettante caratteristiche richieste al fornitore cui si affida il progetto: competenza, affidabilità e flessibilità. Esse identificano i soggetti inclusi a pieno titolo tra i fornitori qualificati: partner cui affidare i progetti più importanti.
Il significato del termine “certezza” utilizzato dalla maggior parte dei clienti intervistati è chiaro: possibilità di pianificazione strategica e di conseguimento dei risultati attesi. Ciò si traduce in affidabilità del fornitore. Ma anche in competenza realizzativa e capacità di gestire i cambiamenti in corso d’opera. Tutto torna. Vediamo allora un po’ più in dettaglio le tre caratteristiche richieste ai fornitori.
Competenza è la caratteristica richiesta al fornitore cui si affida il progetto realizzativo ed è intesa principalmente dal punto di vista tecnico. E’ quindi rivolta in primo luogo al personale tecnico che effettua l’analisti, la progettazione, la programmazione, il test ed il supporto tecnico. In sintesi, si tratta della capacità di realizzare una buona soluzione tecnica che indirizzi al meglio le esigenze funzionali e prestazionali del cliente.
Affidabilità è invece la caratteristica chiesta al fornitore perché ci si possa fidare in quanto capace di adempiere a tutti gli impegni assunti. In questo caso ci si riferisce principalmente alla capacità di completare il progetto nei tempi previsti, contenendo i costi entro i budget e realizzando la soluzione con la qualità attesa. La caratteristica si riferisce principalmente alla gestione dei progetti e vede coinvolti in prima persona i responsabili, capi progetto, direttore tecnico e commerciali. L’inclusione del direttore tecnico e del commerciale è giustificata dai clienti intervistati dalla necessità di coinvolgere l’azienda fornitrice nella sua globalità, a tutti i livelli; evitando cioè di addossare al capo progetto ogni responsabilità dell’esito del progetto.
Flessibilità, infine, rappresenta la caratteristica di adattarsi positivamente alle mutate esigenze del mercato e del contesto del cliente. L’intervista ad un responsabile IT di un grande cliente descrive molto bene tale concetto. “Sarebbe bello stabilire piani precisi – dice il cliente intervistato - ed avere la certezza che essi non cambino mai. Piacerebbe anche a me, oltre che ai miei fornitori; purtroppo, non è mai così nella realtà in cui operiamo. Il mercato cambia più rapidamente di quanto possiamo immaginare. Dobbiamo reagire prontamente con soluzioni adeguate che mettono alla prova le nostre capacità. Dico “nostre” – ribadisce il cliente – perché si tratta di un gioco di squadra in cui entrambi vinciamo o perdiamo. Ma non sempre i fornitori si dimostrano all’altezza della situazione. Spendo più tempo a convincere il fornitore della necessità delle modifiche che a definire la migliore strategia di cambiamento. Altro problema – conclude – sono i costi che lievitano nel tempo più di quanto ci si possa immaginare. Qualche volta, i costi finali non giustificano l’investimento! Ma così è e dobbiamo imparare a convivere con quello che abbiamo a disposizione”.

Prospettiva del fornitore
La percezione che il management del fornitore ha di tali aspettative coincide solo teoricamente; nella pratica essa è inficiata da un problema di fondo: la necessità di chiudere contratti a breve e la difficoltà oggettiva ad investire nel rapporto di partnership, strategicamente migliore ma tatticamente in conflitto con gli obiettivi a breve termine.
Il management tende a coinvolgere le migliori risorse disponibili nell’interpretare le esigenze del cliente e a formulare una buona soluzione. Questo, generalmente, indirizza correttamente le esigenze del cliente ma finisce per degradare lungo lo svolgimento del progetto a causa di stime ottimistiche e piani poco realistici. Le modifiche in corso d’opera, poco e mal gestite, finiscono per compromettere le qualità del risultato finale.
Il sistema di gestione per la qualità basato sulle norme ISO 9001:2000 prevede al riguardo una clausola ben precisa richiedendo attività di riesame, verifica e validazione per garantire la piena e corretta interpretazione dei requisiti.
Collaborazione cliente-fornitore
Esistono, come si è visto, gli strumenti adatti a garantire la corretta interpretazione delle aspettative del cliente. Perché ciò sia efficace nella sostanza, oltre che nella forma, si suggerisce il pieno “coinvolgimento del cliente” in tale fase. Solo il cliente, infatti, potrà affermare se il suo fornitore abbia pienamente capito o meno le reali esigenze. Ciò richiede un rapporto maturo di collaborazione tra cliente e fornitore.
Gap 2: Scostamento tra la qualità percepita dai responsabili del progetto e quella definita nelle specifiche del prodotto
“Qualità della progettazione” è il titolo di questo gap. Essa rappresenta il grado di aderenza della soluzione disegnata alle esigenze del cliente, presenti e future. Una progettazione di qualità indirizza correttamente tutti i requisiti del cliente calati nel contesto attuale; ma è anche in grado di accogliere, in maniera non traumatica, le inevitabili modifiche richieste dall’evoluzione del mercato e dal relativo mutato contesto operativo.
Il gap misura lo scostamento della soluzione progettata rispetto alle esigenze attese dal cliente.
L’elemento valutato da tale misurazione fa riferimento alle specifiche della soluzione tecnica ed applicativa definita. L’ingegneria del software assegna alla fase di analisi e disegno la responsabilità di definire la soluzione che indirizzi tutti i requisiti del cliente. Le specifiche rappresentano la descrizione della soluzione individuata che si andrà a sviluppare.
Effettuare revisioni tecniche (ispezioni) dei documenti di specifica costituisce una best practice di enorme valore; il suo obiettivo è garantire la massima copertura dei requisiti da parte della soluzione identificata e la sua correttezza. Tutti i modelli di qualità indicano in attività di revisione, verifica e validazione della progettazione un elemento importantissimo ai fini della qualità del prodotto finale.
Il questionario proposto può essere utilizzato come checklist nelle revisioni tecniche per verificare l’aderenza delle specifiche del prodotto alle esigenze del cliente.  
Gap 3: Scostamento tra la qualità espressa nelle specifiche del prodotto e quella effettivamente sviluppata
“Qualità del software” è il nome dello scostamento in oggetto. Esso misura quanto il software sviluppato si discosti dalle aspettative di qualità espresse dal cliente e, quindi, attese. Nel campo ingegneristico che stiamo trattando, parliamo della qualità del software intesa come piena aderenza ai requisiti espressi dal cliente. E’ buona prassi tradurre i requisiti di qualità in un “profilo di qualità del prodotto” da inserire nel piano della qualità con relative metriche, valori da raggiungere e azioni concrete da intraprendere.
L’ingegneria del software, come pure i modelli di qualità e di eccellenza, identificano nei test e collaudi le azioni da intraprendere per verificare e validare la qualità del prodotto realizzato.
Il questionario compilato all’inizio del progetto può essere utilizzato come lista di controllo per valutare il grado di aderenza del profilo di qualità del prodotto alle necessità del cliente e, nel corso del progetto, per valutare l’aderenza della qualità raggiunta rispetto allo stesso target.
Gap 4: Scostamento tra la qualità sviluppata nel prodotto e quella dichiarata
“Qualità promessa” potrebbe essere il nome della qualità espressa nell’offerta e nei piani di progetto. Il gap misura il divario tra quanto specificato in tali documenti e quanto, invece, è stato realizzato praticamente al termine del progetto. La qualità di tale comunicazione è di tipo formale e di tipo sostanziale.
L’aspetto formale riguarda la nostra capacità di comunicare in maniera chiara ed esaustiva. Anche da essa dipende l’aspettativa che il cliente si crea. Frasi generiche, aggettivi inappropriati, mancanza di completezza nella descrizione della soluzione finale, ecc. portano a percepire più di quanto si intenda comunicare e, concretamente, si possa mantenere come impegno.
L’aspetto sostanziale dipende invece dalla qualità oggettiva dei prodotti e semilavorati realizzati (documenti, piani, stime, rapporti, prototipi, codice, manuali, ecc.). Piani realistici basati su requisiti condivisi e su stime accurate, rapporti periodici chiari e completi sono sintomi di una buona comunicazione. La completezza e la correttezza dei documenti contribuiscono alla qualità della comunicazione; la puntualità con cui sono prodotti i report sullo stato di avanzamento del progetto e la completezza delle informazioni fornite sono sintomo di una comunicazione efficace, di qualità. L’identificazione dei rischi di progetto, la valutazione delle possibili conseguenze sui risultati attesi e l’adozione di efficaci contromisure devono essere comunicate e mai taciute, come spesso avviene.
Il questionario messo a punto può fungere da lista di controllo per valutare la capacità di comunicare in sintonia con le aspettative del cliente, con la qualità attesa.
Gap 5: Scostamento tra la qualità sviluppata e quella percepita in fase di collaudo o in esercizio
“Qualità finale” possiamo chiamare quella che il cliente rileva quando, al termine del progetto, valuta il prodotto finale per accettazione e successiva messa in esercizio. Il gap rappresenta quindi il divario tra quanto si è realizzato e quanto il cliente si attende. La valutazione si basa sull’esito del collaudo; l’esito porta all’accettazione o meno del prodotto finale. In senso figurato si tratta della “resa dei conti”, la valutazione dell’intero progetto. Un collaudo con esito negativo richiede lavoro aggiuntivo - non previsto dalle stime iniziali - per correggere gli errori, modificare le incongruenze o mancanze, ecc. Tale gap, più di ogni altro, comporta dispendio di tempo e risorse con ripercussioni negative sui costi del progetto e sui tempi di consegna.
Il questionario messo a punto dal modello proposto permette di verificare, prima del collaudo, se i test interni siano stati esaustivi, abbiano coperto i requisiti ed indirizzate le aspettative del cliente. 
Le dimensioni della qualità del software
Il modello utilizza la definizione di 3 dimensioni della qualità concordate con i clienti per valutare il prodotto, il progetto realizzativo e l’organizzazione del fornitore.
1. Caratteristiche del prodotto. Esse indicano aspetti tangibili come la completezza e la correttezza delle funzioni rese disponibili agli utenti, le prestazioni e la facilità d’uso, l’integrazione nell’ambiente operativo in cui è installato e la robustezza di operare in condizioni critiche, la protezione contro intrusioni non autorizzate, ecc. Tali caratteristiche sono ben definite dal modello ISO 9126 per la qualità del software. Non tutte queste caratteristiche si applicano a tutti i prodotti software. Esse saranno definite per ogni singolo sviluppo attribuendone l’importanza, le metriche per misurarle ed i valori target da raggiungere per ciascuno di essi. Il piano di qualità del prodotto descrive il “profilo di qualità” del prodotto e le relative metriche per valutarne il risultato finale. Il gap 5 misura tale divario, tra qualità attesa e qualità percepita. A queste caratteristiche occorre aggiungerne altre relative a standard e norme applicabili, a  limiti e vincoli imposti, ad esigenze specifiche del contesto culturale ed operativo in cui la soluzione sarà calata nella realtà. Il questionario predisposto permette di indirizzare anche questi aspetti.
2. Caratteristiche del progetto. Esse indicano aspetti altrettanto tangibili del progetto: tempi di consegna da rispettare e costi da contenere entro i budget stabiliti. I progetti presentano altre caratteristiche da tenere in considerazione: comunicazione periodica sullo stato di avanzamento delle attività, sui problemi incontrati e relative azioni messe in atto, sui rischi individuati e azioni di contenimento avviate, sulle modifiche richieste e loro impatto sul progetto, ecc. Un progetto rappresenta un investimento importante per il cliente e testimonia la capacità realizzativa del fornitore; entrambi sono interessati a definire obiettivi, limiti e contesto che permettano di valutare in maniera oggettiva il successo del progetto. I piani di progetto rappresentano lo strumento per la condivisione di tali elementi. Il questionario messo a punto dal modello utilizza metriche tipiche del project management basate su tali caratteristiche e permette di valutare la qualità “dichiarata/comunicata” su cui ci si impegna e su cui saremo valutati. Il gap 4 misura appunto tale scostamento. 
3. Caratteristiche dell’organizzazione. Esse indicano la competenza, l’affidabilità e la flessibilità dimostrate dal fornitore durante l’intera esecuzione del progetto. Le tre caratteristiche sono state definite dai clienti intervistati come le più importanti - e, purtroppo, maggiormente carenti - in base all’esperienza. Esse sono indirizzate da specifiche domande nel questionario messo a punto e permettono di valutare la capacità del fornitore di creare e consolidare un clima di fiducia ed un rapporto di collaborazione duraturo. Sono state definite, anche, come le tre caratteristiche principali per la costruzione di un rapporto di “partnership” efficace.
Il modello non può, da solo, risolvere i problemi che un'organizzazione ha nel realizzare prodotti software; esso rappresenta, invece, un validissimo strumento per analizzare lo stato attuale, individuare le cause dei problemi e trovare le giuste soluzioni. Si tratta quindi di uno strumento e non di una soluzione!
Gestione dei gap
Metodi, tecniche, strumenti e metriche
La tabella che segue sintetizza i metodi che possono aiutare a ridurre i gap e aumentare, quindi, la qualità dei prodotti realizzati. Sono anche indicati tecniche e strumenti, e metriche per la valutazione oggettiva del livello di miglioramento delle prestazioni.

Questionario
Di seguito è riportato il questionario messo a punto con la collaborazione di un gruppo di im-prese informatiche e la successiva valutazione da parte di alcuni clienti interessati. Per ogni domanda si richiede di fornire un valore numerico, tra 1 e 10, che rappresenti l’importanza del tema ai fini delle aspettative reali del cliente. Lo stesso questionario è successivamente sottoposto al cliente al termine del progetto. Le domande saranno poste “al futuro” la prima volta e “al passato” la seconda. La differenza tra i due valori rappresenta lo scostamento tra aspettative e percezione finale. Il valore di ciascun tema trattato fornirà indicazioni preziose per capire quali elementi determinano il successo o l’insuccesso. Il questionario è utilizzato anche come lista di controllo (checklist) durante le diverse fasi del ciclo di vita per valutare, di volta in volta, il livello di qualità raggiunto al momento; si tratta quindi di un’azione preventiva ai fini del risultato finale.

Il questionario utilizzato al termine del progetto per rilevare la qualità percepita dal cliente formula domande rivolte alla valutazione di ciò che è stato realizzato. Segue un esempio delle prime due domande del questionario:
1.         La soluzione finale ha realizzato in maniera completa e corretta tutte le funzionalità richieste?
2.        La soluzione finale garantisce prestazioni in linea con le esigenze operative in termini di usabilità, performance, sicurezza, affidabilità, portabilità, manutenibilità?

Conclusioni
Il modello è stato applicato, in via sperimentale, in alcuni progetti per determinarne la validità e migliorarne l’efficacia. I risultati ottenuti confermano l’analisi ricavata anche da studi analoghi eseguiti con tecniche diverse. In ordine di priorità (o gravità!) gli scostamenti maggiori sono relativi ai seguenti temi: ritardo nei tempi di consegna, superamento del budget stabilito, mancata accettazione del prodotto finale da parte degli utenti per mancanza di funzionalità necessarie, per errato sviluppo di quelle previste e per prestazioni non in linea con le necessità operative.
L’analisi di dettaglio dei singoli elementi ha inoltre evidenziato problemi nelle seguenti aree: carenza nella comprensione dei requisiti, gestione non adeguata delle modifiche in corso d’opera, stime poco accurate, pianificazione poco realistica, scarso coinvolgimento del management nelle decisioni importanti, competenza non adeguata del personale tecnico (specialmente quello responsabile della progettazione), test inadeguati alla complessità e criticità del software per il business del cliente, scarso utilizzo di revisioni tecniche nelle fasi alte del ciclo di vita.
Lo studio in oggetto porta ad una conclusione importante: lo sviluppo del software è un’attività creativa e tecnica ad altissimo contenuto umano; necessita perciò di professionisti con grande competenza, capaci di realizzare software di qualità in un ambiente maturo dove i risultati siano prevedibili e raggiungibili e non lasciati al caso. Gli esempi di successo sono quasi sempre determinati dall’atteggiamento “eroico” di poche persone ancora innamorate di questo mestiere! Una formazione robusta, a tutti i livelli, dal management ai singoli tecnici, è l’azione da cui partire. Migliorare i processi di sviluppo adottando le migliori pratiche disponibili (es.: CMMI) è il secondo passo. Adoperare strumenti di produttività è il terzo.
I vari modelli, tra cui quello presentato in questo articolo, sono solo strumenti per chi voglia migliorare e non rappresentano in alcun modo la soluzione del problema. L’organizzazione deve migliorare facendo tesoro della propria esperienza e di quella altrui.