Linea guida: Metrica
Questa guida descrive i principi fondamentali relativi alla raccolta dei valori e fornisce alcuni esempi di criteri da utilizzare.
Relazioni
Descrizione principale

Concetti fondamentali

  • La metrica deve essere semplice, oggettiva, facilmente recuperabile, di facile interpretazione e difficile da fraintendere.
  • La raccolta dei valori della metrica deve essere automatizzata e non intrusiva, cioè non deve interferire con le attività degli sviluppatori.
  • La metrica deve contribuire alla valutazione della qualità all'inizio del ciclo di vita, quando gli sforzi per il miglioramento della qualità software sono efficaci.
  • Per poter riferire l'avanzamento e la qualità in un formato coerente, il personale tecnico e quello gestionale deve utilizzare attivamente dei valori di metrica e delle tendenze assoluti.
  • La scelta di un insieme minimo o ampio di metrica dipende dalle caratteristiche del progetto e dal contesto: se si tratta di un progetto vasto o che ha dei rigidi requisiti di sicurezza o di affidabilità ed i team di sviluppo e di valutazione sono esperti di metrica, può essere utile raccogliere ed analizzare la metrica tecnica. Il contratto potrebbe richiedere la raccolta di determinata metrica oppure l'organizzazione potrebbe tentare di migliorare i propri skill e processi di particolari aree. Non esiste una semplice risposta per tutte le circostanze, il responsabile del progetto deve scegliere ciò che è più appropriato quando viene creato il piano di misurazione. Tuttavia, quando si introduce per la prima volta un programma di metrica, è facile peccare di eccessiva semplicità.

Tassonomia della metrica

La metrica, per determinati aspetti del progetto, include:

  • L'avanzamento in termini di dimensioni e di complessità.
  • La stabilità in termini di frequenza delle modifiche nei requisiti o implementazione, dimensioni o complessità.
  • La modularità in termini di ambito della modifica.
  • La qualità in termini di numero e tipo di errori.
  • La maturità in termini di frequenza degli errori.
  • Le risorse in termini di spesa del progetto rispetto alla spesa pianificata

Le Tendenze sono importanti, da tenere sotto controllo nel tempo più di qualsiasi valore assoluto.

Metrica Scopo Prospettive/misurazioni di esempio
Avanzamento Pianificazione iterazione
Completezza
  • Numero di classi
  • SLOC
  • Function Point
  • Scenari
  • Scenari di test

Queste misurazioni possono essere raccolte anche per classe e per pacchetto

  • Quantità di rilavorazione per iterazione (numero di classi)
Stabilità Convergenza
  • Il numero ed il tipo di modifiche (bug o miglioramenti; interfaccia o implementazione)

Questa misurazione può essere raccolta per iterazione e per pacchetto

  • Quantità di rilavorazione per iterazione
Adattabilità Convergenza
"Rilavorazione" software
  • Media ore uomo/modifica

Questa misurazione può essere raccolta per iterazione e per pacchetto

Modularità Convergenza
"Scarto" software
  • Numero di classi/categorie cambiate per modifica

Questa misurazione può essere raccolta anche per iterazione

Qualità Pianificazione iterazione
Indicatore di rilavorazione
Criterio di rilascio
  • Numero di errori
  • Frequenza rilevazione difetti
  • Densità difetti
  • Profondità ereditarietà
  • Dipendenza classe
  • Dimensione interfaccia (numero di operazioni)
  • Numero di metodi sostituiti
  • Dimensione metodo

Queste misurazioni possono essere raccolte anche per classe e per pacchetto

Maturità Copertura/adeguatezza test
Solidità per l'utilizzo
  • Ore di test/errore e tipo di errore

Questa misurazione può essere raccolta per iterazione e per pacchetto

Profilo di spesa Introspezione finanziaria
Pianificato rispetto ad effettivo
  • Giorni uomo/classe
  • Personale a tempo pieno per mese
  • % budget consumato

Insieme minimo di metrica

Anche i progetti più piccoli devono tenere traccia dell'avanzamento per poter stabilire se il progetto rispetta la pianificazione ed il budget, e in caso contrario, per rieseguire una stima e determinare se sono necessarie delle modifiche all'ambito. L'insieme minimo di metrica quindi è incentrato sulla metrica relativa all'avanzamento.

  • Valore assorbito (Earned Value). Viene utilizzato per stimare di nuovo i tempi ed il budget per la parte restante del progetto e/o per rilevare la necessità di eventuali modifiche all'ambito.
  • Trend dei difetti. Viene utilizzato per semplificare la progettazione dell'impegno richiesto per eliminare i difetti.
  • Trend di avanzamento test. Viene utilizzato per determinare quante attività sono state effettivamente portate a termine.

Di seguito sono descritti in maniera più dettagliata.

Valore assorbito (Earned Value)

Il metodo più comunemente utilizzato ([PMI96]) per misurare l'avanzamento è l'Analisi del valore assorbito.

Il modo più semplice per misurare il valore assorbito è di considerare la somma dell'impegno stimato originale di tutte le attività completate. La "percentuale completata" di un progetto può essere calcolata come valore assorbito diviso l'impegno stimato originale totale del progetto. La produttività (o indice di prestazione) è il valore assorbito diviso l'impegno effettivo speso per le attività completate.

Ad esempio, si supponga che l'impegno lavorativo per la creazione di codice sia stato suddiviso in diversi compiti, molti dei quali ora sono terminati. La stima originaria per i compiti terminati era di 30 giorni lavorativi. L'impegno totale stimato per il progetto era di 100 giorni, quindi si può ipotizzare che il progetto sia completato al 30%.

Grafico dell'avanzamento del valore assorbito

Si supponga che i compiti siano stati completati entro il budget, con solo 25 giorni di impegno. L'indice di prestazione è 30/25 = 1.2 o 120%.
E' possibile ipotizzare che il progetto sarà portato a termine con il 20% al di sotto del budget, e ridurre di conseguenza le stime.

Considerazioni
  • L'indice di prestazione deve essere utilizzato solo per regolare le stime di compiti simili. Un completamento anticipato dei compiti di raccolta dei requisiti non suggerisce che la creazione di codice verrà portata a termine più rapidamente. Quindi, calcolare l'indice di prestazione solo per compiti dello stesso tipo, e regolare solo le stime di compiti simili.
  • E' necessario considerare anche altri fattori. I compiti futuri verranno eseguiti da personale con skill simili e in condizioni simili? I dati sono stati contaminati da "elementi fuori norma", compiti che sono stati ampiamente sovrastimati o sottostimati? Il tempo impiegato è stato riportato correttamente (ad esempio, lo straordinario deve essere incluso anche se non viene pagato)?
  • Le stime dei nuovi compiti stanno già calcolando l'indice di prestazione? In questo caso le stime delle nuove attività tenderanno ad essere più vicine all'obiettivo finale, spingendo l'indice di prestazione verso il 100%. E' necessario ricalcolare costantemente tutte le attività non portate a termine oppure adottare la seguente pratica di Extreme Programming (XP)[JEF01] - fare riferimento alle stime originarie come "punti" e misurare le nuove attività ugualmente in termini di "punti" senza aggiustare la prestazione effettiva. Il vantaggio dei "punti" è che gli aumenti (o le diminuzioni) di prestazione possono essere seguiti ("velocità del progetto" nella terminologia XP).

Se le attività sono ampie (più di 5 giorni) o esistono molti compiti che sono stati parzialmente eseguiti, è possibile inserirli come fattori nell'analisi. Applicare una "percentuale completata" soggettiva, moltiplicarla per la stima dell'impegno per l'attività e includerla nel valore assorbito. Una maggiore coerenza nei risultati si ottiene se esistono delle chiare regole di assegnazione della percentuale completata. Ad esempio, una regola potrebbe essere che ad un compito di codifica non venga assegnato più dell'80% di completamento finché il codice non ha passato una revisione.

Il valore assorbito viene trattato più avanti nella sezione Un insieme di metrica completo: Piano del progetto.

Trend dei difetti

Spesso è utile seguire l'andamento dei difetti aperti e chiusi. Questo fornisce un'indicazione approssimativa sull'eventuale esistenza di un arretrato di lavoro di correzione di difetti da portare a termine e quanto velocemente questi vengono chiusi.

Grafico del trend dei difetti

I trend dei difetti sono solo una delle metriche fornite dalla console di progetto Rational.

Considerazioni
  • Non tutte le richieste di modifica devono avere lo stesso peso, che inficino su una riga di codice soltanto o provochino una riprogettazione significativa. Questo può essere risolto utilizzando alcune delle seguenti tecniche:
    • Fare attenzione agli elementi fuori norma. Le richieste di modifica che richiedono del lavoro sostanziale devono essere identificate come tali ed essere seguite come compiti separati, non raccolte in un gruppo generico di correzioni. Se il trend è dominato da piccole correzioni, raggrupparle in modo tale che ciascuna richiesta di modifica rappresenti un'unità di lavoro più consistente.
    • E' possibile registrare più informazioni, come una "categoria di impegno lavorativo" soggettiva di "meno di 1 giorno" "1 giorno" "meno di 5 giorni" "più di 5 giorni".
    • E' possibile registrare SLOC (Source Line of Code) stimati e SLOC effettivi per ogni richiesta di modifica. Consultare Un piccolo insieme di metrica riportato di seguito.
  • Una mancanza di registrazione di difetti potrebbe implicare una mancanza di verifica. Fare attenzione al livello di impegno lavorativo di test che si verifica quando si esaminano i trend dei difetti.

Trend di avanzamento del test

L'ultima misurazione per la completezza è quanta funzionalità è stata integrata.
Se ognuno dei compiti di sviluppo rappresenta una serie di funzionalità integrate, può esser sufficiente un grafico di andamento del valore assorbito.

Un metodo molto semplice per comunicare l'avanzamento è tramite un trend di avanzamento del test.

Grafico di avanzamento del test di accettazione

Considerazioni
Alcuni scenari di test possono rappresentare in modo significativo più valore o impegno di altri. Non vederci troppo in questo grafico, fornisce semplicemente una conferma dell'avanzamento verso il completamento della funzionalità.

Un piccolo insieme di metrica

L'insieme minimo di metrica descritto in precedenza non è sufficiente per molti dei progetti.

Software Project Management, a Unified framework [ROY98] consiglia il seguente insieme di metrica per tutti i progetti. Queste metriche richiedono le stime ed i valori effettivi SLOC (Source Lines of Code) di ogni richiesta di modifica, che implica un ulteriore impegno per la raccolta.

Metrica e metrica primitiva

SLOC totale SLOCt = Dimensione totale stimata del codice. Può variare in modo significativo quando i requisiti vengono meglio identificati e quando maturano le soluzioni di progettazione. Include il software riutilizzato, soggetto a modifiche da parte del team.
SLOC sotto controllo
della configurazione
SLOCc = Linea di base corrente
Difetti critici SCO0 = numero di SCO di tipo 0 (dove SCO sta per Software Change Order, un altro termine per Richiesta di modifica)
Difetti normali SCO1 = numero di SCO di tipo 1
Richieste di miglioramento SCO2 = numero di SCO di tipo 2
Nuove funzioni SCO3 = numero di SCO di tipo 3
Numero di SCO N = SCO0 + SCO1 + SCO2
Rilavorazione aperta (violazione) B = SLOC cumulativo violato a causa di SCO1 e SCO2
Rilavorazione chiusa (correzioni) F = SLOC cumulativo corretto
Impegno di rilavorazione E = impegno cumulativo speso per le correzioni di SCO di tipo 0/1/2
Tempo di utilizzo UT = ore in cui una determinata linea di base ha operato all'interno di scenari di utilizzo realistici

Metrica per la qualità del prodotto finale

Da questo piccolo insieme di metrica possono essere derivate ulteriori metriche interessanti:

Indice dello scarto B/SLOCt, percentuale di prodotto scartato
Indice di rilavorazione E/impegno totale, percentuale di impegno per la rilavorazione
Modularità B/N, violazione media per SCO
Adattabilità E/N, impegno medio per SCO
Maturità UT/(SCO0 + SCO1), tempo medio fra i difetti
Possibilità di manutenzione (indice materiale di scarto)/(indice rilavorazione), produttività della manutenzione

Indicatori di avanzamento

Stabilità di rilavorazione B - F, violazione rispetto alle correzioni nel tempo
Arretrato di rilavorazione (B-F)/SLOCc, rilavorazione correntemente aperta
Trend della modularità Modularità, nel tempo
Trend dell'adattabilità Adattabilità, nel tempo
Trend della maturità Maturità, nel tempo

Un insieme di metrica completo

Cosa deve essere misurato? Inizio pagina

Gli elementi da misurare sono:

  • il Processo - la sequenza di attività richiamate per generare il prodotto software (ed altri prodotti di lavoro);
  • il Prodotto - i prodotti di lavoro del processo, incluso il software, i documenti ed i modelli;
  • il Progetto - la totalità delle risorse del progetto, le attività ed i prodotti di lavoro;
  • le Risorse - le persone, i metodi ed i tool, i tempi, l'impegno lavorativo ed il budget, disponibili per il progetto.

Il Processo

Per caratterizzare completamente il processo, le misurazioni devono essere fatte al livello più basso dell'attività formalmente pianificata. Le attività vengono pianificate dal responsabile di progetto utilizzando una serie iniziale di stime. Deve essere quindi conservata una registrazione dei valori effettivi nel tempo e qualsiasi eventuale stima aggiornata.

Metrica

Commenti

Durata Tempo trascorso per l'attività
Impegno Unità di impegno lavorativo del personale (ore uomo, giorni uomo, ...)
Output Prodotti di lavoro e relative dimensione e quantità (sono inclusi i difetti come output delle attività di test)
Utilizzo dell'ambiente di sviluppo software CPU, memoria, tool software, attrezzature (workstation, PC), materiale eliminabile. Questi materiali possono essere raccolti per un progetto dalla SEEA (Software Engineering Environment Authority).
Difetti, frequenza di rilevazione, frequenza di correzione. Devono essere raccolti anche il tempo/impegno totale di riparazione ed il materiale di scarto/rilavorazione totale (dove possono essere misurati); probabilmente vengono rilevati dalle informazioni raccolte dai difetti (considerati come prodotti di lavoro).
Richieste di modifica, frequenza di imposizione e frequenza di eliminazione. I commenti sono gli stessi relativi al tempo/impegno.
Altri eventi che possono avere una connessione con queste metriche (testo in formato libero) Questa è una metrica in quanto è un record di un evento che ha implicazioni sul processo.
Numeri, profilo (nel tempo) e caratteristiche del personale
Rotazione del personale Una metrica utile che può spiegare in un'analisi post-mortem perché un processo è andato particolarmente bene o male.
Applicazione dell'impegno Il modo in cui l'impegno viene utilizzato durante le prestazioni delle attività pianificate (rispetto il quale vengono formalmente registrati i tempi per la gestione dell'account dei costi) può essere utile per spiegare le variazioni di produttività: le sottoclassi di applicazione dell'impegno sono, ad esempio:
  • formazione
  • familiarizzazione
  • gestione (da parte del leader del team, ad esempio)
  • amministrazione
  • ricerca
  • lavoro produttivo (è utile registrarlo per prodotto di lavoro e tentare una separazione fra tempi di 'riflessione' e tempi di acquisizione, in modo particolare per i documenti. Questo indicherà al responsabile di progetto quanto il processo della documentazione sia impositivo sul tempo del programmatore.
  • tempo perso
  • riunioni
  • ispezioni, revisioni, analisi - impegno per la preparazione e per le riunioni (alcune di queste sono attività separate ed i relativi tempi ed impegno verranno registrati per una specifica attività di revisione)
Ispezioni, revisioni, analisi (durante un'attività - non analisi pianificate separatamente) Ne registra il numero e la relativa durata ed il numero di problematiche attivate.
Deviazioni dal processo (attivate come non conformità, che richiedono una modifica al progetto) Ne registra il numero e la relativa severità. Questo indica che potrebbe essere richiesta una maggiore formazione, che il processo è stato applicato in maniera non corretta o che non è corretto il modo in cui è stato configurato
Problemi del processo (attivati come difetti del processo, che richiedono una modifica al processo) Ne registra il numero e la severità. Queste informazioni saranno utili nelle analisi post-mortem ed è essenziale il feedback per la SEPA (Software Engineering Process Authority).

Il Prodotto

I prodotti in RUP (Rational Unified Process) sono i prodotti di lavoro, cioè i documenti, i modelli o gli elementi dei modelli. I modelli sono delle raccolte di elementi simili (gli elementi del modello) e di seguito sono elencate le metriche consigliate con i modelli a cui vengono applicate: di solito è ovvio se una metrica riguarda il modello intero o un elemento. Quando questo non è chiaro, è presente del testo esplicativo.

Caratteristiche del prodotto di lavoro

In generale le caratteristiche cui si è interessati per la misurazione sono le seguenti:

  • Dimensione - una misurazione del numero di elementi in un modello, la lunghezza di qualcosa, l'estensione o la massa di qualcosa
  • Qualità
    • Difetti - indicazioni su un prodotto di lavoro che non si esegue come specificato o che non è conforme con la sua specifica o che presenta altre caratteristiche non desiderabili
    • Complessità - una misurazione della complessità di una struttura o dell'algoritmo: maggiore è la complessità, più difficile è capire e modificare una struttura, ed è comprovato che le strutture complesse sono maggiormente soggette ad errori
    • Dipendenza - una misurazione relativa a quanto sono interconnessi gli elementi di un sistema
    • Coesione - una misurazione di quanto un elemento o un componente soddisfa il requisito di disporre di un unico scopo ben definito
    • Primitività - il grado secondo cui le operazioni o i metodi di una classe possono essere composti da altri offerti dalla classe
  • Completezza - una misurazione del punto in cui il prodotto di lavoro soddisfa tutti i requisiti (definiti e coinvolti-il responsabile di progetto deve cercare di renderli espliciti il più possibile, per limitare il rischio di aspettative non soddisfatte). Qui è stato scelto di non distinguere fra sufficiente e completo.
  • Tracciabilità - un'indicazione che i requisiti di un livello sono stati soddisfatti dai prodotti di lavoro ad un livello inferiore e, viceversa, che un prodotto di lavoro di qualsiasi livello ha ragione di esistere
  • Volatilità - il grado di modifica o di inconcludenza di un prodotto di lavoro a causa dei difetti o dei requisiti mutevoli
  • Impegno - una misurazione del lavoro (unità di tempo del personale) richiesta per generare un prodotto di lavoro

Non tutte le caratteristiche riguardano tutti i prodotti di lavoro: quelle pertinenti vengono elaborate con il prodotto di lavoro specifico nelle tabelle riportate di seguito. Quando per una caratteristica vengono elencate diverse metriche, sono tutte potenzialmente di un qualche interesse, poiché forniscono una descrizione completa della caratteristica da diversi punti di vista. Ad esempio, quando si considera la tracciabilità dei casi d'uso, alla fine devono essere tutti riconducibili ad un modello di implementazione (testato): nel contempo, è comunque utile per il responsabile di progetto sapere quanti casi d'uso possono essere attribuiti al modello di analisi, come misurazione dell'avanzamento.

Documenti

Le metriche consigliate riguardano tutti i documenti RUP.

Caratteristica

Metrica

Dimensione Conteggio delle pagine
Impegno Unità di tempo del personale per la produzione, la modifica e la riparazione
Volatilità Numero di modifiche, difetti, aperti, chiusi; pagine di modifica
Qualità Misurata direttamente tramite il conteggio dei difetti
Completezza Non misurata direttamente: giudizio effettuato tramite analisi
Tracciabilità Non misurata direttamente: giudizio effettuato tramite analisi

Modelli

Requisiti

Attributi dei requisiti

Si tratta in effetti di un elemento del modello.

Caratteristica Metrica
Dimensione
  • numero di requisiti in totale (= Nu+Nd+Ni+Nt)
  • numero di cui tenere traccia per i casi d'uso ( = Nu)
  • numero di cui tenere traccia solo per la progettazione, l'implementazione, il test ( = Nd)
  • numero di cui tenere traccia solo per l'implementazione, il test ( = Ni)
  • numero di cui tenere traccia solo per il test ( = Nt)

Questo suddivide i requisiti in quelli che verranno modellati dai casi d'uso e quelli non lo saranno. L'aspettativa è che la tracciabilità del caso d'uso calcoli i requisiti assegnati ai casi d'uso, per tenere traccia della progettazione, dell'implementazione e del test.

Impegno
  • Unità di tempo del personale (produzione, modifica e riparazione)
Volatilità
  • Numero di difetti e delle richieste di modifica
Qualità
  • Numero di difetti, per severità
Tracciabilità

Modello del caso d'uso

Caratteristica Metrica
Dimensione
  • Numero di casi d'uso
  • Numero di pacchetti di casi d'uso
  • Livello riportato del caso d'uso (consultare il white paper, "Stima dell'impegno e della dimensione in base ai casi d'uso"dal sito Web IBM)
  • Numero di scenari, totale e per caso d'uso
  • Numero di attori
  • Lunghezza del caso d'uso (ad esempio, le pagine del flusso di eventi)
Impegno
  • Unità di tempo del personale con la produzione, la modifica e la riparazione
Volatilità
  • Numero di difetti e delle richieste di modifica
Qualità
  • Complessità riportata (0-5, per analogia con COCOMO [BOE81], a livello di classe; l'intervallo di complessità è minore ai livelli superiori dell'astrazione - consultare il white paper, "The Estimation of Effort and Size based on Use Cases" dal sito Web IBM)
  • Difetti - numero di difetti, per severità, aperti, chiusi)
Completezza
  • Casi d'uso completati (rivisti e sotto la gestione della configurazione senza difetti in sospeso)/casi d'uso identificati (o numero stimato dei casi d'uso)
  • Tracciabilità dei requisiti-per-UC (dagli attributi dei requisiti)
Tracciabilità
  • Analisi
    • Scenari realizzati nel modello di analisi/scenari totali
  • Progettazione
    • Scenari realizzati nel modello di progettazione/scenari totali
  • Implementazione
    • Scenari realizzati nel modello di implementazione/scenari totali
  • Test
    • Scenari realizzati nel modello di test (scenari di test)/scenari totali

Progettazione

Modello di analisi

Caratteristica Metrica
Dimensione
  • Numero di classi
  • Numero di sottosistemi
  • Numero di sottosistemi dei sottosistemi ...
  • Numero di pacchetti
  • Metodi per classe, interni, esterni
  • Attributi per classe, interni, esterni
  • Profondità dell'albero di ereditarietà
  • Numero di child
Impegno
  • Unità di tempo del personale per la produzione, la modifica e la riparazione
Volatilità
  • Numero di difetti e delle richieste di modifica
Qualità Complessità
  • RFC (Response For a Class): questo può essere difficile da calcolare perché è necessario un insieme completo di diagrammi di interazione.
Dipendenza
  • Numero di child
  • Dipendenza fra gli oggetti (fan-out della classe)
Coesione
  • Numero di child
Difetti
  • Numero di difetti, per severità, aperti, chiusi
Completezza
Tracciabilità Non applicabile-il modello di analisi diventa il modello di progettazione.

Qui si vedono alcune metriche tecniche specifiche OO che possono non risultare familiari-profondità dell'albero di ereditarietà, numero di child, risposta per una classe, dipendenza fra gli oggetti e così via. Consultare [HEND96] per i dettagli sul significato e la cronologia di queste metriche. Alcune di queste metriche sono state originariamente suggerite da Chidamber e Kemerer (consultare "A metrics suite for object oriented design", IEEE Transactions on Software Engineering, 20(6), 1994), ma sono state applicate qui come suggerito in [HEND96] e si è preferita la definizione di LCOM (lack of cohesion in methods) presentata in quel lavoro.

Modello di progettazione

Caratteristica Metrica
Dimensione
  • Numero di classi
  • Numero di sottosistemi di progettazione
  • Numero di sottosistemi dei sottosistemi ...
  • Numero di pacchetti
  • Metodi per classe, interni, esterni
  • Attributi per classe, interni, esterni
  • Profondità dell'albero di ereditarietà
  • Numero di child
Impegno
  • Unità di tempo del personale (per la produzione, la modifica e la riparazione)
Volatilità
  • Numero di difetti e delle richieste di modifica
Qualità Complessità
  • RFC (Response For a Class): questo può essere difficile da calcolare perché è necessario un insieme completo di diagrammi di interazione.
Dipendenza
  • Numero di child
  • Dipendenza fra gli oggetti (fan-out della classe)
Coesione
  • Numero di child
Difetti
  • Numero di difetti, per severità
Completezza
Tracciabilità Numero di classi nel modello di implementazione/numero di classi

Implementazione

Modello di implementazione

Caratteristica Metrica
Dimensione
  • Numero di classi
  • Numero di file
  • Numero di sottosistemi di implementazione
  • Numero di sottosistemi dei sottosistemi ...
  • Numero di pacchetti
  • Metodi per classe, interni, esterni
  • Attributi per classe, interni, esterni
  • Dimensione dei metodi*
  • Dimensione degli attributi*
  • Profondità dell'albero di ereditarietà
  • Numero di child
  • Dimensione stimata* al completamento
Impegno
  • Unità di tempo del personale (con produzione, modifica e riparazione separate)
Volatilità
  • Numero di difetti e delle richieste di modifica
  • Violazione* per ogni modifica correttiva o perfettiva, stimata (prima della correzione) ed effettiva (alla chiusura)
Qualità Complessità
  • RFC (Response For a Class, risposta per una classe)
  • Complessità ciclomatica dei metodi**
Dipendenza
  • Numero di child
  • Dipendenza fra gli oggetti (fan-out della classe)
  • MPC (Message passing coupling, dipendenza passaggio di messaggi)***
Coesione
  • Numero di child
  • LCOM (Lack of cohesion in methods, mancanza di coesione nei metodi)
Difetti
  • Numero di difetti, per severità, aperti, chiusi
Completezza

* Deve essere scelto un metodo di misurazione della dimensione del codice e deve essere applicato costantemente, ad esempio non-comment (non commento), non-blank (non spazio vuoto). Consultare [ROY98] per una trattazione sui meriti e l'applicazione di 'righe di codice' come metrica. Vedere lo stesso riferimento per la definizione di 'violazione (breakage)'.

** L'utilizzo della complessità ciclomatica non viene accettato universalmente - in particolare quando applicata ai metodi di una classe. Per una trattazione su questa metrica, consultare [HEND96].

*** Originariamente di Li ed Henry, "Object-oriented metrics that predict maintainability", J. Systems and Software, 23(2), 1993, e descritto anche in [HEND96].

Test

Modello di test

Caratteristica Metrica
Dimensione
  • Numero di scenari di test, procedure di test, script di test
Impegno
  • Unità di tempo del personale (con produzione, modifica e riparazione separate) per la produzione di scenari di test, e così via
Volatilità
  • Numero di difetti e di richieste di modifica archiviate nei confronti del modello di test
Qualità
  • Difetti - numero di difetti per severità, aperti, chiusi (sono difetti attivati nell'ambito del modello di test stesso, non difetti attivati dal team di test per altro software)
Completezza
Tracciabilità
  • Numero di scenari di test riportati con esito positivo nel riepilogo di valutazione del test/Numero di scenari di test

Gestione

Modello di modifica-si tratta di un modello di nozioni per una presentazione congruente-le metriche vengono raccolte a prescindere dal sistema utilizzato per gestire le richieste di modifica.

Caratteristica Metrica
Dimensione
  • Numero di difetti, richieste di modifica per severità e stato, classificate inoltre come numero di modifiche perfettive, numero di modifiche di adattamento e numero di modifiche correttive.
Impegno
  • Impegno lavorativo per la riparazione dei difetti, impegno lavorativo per l'implementazione delle modifiche in unità di tempo del personale
Volatilità
  • Violazione (stimata, effettiva) per il sottoinsieme del modello di implementazione.
Completezza
  • Numero di difetti scoperti/numero di difetti previsti (se viene utilizzato un modello di affidabilità)

Piano del progetto (sezione 4.2 del piano di sviluppo di software)

Esistono delle misurazioni che provengono dall'applicazione delle tecniche del valore assorbito (Earned Value) per la gestione del progetto; insieme denominati C/SCSC (Cost/Schedule Control Systems Criteria, criteri dei sistemi di controllo costi/tempi). Una tecnica semplice di valore assorbito è descritta in precedenza come parte di Un insieme minimo di metriche. Possono essere eseguite delle analisi più dettagliate utilizzando le metriche correlate, incluso:

  • BCWS, Budgeted Cost for Work Scheduled
  • BCWP, Budgeted Cost for Work Performed
  • ACWP, Actual Cost of Work Performed
  • BAC, Budget at Completion
  • EAC, Estimate at Completion
  • CBB, Contract Budget Base
  • LRE, Latest Revised Estimate (EAC)

fattori derivati per la discrepanza di costi e tempi. Consultare [ROY98] per una trattazione dell'applicazione di un approccio valore assorbito per la gestione del progetto software.

Il Progetto

Il progetto deve esser caratterizzato in termini di tipo, dimensione, complessità e formalità (anche se in genere il tipo, la dimensione e la complessità determinano la formalità), poiché questi aspetti condizioneranno le aspettative relative alle varie soglie per misurazioni di livello inferiore. Altri vincoli devono essere catturati nel contratto (o specifiche). Le metriche derivate dal processo, dal prodotto e dalle risorse acquisiranno tutte le altre metriche a livello del progetto. Il tipo di progetto ed il dominio possono essere registrati con una descrizione di testo, verificando che vi siano dettagli sufficienti a caratterizzare il progetto in modo accurato. Registrare la dimensione del progetto per costo, impegno lavorativo, durata, dimensione del codice da sviluppare, Function Point da distribuire. La complessità del progetto può essere descritta - in qualche maniera in modo soggettivo-collocando il progetto in un grafico che mostra la complessità tecnica e di gestione relativa ad altri progetti completati. [ROY98], la figura 14-1 mostra un simile diagramma.

Le metriche derivate descritte in [ROY98], che sono gli indicatori principali del responsabile progetto, possono essere ricavate dalle metriche raccolte per il prodotto ed il processo. Tra queste, si segnalano:

  • Modularità = violazione media (NCNB*) per modifica perfettiva o correttiva sul modello di implementazione
  • Adattabilità = impegno medio per modifica perfettiva o correttiva sul modello di implementazione
  • Maturità = tempi del test attivo/numero di modifiche correttive
  • Manutenibilità = Produttività di manutenzione/Produttività di sviluppo = [correzioni cumulative effettive/impegno cumulativo per le modifiche perfettive e correttive]/[numero stimato di NCNB al completamento/impegno di produzione stimato al completamento]
  • Stabilità della rilavorazione = violazione cumulativa-correzioni cumulative
  • Arretrato di rilavorazione = [violazione cumulativa-correzioni cumulative]/unità NCNB testata

* NCNB è una dimensione di codice non commento (non-comment), non spazio vuoto (non-blank).

L'avanzamento deve essere riportato dal piano del progetto utilizzando le metriche di completamento del prodotto di lavoro - con un peso particolare (dalla prospettiva del valore assorbito) dato alla produzione di software funzionante.

Se viene utilizzato un modello di stima come COCOMO (consultare [BOE81], devono essere registrati i diversi fattori di scala ed i determinanti dei costi (cost driver). Questi elementi in effetti formano una caratterizzazione piuttosto dettagliata del progetto.

Le Risorse

Le voci da misurare includono le persone (esperienza, skill, costo, prestazione), i metodi ed i tool (in termini di effetto sulla produttività e qualità, costo), i tempi, l'impegno, il budget (le risorse utilizzate e le risorse rimaste).

Il profilo del personale deve essere registrato nel tempo, con il tipo (analista, progettista, ecc.), il grado (che implica il costo) ed il team a cui è assegnato. Devono essere registrati sia i dati effettivi che del piano.

Il modello COCOMO richiede la caratterizzazione delle esperienze e delle capacità del personale, e l'ambiente di sviluppo del software, ed è un buon framework in cui conservare le metriche.

Le informazioni relative alla spesa, al budget e ai tempi verranno dal piano del progetto.