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 .