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

15

Mi chiedo se qualcuno abbia fatto degli esperimenti che correlano le metriche del codice (SLOC, complessità ciclomatica, ecc.) con la densità dei bug nelle applicazioni orientate agli oggetti.

Non sto cercando esperimenti che dimostrino o smentiscano solo una correlazione, ma su entrambi. Non sto cercando di trovare un proiettile d'argento in quanto ritengo che la densità dei bug di un progetto possa essere correlata a una o più metriche per un determinato progetto o team e la correlazione possa cambiare durante la vita del progetto / squadra.

Il mio obiettivo è

  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. Esegui un'analisi della causa principale per verificare perché ciò accade (ad esempio, ci manca una certa abilità di progettazione?).
  4. Migliora l'abilità e misura il cambiamento per un paio di itereazioni.
  5. Risciacquare e ripetere da 2.

Se non hai esperienza in merito, ma ricorda di aver visto un articolo / blog su questo argomento, sarei grato se tu possa condividerlo.

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

posta Augusto 17.05.2012 - 11:55
fonte

3 risposte

10

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 .

    
risposta data 17.05.2012 - 15:33
fonte
6

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

Correllation between Cyclomatic Complexity and Bugs density: Is this the real Issue?

The answer is no. Keeping the size constant, studies show no correlation between CC and defect density. However, there are other two interesting correlations to study:

The first one is: Does CC strongly correlate with the duration of detecting and fixing defects? In other words, if CC is lower, would we spend less time debug and fix defects?

The second one is: Does CC strongly correlate with the Fault Feedback Ratio (FFR, the average number of defects which results from applying one change or fixing one defect)?

It needs more investigation to see if anyone has ever studied this correlation empirically. But, my gut feeling and the feedback I get from the teams I work with is that there is strong positive correlation between cyclomatic complexity on one side and the duration of detecting and fixing a defect or the change impact on another side.

This is a good experiment to do. Keep alert for the results!

    
risposta data 30.07.2012 - 08:07
fonte
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 McCabe stesso (a cui è attribuito il merito di aver sviluppato la metrica della complessità ciclomatica). La maggior parte di questi pre-data l'uso diffuso di linguaggi orientati agli oggetti, ma poiché questa metrica si applica ai metodi all'interno di quei linguaggi, i riferimenti potrebbero essere ciò che stai cercando.

Questi riferimenti sono:

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

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

    
risposta data 22.08.2012 - 22:38
fonte

Leggi altre domande sui tag