LA QUALITÀ NEI PRODOTTI E SERVIZI

Alfonso Fuggetta

1. La complessità della valutazione della qualità

L’acquisizione, la valutazione, e l’utilizzo di beni e servizi è un processo complesso e

delicato. In particolare, valutare la qualità di beni e servizi risulta difficile, con risultati
che appaiono per lo più discutibili e spesso scarsamente verificabili. Il problema di fondo
è che il concetto di qualità assume connotazioni diverse in funzione dell’oggetto
esaminato, del contesto di analisi e del punto di vis ta dell’osservatore. In generale, con
“qualità” si intende l’insieme di attributi che caratterizzano un bene o un servizio, e che
ne determinano la capacità di soddisfare i bisogni impliciti e espliciti dell’utenza. Ma
quando questa definizione generale viene applicata ad uno specifico bene/servizio ci si
accorge che essa lascia adito ad un numero di possibili interpretazioni molto alto.

Quali sono le cause di questa difficoltà e quali i fattori che influenzano i processi di
valutazione della qualità dei beni e servizi? Non è facile fornire una visione sintetica del
problema, anche perché nella stessa comunità scientifica esistono differenze di opinione
anche molto marcate. Appare comunque possibile individuare un certo insieme di
concause e fattori che rendono complesso e critico il processo valutazione della qualità:

1. In primo luogo, il mondo delle tecnologie dell’informazione è

caratterizzato da una velocità e intensità di cambiamento che non ha
precedenti nella storia dello sviluppo industriale. Basti pensare a come
evolvono i mercati dei personal computer e delle tecnologie trasmissive. I
concetti di “veloce” e “capace” hanno un significato che muta anche
profondamente nel giro di pochi mesi. Allo stesso modo, nuovi servizi
nascono e si diffondono con una rapidità e una pervasività che non ha
precedenti nella storia dello sviluppo economico della nostra società. Nel
volgere di meno di un quinquennio, il Web e Internet, da strumenti
utilizzati sostanzialmente solo dal mondo della ricerca, sono divenuti una
delle principali occasioni di crescita economica e sociale di questo secolo.
Società come Amazon, nate pochi anni fa, hanno oggi giri di affari e
capitalizzazioni anche superiori a quelle di aziende consolidate. Ha fatto
scalpore il recente annuncio secondo il quale Yahoo (uno dei più famosi
“portal” di Internet) avrebbe superato come capitalizzazione in borsa il
Wall Street Journal. Quali sono i “parametri di qualità” per servizi così

1
 fortemente innovativi e per i quali non esistono significativi termini di
confronto?

2. I prodotti IT, e in particolare il software, sono contraddistinti da una

complessità estremamente elevata. Per esempio, anche strumenti di lavoro
molto diffusi e poco costosi come i programmi di produttività individuale
(fogli elettronici, word processor, …) sono costituiti da un numero
estremamente elevato di funzioni e “feature”, spesso fortemente integrate e
componibili. Nel caso di sistemi così complessi, risulta difficile enucleare
un insieme ragionevolmente limitato di parametri e caratteristiche che
possano rappresentare in maniera significativa il comportamento e le
prestazioni del sistema osservato.

3. Le tecnologie dell’informazione costituiscono il “sistema nervoso” di

moltissimi prodotti e servizi. Un aeroplano non può volare senza i
computer di bordo. La borsa non funzionerebbe senza i sistemi informatici.
Un’azienda di servizi di telecomunicazioni non potrebbe operare senza i
sistemi di supporto alla commutazione e gestione del traffico, o senza i
sistemi informatici di supporto ai call centers. Questa pervasività, se da un
lato può ancora una volta sottolineare la ricchezza e potenzialità delle
tecnologie dell’informazione, d’altro canto identifica anche una forte
criticità per ciò che concerne la valutazione della loro qualità. Infatti, in
tutti gli esempi proposti in precedenza le tecnologie dell’informazione sono
immerse all’interno di sistemi più complessi, siano essi strutture
organizzative come un call center o apparati elettromeccanici come un
aeroplano. Ciò che si può misurare, spesso, sono le caratteristiche
prestazionali del sistema complessivo, mentre risulta critico identificare il
contributo specifico delle tecnologie dell’informazione. Nel caso citato in
precedenza del sistema informativo di un call center, se l’operatore non
riesce a soddisfare le richieste di un utente, la colpa è da attribuirsi ad una
mancanza di professionalità dell’operatore o ad una “scarsa qualità” del
sistema informatico utilizzato dall’operatore per ricercare una soluzione ai
bisogni dell’utente?

4. Lo sviluppo del software, il cuore di un sistema informatico complesso, è

un’attività creativa che non può essere ricondotta alle tradizionali
produzioni manifatturiere. Non si tratta di progettare un bene e poi di
assemblarlo e costruirlo su larga scala (come nel caso di un auto o di
frigorifero). L’attività di progettazione e ideazione del bene “software” è
essa stessa il processo di “costruzione” del prodotto. Questo vuol dire che i
tradizionali modelli di controllo e gestione di attività manifatturiere
classiche trovano scarsa applicazione nel caso dei prodotti software e dei
relativi processi di sviluppo.

5. La valutazione di beni e servizi spesso è condizionata dalla cultura,

formazione, ruolo e attitudine dell’utente. Per esempio, ciò che è “facile da

2
 usare” per un utente, può non esserlo per altri. Il dibattito tra interfacce
grafiche (à la Windows) e interfacce tradizionali (per esempio DOS) è
ancora in corso e probabilmente non terminerà molto presto.

6. Ancora troppo spesso, la valutazione e lo studio dei prodotti IT, e in

particolare del software, si basa su competenze insufficienti e su una
sostanziale superficialità di chi gestisce tali processi di valutazione. Se
guardiamo, per esempio, a quanto si spende nella preparazione dei bandi di
gara per le opere di ingegneria civile e per lo sviluppo del software, ci
accorgiamo che mentre nel primo caso è normale considerare necessario
investire una percentuale anche non marginale del costo complessivo
dell’opera, nel caso del software si assume spesso che esso sia una
“commodity” e che la costruzione dei capitolati di gara sia un’attività di
tipo amministrativo e, magari, da delegare al fornitore.

Le precedenti osservazioni vogliono mettere in evidenza un fatto estremamente

importante: valutare la qualità di beni e servizi è un processo complesso, ancora non
ben compreso e fortemente influenzato da una serie di fattori organizzativi, culturali e
economici. Siamo solo all’inizio di un cammino verso una matura comprensione del
problema, anche se qualche risultato significativo è stato ottenuto.
Nei successivi paragrafi del capitolo verranno illustrati alcuni contributi sul tema qualità.
In particolare saranno discussi gli standard e modelli di qualità oggi disponibili, le
metriche e i metodi per la progettazione e gestione di sistemi di raccolta dei dati.

2. Standard di qualità: ISO 9000 e ISO 9126

I contributi forse più noti per ciò che concerne la qualità sono gli standard dell’ISO
relativi ai processi produttivi e di servizio, e ai prodotti software. In particolare, la serie
di standard ISO 9000 [5] si occupa di definire le caratteristiche e i requisiti di un sistema
di qualità aziendale (standard di processo), mentre lo standard ISO 9126 [4] definisce
alcune nozioni generali concernenti la qualità dei prodotti software (standard di
prodotto). Si noti che mentre la serie di standard ISO 9000 ha una campo di applicazione
che va ben al di là dei processi di sviluppo del software, lo standard ISO 9126 è specifico
dei prodotti software. Vediamo ora sinteticamente le caratteristiche e la struttura di
questi due standard.

2.1. ISO 9000

ISO 9000 è una collezione di documenti suddivisi in due macro categorie: linee guida e
standard veri e propri.
Gli standard della serie ISO 9000 sono tre (vedi Figura 1):
• ISO 9001: definisce il sistema per l’assicurazione di qualità per
un’azienda che svolge attività di progettazione, produzione, test,
installazione e fornitura di servizi di supporto.

3
 • ISO 9002: come lo standard ISO 9001 ma non considera la fase di
progettazione.
• ISO 9003: si limita a considerare la fase di test..

Installazione e
Progettazione Produzione Test
servizi

ISO
9003

ISO 9002

ISO 9001

Figura 1: Estensione degli standard della serie ISO 9000.

I tre standard citati in Figura 1 sono quindi alternativi: ciascuna azienda deve selezionare
il modello di qualità (e quindi lo standard) più vicino alle caratteristiche delle proprie
attività produttive o di servizio. Nel caso dello sviluppo di software lo standard utilizzato
è l’ISO 9001.

Al di là dei diversi livelli di copertura del processo aziendale, tutte e tre gli standard
hanno la stessa filosofia: essi descrivono i requisiti generali del sistema di controllo
utilizzato da un’azienda per verificare la qualità dei beni e servizi che essa offre
all’utenza. I requisiti contenuti negli standard della serie ISO 9000 non costituiscono di
per se stessi indicazioni puntuali su come il sistema di qualità debba essere realizzato.
Piuttosto, indicano l’obiettivo al quale l’azienda deve tendere. Come tali, sono il punto di
partenza per la realizzazione di un sistema di qualità aziendale, non certo il traguardo. La
trasformazione di tali requisiti in strutture organizzative e procedure operative richiede
un significativo lavoro da parte della singola azienda, che deve declinare i requisiti dello
standard all’interno della propria realtà.

Le linee guida sono state introdotte proprio per facilitare questo lavoro progettuale. Esse
coprono i seguenti argomenti:

• ISO 9000-1: Linee guida per la selezione degli standard ISO 9000.
• ISO 9000-2: Linee guida generali per l’applicazione degli standard della
serie ISO 9000.
• ISO 9000-3: Linee guida per l’applicazione dello standard ISO 9001 allo
sviluppo e manutenzione del software.
• ISO 9000-4: Linee guida per Dependability Programme Management.

4
 • ISO 9004-1: Elementi di un sistema di qualità – linee guida generali.
• ISO 9004-2: Elementi di un sistema di qualità – linee guida per i servizi.
• ISO 9004-3: Elementi di un sistema di qualità – linee guida per i
materiali.
• ISO 9004-4: Elementi di un sistema di qualità – linee guida per il
processo di miglioramento.

Per meglio comprendere la natura degli standard della serie ISO 9000, vediamo due
esempi tratti dalla norma ISO 9001. Essi riguardano le attività di progettazione e la
verifica di conformità dei prodotti acquisiti dal fornitore e utilizzati per le attività di
produzione e/o fornitura di servizi all’utenza.
“4.4 Design control
4.4.1 General
The supplier shall establish and maintain documented
procedures to control and verify the design of the product in
order to ensure that the specified requirements are met.”
…
4.10 Inspection and testing
…
4.10.2 Receiving inspection and testing
4.10.2.1
The supplier shall ensure that incoming product is not used or
processed […] until it has been inspected or otherwise verified
as confoming to specified requirements. Verification of the
specified requirements shall be in accordance with the quality
plan and/or documented procedures.”
Questi esempi confermano che gli standard ISO 9000 non indicano direttamente come le
diverse attività di controllo di qualità devono essere svolte. Essi si limitano ad elencare
tutti i passaggi chiave che un’azienda deve prevedere per poter disporre di un efficace
sistema di qualità.
Uno dei principali requisiti che un’azienda deve soddisfare per poter rendere i propri
processi conformi allo standard ISO 9000 è la creazione del manuale di qualità. Tale
manuale descrive tutte le procedure che l’azienda si impegna ad utilizzare per soddisfare
i requisiti contenuti nelle norme ISO 9000.
Come qualsiasi altro standard, la conformità di un’azienda ai requisiti degli standard
della serie ISO 9000 può essere certificata da un organismo di certificazione accreditato.
La conformità viene riconosciuta attraverso l’emissione di un certificato che ha una
durata limitata nel tempo. Questo vuol dire che l’azienda che vuol mantenere la
certificazione ISO 9000 deve periodicamente risottomettersi alle attività di
certificazione.

5
Le attività di certificazione ISO 9000 vengono effettuate da organismi che sono
accreditati a svolgere tale ruolo per uno specifico settore di mercato (per esempio,
l’industria meccanica piuttosto che quella chimica). In Italia, l’ente che coordina e
governa le attività legate alla normazione e agli standard è l’UNI (Ente Nazionale
Italiano di Unificazione). L’UNI ha definito un Sistema Qualità Italia (illustrato in
Figura 2) che è organizzato su tre livelli come descritto nella didascalia della figura.

IL LIVELLO DI RIFERIMENTO, che promulga norme tecniche essenziali per la

certificazione, e che garantisce, mediante l'accreditamento, le attività di prova e
certificazione. Appartengono a questo livello i MINISTERI coinvolti in questa attività,
il CNR, gli organismi di normazione UNI e CEI, gli organismi di accreditamento
SINAL e SINCERT, gli ISTITUTI METROLOGICI.
IL LIVELLO OPERATIVO PER LA QUALITA', che comprende i laboratori di
taratura e prova e gli organismi che certificano prodotti, sistemi di qualità e personale.
IL LIVELLO PRODUTTIVO che comprende tutte le attività di produzione, sia di
beni (le industrie) sia di servizi (il settore terziario), che applicano un sistema di qualità
conforme alle norme UNI EN ISO 9000.
Figura 2: Il Sistema Qualità Italia (dal sito dell'UNI: http://www.uni.unicei.it/sqi/home.html).

6
Gli istituti di accreditamento italiani citati in Figura 2 sono il SINAL e il SINCERT. Al
giugno 1998, gli organismi accreditati in Italia a rilasciare certificati nel settore EAC 33
(quello relativo alla IT) sono (fonte Sincert):
• ANCIS
• Ass. Nazionale per la Certificazione e la Qualità delle Imprese di Servizi
• CERMET Soc. Cons. a r.
• CNIM Comitato Nazionale Italiano per la Manutenzione
• Det Norske Veritas Italia S.r.l
• IMQ Istituto Italiano del Marchio di Qualità
• MACROSISTEMI S.n.c
• QUASER Istituto Italiano Qualità Servizi
• SGS ICSS.r.l. Servizi di Certificazione Internazionale

Quali sono le implicazioni che gli standard della serie ISO 9000 possono avere sulle
pubbliche amministrazioni? Sostanzialmente due:
1. Le PA possono richiedere ai propri fornitori la certificazione ISO 9000.
Tale richiesta serve a fornire una qualche garanzia alla PA circa la capacità
del fornitore di garantire adeguati livelli di qualità.

2. Le PA possono utilizzare le norme ISO 9000 come riferimento per

migliorare i propri processi di servizio (cioè il proprio modo di lavorare).

Come ultima osservazione va notato che la certificazione ISO 9000 non costituisce di
per se stessa una garanzia assoluta di affidabilità di un’azienda o ente. La certificazione
attesta che al momento della visita ispettiva sono stati riscontrati la presenza e l’utilizzo
di tutti gli elementi distintivi di un sistema di qualità. Ovviamente, risulta più difficile
verificare che tali elementi sono realmente vivi e presenti nelle quotidiane attività
dell’azienda. Nella scelta di un fornitore, quindi, la certificazione va considerata come
elemento utile ma certamente non decisivo.

2.2. ISO 9126

Il contenuto dello standard ISO 9126 è molto semplice: si tratta di un elenco di

caratteristiche di qualità di un generico prodotto software e delle relative
sottocaratteristiche.

1. Functionality:
• Suitability: coerenza delle funzioni offerte dal prodotto rispetto alle
esigenze dell’utenza.
• Accuracy: correttezza e precisione dei risultati prodotti.

7
 • Interoperability: capacità del prodotto di interagire con altri sis temi
software.
• Compliance: conformità a standard, convenzioni o regolamenti rilevanti
per il settore applicativo del prodotto.
• Security: capacità del prodotto di prevenire accessi non autorizzati alle
informazioni e funzioni gestite dal prodotto.
2. Reliability:
• Maturity: distribuzione dei malfunzionamenti in funzione degli errori
presenti nel software.
• Fault tolerance: capacità di mantenere livelli predeterminati di prestazioni
anche in presenza di malfunzionamenti o utilizzi scorretti del prodotto.
• Recoverability: capacità del prodotto di ripristinare il livello appropriato
di prestazioni del prodotto e di recuperare tutte le informazioni rilevanti a
valle di un malfunzionamento del prodotto.
3. Usability:
• Understandability: facilità di comprensione per l’utenza dei concetti del
prodotto.
• Learnability: facilità di apprendimento del prodotto.
• Operability: facilità di utilizzo del prodotto da parte dell’utenza.
4. Efficiency:
• Time behaviour: tempi di risposta.
• Resource behaviour: utilizzo delle risorse di sistema.
5. Maintainability:
• Analysability: facilità con la quale è possibile localizzare un errore nel
codice del prodotto.
• Changeability: facilità con la quale è possibile cambiare il codice del
programma.
• Stability: livello del rischio di effetti indesiderati attraverso la modifica
del codice.
• Testability: sforzo necessario per verificare il programma.
6. Portability:
• Adaptability: capacità del prodotto di essere adattato a diversi ambienti
operativi.
• Installability: facilità di installazione del prodotto.
• Conformance: conformità a standard relativi alla portabilità.
• Replaceability: facilità con cui si può utilizzare il prodotto al posto di un
altro componente.

Oltre alla definizione di queste caratteristiche, lo standard ISO 9126 offre alcune linee
guida molto generali per il loro utilizzo. In particolare, le caratteristiche di qualità
devono essere tradotte in metriche concrete che permettano una valutazione quantitativa
della qualità del bene o servizio osservato. Queste metriche devono essere selezionate
tenendo conto delle specifiche caratteristiche del prodotto considerato. Per fare questo,
lo standard ISO 9126 propone uno schema di processo di valutazione che è rappresentato

8
in Figura 3. In funzione dei requisiti di qualità devono venire selezionate le metriche, i
valori di riferimento, i criteri di valutazione. Tutto ciò viene utilizzato per valutare i
diversi componenti del prodotto software sviluppato e per valutarne così le
caratteristiche di qualità.

Rating level Assessment

Metric selection
Quality definition criteria definition
requirement
definition A0 A0 A0
A0

Software
development

A0

Measurement

A0

Rating

A0

Assessment

A0

Figura 3: struttura del processo di valutazione proposto nell’ISO 9126.

Quale può essere il contributo fornito dallo standard ISO 9126 al miglioramento della
qualità dei prodotti software? In realtà, questo standard ha più un significato simbolico
che pratico. Esso certamente mette in luce alcune caratteristiche salienti di un prodotto
software, anche se formulate in modo estremamente generico. Forse il contributo più
utile sta proprio nell’idea che queste caratteristiche generiche di qualità possono essere
tradotte in un concreto programma di misura e validazione solo attraverso un processo
che va a studiare le caratteristiche del prodotto, della struttura organizzativa che lo

9
produce e del mercato all’interno del quale si va a collocare. Queste osservazioni
verranno estensivamente riprese nella descrizione del paradigma GQM.

3. Le metriche

Ogni qual volta si vuole valutare la bontà di un bene o di un servizio risulta pressoché
indispensabile esprimere il giudizio attraverso una metrica [1]. Una metrica è una
funzione che permette di associare ad un attributo di un entità (per esempio l’altezza di
una persona) un valore numerico o simbolico (per esempio il numero 1.80 che esprime
in metri l’altezza della persona). Non esistono solo metriche numeriche. Quando
compiliamo un questionario di valutazione di un bene o di servizio ci troviamo spesso di
fronte a domande le cui risposte sono codificate attraverso un insieme di valori
predefiniti. Per esempio, se ci viene chiesto di valutare la cortesia è efficienza di un
servizio di assistenza all’utente, tipicamente le risposte possibili sono “ottimo”, “buono”,
“sufficiente” e “insufficiente”. Questa è una metrica che si basa su valori scalari e non
numerici.

Il numero di metriche potenzialmente utilizzabili per valutare beni e servizi IT è

estremamente elevato. Qualsiasi libro di ingegneria del software o di metriche ne riporta
decine se non centinaia. Esse coprono gli aspetti più disparati di un bene/servizio. Un
primo esempio di metriche di prodotto sono le metriche dimensionali per il software.
Esse valutano le dimensioni di un programma. Tali metriche sono sostanzialmente di due
tipi:

1. Metriche basate sul numero di istruzioni del programma, opportunamente

conteggiate. Esempi: LOC (Lines Of Code), NLOC (Non-commented
Lines Of Code).

2. Metriche basate sul numero di funzionalità presenti nel programma.

L’esempio classico in questo caso è costituito dai Function Point. La
dimensione in Function Point di un programma viene calcolata
conteggiando alcuni parametri caratteristici del programma (quali il
numero di ingressi e di uscite). Tali conteggi vengono poi aggregati
attraverso l’utilizzo di una espressione che pesa i contributi dei diversi
conteggi calcolando il valore che esprime il numero di Function Point del
programma.

Altre metriche di prodotto sono quelle che valutano la difettosità di un programma e

sono spesso espresse attraverso rapporti: per esempio numero di errori rilevati per
modulo oppure numero di errori rilevati in un periodo di tempo.
Altri esempi di metriche molto utilizzate sono quelle relative al lavoro richiesto per
sviluppare o modificare un programma. Si parla in questo caso di anni/uomo o
mesi/uome per indicare il lavoro svolto da una risorsa umana in un certo periodo di
tempo.

10
Batini e Raiss propongono uno schema che sintetizza le tipologie di metriche elementari
disponibili (vedi Tabella 1).

Combinazione Adatta a rappresentare Esempio

Time / Size L’efficienza o lo sforzo − Tempo di esecuzione di uno
step di un programma
− Tempo di risoluzione di una
anomalia per stmts di source
code
Count / Size La densità di un fenomeno − Densità di difetti od errori
− Copertura dei test
Size / Size La incidenza di un − Numero ciclomatico per
fenomeno modulo
− Percentile di moduli con alta
densità di errori
Size / Time Andamento nel tempo − Volume di sw sviluppato per
mese
Count / Time La frequenza − Numero di errori umani
commessi nell’interagire con il
sw in un mese
− N° di transazioni per secondo
− N° di LOC modificate per mese
Time / Time La incidenza − % di disponibilità effettiva di
un componente rispetto al tempo
operativo
Size / Count La estensione − N° medio di cammini
linearmente indipendenti testati
in un test
Time / Count Intervalli di tempo − Temp o tra due errori
consecutivi (di un componente
hw o sw, od umani)
− Tempo ncessario a riparare un
difetto rilevato
Count / Count La incidenza − N° di operazioni umane
compiute correttamente
nell’utilizzo del sw
Tabella 1: tipologie di metriche elementari secondo Batini e Raiss.

11
Se il numero di potenziali metriche è così elevato, come fare a scegliere le metriche che
sono adatte e utili per risolvere uno specifico problema di misura? Va tenuto presente
che raccogliere dati e spesso estremamente costoso ed è quindi necessario limitare il
numero di metriche di cui si vuole studiare l’andamento. Serve quindi un metodo che ci
permetta di definire un programma di misura che minimizzi il numero di dati da
raccogliere in funzione dell’obiettivo di misura perseguito. A questo proposito, lo
standard ISO 9126 offre una qualche indicazione utile. Ma esso rimane ad un livello
estremamente generale. Un approccio che ricalca gli stessi principi ispiratori, ma che si
articola in maniera molto più concreta è il paradigma GQM che verrà descritto nel
prossimo paragrafo.

12
 4. La definizione dei programmi di misura

Prestudy. This activity aims at collecting the information on the context where the measurement
activity has to be carried out. One must identify preconditions and constraints, strategic
objectives of the company, existing experiences and data, and characteristics of the
organization, product, and market.
Identification of GQM goals. Based on the description of the context, a set of goals for the
improvement activity are defined and ranked according to their relevance and importance to
the organization strategy.

Context
Prestudy characterization

Identification of GQM
GQM goals goals

Production of the GQM

GQM plan plan

Production of the Measurement

measurement plan plan

Collection and Validated

validation of data data

Analysis of Results of the

data evaluation

Packaging of Experience
experiences packages

Production of the GQM plan. The identified goals are used as the starting point to create the GQM
plan, i.e., a structured document where each goal is associated with a set of metrics needed
to achieve the identified goals.
Production of the measurement plan. The measurement plan is the operational counterpart of the
GQM plan: the latter indicates what data we may want to collect, while the former indicates
how the data collection activity has to be carried out.
Collection and validation of data. This activity aims at collecting and evaluating process and product
data, according to the GQM and measurement plans.
Analysis of data. Collected data are analyzed to understand and evaluate the level of accomplishment
of the different goals that were initially selected.
Packaging of experiences. The experiences that have been gained in conducting the measurement
activity are packaged so that they can be reused in future projects.
Figura 4:struttura del processo GQM (da [2]).

13
Un programma di misura è costituito dall’insieme di informazioni che specificano quali
dati raccogliere e secondo quali modalità operative tale raccolta deve essere condotta

Il principale problema da affrontare è in quest’ambito la scelta delle metriche. A questo

proposito è possibile utilizzare un metodo sviluppato negli anni ’80 presso la Università
del Maryland e denominato paradigma GQM (Goal/Question/Metric). GQM nasce per la
definire programmi di misura per la produzione del software, ma può essere applicato
anche in altri contesti (come vedremo tra breve).

Le idee di fondo che caratterizzano il metodo GQM sono sostanzialmente due:

1. La definizione di un processo di misura deve essere guidato dagli obiettivi

dell’utente del programma. Non esistono programmi standard di misura.
Esistono linee guida che possono essere di ausilio nel progettare il
programma di misura adatto a soddisfare i bisogni di una specifica
organizzazione.

2. La creazione di un programma di misura è esso stesso un processo

complesso che richiede pianificazione, organizzazione e utilizzo di risorse
adeguate.

Per rispondere a queste sfide, GQM identifica innanzi tutto un processo che indica le fasi
secondo le quali procedere per definire il programma di misura e i prodotti intermedi che
tale processo deve generare (vedi Figura 4). I passi più importanti sono certamente la
identificazione dei goals (obiettivi) di misura, del GQM (cioè delle metriche da
raccogliere) e del measurement plan (cioè delle modalità secondo le quali raccogliere i
dati).

Per quanto riguarda l'identificazione dei goal e del GQM plan, GQM propone di
procedere secondo i seguenti passi:

• I goal vengono identificati secondo uno schema (goal template) illustrato

nella parte superiore della Tabella 2. La tabella descrive un obiettivo di
misura relativo ad un caso reale: i processi di servizio di una società di
servizi di telecomunicazioni. Il goal è rappresentato dall’oggetto
dell’attività di misura, dallo scopo dell’attività di misurazione, dalle
caratteristiche di qualità che si vogliono misurare, dal punto di vista che
si assume nell’effettuare la raccolta dati, e dal contesto all’interno del
quale tale raccolta dati viene effettuata. Nell’esempio citato, il goal può
essere letto nel seguente modo: “Studiare i processi di servizio con lo
scopo di caratterizzarne costi, durate, … dal punto di vista di vari
responsabili dei processi e nel contesto delle attività di un centro di lavoro
periferico.” Un secondo esempio di goal è presentato in Tabella 3.
• I diversi goal identificati vengono poi confrontati, combinati e ordinati
secondo le priorità indicate dall’utente. Questo serve per definire

14
 similitudini, sinergie e priorità nella definizione del programma di
misura.
• Si procede quindi a dettagliare i goal attraverso l’uso di un abstractions
sheet (parte inferiore delle Tabelle 2 e 3). Nell’abstraction sheet si
dettagliano i fattori di qualità (Quality Factor) da studiare nell’ambito del
goal, i fattori di variazione (Variation Factor) che si suppone abbiano
un’influenza sui fattori di qualità, le ipotesi che in azienda si formulano
circa l’andamento dei fattori di qualità (Baseline Hypotheses) e
l’influenza che si stima abbiano sulle ipotesi i diversi fattori di variazione
identificati (Impact of Baseline Hypotheses). Queste informazioni
vengono dedotte intervistando le persone coinvolte nel processo o a
contatto con il prodotto considerato. Si noti che gli abstraction sheet
vengono sviluppati attraverso un approccio iterativo che raffina le
informazioni raccolte attraverso fasi cicliche di interviste e verifiche.
• Dagli abstraction sheet è abbastanza facile derivare le domande
(Question) alle quali si vuole poter rispondere attraverso la creazione del
processo di misura. Per esempio, nel caso di Tabella 2 una domanda
potrebbe essere “Quale è il costo medio per intervento per tipologia di
utente?” Dalle domande e dalle altre informazioni contenute
nell’abstraction sheet risulta infine abbastanza agevole derivare
l'indicazione delle metriche (Metrics) da raccogliere (nell’esempio, costo
di un singolo intervento, tipologia dell’utente coinvolto nell’intervento,
numero di interventi per uno specifico tipo di utenti).

Una volta definito il GQM plan, è necessario procedere alla definizione del measurement
plan, cioè delle modalità secondo le quali raccogliere e memorizzare le informazioni
relative alle metriche prescelte. Tale fase deve prevedere la verifica della fattibilità della
raccolta dei dati prescelti e del costo da sostenere per rilevare tali dati. Inoltre deve
predisporre gli strumenti organizzativi (per esempio, circolari al personale) e tecnologici
(per esempio, database per memorizzare i dati e procedure automatiche di raccolta, se
fattibili) che permettono di attuare il programma di raccolta dati così progettato.

In sintesi, il metodo GQM fornisce una serie di indicazioni metodologiche che guidano il
progettista di un programma di misurazione nella definizione delle metriche da
raccogliere e delle modalità di raccolta. Ciò avviene attraverso uno studio dettagliato
delle motivazioni e degli obiettivi del programma di misura. Questa focalizzazione
centrata sugli obiettivi permette di ottenere informazioni che sono coerenti con le
aspettative e i bisogni di chi ha avviato il programma di misurazione. Inoltre, permette di
minimizzare il numero di dati da raccogliere, facilitando il lavoro di chi dovrà
collezionare le informazioni e riducendo i costi del processo di raccolta.

15
Oggetto Scopo Caratteristiche Punto di vista Contesto

I processi di service Caratterizzare Costo, Durata, Resp. centro di lavoro Attività svolte dai
assurance, service Impiego di risorse, Resp. Filiale centri di lavoro
delivery e network Performance, Resp. Direz. Territoriale
creation Qualità per il Resp. Direzione Generale
cliente
Caratteristiche Fattori d’influenza
Come si possono descrivere in dettaglio le Quali fattori possono influenzare le caratteristiche
caratteristiche d’interesse? considerate?
QF1. Costo (tutti i processi) VF1. Tipo di servizio (service assurance, service delivery,
QF1.1. Costo di un’attività network creation)
QF1.1.1. Costo di un intervento VF2. Tipologia dell’attività
QF2. Durata (tutti i processi) VF3. Tipologia dell’intervento (cessazione, nuovo impianto,
QF2.1. Durata di un’attività trasloco, ISDN, RFD/ITAPAC, varie)
QF2.1.1. Durata di un intervento VF4. Tipologia del cliente
VF4.1. Classe di spesa (totale sulla bolletta)
QF3. Impiego di risorse (tutti i processi)
VF4.2. Tipologia di spesa (suddivisione
QF3.1. Impiego di risorse in un’attività
apparati/traffico)
QF3.1.1. Impiego di risorse per un
VF4.2.1. Spesa per tipologia di traffico
intervento
(nazionale/internazionale, verso
QF4. Produttività delle risorse (tutti i processi) terminale fisso /mobile)
QF4.1. Numero d’interventi per unità di VF4.3. Categoria merceologica
tempo
VF5. Tipologia dell’oggetto dell’intervento
QF5. Performance (tutti i processi)
VF6. Personale che esegue l’intervento (sociale o d’impresa)
QF5.1. Tempo medio d’intervento
VF7. Impresa che esegue i lavori
QF5.2. Tempo medio di giacenza delle
VF8. Centro di Lavoro competente
richieste
QF5.3. Numero d’interventi per unità di VF8.1. Reparto
tempo VF8.1.1. Addetto
QF6. Qualità per il cliente (service assurance) VF9. Livello di manutenzione (es. Numero d’ore/interventi
QF6.1. Tempo di risposta di manutenzione in passato)
QF6.2. T empo di risoluzione VF10. Istante d’osservazione
QF6.3. Numero di reclami
QF6.4. Numero d’interventi in corso
QF6.5. Numero di segnalazioni aperte
QF6.6. Numero d’interventi entro N giorni
Ipotesi di base Impatto dei fattori d’influenza sulle ipotesi di base
Quali sono i valori assunti dalle caratteristiche In che modo i fattori d’influenza fanno variare le
d’interesse? caratteristiche?
BH1. Costo medio di service assurance IH1. Il costo medio delle attività per clienti TOP è
BH1.1. Costo medio delle attività di tipo maggiore/minore del costo per clienti business
X: L. Y IH2. Il costo delle attività di tipo X nel CLGRA Y è
BH1.1.1. Costo medio degli maggiore/minore del costo nel CLGRA Z
interventi Z per le IH3. Il costo medio per clienti business è maggiore/minore
attività di tipo X: Lit. di quello per clienti residenziali
Y IH4. Il costo dipende/non dipende dall’impresa
BH1.2. Costo medio delle attività di tipo X IH5. Il costo dipende/non dipende dall’oggetto della
per clienti Y: L. Z manutenzione
BH1.3. …

Tabella 2:Formulazione di un goal e relativo abstraction sheet.

16
Oggetto Scopo Caratteristiche Punto di Contesto
vista
La rete Caratterizzare Costo Scelte strategiche della direzione
d’accesso Utilizzo Resp.
Ricavo Direzione
Qualità del Generale
servizio

Caratteristiche
4.1.1.1. Fattori d’influenza
Come si possono descrivere in dettaglio le caratteristiche Quali fattori possono influenzare le caratteristiche
d’interesse? considerate?
QF1. Costo VF1. Tecnologia utilizzata per la linea/impianto
QF1.1. Costo d’esercizio VF2. Localizzazione geografica (centri di lavoro di
QF1.2. Costo di manutenzione competenza)
QF1.3. Costo d’ammortamento VF3. Distribuzione temporale (fasce orarie,
QF1.4. Costo di delivery settimana, anno)
QF1.5. Spesa in dotazioni ed investimenti VF4. Programmi tariffari
QF2. Utilizzo VF5. Tipologia di cliente
QF3. Ricavo VF6. Evoluzione temporale
QF3.1. Ricavo da traffico VF7. Tipo di servizio (dati, fonia, …)
QF3.2. Ricavo da canone VF8. Livello di manutenzione (es. Numero di
QF3.3. Ricavo da vendita di servizi accessori ore/interventi di manutenzione in passato)
QF3.4. Ricavo da noleggio apparecchiature
QF3.5. Ricavo da vendita di apparecchiature
QF3.6. Ricavo/costo da roaming
QF4. Qualità del servizio
QF4.1. Frequenza dei guasti
QF4.2. Tempo di disservizio (%)

Ipotesi di base Impatto dei fattori d’infl uenza sulle ipotesi di

Quali sono i valori assunti dalle caratteristiche
d’interesse?
BH1. Dati ricavati dagli indicatori attualmente in uso
BH2. Costo complessivo per linea: L. X annue
BH3. Qualità del servizio X
BH3.1. Frequenza dei guasti: N per anno
BH3.2. Disservizio: X% del tempo
base
In che modo i fattori d’influenza fanno variare le
caratteristiche?
IH1. La stessa tecnologia applicata in zone
geografiche diverse permette di ottenere
risultati diversi (la strategia di sviluppo
dipende dalla localizzazione geografica: una
tecnologia che va bene a Milano non è detto
che vada bene in provincia di Matera).
IH2. Il programma tariffario influenza fortemente
l’andamento del traffico per le categorie di
utenti che spendono meno, ma poco per gli
utenti Top
IH3. I nuovi servizi si diffondono inizialm ente nella
fascia Top per poi coinvolgere man mano le
fasce inferiori
IH4. L’appartenenza di un cliente ad una certa fascia
varia poco al variare del tempo
IH5. L’uso dei servizi accessori è strettamente
correlato alla tipologia di cliente

Tabella 3: Un secondo esempio di goal di misura.

17
5. Alberi di qualità

In molte situazioni è necessario basare decisioni sulla valutazione di una serie di fattori.
Classico è il caso della valutazione dei fornitori che si deve normalmente basare
sull’analisi congiunta di una serie di variabili quali l’affidabilità del fornitore, le sue
capacità tecniche e la conoscenza dei problemi che è chiamato a risolvere.

Solidità
finanziaria qualificazione ed esperienza del personale
(titolo di studio, esperienza, formazione)
disponibilità di personale qualificato
(manageriale, tecnico e di supporto al cliente)

disponibilità di strumenti e tecnologie

Capacità
Affidabilità tecnica maturità del processo produttivo

autonomia operativa (capacità di svolgere

autonomamente l’ incarico, utilizzando il meno
possibile sotto-contraenti)

prontezza degli interventi

in situazioni simili
Affidabilità
in passato in generale

Figura 5: Un esempio di albero di valutazione per la scelta di un fornitore.

Risulta in questi casi utile utilizzare diagrammi ad albero per decomporre

gerarchicamente i diversi fattori che contribuiscono alla formulazione di un giudizio. Per
esempio, la Figura 5 illustra un classico esempio di albero di valutazione che sintetizza i
parametri utilizzati per selezionare un fornitore.

Un albero di questo tipo (detto albero di qualità) può essere costruito in maniera bottom-
up aggregando metriche elementari identificate, per esempio, tramite il metodo GQM.
Oppure, può essere direttamente costruito in maniera top-down procedendo alla
identificazione dei parametri di qualità per raffinamenti successivi.

Un albero di qualità può essere pesato ed utilizzato per esprimere giudizi sintetici di tipo
quantitativo. Dopo aver assegnato un peso ad ogni nodo dell’albero, si valuta l’entità
oggetto di studio assegnando un punteggio per ogni attributo rappresentato dalle foglie
dell’albero. I diversi punteggi vengono poi aggregati in base alla struttura dell’albero e ai
pesi assegnati ottenendo così un giudizio sintetico complessivo. Una descrizione
completa di questo metodo di calcolo è presentata in [2].

18
6. Riferimenti
[1] N.E. Fenton, S.L. Pfleeger. Software metrics: a rigorous and practical
approach, 2nd edition. Thompson Computer Press, 1996.
[2] A. Fuggetta, C. Ghezzi, S. Morasca, A. Morzenti e M. Pezzè. Ingegneria del
Software. Mondadori Informatica, 1994.
[3] Fuggetta, L. Lavazza, S. Morasca, S. Cinti, G.Oldano e E. Orazi. Applying
GQM to an industrial software factory. ACM Transactions on Software
Engineering and Methodology, Ottobre 1998.
[4] ISO. International Standard ISO 9126, First Edition, 1991.
[5] A cura di R. Peach, The ISO 9000 Handbook. Irwin Professional Publishing,
1997.

19