Experimentos que correlacionan las métricas del código con la densidad de errores

15

Me pregunto si alguien ha hecho algunos experimentos que correlacionan las métricas de código (SLOC, Complejidad Ciclomática, etc.) con la 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 porque creo que la densidad de errores de un proyecto podría se correlaciona 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. 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 relacione con la cantidad de errores nuevos.
  3. Haga un análisis de la 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 a partir de 2.

Si no tienes experiencia en esto, pero recuerda haber visto un artículo / blog sobre este tema, te agradecería que lo compartieras.

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

pregunta Augusto 17.05.2012 - 11:55
fuente

3 respuestas

10

Cuando 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 de McCabe Complejidad ciclomática . 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 podrían servir como buenos indicadores de posibles defectos, o quizás una mayor probabilidad de que se inyecten defectos si se hacen modificaciones a 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 un gran número de rutas independientes a través del código. Un módulo (de nuevo, especialmente a nivel de clase o método) con un gran número de líneas también es difícil de entender ya que el aumento en las líneas significa que están sucediendo más cosas. Existen muchas herramientas de análisis estático que admiten la computación tanto de las líneas de código fuente contra reglas específicas como de la complejidad ciclomática, parece que capturarlas sería atrapar la fruta de bajo rendimiento.

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

También hay un grupo de métricas conocidas como métricas CK. La primera definición de este conjunto de indicadores parece estar en un documento titulado Un conjunto de indicadores para el diseño orientado a objetos por Chidamber y Kemerer. Definen los métodos ponderados por clase, la profundidad del árbol de herencia, el número de hijos, el acoplamiento entre clases de objetos, la respuesta para una clase y la 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 la literatura académica que analiza estas métricas, podría interesarle el Análisis empírico de las métricas de CK para la complejidad del diseño orientado a objetos: implicaciones para defectos de software, escrito por Ramanath Subramanyam y M.S. Krishna. Analizaron tres de las seis métricas CK (métodos ponderados por clase, acoplamiento entre el objeto clasificado y el árbol de la profundidad de la herencia). Al mirar el documento, parece que encontraron que estas métricas son potencialmente válidas, pero deben interpretarse con cautela como "mejora", lo que podría llevar a otros cambios que también conduzcan a una mayor probabilidad de defectos.

El análisis empírico de métricas de diseño orientadas a objetos para predecir fallas de severidad alta y baja, escritas por Yuming Zhou y Hareton Leung, también examinan las métricas de CK. Su enfoque fue determinar si pueden predecir defectos basándose en estas métricas. Encontraron 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 algún nivel de significación estadística en la predicción de áreas donde podrían ubicarse los defectos.

Si tiene una membresía IEEE, recomendaría buscar en Transacciones IEEE en Ingeniería de Software para obtener más información académica. Publicaciones y IEEE Software para más informes del mundo real y aplicados. La ACM también puede tener publicaciones relevantes en su biblioteca digital .

    
respondido por el Thomas Owens 17.05.2012 - 15:33
fuente
6

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 problema real?

     

La respuesta es no. Manteniendo el tamaño constante, estudios no muestran   correlación entre CC y densidad de defectos. Sin embargo, hay otros   Dos interesantes correlaciones para estudiar:

     

El primero es: ¿CC se correlaciona fuertemente con la duración de   ¿Detectando y arreglando defectos? En otras palabras, si CC es menor, ¿podríamos   ¿Pasa menos tiempo depurando y arreglando defectos?

     

El segundo es: ¿CC se correlaciona fuertemente con la retroalimentación de fallas?   Ratio (FFR, el número promedio de defectos que resultan de la aplicación   un cambio o arreglando un defecto)?

     

Se necesita más investigación para ver si alguien ha estudiado esto alguna vez.   correlación empírica. Pero, mi instinto y la retroalimentación que recibo   de los equipos con los que trabajo es que hay un fuerte positivo   correlación entre la complejidad ciclomática en un lado y la duración   de detectar y reparar un defecto o el cambio de impacto en otro lado.

     

Este es un buen experimento para hacer. ¡Mantente alerta por los resultados!

    
respondido por el Amr Noaman 30.07.2012 - 08:07
fuente
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 una baja fiabilidad y errores frecuentes". Luego menciona algunas referencias que apoyan 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 ellos preceden 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 Software Ingeniería, SE-2, no. 4 (diciembre): 308-20
  • Shen, Vincent Y., et al. 1985. "Identificación de software propenso a errores: un estudio empírico". IEEE Transactions on Software Engineering 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 están demasiado complicadas y que tienen una alta probabilidad de contener errores. Aunque no he calculado, la distribución de errores dentro de las funciones de alta complejidad ciclomática frente a las funciones de baja complejidad ciclomática, la investigación de esas funciones me ha permitido descubrir errores de programación pasados por alto.

    
respondido por el QuantumOmega 22.08.2012 - 22:38
fuente

Lea otras preguntas en las etiquetas