Data Driven Quality Inspection

Motivación

El autor plantea un método para resolver los problemas que según él se plantean en los métodos
formales de inspección de software. Los dos problemas mencionados son:

 el volumen de artefactos generados por proyectos de software (equivalente a mucho

tiempo de inspección).
 dependencia de los resultados respecto a la capacitación y habilidad de los inspectores.

El método planteado no solo incluye las clásicas tareas manuales de inspección, sino que
también propone investigar aspectos más de base en el desarrollo de sistemas. Un ejemplo de
esto es la detección de patrones de errores humanos y la detección y prevención de “cadena de
errores”.

Planteo

La idea principal es generar “hipótesis” acerca de la calidad de los artefactos del proyecto en
base a datos procedentes de métricas. Estas hipótesis permitirán guiar de forma más eficiente y
efectiva sucesivas inspecciones dado que los inspectores se concentrarán en comprobar su
validez.

Una hipótesis incluye información acerca del tipo de defecto que es probable que exista en
determinado artefacto (defect type) así como también que partes del artefacto pueden contener
estos defectos (defect location).

Hay que recordar que el objetivo de DDQI no es solamente encontrar y remover defectos, sino
también prevenir futuras ocurrencias de los mismos. Por este motivo, cada defecto encontrado
en un artefacto debe llevar a analizar la causa raíz del mismo. Una vez encontrada la causa, se
podrán elaborar nuevas hipótesis que podrán ser aplicadas a nuevos artefactos afectados por la
misma causa raíz.

El proceso de DDQI agrega dos etapas previas al proceso de inspección formal. En estas dos
etapas se toman métricas del artefacto a inspeccionar (además de métricas históricas) y se
generan las hipótesis para luego dar paso al proceso normal de inspección.

Se debe hacer énfasis en el hecho de que DDQI basa su funcionamiento en la elaboración de

hipótesis en base a datos empíricos sobre defectos inyectados en distintos artefactos.

Se sugiere realizar la recolección de estos datos de forma automática (líneas de código,

complejidad del mismo, ratio de comentarios, etc.). Para aquellos artefactos donde no es posible
(especificación de requerimientos, etc.) se plantea concentrarse en patrones de errores humanos
y de comportamiento.
Ejemplos

Caso 1: DDQI sobre documento de especificación de requerimientos (ESRE) y diseño.

Tomando las fechas y horas de modificación de ambos artefactos se grafica y se elaboran las
siguientes hipótesis:

- dada la falta de comunicación entre trabajadores diarios y nocturnos, revisar

documentos modificados en la misma fecha en dichas franjas horarias.
- Se detecta un “gap” de dos meses en el cual no hay modificaciones en los archivos
(falta de trazabilidad). Investigar porqué.

Caso 2: DDQI sobre código. (Average Identifier Length)

Midiendo la longitud de las variables en cada artefacto de código se puede inferir la experiencia
y la formación de los desarrolladores.

1)Infer the programmer’s background from AIL

-- IF (AIL less than 8) THEN COBOL developers

-- IF (AIL greater than 9) AND (AIL less than 12) THEN C/C++
-- IF (AIL greater than 18) THEN Java (only) developers

2)From programmer’s background, build hypothesis about injected defects. ( in Java example )

-- IF COBOL programmer, check the “Error handling routine” and “inappropriate try-catch
block”.
-- IF C/C++, check bugs of “Null Pointer Dereference”.
-- IF Java, check “Resource Leaking” and too many “new”

Conclusiones

Según el autor, el método resulta efectivo según la calidad de las hipótesis inferidas de los datos
empíricos. DDQI fue aplicado a más de 1300 proyectos a lo largo de 9 años demostrando su
efectividad ya que permitió aumentar en 4 veces la cantidad de proyectos inspeccionados
reduciendo considerablemente el tiempo promedio de inspección.

También se comprobó que inspectores menos experientes produjeron resultados confiables a

diferencia de los producidos mediante métodos clásicos.

Si bien el autor reconoce la importancia de otros estudios (Fagan, Cleanroom) su enfoque

permite obtener resultados de gran calidad en tiempos más cortos.

No sugiere a DDQI como un reemplazo de los métodos clásicos sino más bien como un
complemento de estos.

Por otro lado plantea el futuro de DDQI en dos direcciones: a corto plazo, reducir el esfuerzo de
inspecciones y producir acciones de prevención de defectos más detallados; a largo plazo,
generar una base de conocimiento que permita una generalización de la evidencia empírica.
Referencias

[1] N. Hosokawa, “Data-Driven Quality Inspection,” Review Literature And Arts Of

The Americas, Bethesda, Maryland: 2008.