Esperimenti che correlano le metriche del codice alla densità dei bug


16

Mi chiedo se qualcuno abbia fatto alcuni esperimenti correlando le metriche del codice (SLOC, complessità ciclomatica, ecc.) Con la densità di bug nelle applicazioni orientate agli oggetti.

Non sto cercando esperimenti che provino o confutino solo una correlazione, ma su entrambi. Non sto cercando di trovare un proiettile d'argento poiché credo che la densità di bug di un progetto possa essere correlata a una o più metriche per un determinato progetto o gruppo e la correlazione può cambiare durante la vita del progetto / gruppo.

Il mio obiettivo è quello di

  1. Misura tutte le metriche interessanti per 2-3 mesi (ne abbiamo già parecchie dal sonar).
  2. Trova una metrica correlata al numero di nuovi bug.
  3. Effettuare un'analisi delle cause alla radice per verificare perché ciò accada (ad esempio, ci manca una certa abilità progettuale?).
  4. Migliora l'abilità e misura il cambiamento per un paio di iterazioni.
  5. Risciacquare e ripetere da 2.

Se non hai alcuna esperienza in merito, ma ricorda di aver visto un articolo / blog sull'argomento, ti sarei grato se puoi condividerlo.


Finora ho trovato i seguenti link con alcune informazioni su questo argomento


1
Se si desidera evitare la chiusura, è necessario ripetere la domanda. I siti di Stack Stack non sono motori di ricerca e gli utenti non sono assistenti di ricerca personali . Invece di chiedere collegamenti ai documenti, l'enfasi dovrebbe essere sulla domanda quali tipi di metriche sono state correlate con i difetti e la densità dei difetti.
Thomas Owens

1
Mi dispiace che la domanda si sia presentata come una richiesta per diventare il mio assistente di ricerca personale , non è sicuramente quello che volevo fare, ma trovare questo tipo di documenti non è qualcosa di molto comune. Ho cambiato il titolo in modo che gli altri non abbiano la stessa impressione.
Augusto,

Risposte:


11

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 .


Le metriche di Halstead hanno dimostrato di essere fortemente correlate con SLOC grezzo (numero di righe di codice sorgente). A quel punto, tutto ciò che è correlato a qualsiasi metrica di Halstead è diventato noto per essere correlato con SLOC grezzo ed è più facile misurare SLOC rispetto a qualsiasi metrica di Halstead.
John R. Strohm,

@ JohnR.Strohm Non sono d'accordo sul fatto che sia più facile contare SLOC che calcolare le metriche di Halstead, quando si utilizzano strumenti per eseguire il calcolo. Supponendo che le metriche di Halstead siano valide (il che è in realtà dibattuto, ma nulla conta per una metrica non valida), conoscere il tempo necessario per sviluppare il codice o il numero previsto di difetti nel sistema è un valore più utile rispetto alla conoscenza della quantità di linee. Sono in grado di creare pianificazioni con dati temporali, piani di qualità con dati di difetto o allocare tempo sufficiente per una revisione del codice con difficoltà. È più difficile usare SLOC crudo per queste cose.
Thomas Owens

@ JohnR.Strohm Sono sicuro che l'esecuzione di un programma di calcolo metrico Halstead richiede un po 'più di tempo rispetto a un programma di conteggio SLOC. Ma supponendo che un output valido diventi un input valido in un processo decisionale, preferirei avere tempo, sforzi e dati significativi sui difetti piuttosto che un conteggio SLOC grezzo. Il valore aggiunto della metrica più complessa spesso vale il tempo di calcolo aggiuntivo, assumendo nuovamente input validi e output di calcolo validi.
Thomas Owens

@ThomasOwens, la questione se lo sforzo del software, e quindi i costi e il programma, possano essere stimati direttamente dalle stime di SLOC grezzo è stata fatta a morte. Dopo una considerevole ricerca sui dati reali del progetto, la domanda è stata risolta, in senso affermativo. Vedi "Software Engineering Economics", di Barry Boehm, 1981.
John R. Strohm,

@ThomasOwens: Inoltre, bisogna riconoscere che le metriche di Halstead sono intrinsecamente retrospettive. Non puoi misurare le metriche Halstead del software che non hai ancora scritto. D'altra parte, è possibile stimare SLOC grezzo per un determinato compito e, date le specifiche abbastanza dettagliate e una piccola esperienza, è relativamente facile avvicinarsi abbastanza al preventivo. Inoltre, è MOLTO facile confrontare le stime con gli effettivi, perfezionare l'euristica di stima e calibrare il proprio stimatore di costi. La General Dynamics / Fort Worth ha lavorato molto su questo nei primi anni '80.
John R. Strohm,

7

Ho discusso delle possibili correlazioni in uno dei miei post sul blog :

Correlazione tra complessità ciclomatica e densità di bug: è questo il vero problema?

La risposta è no. Mantenendo le dimensioni costanti, gli studi non mostrano alcuna correlazione tra CC e densità dei difetti. Tuttavia, ci sono altre due correlazioni interessanti da studiare:

Il primo è: CC è fortemente correlato alla durata del rilevamento e della correzione dei difetti? In altre parole, se CC fosse inferiore, dedicheremmo meno tempo al debug e ripareremmo i difetti?

Il secondo è: CC è fortemente correlato al Rapporto di feedback guasti (FFR, il numero medio di difetti che risulta dall'applicazione di una modifica o dalla correzione di un difetto)?

Ha bisogno di ulteriori indagini per vedere se qualcuno ha mai studiato empiricamente questa correlazione. Ma il mio istinto e il feedback che ricevo dai team con cui lavoro è che esiste una forte correlazione positiva tra la complessità ciclomatica da un lato e la durata del rilevamento e della correzione di un difetto o dell'impatto del cambiamento su un altro lato.

Questo è un buon esperimento da fare. Stai attento ai risultati!


Non degno di un voto negativo, ma dovrebbe essere "alcuni studi non mostrano alcuna correlazione", poiché altri studi mostrano una correlazione.
David Hammen,

3

Nel libro Code Complete, p.457, Steve McConnell afferma che "la complessità del flusso di controllo è importante perché è stata correlata con bassa affidabilità e frequenti errori". Quindi menziona alcuni riferimenti che supportano tale correlazione, incluso lo stesso McCabe (a cui è attribuita la capacità di sviluppare la metrica della complessità ciclomatica). La maggior parte di questi precede l'uso diffuso di linguaggi orientati agli oggetti, ma poiché questa metrica si applica ai metodi all'interno di tali linguaggi, i riferimenti potrebbero essere quello che stai cercando.

Tali riferimenti sono:

  • McCabe, Tom. 1976. "Una misura di complessità". Transazioni IEEE sull'ingegneria del software, SE-2, n. 4 (dicembre): 308-20
  • Shen, Vincent Y., et al. 1985. "Identificazione del software soggetto a errori - Uno studio empirico". Transazioni IEEE sull'ingegneria del software SE-11, n. 4 (aprile): 317-24.
  • Ward, William T. 1989. "Prevenzione dei difetti del software usando la metrica della complessità di McCabe". Hewlett-Packard Journal, aprile 64-68.

Dalla mia esperienza, la metrica di McCabe, in quanto può essere calcolata da un programma su molte sezioni di codice, è utile per trovare metodi e funzioni che sono troppo complicati e che hanno un'alta probabilità di contenere errori. Sebbene non abbia calcolato, la distribuzione degli errori all'interno delle funzioni di elevata complessità ciclomatica rispetto alle funzioni di bassa complessità ciclistica, lo studio di tali funzioni mi ha permesso di scoprire errori di programmazione trascurati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.