Metrica software
Una metrica software è uno standard per la misura di alcune proprietà del software o delle sue specifiche.
I metodi quantitativi si sono dimostrati strumenti potenti in altri campi della scienza, per questo motivo per la scienza dei computer pratici e teorici si sono impegnati a fondo per mettere a punto un simile approccio nello sviluppo di software. L'ingegnere del software Tom DeMarco ha affermato che "non puoi controllare ciò che non sai misurare".
Metriche software più utilizzate
Le metriche software comunemente adottate sono:
Utilizzo
Le metriche software possono essere utilizzate per:
- stimare il budget per il progetto e la codifica
- stimare la produttività individuale e la qualità
- stimare la produttività del progetto e la qualità
- stimare la qualità del software
Limitazioni
La valutazione di "quanto" software sia presente in un programma è molto difficoltosa da soddisfare, definire o misurare, specialmente se è necessario fare previsioni antecedenti la progettazione di dettaglio. L'utilità pratica delle metriche software è così limitata a domini ristretti dove cioè è possibile stabilire il processo di misura.
Le metodologie di gestione come il Modello di maturità e capacità o anche l'ISO 9000 si sono quindi concentrati maggiormente sulle metriche di processo che assistono nel monitoraggio e nel controllo del processo di produzione del software.
Esempi di metriche di processo che riguardano il software:
- Numero di volte in cui si è fallita la ricompilazione del programma
- Numero di bug introdotti per ore di sviluppo
- Numero di cambiamenti richiesti
- Quantità di ore disponibili di un programmatore al mese
- Numero di release di patch richieste in seguito al primo prodotto sviluppato
Critiche
Debolezze potenziali e critiche dell'approccio tramite metriche:
- Immoralità: È stato detto che è immorale ridurre il lavoro di persone in un piccolo ventaglio di variabili numeriche e successivamente giudicare loro attraverso tali misurazioni. Un supervisore può assegnare un programmatore esperto per i compiti del progetto più complicati; egli potrebbe generare la maggior parte degli errori e spendere molto tempo. Un caposquadra non informato potrebbe giudicare tale programmatore come scarsamente produttivo senza consultare il supervisore che ha il quadro d'insieme.
- Degradazione: Pura "gestione attraverso numeri" priva di riguardo rispetto alla qualità dell'esperienza degli impiegati, nessun riguardo per la 'gestione del personale'.
- Disallineamento: Il processo di misurazione è influenzato all'atto di misura dalla ricerca di dipendenti che massimizzano la percezione, da parte del misuratore, di poter amministrare le loro performance. Per esempio, se sono utilizzate le linee di codice per giudicare le performance, allora i dipendenti scriveranno tante linee di codice separate quante ne sono possibili, e se troveranno un modo per compattare il loro codice, potrebbero non adottarlo.
- Inaccuratezza: Le metriche dovrebbero essere al tempo stesso significative e accurate. Le linee di codice sono molto accurate, perché misurano esattamente ciò che è stato editato, ma poco significative, perché non dicono nulla sulla difficoltà reale del problema. I punti funzione invece, sviluppati per una misura migliore della complessità del codice o delle specifiche, possono dare una misura sia significativa che accurata, ma richiedono esperienza e giudizio per essere usati in modo adeguato: stime differenti produrranno risultati differenti. Questo fa dei punti funzione una metrica difficile da utilizzare proficuamente e non adatta a strutture manageriali prive di esperienza nel settore dello sviluppo software.
