L'articolo analizza l'applicazione del modello SERVQUAL nello sviluppo software, evidenziando cinque gap tra le aspettative e la qualità percepita del prodotto. Viene proposto un questionario per raccogliere le esigenze del cliente all'inizio e per valutare la soddisfazione alla fine del progetto. La metodologia è stata sperimentata con piccole e medie imprese italiane, ma richiede maggiore divulgazione nel settore per migliorare la qualità del software.

1. 1
Il modello SERVQUAL applicato allo sviluppo
del software
I Gap da colmare per realizzare software di successo
Ercole Colonese, 2009
Articolo pubblicato su “Qualità On Line, N. 1-2009, maggio.
Notiziario dell’AICQ – Associazione Italiana Cultura Qualità”
Sommario
Il modello SERVQUAL è stato messo a punto da Valerie
A. Zeithaml, A. Parasuraman e Leonard L. Berry per valu-
tare la qualità di un servizio erogato rispetto alle esigen-
ze del cliente; aiuta quindi ad individuare le aree di po-
tenziale miglioramento.
In questo articolo si presenta la trasposizione del model-
lo nello sviluppo del software; si applica cioè alla realiz-
zazione di un prodotto invece che di un servizio, come
indirizzato dal modello originale. La tecnica proposta
permette di valutare gli scostamenti ("gap") tra la quali-
tà del prodotto richiesto (e quindi atteso) dal cliente e
quella percepita a fronte del prodotto realizzato. I gap
proposti sono 5 quanto quelli del modello originale, ma
con una diversa interpretazione legata alle singole fasi
del ciclo di vita del software.
Per la valutazione dei singoli gap si utilizza un questiona-
rio da sottoporre al cliente all’inizio del progetto ed al
suo temine; il primo questionario aiuta a rilevare le esi-
genze, il secondo a valutare il grado di soddisfacimento
delle stesse.
Il modello è stato sperimentato presso un gruppo di pic-
cole 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 sof-
tware
Indice
Sommario.......................................................................1
Introduzione...................................................................2
Il modello applicato al contesto dello sviluppo
software.........................................................................2
Qualità del software......................................................3
Scostamenti...................................................................5
Le dimensioni della qualità del software.......................7
Gestione dei gap............................................................8
Conclusioni...................................................................10
Bibliografia ..........................................................................................
Articolo
Ercole Colonese
Consulenza di management e IT

2. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
2
Introduzione
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 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.
Figura 1. Modello SERVQUAL applicato allo sviluppo del software.
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.
Standard di mercato Esigenze di business Esperienza, contesto
Qualità attesa
(Esigenze)
Qualità percepita
(Collaudo/Esercizio)
Qualità realizzata
(Prodotto sviluppato)
Qualità della progetta-
zione (Specifiche)
Qualità percepita dai
responsabili del pro-
getto (Requisiti)
Qualità dichiarata
(Offerta, Piani di pro-
getto)
Cliente
Fornitore
Gap 4
Gap 1
Gap 2
Gap 3
Gap 5

3. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
3
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à del software
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,

4. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
4
“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

5. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
5
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

6. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
6
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 re-
sponsabili del progetto e quella definita nelle speci-
fiche 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.

7. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
7
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 svi-
luppata
“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 quel-
la 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

8. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
8
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 1 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.
Tabella 1. Metodi per ridurre i gap
Gap Metodica Tecniche/Strumenti Metriche
Gap 1
Condivisione dei requisiti con
il cliente.
Ispezione dei requisiti.
Condivisione dei requisiti con il cliente.
Realizzazione di prototipi.
Matrice dei requisiti.
Profilo di qualità del prodotto.
Livello di condivisione dei requi-
siti con il cliente.
Gap 2
Riesame, verifica e valida-
zione della progettazione.
Matrice di tracciabilità dei requisiti.
Prototipi dei componenti critici.
Ispezione del disegno.
Valutazione delle prestazioni del disegno del pro-
dotto.
Livello di copertura dei requisiti.
Accettazione dei prototipi.
Gap 3
Ispezione dei documenti di
progetto.
Copertura del test del sof-
tware.
Strategia e piano di test.
Casi di test e scenari di test.
Ambienti e strumenti per il test.
Livello di copertura dei test.
Rispetto dei valori target dei
requisiti di qualità.

9. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
9
Gestione degli errori. Matrice di copertura dei test.
Valutazione delle prestazioni del prodotto.
Rapporti esito test.
Errori rilevati dai test.
Gap 4
Stime accurate basate sui
requisiti condivisi. Pianifica-
zione realistica del progetto.
Piano della qualità.
Matrice di tracciabilità dei requisiti.
Verifica delle stime e revisione dei piani.
Gestione dei rischi.
Controllo dello stato di avanzamento del progetto.
Gestione dei problemi.
Assicurazione qualità di prodotto e di processo.
Ritardo nelle consegne.
Superamento dei costi.
Rilevi sui piani e sui report.
Gap 5
Condivisione del piano e de-
gli obiettivi del collaudo di
accettazione.
Condivisione del piano di collaudo e dei criteri di
accettazione.
Matrice di copertura del collaudo.
Gestione degli errori.
Copertura dei requisiti.
Numero e gravità di errori rileva-
ti.
Questionario
Di seguito è riportato il questionario messo a punto
con la collaborazione di un gruppo di imprese
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.
Tabella 2. Questionario
Area/Contenuti Valutazione
Qualità della soluzione
1. La soluzione finale dovrà realizzare in maniera completa e correttamente tutte le funzionalità richieste?
2. La soluzione finale dovrà garantire prestazioni in linea con le esigenze operative in termini di usabilità, performan-
ce, sicurezza, affidabilità, portabilità, manutenibilità, ecc.?
3. La soluzione finale dovrà rispettare i vincoli ed i limiti imposti, aderire agli standard e altre specifiche applicabili?
4. La soluzione finale dovrà calarsi senza impatti negativi nel contesto culturale e produttivo cui è destinato?
5. La soluzione finale dovrà superare tutti i criteri di accettazione stabiliti per essere accettata?
Efficacia del progetto
6. Il progetto dovrà essere basato sulle esigenze reali, su stime accurate e piani realistici?
7. Il progetto dovrà rispettare i tempi di consegna pianificati, finali ed intermedi?
8. Il progetto dovrà contenere i costi entro i budget stabiliti?
9. Il progetto dovrà garantire una comunicazione periodica sullo stato di avanzamento del progetto, sui problemi ed il
loro stato di risoluzione, i rischi e le azioni intraprese?
10. In caso di problemi seri al progetto si dovranno concordare con il management azioni adeguate?
Competenza, affidabilità e flessibilità dell’organizzazione
11. L’organizzazione del progetto dovrà avvalersi di personale tecnico adeguato, per numero e competenza, alla
complessità della realizzazione, ai tempi ed alla qualità attesa?
12. Il gruppo di lavoro dovrà assumersi le responsabilità di sua competenza collaborando con il cliente nella risoluzio-
ne pronta dei problemi?
13. L’organizzazione del progetto dovrà essere capace di proporre soluzioni innovative?
14. Il team di lavoro dovrà comunicare con regolarità e chiarezza lo stato del progetto?
15. L’organizzazione del progetto dovrà avere la flessibilità necessaria a gestire le modifiche in corso d’opera coeren-
temente con gli obiettivi del progetto e le mutate esigenze?
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?

10. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
10
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.
Bibliografia
Alessandro Banci, Giuseppe Iacono, La qualità nei
progetti software,1993, Franco Angeli
Ilene Burnstein et all., A Testing Maturity Model for
Software Test Process, Assessment and
Improvement, Illinois Institute of Technology, 1999,
ASQ
Capability Maturity Model® Integration (CMMISM),
V1.2, CMMI-DEV, V1.2 Improving processes for
better products – Carnegie Mellon, Software
Engineering Institute (SEI), CMMI Product Team,
December 2010
G.A. Cignoni, P. De Risi, Il test e la qualità del softwa-
re, 1998, Il Sole 24 Ore
Philip B. Crosby, La qualità non costa, 1986, McGraw-
Hill
Lesly Munro-Faure, Malcom Munro-Faure, Qualità
totale: tecniche di attuazione, 1994, Jackson Libri
Myers G. J., The art of Software Testing – Second Edi-
tion, 2004, John Wiley & Sons, New York
Stefano Nocentini, Il sistema di qualità del software,
1993, ETASLIBRI
Giorgio Pala, La qualità. Perché, per chi e come farla,
1994, Franco Angeli
Geary A. Rummler and Alan P. Brache, Improving
performance, Jossey, 1990, Bass Publishers
Donald J. Wheeler, Understanding Variation – The
Key To Managing Chaos, 1993, SPC Press
Valerie A. Zeithaml, A. Parasuraman, Leonard L.
Berry, Servire qualità, 1991, McGraw-Hill

11. Ercole Colonese, 2009, Il modello SERVQUAL applicato allo sviluppo del software
11
Ercole Colonese è consulente di Direzione, Organizzazione e IT, nell’ambito dello sviluppo
software e della gestione dei servizi IT.
La sua esperienza è maturata in moltissimi anni di lavoro presso i laboratori internazionali
IBM di sviluppo software, dove ha ricoperto ruoli tecnici, manageriali e dirigenziali.
E’ socio APCO. E’ membro del Consiglio Direttivo di AICQ-CI nel Sottocomitato per la Quali-
tà del Software e dei Servizi IT.
Collabora con Quality Solutions Srl, società di Consulenza.
Ha realizzato Sistemi qualità aziendali certificati ISO/IEC 9001 e Sistemi di gestione dei ser-
vizi IT certificati ISO 20000-1.
Ha implementato modelli di eccellenza (EFQM, Malcolm Baldrige, Six-Sigma).
Ha condotto progetti di reingegnerizzazione dei processi di sviluppo software in ottica di
miglioramento delle performance e della qualità. Ha applicato il modello di maturità Capa-
bility Maturity Model (SEI-CMMI).
Come docente, tiene corsi sui vari temi dell’Ingegneria del software e sui sistemi di gestio-
ne dei servizi IT presso società private ed enti. In passato ha tenuto corsi presso il Learning
Center IBM, l’Università Tor Vergata di Roma, il Politecnico di Vibo Valentia e l’Università
del Sacro cuore di Roma.
Ha collaborato con il CIRPS su progetti di ricerca tecnica.
Con il CNIPA (ora DigitPA) ha collaborato sul tema del riuso del software applicativo.
Collabora alla pubblicazione dei Quaderni AICQ con articoli monotematici sulla qualità del
software e dei servizi IT. Sempre con AICQ ha pubblicato il libro “Collaudo e qualità del sof-
tware” edito da Editrice UNI Service.
Articoli sull’Ingegneria del software sono pubblicati sul proprio sito all’indirizzo:
http://www.colonese.it/pubblicazioni/html.
e-mail: ercole@colonese.it www.colonese.it
Autore