Ogni volta che sento dei tentativi di associare qualche tipo di metrica basata su codice a difetti del software, la prima cosa a cui penso è la complessità ciclomatica di McCabe . Vari studi hanno scoperto che esiste una correlazione tra un'elevata complessità ciclomatica e il numero di difetti. Tuttavia, altri studi che hanno esaminato moduli con dimensioni simili (in termini di righe di codice) hanno scoperto che potrebbe non esserci una correlazione.
Per me, sia il numero di righe in un modulo che la complessità ciclomatica potrebbero servire da buoni indicatori di possibili difetti, o forse una maggiore probabilità che vengano iniettati difetti se vengono apportate modifiche a un modulo. Un modulo (specialmente a livello di classe o di metodo) con elevata complessità ciclomatica è più difficile da comprendere poiché vi è un gran numero di percorsi indipendenti attraverso il codice. Un modulo (di nuovo, specialmente a livello di classe o di metodo) con un gran numero di linee è anche difficile da capire poiché l'aumento delle linee significa che stanno accadendo più cose. Esistono molti strumenti di analisi statica che supportano il calcolo di entrambe le righe di codice sorgente rispetto a regole specifiche e complessità ciclomatica, sembra che catturarli significherebbe afferrare i frutti bassi.
Le misure di complessità di Halstead potrebbero anche essere interessanti. Sfortunatamente, la loro validità sembra essere in qualche modo dibattuta, quindi non avrei bisogno di fare affidamento su di loro. Una delle misure di Halstead è una stima dei difetti basata sullo sforzo o sul volume (una relazione tra la durata del programma in termini di operatori e operandi totali e il vocabolario del programma in termini di operatori e operatori distinti).
Esiste anche un gruppo di metriche note come metriche CK. La prima definizione di questa suite di metriche sembra essere in un documento intitolato A Metrics Suite for Object Oriented Design di Chidamber e Kemerer. Definiscono metodi ponderati per classe, albero della profondità dell'ereditarietà, numero di figli, accoppiamento tra classi di oggetti, risposta per una classe e mancanza di coesione nei metodi. Il loro documento fornisce i metodi di calcolo e una descrizione di come analizzarli.
In termini di letteratura accademica che analizza queste metriche, potresti essere interessato all'analisi empirica delle metriche CK per la complessità del design orientato agli oggetti: implicazioni per i difetti del software, creata da Ramanath Subramanyam e MS Krishna. Hanno analizzato tre delle sei metriche CK (metodi ponderati per classe, accoppiamento tra oggetti classificati e albero della profondità dell'ereditarietà). Dando un'occhiata al documento, sembra che abbiano scoperto che si tratta di metriche potenzialmente valide, ma devono essere interpretate con cautela poiché il "miglioramento" potrebbe portare ad altri cambiamenti che comportano anche una maggiore probabilità di difetti.
Anche l'analisi empirica delle metriche di progettazione orientate agli oggetti per la previsione di guasti ad alta e bassa gravità, autore di Yuming Zhou e Hareton Leung, esamina le metriche CK. Il loro approccio era determinare se sono in grado di prevedere i difetti sulla base di queste metriche. Hanno scoperto che molte delle metriche CK, ad eccezione della profondità dell'albero ereditario e del numero di bambini) avevano un certo livello di significatività statistica nella previsione delle aree in cui si potevano individuare i difetti.
Se hai un abbonamento IEEE, ti consiglio di cercare nelle Transazioni IEEE sull'ingegneria del software per ulteriori pubblicazioni accademiche e il software IEEE per alcuni rapporti reali e applicati. L'ACM potrebbe anche avere pubblicazioni pertinenti nella sua biblioteca digitale .