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:
-
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.
-
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.
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.
|
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.
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].
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.
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.
|
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.
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].
|