Indicador de defecto de software

Un indicador de defecto de software es un patrón que se puede encontrar en el código fuente y que está fuertemente correlacionado con un defecto de software , un error u omisión en el código fuente de un programa informático que puede provocar un mal funcionamiento del mismo. Al inspeccionar el código fuente de los programas informáticos , no siempre es posible identificar defectos directamente, pero a menudo hay patrones, a veces llamados antipatrones , que indican la presencia de defectos.

Algunos ejemplos de indicadores de defectos de software:

Código deshabilitado: Se ha escrito código y el programador lo ha deshabilitado o apagado sin dejar claro por qué lo ha deshabilitado, cuándo o si se volverá a habilitar.
Rutina demasiado compleja: un programa (método, módulo, rutina, subrutina, procedimiento o cualquier bloque de código nombrado) contiene más de 10 términos binarios en declaraciones condicionales. ^[1]
Variables no utilizadas: Las variables no referenciadas son un fuerte indicador de otros errores. ^[2]
Número de colaboradores distintos: la cantidad de desarrolladores únicos que han hecho contribuciones al historial de contribuciones de un proyecto. Esta es una métrica de proceso que resulta útil para indicar defectos de software. ^[3]

Véase también

Referencias

^ William T. Ward: "Prevención de defectos de software utilizando la métrica de complejidad de McCabe", Hewlett-Packard Journal , abril de 1989, págs. 64-69: La complejidad del flujo de control se ha correlacionado con baja confiabilidad y errores frecuentes.
^ David N. Card, Victor E. Church y William W. Agresti: "Un estudio empírico de las prácticas de diseño de software", IEEE Transactions on Software Engineering , SE-12, n.º 2, febrero de 1986, págs. 264-71: el 46 por ciento de las rutinas sin variables no utilizadas no tenían errores, en comparación con solo el 17 al 29 por ciento de las que tenían una o más variables no referenciadas.
^ Madeyski, Lech y Marian Jureczko. “¿Qué métricas de proceso pueden mejorar significativamente los modelos de predicción de defectos? Un estudio empírico”. Software Quality Journal 23.3 (2015): 393–422. Web.

Enlaces externos

Publicación especial 500-235 del NIST Pruebas estructuradas: una metodología de pruebas que utiliza la métrica de complejidad ciclomática

[1] William T. Ward: "Prevención de defectos de software utilizando la métrica de complejidad de McCabe", Hewlett-Packard Journal , abril de 1989, págs. 64-69: La complejidad del flujo de control se ha correlacionado con baja confiabilidad y errores frecuentes.

[2] David N. Card, Victor E. Church y William W. Agresti: "Un estudio empírico de las prácticas de diseño de software", IEEE Transactions on Software Engineering , SE-12, n.º 2, febrero de 1986, págs. 264-71: el 46 por ciento de las rutinas sin variables no utilizadas no tenían errores, en comparación con solo el 17 al 29 por ciento de las que tenían una o más variables no referenciadas.

[3] Madeyski, Lech y Marian Jureczko. “¿Qué métricas de proceso pueden mejorar significativamente los modelos de predicción de defectos? Un estudio empírico”. Software Quality Journal 23.3 (2015): 393–422. Web.