C'è qualche lavoro nell'applicazione delle misure di complessità di Halstead per determinare la qualità del software?

Nel 1977, Maurice Howard Halstead ha introdotto le sue misure di complessità per i sistemi software , che includevano misurazioni del vocabolario del programma, lunghezza del programma, volume, difficoltà, sforzo e un numero stimato di bug in un modulo. Secondo Wikipedia, la difficoltà si riferisce alla difficoltà di comprendere il programma durante la lettura o la scrittura e lo sforzo può essere tradotto nel tempo necessario per codificare un'applicazione in cui Tempo = (Sforzo / 18) secondi.

Una misurazione è inutile a meno che i dati e i calcoli non si riferiscano ad alcuni aspetti dello sviluppo del software. Tuttavia, non ho trovato alcun lavoro che affermi che una difficoltà di un certo valore o superiore tende ad un aumento statisticamente significativo dei difetti o una relazione tra difficoltà e tempo per leggere il codice (una difficoltà di N produce una media di M ore trascorse comprendere la base di codice) o qualsiasi analisi di essere in grado di calcolare il Tempo dopo che il fatto sia utile nel determinare la qualità (specialmente dal momento che il tempo di scrivere dovrebbe essere già stato registrato come misura). Sono particolarmente interessato alla stima dei bug di Halstead (che non è menzionata su Wikipedia) - il numero di bug in un'applicazione può essere stimato in Volume / 3000 o Sforzo ^ (2/3) / 3000.

Sto cercando due cose:

Qualcuno ha usato le misure di complessità del software di Halstead in un'applicazione del mondo reale per valutare la qualità del software? In tal caso, come li hai applicati e si sono rivelati una misura utile, valida e / o affidabile?
Esistono ricerche accademiche sotto forma di sondaggi, analisi o casi studio che discutono della validità (o invalidità) delle misure di complessità di Halstead quando applicate alla qualità del software?
Esistono ricerche accademiche sotto forma di sondaggi, analisi o casi di studio che dimostrano l'uso di Source Lines of Code (SLOC) per calcolare qualcosa di simile alle metriche di Halstead su Volume, Difficoltà, Sforzo, Tempo e Bug? Sospetterei che il volume potrebbe semplicemente corrispondere a un conteggio SLOC e che la difficoltà potrebbe corrispondere alla complessità ciclomatica (e possibilmente ad altre misure). Sono anche consapevole che misurare lo sforzo, la produttività o il tempo in SLOC è potenzialmente fuorviante.

quality metrics measurement

— Thomas Owens
fonte

Avrai qualche problema a trovare risultati negli ultimi 15 anni, dal momento che il lavoro di metrica di Halstead è stato svolto più o meno come 30-40 anni fa e la forte correlazione con SLOC è stata scoperta quasi immediatamente. (Questo è dalla memoria, da un discorso di un nuovo candidato alla facoltà di dottorato alla UT Austin del 1977.)

— John R. Strohm,

Grazie per quello Aggiornerò la domanda e rifocalizzerò i miei vecchi lavori di ricerca.

— Thomas Owens

Risposte:

Microsoft Research ha svolto alcuni lavori in questo settore. Dai un'occhiata a questa pagina: http://research.microsoft.com/en-us/people/nachin/ . Sebbene non sia specificamente basato su Halstead, Nachi e il suo team hanno svolto alcune indagini usando Halstead, la complessità ciclomatica, la modifica del codice e altre misure per valutare il rischio relativo e la fragilità per apportare modifiche nelle aree del codice. C'è anche un documento interessante su come anche l'efficacia organizzativa gioca un ruolo importante ma è fuori tema. :)

— nithins
fonte

Dovrò leggere alcuni di quelli. Sicuramente qualcosa che mi interessa, ma lo sono (almeno adesso), particolarmente interessato a Halstead, quindi mi concentrerò lì. Ho aggiunto il sito ai segnalibri in modo da poterlo leggere quando avrò ancora un po 'di tempo, ma per ora ecco un +1.

— Thomas Owens

La complessità ciclomatica di McCabe ha dimostrato, sul codice reale, di essere fortemente correlata con lo SLOC grezzo, al punto che non esiste alcun valore incrementale nel calcolo.

— John R. Strohm,

Ci sono alcuni studi del genere. Google è il tuo AMICO.

Le metriche di Halstead sono cadute in disgrazia quando è stato dimostrato che tutti erano fortemente correlati con SLOC grezzo (righe di codice sorgente). A quel punto, diventa più facile misurare SLOC e farcela.

Ecco un risultato da Google Libri .

— John R. Strohm
fonte

Ho cercato su Google da prima di porre questa domanda e non ho ancora trovato documenti pubblicati o altre fonti affidabili. Inoltre, non riesco a vedere come una metrica correlata a SLOC possa essere scarsa. SLOC / tempo è una misura scarsa della produttività, ma altre metriche basate su SLOC sono generalmente considerate valide, ad esempio difetti / SLOC.

— Thomas Owens

@Thomas: Non è che le metriche di Halstead siano "correlate" a SLOC, è che sono fortemente correlate. Statistiche 102. Dire che Y e X sono fortemente correlati significa che il rapporto Y / X è essenzialmente costante per tutti i set di dati. In questo caso, non ha senso misurare Y se è più facile misurare X, perché Y non ti sta davvero dicendo nulla di ciò che non sai già da X.

— John R. Strohm

Ha senso. Le metriche di Halstead si basano sul numero di operatori e operandi distinti e totali. È logico che un programma più lungo avrà più operatori / operandi totali e avrà più probabilità operatori / operandi più distinti. Le metriche di volume e difficoltà potrebbero essere ottenute utilizzando SLOC invece di operatori / operandi. Tuttavia, ciò non riguarda la validità, le applicazioni e il significato (o la mancanza di significato) delle metriche Effort, Time e Bugs. Anche se calcolate con SLOC invece di operatori / operandi, queste metriche dicono qualcosa di significativo sul sistema?

— Thomas Owens

SLOC è più facile da contare e probabilmente più utile. Le stime di SLOC sono utilizzate da diverse tecniche di stima dei costi, monitorate in PSP e TSP e possono essere utilizzate in altre metriche come la densità dei difetti. Ciò, secondo me, dice che contare SLOC potrebbe essere meglio che contare operatori / operandi. In secondo luogo, e finora senza risposta, è la validità delle metriche di sforzo, tempo e bug, indipendentemente dalle misure utilizzate per calcolarle. Concordo sul fatto che elaborarli con SLOC potrebbe essere migliore, ma anche se lo facessi, significherebbero qualcosa?

— Thomas Owens

@ThomasOwens: Probabilmente no. Se Effort, Time e Bugs sono tutti fortemente correlati a SLOC, allora ti dice che tutti i programmi di una determinata dimensione richiedono circa lo stesso tempo e sforzo e hanno lo stesso numero di bug. I primi due sono quelli su cui si basa la stima basata su SLOC (ad es. COCOMO) e sono come dire che l'acqua è bagnata. Il terzo non ti aiuta davvero.

— John R. Strohm,

Che il volume di Halstead sia correlato a SLOC è interessante ma limitato. Statistiche di base: la correlazione lineare non è transitiva. X correlato a Y, Y correlato a Z NON SIGNIFICA che X è correlato a Z.

— user1704475
fonte

Quando X e Y sono semplicemente correlati e Y e Z sono semplicemente correlati, sì, X e Z non sono necessariamente correlati, a causa dei livelli di rumore relativamente elevati nelle prime due correlazioni. Quando X e Y sono fortemente correlati e Y e Z sono fortemente correlati, c'è molto, molto poco rumore coinvolto, e diventa altamente probabile in ogni dato caso che X e Z saranno trovati come correlati.

— John R. Strohm,