-
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à.
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
|
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
|
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%.
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.
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.
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à.
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
|
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.
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).
|
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
|
|
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
|
|
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 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 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.
|