Existe algum trabalho na aplicação das medidas de complexidade de Halstead para determinar a qualidade do software?

Em 1977, Maurice Howard Halstead introduziu suas medidas de complexidade para sistemas de software , que incluíam medidas do vocabulário do programa, duração do programa, volume, dificuldade, esforço e um número estimado de erros em um módulo. De acordo com a Wikipedia, a dificuldade está relacionada à dificuldade de entender o programa ao lê-lo ou escrevê-lo, e o esforço pode ser traduzido no tempo que leva para codificar um aplicativo em que Tempo = (esforço / 18) segundos.

Uma medida é inútil, a menos que os dados e cálculos estejam relacionados a algum aspecto do desenvolvimento de software. No entanto, não encontrei nenhum trabalho que indique que uma dificuldade de um determinado valor ou superior tenda a um aumento estatisticamente significativo de defeitos ou a uma relação entre dificuldade e tempo para ler o código (uma dificuldade de N produz uma média de M horas gastas entender a base do código) ou qualquer análise de poder calcular o tempo após o fato de ser útil na determinação da qualidade (principalmente porque o tempo para escrever já deveria ter sido registrado como uma medida). Estou especialmente interessado na estimativa de erros de Halstead (que não é mencionada na Wikipedia) - o número de erros em um aplicativo pode ser estimado em Volume / 3000 ou Effort ^ (2/3) / 3000.

Estou procurando duas coisas:

Alguém usou as medidas de complexidade de software da Halstead em um aplicativo do mundo real para avaliar a qualidade do software? Em caso afirmativo, como você os aplicou e eles se mostraram uma medida útil, válida e / ou confiável?
Existe alguma pesquisa acadêmica na forma de pesquisas, análises ou estudos de caso que discutam a validade (ou invalidez) das medidas de complexidade de Halstead quando aplicadas à qualidade do software?
Existe alguma pesquisa acadêmica na forma de pesquisas, análises ou estudos de caso que demonstrem o uso do SLOC (Source Lines of Code) para calcular algo semelhante às métricas de Halstead de Volume, Dificuldade, Esforço, Tempo e Erros? Eu suspeitaria que o Volume corresponda apenas a uma contagem SLOC e a Dificuldade corresponda à complexidade ciclomática (e possivelmente a outras medidas). Também sei que medir o esforço, a produtividade ou o tempo no SLOC é potencialmente enganador.

quality metrics measurement

— Thomas Owens
fonte

Você terá problemas para encontrar resultados nos últimos 15 anos, já que o trabalho de métricas de Halstead foi feito há mais ou menos 30 a 40 anos, e a forte correlação com o SLOC foi descoberta quase imediatamente. (Esta é a partir da memória, a partir de uma palestra de um novo candidato Ph.D. faculdade em UT Austin ca. 1977.)

— John R. Strohm

Obrigado por isso. Vou atualizar a pergunta e reorientar meu esforço de pesquisa para documentos mais antigos.

— Thomas Owens

Respostas:

A Microsoft Research fez algum trabalho nesta área. Confira esta página: http://research.microsoft.com/en-us/people/nachin/ . Embora não seja especificamente baseado em Halstead, Nachi e sua equipe fizeram algumas investigações usando Halstead, complexidade ciclomática, rotatividade de código e outras medidas para avaliar o risco e a fragilidade relativos para fazer alterações nas áreas de código. Há também um artigo interessante sobre como a eficácia organizacional também desempenha um grande papel, mas isso não é relevante. :)

— nithins
fonte

Vou ter que ler alguns desses. Definitivamente, algo em que estou interessado, mas estou (pelo menos agora), particularmente interessado em Halstead, então vou me concentrar lá. Marquei o site como favorito para que eu possa lê-lo quando tiver mais tempo, mas aqui está o +1 por enquanto.

— Thomas Owens

A complexidade ciclomática de McCabe demonstrou, no código real, estar fortemente correlacionada com o SLOC bruto, a tal ponto que não há valor incremental em sua computação.

— John R. Strohm

Existem alguns estudos desse tipo. Google é seu amigo.

As métricas de Halstead ficaram em desuso quando foi demonstrado que todas elas estavam fortemente correlacionadas com o SLOC bruto (linhas de código-fonte). Nesse ponto, fica mais fácil medir o SLOC e fazer com ele.

Aqui está um resultado do Google Livros .

— John R. Strohm
fonte

Pesquisei no Google desde antes e fiz essa pergunta e ainda não encontrei artigos publicados ou outras fontes respeitáveis. Além disso, não vejo como uma métrica relacionada ao SLOC pode ser ruim. SLOC / tempo é uma baixa medida de produtividade, mas outras métricas baseadas em SLOC são geralmente consideradas válidas, um exemplo são defeitos / SLOC.

— Thomas Owens

@ Thomas: Não é que as métricas de Halstead estejam "relacionadas" ao SLOC, é que elas estão fortemente correlacionadas. Estatísticas 102. Dizer que Y e X estão fortemente correlacionados significa que a razão Y / X é essencialmente constante para todos os conjuntos de dados. Quando for esse o caso, não há nenhum ponto na medição Y se é mais fácil de medir X, porque Y não está realmente dizendo nada que você ainda não sabe de X.

— John R. Strohm

Isso faz sentido. As métricas da Halstead são baseadas no número de operadores e operandos distintos e totais. É senso comum que um programa mais longo terá mais operadores / operandos totais e provavelmente terá operadores / operandos mais distintos. As métricas de volume e dificuldade podem ser obtidas usando SLOC em vez de operadores / operandos. No entanto, isso não trata da validade, aplicativos e significado (ou falta de significado) das métricas Esforço, Tempo e Erros. Mesmo quando computadas com SLOC em vez de operadores / operandos, essas métricas dizem algo significativo sobre o sistema?

— Thomas Owens

O SLOC é mais fácil de contar e provavelmente mais útil. As estimativas de SLOC são usadas por várias técnicas de estimativa de custos, rastreadas no PSP e TSP, e podem ser usadas em outras métricas, como densidade de defeitos. Isso, para mim, diz que contar SLOC pode ser melhor do que contar operadores / operandos. Segundo, e sem resposta até agora, é a validade das métricas de Esforço, Tempo e Erros, independentemente de quais medidas sejam usadas para calculá-las. Concordo que computá-los com SLOC pode ser melhor, mas mesmo se eu fizesse, eles significariam alguma coisa?

— Thomas Owens

@ Thomashowens: Provavelmente não. Se Esforço, Tempo e Bugs estiverem fortemente correlacionados ao SLOC, será informado que todos os programas de um determinado tamanho levam aproximadamente o mesmo tempo e esforço e têm o mesmo número de bugs. Os dois primeiros são sobre os quais se baseia a estimativa baseada no SLOC (por exemplo, COCOMO) e são como dizer que a água está molhada. O terceiro realmente não ajuda.

— John R. Strohm

Que o Halstead Volume esteja correlacionado com o SLOC é interessante, mas limitado. Estatísticas básicas: a correlação linear não é transitiva. X correlacionado com Y, Y correlacionado com Z NÃO SIGNIFICA que X está correlacionado com Z.

— user1704475
fonte

Quando X e Y são meramente correlacionados, e Y e Z são meramente correlacionados, sim, X e Z não são necessariamente correlacionados, devido aos níveis de ruído relativamente altos nas duas primeiras correlações. Quando X e Y estão fortemente correlacionados, e Y e Z estão fortemente correlacionados, há muito, muito pouco ruído envolvido, e torna-se altamente provável, em qualquer caso, que X e Z sejam correlacionados.

— John R. Strohm