Ogni volta che sento di tentativi di associare un tipo di metrica basata su codice con difetti del software, la prima cosa che penso è di McCabe"> complessità ciclomatica . Vari studi hanno trovato che esiste una correlazione tra una elevata complessità ciclomatica e il numero di difetti. Tuttavia, altri studi che hanno esaminato moduli di dimensioni simili (in termini di righe di codice) hanno rilevato che potrebbe non esserci una correlazione.
Per me, sia il numero di linee in un modulo che la complessità ciclomatica potrebbero servire da buoni indicatori di possibili difetti, o forse una maggiore probabilità che i difetti vengano iniettati se vengono apportate modifiche a un modulo. Un modulo (specialmente a livello di classe o di metodo) con elevata complessità ciclomatica è più difficile da capire poiché esiste un gran numero di percorsi indipendenti attraverso il codice. Un modulo (di nuovo, soprattutto a livello di classe o di metodo) con un gran numero di linee è anche difficile da capire poiché l'aumento delle righe significa che stanno accadendo molte cose. Esistono molti strumenti di analisi statica che supportano il calcolo di entrambe le linee di codice sorgente in base a regole specifiche e complessità ciclomatica, sembra che catturarli catturerebbe il frutto basso in sospensione.
Anche le misure di complessità di Halstead potrebbero essere interessanti. Sfortunatamente, la loro validità sembra essere alquanto dibattuta, quindi non mi baserei su di loro. Una delle misure di Halstead è una stima dei difetti basata sullo sforzo o sul volume (una relazione tra la lunghezza 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 noto come metriche CK. La prima definizione di questa suite di metriche sembra essere in un documento intitolato A Metrics Suite per Object Oriented Design di Chidamber e Kemerer. Definiscono metodi ponderati per classe, profondità dell'albero di ereditarietà, numero di figli, accoppiamento tra classi di oggetti, risposta per una classe e mancanza di coesione nei metodi. Il loro articolo fornisce i metodi di calcolo e una descrizione di come analizzare ciascuno di essi.
In termini di letteratura accademica che analizza queste metriche, potreste essere interessati all'analisi empirica delle metriche CK per la complessità progettuale orientata agli oggetti: implicazioni per difetti del software, create da Ramanath Subramanyam e M.S. Krishna. Hanno analizzato tre delle sei metriche CK (metodi ponderati per classe, accoppiamento tra oggetto classificato e albero della profondità di ereditarietà). Osservando la carta, sembra che abbiano trovato queste metriche potenzialmente valide, ma devono essere interpretate con cautela poiché "migliorando" si potrebbero portare ad altre modifiche che portano anche a una maggiore probabilità di difetti.
Analisi empirica di metriche progettuali orientate agli oggetti per la previsione di errori di gravità alta e bassa, create da Yuming Zhou e Hareton Leung, esaminano anche le metriche CK. Il loro approccio consisteva nel determinare se potevano prevedere i difetti sulla base di questi parametri. Hanno scoperto che molte delle metriche CK, ad eccezione della profondità dell'albero genealogico e del numero di bambini) avevano un certo livello di significatività statistica nella previsione delle aree in cui potevano essere localizzati i difetti.
Se hai un abbonamento IEEE, ti consiglio di cercare nelle Transazioni IEEE sull'ingegneria del software per ulteriori informazioni pubblicazioni e Software IEEE per altri rapporti reali e applicati. L'ACM potrebbe anche avere pubblicazioni pertinenti nella loro biblioteca digitale .