Concetto: Metrica
La metrica è composta da numeri utilizzati come misure per lo standard di qualità nella comparazione di elementi o periodi di tempo diversi.
Relazioni
Elementi correlati
Descrizione principale

Motivi delle misurazioni

Le misurazioni vengono effettuate principalmente per ottenere il controllo di un progetto, e quindi essere in grado di gestirlo. Le misurazioni sono utili per valutare quanto vicini o lontani si è dagli obiettivi preposti nel piano in termini di completamento, qualità, conformità con i requisiti, ecc.

Le misurazioni sono utili anche per poter stimare meglio l'impegno lavorativo, i costi e la qualità di nuovi progetti, in base all'esperienza passata. Infine sono utili per valutare il miglioramento nel tempo di alcuni aspetti chiave delle prestazioni del processo, per individuare gli effetti delle modifiche.

La misurazione di alcuni aspetti chiave di un progetto aggiunge un costo non trascurabile. Quindi non si effettuano misurazioni su qualunque cosa semplicemente perché è possibile. E' necessario impostare degli obiettivi ben precisi per questo impegno lavorativo e raccogliere unicamente della metrica che consenta il raggiungimento di questi obiettivi.

Esistono due tipi di obiettivi:

  1. Obiettivi di conoscenza: vengono espressi dall'utilizzo di verbi come valutare, prevedere, monitorare. Sono utili per comprendere meglio il processo di sviluppo. Ad esempio, si potrebbe voler valutare la qualità del prodotto, ottenere dei dati per pianificare l'impegno lavorativo per le verifiche, monitorare il test o tenere traccia delle modifiche di requisiti.
  2. Obiettivi di modifiche o di risultati: questi vengono espressi dall'utilizzo di verbi come aumentare, ridurre, migliorare o ottenere. In genere si è interessati ad osservare come le cose cambiano o migliorano nel tempo, da un'iterazione all'altra, da un progetto all'altro.

Esempi:

  • Monitorare l'avanzamento relativo al piano
  • Migliorare la soddisfazione del cliente (customer satisfaction)
  • Migliorare la produttività
  • Migliorare la prevedibilità
  • Aumentare il riutilizzo

Questi obiettivi generali di gestione non si trasformano direttamente in metrica. E' necessario convertirli in obiettivi secondari più piccoli (o obiettivi azione) che identificano le azioni che i membri del progetto devono intraprendere per raggiungere l'obiettivo. Ed è necessario far sì che le persone coinvolte ne comprendano i vantaggi.

Esempi

L'obiettivo per "migliorare la customer satisfaction" si suddivide in:

  • Definire la customer satisfaction
  • Misurare la customer satisfaction, in diversi rilasci
  • Verificare il miglioramento della soddisfazione

L'obiettivo per "migliorare la produttività" si suddivide in:

  • Misurare l'impegno lavorativo
  • Misurare l'avanzamento
  • Calcolare la produttività in diverse iterazioni o progetti.
  • Confrontare i risultati

Alcuni degli obiettivi secondari (ma non tutti) potrebbero richiedere la raccolta di metrica.

Esempio

"Misurare la customer satisfaction" può essere ricavato da

  • Valutazione del client (dove il cliente fornisce un punteggio su aspetti diversi)
  • Numero di chiamate alla hotline del supporto clienti e severità.

Per ulteriori informazioni, consultare [AMI95].

Un utile metodo per classificare in categorie gli obiettivi è in base alle necessità aziendali, del progetto e tecniche. Questo fornisce un framework per il perfezionamento trattato in precedenza.

Metrica per esigenze aziendali

Un'organizzazione deve conoscere, e forse migliorare, i costi per 'voce', abbreviarne i tempi di commercializzazione (time-to market), pur distribuendo un prodotto di qualità conosciuta (obiettiva e soggettiva), e la domanda di manutenzione appropriata. Un'organizzazione di tanto in tanto (o anche continuamente) potrebbe dover migliorare le proprie prestazioni per restare competitiva. Per ridurre i rischi, un'organizzazione deve conoscere il livello di skill e di esperienza del proprio personale e accertarsi di disporre delle altre risorse e capacità per competere nella sfera scelta. Un'organizzazione deve essere in grado di introdurre una nuova tecnologia e determinare i costi-vantaggi di quella tecnologia. La tabella che segue elenca degli esempi di tipi di metrica pertinenti a queste esigenze per un'azienda di sviluppo di software.

Problematica

Metrica

Costo della voce Costo per riga di codice, costo per Function Point, costo per caso d'uso. Impegno normalizzato (in una parte definita del ciclo di vita, del linguaggio di programmazione, del grado del personale, ecc.) per riga di codice, Function Point o caso d'uso. Questa metrica non consiste in genere di semplici numeri, dipende dalla dimensione del sistema da distribuire e dalla tempificazione (se è compressa o meno).
Tempi di costruzione Tempo trascorso per riga di codice o per Function Point. Anche questo dipende dalla dimensione del del sistema. I tempi possono essere abbreviati aggiungendo del personale - ma solo fino ad un determinato punto. Una capacità gestionale dell'organizzazione stabilisce esattamente dove è il limite.
Densità degli errori nel prodotto distribuito Errori (rilevati dopo la distribuzione) per riga di codice o per Function Point.
Qualità soggettiva Facilità d'uso, facilità dell'operazione, accettazione del cliente. Sono stati ideati dei tentativi di quantificazione, anche se si tratta di metodi approssimativi.
Facilità di manutenzione Costo per riga di codice o Function Point per anno.
Profilo skill, profilo esperienza Il gruppo delle risorse umane presumibilmente detiene un qualche genere di database di skill ed esperienza.
Capacità tecnologiche
  • Tool - un'organizzazione deve conoscere quali sono di uso generale ed il tipo di competenza necessaria per quelli non utilizzati regolarmente.
  • Maturità del processo - ad esempio, in che punto si colloca l'organizzazione nella scala SEI CMM
  • Capacità di domini - in che domini applicativi è in grado di eseguire l'organizzazione
Misurazioni di miglioramento del processo
  • Tempi di esecuzione ed impegno lavorativo del processo.
  • Tassi di errore, statistiche di analisi causale, tassi fissi, materiale di scarto e rilavorazione.

Metrica per esigenze di progetto

Un progetto deve soddisfare i seguenti criteri prima della distribuzione:

  • capacità richieste funzionali e non funzionali
  • vari vincoli tecnici
  • vincoli di budget e di tempi
  • determinate caratteristiche di transizione, operative e di manutenzione

Il responsabile di progetto deve essere in grado di rilevare se sta dirigendosi verso l'ottenimento degli obiettivi, trattati nella tabella che segue per un'idea su cose tenere presente quando si pensa alle misurazioni del progetto:

Problematica

Impegno lavorativo e budget del progetto
  • Il progetto in che modo tiene traccia dell'impegno lavorativo e dei costi rispetto al piano?
Tempificazione del progetto
  • Il progetto sta mantenendo i punti cardine?
Transizione/Installazione
  • L'impegno lavorativo, i costi e gli skill previsti sono accettabili?
Operazione
  • I requisiti previsti di impegno lavorativo skill sono supportabili dal cliente?
Manutenzione/Supportabilità
  • I requisiti previsti di impegno lavorativo e skill sono accettabili per il cliente?
Requisiti funzionali
  • I requisiti sono validi, completi?
  • I requisiti sono assegnati ad un'iterazione?
  • I requisiti sono stati realizzati secondo il piano?
Requisiti non funzionali
  • Prestazioni
    • Il sistema soddisfa i requisiti dei tempi di risposta, di risultato e di recupero?
  • Capacità
    • Il sistema può gestire il numero di utenti simultanei richiesto? Il sito web può gestire il numero di richieste di informazioni (hit) richiesto per secondo? E' disponibile sufficiente memoria per il numero richiesto di record cliente?
  • Fattori della qualità
    • Affidabilità: ogni quanto sono consentiti gli errori di sistema e da cosa è costituito un errore di sistema?
    • Utilizzabilità: l'utilizzo del sistema è semplice e piacevole? Quanto tempo è necessario per apprenderne l'utilizzo e quali sono gli skill richiesti?
    • Tolleranza errori/robustezza/capacità di recupero/sopravvivenza: il sistema può continuare a funzionare se si verificano degli errori? Il sistema riesce a gestire degli input errati? Il sistema è in grado di eseguire un recupero automatico dopo un errore?
  • Requisiti di progettazione particolari
    • Sicurezza: il sistema è in grado di andare in esecuzione senza rischi per la vita o per la proprietà (tangibile e non tangibile)?
    • Protezione/riservatezza: il sistema protegge i dati sensibili da accessi non autorizzati? Il sistema è protetto da accessi malintenzionati?
    • Impatto ambientale: il sistema rispetta i requisiti ambientali?
  • Altri requisiti regolamentari o legali
  • Vincoli
    • Ambiente esterno: il sistema è in grado di eseguire operazioni nell'ambiente prescritto?
    • Risorse, host, destinazione: il sistema rispetta i vincoli di CPU, memoria, lingua, ambiente hardware/software?
    • Utilizzo di altro software esistente o COTS (commercial-off-the-shelf, disponibile sul mercato): il sistema rispetta i vincoli di riutilizzo?
    • Disponibilità e skill del personale: il sistema può essere creato con il numero ed il tipo di personale disponibile?
    • Compatibilità/supporto interfaccia: il sistema è in grado di supportare l'accesso richiesto da e verso altri sistemi?
    • Riutilizzabilità: quali provvedimenti sono stati presi per rendere il sistema riutilizzabile?
    • Standard imposti: il sistema ed il metodo di sviluppo sono compatibili?
    • Altri vincoli di progettazione (ad esempio strutturali, algoritmici):  il sistema utilizza lo stile strutturale richiesto? Vengono utilizzati gli algoritmi prescritti?

Questo è un ampio elenco ma non esaustivo, delle problematiche rivolte al responsabile di progetto. Molte richiedono la raccolta e l'analisi di metrica, alcune richiedono anche lo sviluppo di test specifici (per ricavare le misurazioni) per trovare la risposta alle domande poste.

Metrica per esigenze tecniche

Molte delle esigenze del progetto non hanno delle misurazioni dirette ed anche per quelle che ne dispongono potrebbe non essere ovvio cosa è necessario fare o cambiare per migliorarle. E' possibile utilizzare gli attributi qualità di livello inferiore per costruire la qualità, rispetto ad altri vari attributi di qualità di livello superiore come quelli identificati nell'ISO Standard 9126 (Software Quality Characteristics and Metrics) e quelli menzionati in precedenza nelle esigenze del progetto. Queste misure tecniche sono delle caratteristiche di progettazione (strutturale e funzionale) e degli effetti (riguardanti il processo ed il prodotto) che contribuiscono alle esigenze della metrica a livello di progetto. Gli attributi della tabella riportata di seguito sono stati utilizzati per ricavare un insieme di esempio di metrica per il processo e per i prodotti di lavoro Rational Unified Process. Sono reperibili in Linee guida per il prodotto di lavoro: Metrica.

Qualità

Attributi

Validità dei requisiti
  • Volatilità: frequenza di modifiche, incidenza dell'introduzione di nuovi requisiti
  • Validità: sono i requisiti giusti?
  • Completezza: mancano dei requisiti?
  • Correttezza dell'espressione: i requisiti sono esposti in modo corretto?
  • Chiarezza: le descrizioni sono comprensibili e prive di ambiguità?
Validità della progettazione
  • Dipendenza:  quanto sono estese le connessioni fra gli elementi del sistema?
  • Coesione: ciascun componente dispone di un unico scopo ben definito?
  • Primitività: i metodi o le operazioni di una classe possono essere generati da altri metodi o operazioni della classe? In tal caso non sono primitivi (una caratteristica auspicabile).
  • Completezza: la progettazione realizza a pieno i requisiti?
  • Volatilità: frequenza delle modifiche strutturali.
Validità dell'implementazione
  • Dimensione: di quanto l'implementazione è vicina alla dimensione minima (per risolvere il problema)? L'implementazione rispetterà i vincoli?
  • Complessità: il codice algoritmicamente è difficile o intricato? E' difficile da comprendere e modificare?
  • Completezza: l'implementazione realizza fedelmente tutta la progettazione?
Validità del test
  • Copertura: quanto approfonditamente viene testato il software? Le istruzioni vengono tutte eseguite da una serie di test? Il test prova molti percorsi nel codice?
  • Validità: i test sono loro stessi un corretto riflesso dei requisiti?
Validità del processo (al livello più basso)
  • Incidenza degli errori, causa degli errori: qual'è l'incidenza degli errori in un compito e quali sono le cause?
  • Impegno e durata: quanto impegno di risorse umane richiede un'attività e che durata?
  • Produttività: per unità di impegno di risorsa umana, quanto produce un'attività?
  • Validità dei prodotti di lavoro: qual è il livello di errori negli output di un compito?
Efficacia della modifica al processo/tool (uguale alla Validità del processo ma con modifiche in percentuale piuttosto che valori totali):
  • Incidenza degli errori, causa degli errori
  • Impegno lavorativo e durata
  • Produttività
  • Validità dei prodotti di lavoro

Per un approfondimento sui concetti di metrica consultare [WHIT97].

Cos'è una metrica?

Si distinguono due tipi di metrica:

  • Una metrica è un attributo misurabile di un'entità. Ad esempio, l'impegno lavorativo del progetto è una misura (vale a dire, una metrica) della dimensione del progetto. Per poter calcolare questa metrica è necessaria la somma di tutte prenotazioni del time sheet (foglio di tempificazione) relativo al progetto.
  • Una metrica primitiva è una voce di dati non elaborati utilizzata per calcolare una metrica. Nell'esempio riportato le prenotazioni del time sheet costituiscono la metrica primitiva. Una metrica primitiva di solito è una metrica che esiste in un database ma non viene interpretata in isolamento.

Ogni metrica è composta da una o più metriche raccolte. Di conseguenza ogni metrica primitiva deve essere identificata in modo chiaro e ne deve essere definita la procedura di raccolta.

Le metriche per supportare gli obiettivi di modifica o di risultato in genere sono "prime derivate" nel tempo (o sono iterazioni o un progetto). Si è interessati ad un trend, non ad un valore assoluto. Per "migliorare la qualità" è necessario verificare che il livello residuo di difetti noti diminuisca nel tempo.

Maschere

Maschera di una metrica

Nome Nome della metrica ed qualsiasi eventuale sinonimo noto.
Definizione Gli attributi delle entità misurate con la metrica, come viene calcolata e da quali metriche primitive viene calcolata.
Obiettivi Elenco degli obiettivi e delle domande relativi alla metrica. E' presente anche una spiegazione sui motivi dell'utilizzo della metrica.
Procedura di analisi Come si prevede di utilizzare la metrica. Precondizioni per l'interpretazione della metrica (ad es., intervallo valido di altre metriche). I valori obiettivo o i trend. Modelli di tecniche di analisi e di tool da utilizzare. Presupposizioni implicite (ad esempio, relative all'ambiente o ai modelli). Procedura di calibrazione. Memorizzazione.
Responsabilità Chi deve raccogliere e riunire i dati di misurazione, preparare i report ed analizzare i dati.

Maschera di una metrica primitiva

Nome Nome della metrica primitiva
Definizione Descrizione non ambigua della metrica in termini di ambiente del progetto
Procedura di raccolta Descrizione della procedura di raccolta. Tool di raccolta dati e modulo da utilizzare. Punti nel ciclo di vita quando vengono raccolti i dati. Procedura di verifica da utilizzare. Dove verranno memorizzati i dati, il formato, la precisione.
Responsabilità Chi è responsabile della raccolta di dati. Chi è responsabile della verifica dei dati.

Compiti delle metriche

Esistono due compiti:

  • Definizione del piano di misurazione
  • Raccolta delle misure

La definizione del piano di misurazione viene effettuata una volta sola per ciclo di sviluppo, nella fase di inizio, come parte dell'attività di pianificazione generale, oppure a volte come parte della configurazione del processo nel caso di sviluppo. Il piano di misurazione può essere rivisto come qualunque altra sezione del piano di sviluppo di software nel corso del progetto.

La raccolta delle misure viene effettuata in maniera ripetitiva, almeno una volta per iterazione e a volte più frequentemente; ad esempio, una volta a settima in un'iterazione che si distribuisce su molti mesi.

Le metriche raccolte fanno parte del documento di valutazione dello stato, da utilizzare durante la valutazione dell'avanzamento e dello stato del progetto. Possono essere accumulate per un successivo utilizzo nelle stime di progetto e nei trend in ambito aziendale.

Come vengono utilizzate le metriche?

Stima

Il responsabile di progetto in particolare deve eseguire la pianificazione (assegnare le risorse ai compiti con dei budget e dei tempi. L'impegno lavorativo ed i tempi vengono stimati in base ad un giudizio relativo a cosa deve essere prodotto, oppure il contrario: esistono delle risorse e dei tempi prefissati ed è necessaria una stima di cosa può essere prodotto. La stima in genere viene ricavata, a scopo di pianificazione, in base al calcolo delle esigenze di risorse basate su altri fattori, di solito la dimensione e la produttività.

Previsione

La previsione differisce di poco dalla stima e in genere è relativa al calcolo del futuro valore di qualche fattore, in base al valore odierno di quel fattore, ed altri fattori influenti. Ad esempio, considerando dei dati di prestazione, è utile ricavare da questi (prevedere) come reagisce il sistema a pieno carico o in una configurazione con risorse limitate o diminuite. I modelli di previsione di affidabilità utilizzano i dati della frequenza di errori per prevedere quando il sistema raggiungerà dei determinati livelli di affidabilità. Una volta pianificata un'attività, il responsabile di progetto avrà bisogno dei dati tramite i quali prevedere le date del termine e l'impegno lavorativo al completamento.

Valutazione

La valutazione viene utilizzata per stabilire la posizione corrente per il confronto con una soglia, o l'identificazione dei trend, o per il confronto con delle alternative, o come base per la stima o la previsione.

Per ulteriori informazioni sulla metrica nella gestione di un progetto, leggere [ROY98].