Experimenta la correlación de las métricas de código con la densidad de errores

16

Me pregunto si alguien ha realizado algunos experimentos correlacionando métricas de código (SLOC, Complejidad Ciclomática, etc.) con densidad de errores en aplicaciones orientadas a objetos.

No estoy buscando experimentos que solo prueben o refuten una correlación, sino en ambos. No estoy tratando de encontrar una bala de plata, ya que creo que la densidad de errores de un proyecto podría correlacionarse con una o más métricas para un proyecto o equipo determinado y la correlación puede cambiar durante la vida útil del proyecto / equipo.

Mi objetivo es

  1. Mida todas las métricas interesantes durante 2-3 meses (ya tenemos bastantes de sonar).
  2. Encuentre una métrica que se correlacione con la cantidad de nuevos errores.
  3. Haga un análisis de causa raíz para verificar por qué sucede esto (por ejemplo, ¿nos falta una cierta habilidad de diseño?).
  4. Mejore la habilidad y mida el cambio para un par de iteraciones.
  5. Enjuague y repita desde 2.

Si no tiene experiencia en esto, pero recuerde haber visto un artículo / blog sobre este tema, le agradecería si pudiera compartirlo.


Hasta ahora he encontrado los siguientes enlaces con información sobre este tema.

Augusto
fuente
1
Si desea evitar el cierre, debe reformular su pregunta. Los sitios de Stack Exchange no son motores de búsqueda y los usuarios no son asistentes de investigación personal . En lugar de pedir enlaces a documentos, el énfasis debería estar en preguntar qué tipos de métricas se han correlacionado con defectos y densidad de defectos.
Thomas Owens
1
Lamento que la pregunta surgiera como una solicitud para convertirme en mi asistente de búsqueda personal , definitivamente no es lo que quería hacer, pero encontrar este tipo de documentos no es algo muy común. He cambiado el título para que otras personas no tengan la misma impresión.
Augusto

Respuestas:

11

Cada vez que escucho sobre intentos de asociar algún tipo de métrica basada en código con defectos de software, lo primero que pienso es en la complejidad ciclomática de McCabe . Varios estudios han encontrado que existe una correlación entre una alta complejidad ciclomática y el número de defectos. Sin embargo, otros estudios que analizaron módulos con un tamaño similar (en términos de líneas de código) encontraron que podría no haber una correlación.

Para mí, tanto el número de líneas en un módulo como la complejidad ciclomática pueden servir como buenos indicadores de posibles defectos, o tal vez una mayor probabilidad de que se inyecten defectos si se realizan modificaciones en un módulo. Un módulo (especialmente a nivel de clase o método) con alta complejidad ciclomática es más difícil de entender ya que hay una gran cantidad de rutas independientes a través del código. Un módulo (de nuevo, especialmente a nivel de clase o método) con una gran cantidad de líneas también es difícil de entender ya que el aumento de líneas significa que están sucediendo más cosas. Hay muchas herramientas de análisis estático que admiten el cálculo tanto de las líneas de código fuente con reglas específicas como de la complejidad ciclomática, parece que capturarlas estaría tomando la fruta que cuelga.

Las medidas de complejidad de Halstead también pueden ser interesantes. Desafortunadamente, su validez parece ser algo debatida, por lo que no necesariamente confiaría en ellos. Una de las medidas de Halstead es una estimación de defectos basada en el esfuerzo o el volumen (una relación entre la longitud del programa en términos de operadores totales y operandos y el vocabulario del programa en términos de operadores y operadores distintos).

También hay un grupo de métricas conocidas como CK Metrics. La primera definición de este conjunto de métricas parece estar en un artículo titulado Un conjunto de métricas para el diseño orientado a objetos por Chidamber y Kemerer. Definen métodos ponderados por clase, profundidad del árbol de herencia, número de hijos, acoplamiento entre clases de objetos, respuesta para una clase y falta de cohesión en los métodos. Su documento proporciona los métodos computacionales, así como una descripción de cómo analizar cada uno.

En términos de literatura académica que analice estas métricas, es posible que le interese el análisis empírico de métricas CK para la complejidad del diseño orientado a objetos: implicaciones para defectos de software, escrito por Ramanath Subramanyam y MS Krishna. Analizaron tres de las seis métricas CK (métodos ponderados por clase, acoplamiento entre objetos clasificados y árbol de profundidad de herencia). Echando un vistazo al artículo, parece que descubrieron que estas son métricas potencialmente válidas, pero deben interpretarse con precaución como "mejorar" uno podría conducir a otros cambios que también conducen a una mayor probabilidad de defectos.

El análisis empírico de las métricas de diseño orientado a objetos para predecir fallas de gravedad alta y baja, escrito por Yuming Zhou y Hareton Leung, también examina las métricas de CK. Su enfoque fue determinar si pueden predecir defectos basados ​​en estas métricas. Descubrieron que muchas de las métricas de CK, a excepción de la profundidad del árbol de herencia y el número de hijos) tenían cierto nivel de significación estadística en la predicción de áreas donde se podrían localizar defectos.

Si tiene una membresía de IEEE, recomendaría buscar en las Transacciones de IEEE sobre Ingeniería de Software más publicaciones académicas y IEEE Software para obtener algunos informes más reales y aplicados. El ACM también podría tener publicaciones relevantes en su biblioteca digital .

Thomas Owens
fuente
Se ha demostrado que todas las métricas de Halstead están fuertemente correlacionadas con SLOC sin procesar (número de líneas de código fuente). En ese momento, cualquier cosa que esté correlacionada con cualquier métrica de Halstead se sabe que está correlacionada con SLOC sin procesar, y es más fácil medir SLOC que cualquiera de las métricas de Halstead.
John R. Strohm
@ JohnR.Strohm No estoy de acuerdo en que sea más fácil contar SLOC que calcular las métricas de Halstead, cuando está utilizando herramientas para hacer el cálculo. Suponiendo que las métricas de Halstead son válidas (lo que en realidad se debate, pero nada importa para una métrica no válida), conocer la cantidad de tiempo requerida para desarrollar el código o la cantidad proyectada de defectos en el sistema es un valor más útil que conocer la cantidad de lineas. Puedo crear cronogramas con datos de tiempo, planes de calidad con datos de defectos o asignar tiempo suficiente para una revisión de código con dificultad. Es más difícil usar SLOC sin procesar para esas cosas.
Thomas Owens
@ JohnR.Strohm Estoy seguro de que un programa de cómputo métrico de Halstead tarda un poco más en ejecutarse que un programa de conteo SLOC. Pero suponiendo que la salida válida se convierta en una entrada válida en la toma de decisiones, prefiero tener datos significativos de tiempo, esfuerzo y defectos que un recuento de SLOC sin procesar. El valor agregado de la métrica más compleja a menudo vale el tiempo de cálculo adicional, asumiendo nuevamente entradas y salidas válidas de cómputo.
Thomas Owens
@ThomasOwens, la cuestión de si el esfuerzo de software y, por lo tanto, el costo y el cronograma, pueden estimarse directamente a partir de estimaciones de SLOC sin procesar que se han realizado hasta la muerte. Después de una considerable investigación sobre datos reales del proyecto, la pregunta se resolvió afirmativamente. Ver "Software Engineering Economics", por Barry Boehm, 1981.
John R. Strohm
@ThomasOwens: Además, uno debe reconocer que las métricas de Halstead son inherentemente retrospectivas. No puede medir las métricas de software de Halstead que aún no ha escrito. Por otro lado, ES posible estimar SLOC sin procesar para una tarea determinada y, dadas las especificaciones suficientemente detalladas y un poco de experiencia, es relativamente fácil acercarse bastante a la estimación. Además, es MUY fácil comparar las estimaciones con las reales, ajustar las heurísticas de estimación y calibrar el estimador de costos. General Dynamics / Fort Worth trabajó mucho en esto a principios de la década de 1980.
John R. Strohm
7

He discutido posibles correlaciones en una de mis publicaciones de blog :

Correllación entre la complejidad ciclomática y la densidad de errores: ¿es este el verdadero problema?

La respuesta es no. Manteniendo el tamaño constante, los estudios no muestran correlación entre CC y la densidad del defecto. Sin embargo, hay otras dos correlaciones interesantes para estudiar:

La primera es: ¿CC se correlaciona fuertemente con la duración de la detección y reparación de defectos? En otras palabras, si CC es menor, ¿pasaríamos menos tiempo depurando y reparando defectos?

El segundo es: ¿CC se correlaciona fuertemente con la relación de retroalimentación de fallas (FFR, el número promedio de defectos que resulta de aplicar un cambio o corregir un defecto)?

Se necesita más investigación para ver si alguien ha estudiado esta correlación empíricamente. Pero, mi intuición y la retroalimentación que recibo de los equipos con los que trabajo es que existe una fuerte correlación positiva entre la complejidad ciclomática en un lado y la duración de la detección y reparación de un defecto o el impacto del cambio en el otro lado.

Este es un buen experimento para hacer. ¡Manténgase alerta para los resultados!

Amr Noaman
fuente
No merece un voto negativo, pero eso debería ser "algunos estudios no muestran correlación", porque otros estudios sí muestran una correlación.
David Hammen
3

En el libro Code Complete, p.457, Steve McConnell dice que "la complejidad del flujo de control es importante porque se ha correlacionado con baja confiabilidad y errores frecuentes". Luego menciona algunas referencias que respaldan esa correlación, incluido el propio McCabe (a quien se le atribuye haber desarrollado la métrica de complejidad ciclomática). La mayoría de estos son anteriores al uso generalizado de lenguajes orientados a objetos, pero como esta métrica se aplica a los métodos dentro de esos lenguajes, las referencias pueden ser lo que está buscando.

Esas referencias son:

  • McCabe, Tom. 1976. "Una medida de complejidad". Transacciones IEEE en Ingeniería de Software, SE-2, no. 4 (diciembre): 308-20
  • Shen, Vincent Y. y col. 1985. "Identificación de software propenso a errores: un estudio empírico". Transacciones IEEE sobre Ingeniería de Software SE-11, no.4 (abril): 317-24.
  • Ward, William T. 1989. "Prevención de defectos de software utilizando la métrica de complejidad de McCabe". Hewlett-Packard Journal, abril, 64-68.

Desde mi propia experiencia, la métrica de McCabe, como puede ser calculada por un programa en muchas secciones de código, es útil para encontrar métodos y funciones que son demasiado complicadas y que tienen una alta probabilidad de contener errores. Aunque no he calculado, la distribución de errores dentro de funciones de alta complejidad ciclomática versus funciones de baja complejidad ciclomática, investigar esas funciones me ha permitido descubrir errores de programación pasados ​​por alto.

QuantumOmega
fuente