¿Existe algún trabajo en la aplicación de las medidas de complejidad de Halstead para determinar la calidad del software?

En 1977, Maurice Howard Halstead introdujo sus medidas de complejidad para los sistemas de software , que incluían mediciones del vocabulario del programa, la longitud del programa, el volumen, la dificultad, el esfuerzo y un número estimado de errores en un módulo. Según Wikipedia, la dificultad se relaciona con la dificultad de comprender el programa al leerlo o escribirlo, y el esfuerzo puede traducirse en el tiempo que lleva codificar una aplicación donde Tiempo = (Esfuerzo / 18) segundos.

Una medición es inútil a menos que los datos y los cálculos se relacionen con algún aspecto del desarrollo de software. Sin embargo, no he encontrado ningún trabajo que indique que una dificultad de cierto valor o mayor tiende a un aumento estadísticamente significativo de defectos o una relación entre la dificultad y el tiempo para leer el código (una dificultad de N produce un promedio de M horas dedicadas comprender la base del código) o cualquier análisis de poder calcular el tiempo después de que el hecho sea útil para determinar la calidad (especialmente porque el tiempo de escritura ya debería haberse registrado como una medida). Estoy especialmente interesado en la estimación de errores de Halstead (que no se menciona en Wikipedia): el número de errores en una aplicación se puede estimar por Volumen / 3000 o Esfuerzo ^ (2/3) / 3000.

Estoy buscando dos cosas:

¿Alguien ha utilizado las medidas de complejidad de software de Halstead en una aplicación del mundo real para evaluar la calidad del software? Si es así, ¿cómo los aplicó y resultaron ser una medida útil, válida y / o confiable?
¿Existe alguna investigación académica en forma de encuestas, análisis o estudios de casos que discutan la validez (o invalidez) de las medidas de complejidad de Halstead cuando se aplican a la calidad del software?
¿Existe alguna investigación académica en forma de encuestas, análisis o estudios de casos que demuestren el uso de las líneas de código fuente (SLOC) para calcular algo similar a las métricas de volumen, dificultad, esfuerzo, tiempo y errores de Halstead? Sospecho que el volumen podría corresponder a un recuento de SLOC y la dificultad podría corresponder a la complejidad ciclomática (y posiblemente a otras medidas). También soy consciente de que medir el esfuerzo, la productividad o el tiempo en SLOC es potencialmente engañoso.

quality metrics measurement

— Thomas Owens
fuente

Tendrá algunos problemas para encontrar resultados en los últimos 15 años, ya que el trabajo de métricas de Halstead se realizó más o menos hace 30-40 años, y la fuerte correlación con SLOC se descubrió casi de inmediato. (Esto es de memoria, de una charla de un nuevo candidato a doctorado en la UT Austin, ca. 1977.)

— John R. Strohm,

Gracias por eso. Actualizaré la pregunta y reenfocaré mi esfuerzo de búsqueda en documentos más antiguos.

— Thomas Owens

Respuestas:

Microsoft Research ha realizado algunos trabajos en esta área. Echa un vistazo a esta página: http://research.microsoft.com/en-us/people/nachin/ . Aunque no se basa específicamente en Halstead, Nachi y su equipo han realizado una investigación utilizando Halstead, complejidad ciclomática, cambio de código y otras medidas para evaluar el riesgo relativo y la fragilidad para realizar cambios en áreas de código. También hay un documento interesante sobre cómo la efectividad organizacional también juega un papel importante, pero eso está fuera de tema. :)

— nithins
fuente

Tendré que leer algunos de esos. Definitivamente algo en lo que estoy interesado, pero estoy (al menos en este momento), particularmente interesado en Halstead, así que me concentraré allí. Marqué el sitio como favorito para poder leerlo cuando tenga más tiempo, pero por el momento hay un +1.

— Thomas Owens

Se ha demostrado que la complejidad ciclomática de McCabe, en código real, se correlaciona muy fuertemente con SLOC sin procesar, hasta el punto de que no hay ningún valor incremental en su cálculo.

— John R. Strohm

Hay bastantes estudios de este tipo. Google es tu amigo.

Las métricas de Halstead cayeron en desgracia cuando se demostró que todas ellas estaban fuertemente correlacionadas con SLOC (líneas de código fuente) sin procesar. En ese punto, se hace más fácil medir el SLOC y terminar con él.

Aquí hay un resultado de Google Books .

— John R. Strohm
fuente

He estado buscando en Google desde antes de hacer esta pregunta y aún no he encontrado ningún artículo publicado u otras fuentes de buena reputación. Además, no veo cómo una métrica relacionada con SLOC puede ser deficiente. SLOC / tiempo es una medida pobre de productividad, pero otras métricas basadas en SLOC generalmente se consideran válidas, por ejemplo, defectos / SLOC.

— Thomas Owens

@Thomas: No es que las métricas de Halstead estén "relacionadas" con SLOC, es que están fuertemente correlacionadas. Estadísticas 102. Decir que Y y X están fuertemente correlacionados significa que la relación Y / X es esencialmente constante para todos los conjuntos de datos. Cuando ese es el caso, no tiene sentido medir Y si es más fácil medir X, porque Y realmente no te dice nada que no sabes de X.

— John R. Strohm

Eso tiene sentido. Las métricas de Halstead se basan en el número de operadores y operandos distintos y totales. Es de sentido común que un programa más largo tendrá más operadores / operandos totales y será más probable que tenga operadores / operandos más distintos. Las métricas de Volumen y Dificultad se pueden obtener utilizando SLOC en lugar de operadores / operandos. Sin embargo, eso no aborda la validez, las aplicaciones y el significado (o la falta de significado) de las métricas de esfuerzo, tiempo y errores. Incluso cuando se calcula con SLOC en lugar de operadores / operandos, ¿estas métricas dicen algo significativo sobre el sistema?

— Thomas Owens

SLOC es más fácil de contar y probablemente más útil. Las estimaciones de SLOC se utilizan mediante varias técnicas de estimación de costos, rastreados en el PSP y TSP, y se pueden utilizar en otras métricas, como la densidad de defectos. Para mí, eso dice que contar SLOC podría ser mejor que contar operadores / operandos. En segundo lugar, y sin respuesta hasta ahora, está la validez de las métricas de esfuerzo, tiempo y errores, independientemente de las medidas que se utilicen para calcularlos. Estoy de acuerdo en que calcularlos con SLOC podría ser mejor, pero incluso si lo hiciera, ¿significarían algo?

— Thomas Owens

@ThomasOwens: Probablemente no. Si el esfuerzo, el tiempo y los errores están estrechamente relacionados con SLOC, le indica que todos los programas de un tamaño determinado requieren aproximadamente el mismo tiempo y esfuerzo y tienen el mismo número de errores. Los dos primeros son en los que se basa la estimación basada en SLOC (por ejemplo, COCOMO) y son como decir que el agua está húmeda. El tercero realmente no te ayuda.

— John R. Strohm

Que Halstead Volume esté correlacionado con SLOC es interesante pero limitado. Estadísticas básicas: la correlación lineal no es transitiva. X correlacionado con Y, Y correlacionado con Z NO SIGNIFICA que X está correlacionado con Z.

— usuario1704475
fuente

Cuando X e Y están simplemente correlacionados, e Y y Z están simplemente correlacionados, sí, X y Z no están necesariamente correlacionados, debido a los niveles de ruido relativamente altos en las dos primeras correlaciones. Cuando X e Y están fuertemente correlacionados, e Y y Z están fuertemente correlacionados, hay muy, muy poco ruido involucrado, y se vuelve altamente probable en cualquier caso dado que se encontrará que X y Z están correlacionados.

— John R. Strohm