Ercole Colonese

Metriche del software

Perché misurare?

Le metriche del software meritano un discorso particolare.

"Senza misure non è possibile alcun miglioramento!" ha detto perentoriamente qualcuno.

E' un'asserzione importante quanto assoluta.

Molti dei problemi riscontrati nei progetti software in crisi sono ascrivibili alla mancanza di una cultura della misurazione. Di quali misurazioni stima parlando? Di quelle fondamentali per un progetto software: il dimensionamento del software da sviluppare, la produttività dell'organizzazione, la stima dei tempi e dei costi di realizzazione, la difettosità del software.

La carenza di misurazioni è direttamente associata alla "scarsa accuratezza delle stime", un altro bel problema!

"In questa azienda i consuntivi non rispettano mai i preventivi!" tuona la direzione.

Ma erano le stime iniziali ad essere sbagliate o è la gestione non corretta del progetto a generare ritardi ed extra costi? Bella domanda. Forse sono strettamente legate tra di loro le due cose.

Stime corrette ed affidabili richiedono la presenza in azienda di una "cultura delle misure" consolidata. E questo genera un effetto positivo in tutta l'organizzazione: anche i capi progetto hanno questa cultura e quindi gestiscono i progetti adottando le metriche necessarie. Ritardi ed extracosti sono subito individuati e corretti.

Ma in una tale organizzazione anche i processi sono misurati per verificare se questi siano efficaci o meno. E se non lo sono (e solo le misure possono dirlo) vengono opportunamente migliorati.

Un'organizzazione con tale cultura riesce anche a misurare se stessa e a capire dove può migliorare.

Per finire, un'organizzazione che adoperi sistematicamente le misure (non troppe, solo quelle che servono!) non può che far bene e migliorare di continuo. Chi invece non le usa ...!

Cosa e come misurare?

Si tratta di metodi e tecniche per misurare "cosa" si realizza (il prodotto), "come" lo si realizza (il processo, il progetto) e "chi" lo realizza (l'organizzazione).

Le metriche coprono quindi l'intera organizzazione software: l'organizzazione stessa coinvolta, il progetto software, il processo di sviluppo, il software sviluppato.

Il processo relativo alle misurazioni prevede le seguenti attività:

Definire le metriche necessarie: si tratta della definizione delle metriche necessarie per valutare la qualità dei processi, dei progetti e dei prodotti realizzati partendo dagli obiettivi e selezionando gli indicatori più efficaci;
Pianificare il programma di misurazione: si tratta della pianificazione del programma di misure da realizzare (cosa, come, chi e quando misurare) e le modalità di reporting e di valutazione. Il piano delle misure è documentato nel Piano della qualità;
Eseguire il programma di misurazione: si tratta dell'esecuzione delle misurazioni pianificate durante il ciclo di sviluppo, della produzione della reportistica, della valutazione dei risultati e della predisposizione di eventuali azioni necessarie in caso di scostamento dai valori attesi.

Alcuni esempi di metriche del software

Di seguito sono proposte alcune metriche semplici per indirizzare gli obiettivi dell'azienda. L'esempio riportato è reale ed è stato sperimentato con successo da un gruppo di piccole e medie aziende italiane di software.

Gli obiettivi che si intendono misurare con le metriche adottate sono riportate qui di seguito.

Obiettivo	Descrizione
O1	Capacità dell’organizzazione di far fronte alle esigenze dei progetti garantendo processi, mezzi e risorse adeguati
O2	Capacità dei progetti di rispettare i tempi, i costi ed il livello di qualità atteso
O3	Capacità di pianificare i progetti con stime corrette e realistiche
O4	Capacità di controllare puntualmente lo stato di andamento dei progetti e di reagire prontamente nei casi di deviazione dai piani
O5	Capacità dell’organizzazione di sviluppare prodotti con la qualità attesa
O6	Capacità di migliorare i processi per aumentare le capacità descritte sopra

Un esempio concreto

Supponiamo di aver definito gli obiettivi aziendali riportati in precedenza.

Le metriche adoperate per tenere sotto controllo gli obiettivi aziendali stabiliti sono quelle riportate qui di seguito. Sperimentate con successo, possono essere adattate alle esigenze particolari di ciascuna azienda che le voglia utilizzare. Per motivi di semplicità l'indicatore (cosa misurare) è espresso in linguaggio naturale. Gli algoritmi di misurazione possono essere ricavati facilmente da ogni esperto di metriche.

Categoria: Metriche relative all'organizzazione (O1)

Metrica

Cosa misurare

Adeguatezza della struttura organizzativa alle esigenze dei progetti (disponibilità delle risorse richieste)

Disponibilità delle risorse pianificate (Numero e Permanenza di persone nel progetto).

Adeguatezza delle risorse disponibili (Competenza, Esperienza, Produttività rispetto alle caratteritiche richieste).

Impatti sul cliente causati dalle persone (Numero di rilievi fatti dal cliente).

Categoria: Metriche di processo (O6)

Metrica

Cosa misurare

Aderenza al processo (da parte dei progetti)

Livello di aderenza del progetto ai processi aziendali (Numero di non conformità rilevate nei progetti).

Efficacia dei processi

Livello di efficacia dei processi (Numero di non conformità relative ad obiettivi dei progetti non raggiunti e da addebitate ai processi stabiliti).

Esempio: Metodi di stima non adeguati, Dati statistici incompleti o errati, Checklist incomplete o errate, Template non adeguati, Metodi e tecniche non adeguate, Strumenti non adeguati, ecc.).

Categoria: Metriche di progetto (O2, O4)

Metrica	Cosa misurare
Rispetto dei tempi di consegna (O2, O4)	Ritardo nelle consegne (Numero di giorni di ritardo rispetto ai piani delle consegne[1]).
Contenimento dei costi (O3, O4)	Extracosti (Scostamento percentuale dei costi a consuntivo rispetto ai preventivi[2]).
Raggiungimento della qualità (O4, O5)	Rilascio dei deliverable previsti (Numero di deliverable rilasciati rispetto a quelli previsti). Qualità dei deliverable (Numero di rilievi fatti dal cliente in fase di consegna, approvazione, collaudo)

Categoria: Metriche di prodotto nelle varie fasi del ciclo di vita (O5)

Metrica

Cosa misurare

- Analisi:

Completezza e correttezza dell’interpretazione dei requisiti

Qualità dei requisiti (Numero di errori rilevati durante l’intero ciclo di sviluppo ed imputabili ad una interpretazione dei requisiti incompleta o non corretta).

- Progettazione:

Qualità della progettazione

Livello di strutturazione dell’architettura applicativa.

Livello di coesione dei componenti applicativi.

Livello di disaccoppiamento dei componenti applicativi.

Livello di strutturazione dei dati (information hiding).

Livello di aderenza agli standard tecnologici richiesti (OO, CORBA, SOA, SOAP, ecc.).

- Codifica:

Qualità del software

Livello di aderenza del codice agli standard di codifica (strutturazione, commenti, dimensioni, ecc.).

- Rilascio:

Difettosità residua (del software rilasciato in esercizio)

Numero di difetti rilasciati in produzione/Dimensioni del software (FP o KLocs)[3].

- Tutte le fasi:

Qualità della documentazione prodotta (documenti tecnici e manuali)

Completezza della documentazione (documenti prodotti rispetto a quelli previsti).

Aderenza agli standard documentali applicabili (numero di anomalie rilevate).

Correttezza della documentazione (numero di anomalie rilevate)

- Collaudo:

Efficacia dei test

Efficienza dei test (produttività)

Livello di copertura dei test rispetto ai requisiti (Matrice di tracciabilità dei requisiti).

Numero di errori rilevati rispetto al numero previsto (ricavato dalla curva di rimozione degli errori).

Numero medio di errori rilevati per caso di test.

Giorni persona spesi per caso di test eseguito

[1] E’ importante analizzare le cause dei ritardi per verificare se il problema è stato generato da stime iniziali non corrette, da una pianificazione non realistica o da una conduzione del progetto non adeguata.

[2] Nel caso di scostamento dei costi consuntivi rispetto alle stime iniziali occorre distinguere se esso (lo scostamento) sia dovuto ad una errata stima iniziale oppure ad uno “sforamento” vero e proprio del budget.

[3] Il numero dei difetti (errori) residui nel software rilasciato in esercizio è calcolato estrapolandolo dall’andamento della curva di rimozione dei difetti nelle fasi del ciclo di sviluppo. La rimozione degli errori è effettuata tramite le revisioni tecniche interne prima (fasi alte del ciclo) e con le attività di test dopo. L’andamento della curva mostra infatti quale sarebbe il numero di errori rimossi nella fase successiva a quella dei test e del collaudo finale: tale fase coincide proprio con l’utilizzo del software da parte degli utenti. Presupposto per l’utilizzo delle curve è quella della registrazione dei difetti rilevati in tutte le fasi del ciclo di sviluppo ed una corretta progettazione ed esecuzione dei test.

News/Articoli/Libri

News

Collaudo e qualità del software

Professione IT oggi in Italia ...

Collaborazioni

Associazioni

Indagine sull'utilizzo delle best practice

Best practice del software proposte