Métricas - Las 7 preguntas al analizar los datos

Los datos son los datos. Y tendemos a darles mucha importancia. Y la tienen. Sin embargo, a la hora de interpretarlos, no solemos tener la disciplina de estudiar su origen y circunstancias. Lo que es peor, no solemos tener criterio a la hora de agregarlos o no a los demás datos recopilados.

Aquí van 7 preguntas que me parecen fundamentales a la hora de analizar los datos recopilados en un proceso de MA (Medición y Análisis), o en general en cualquier proceso de Métricas:

1. ¿Quién recopiló esos datos? (Esperemos que fueran las mismas personas que se formaron en las técnicas adecuadas de recopilación de datos)
2. ¿Cómo se recopilaron los datos? (Esperemos que fuese mediante herramientas/procesos automatizados, y que no requiriesen esfuerzo adicional al trabajo diario)
3. ¿Cuándo se recopilaron los datos? (Esperemos que fuese al mismo tiempo o en el mismo día que las tareas relacionadas a dichos datos)
4. ¿Qué significan esos valores? (¿Ha habido cambios recientes en el proceso? ¿Realmente esos valores me dicen lo que quiero o necesito saber?)
5. ¿Cómo se obtuvieron esos valores calculados a partir de los datos originales?
6. ¿Qué fórmulas se usaron para calcular esos datos? (¿Están midiendo lo que necesitamos medir? ¿Funcionan? ¿Son relevantes? ¿Son obsoletos?)
7. ¿Estamos recopilando los datos de la forma correcta? ¿Son los datos correctos? Los datos deberían ser consistentes, y la forma en que se recopilan, a su vez, también debería ser consistente. Hay que asegurarse de que los datos tengan la información requerida para los análisis que necesitamos llevar a cabo.

Veamos un ejemplo:
Tenemos unos datos de defectos encontrados en pruebas unitarias. Nos haríamos cada unas de las preguntas y analizaríamos las respuestas:

1. La persona nos dará una pista de en qué circunstancias se obtuvieron los datos, si han sido automáticos, o si se han rellenado de forma asíncrona al proceso de pruebas.
2. Si el proceso no es automatizado, será más propenso a errores o a manipulación deliberada. En este caso nos va a interesar saber las ejecuciones que se han hecho de los tests, y cómo se han obtenido los defectos. ¿Se han lanzado todas las pruebas, o se ha parado al llegar a un error grave?
3. Si el proceso no es automático, habrá que ver cuándo se han rellenado esos datos. Normalmente, todo lo que no se rellene en el mismo día en que se produce, es mucho menos fiable.
4. Significado: hay que interpretar si ante las mismas pruebas, ayer hubo 5 fallos, y hoy 10. ¿Qué ha cambiado en el código? ¿Y en el proceso? ¿Se han modificado los tests para que se justifiquen ese doble nº de fallos? ¿Ha habido un programador menos experimentado que haya estado tocando hoy el código? etc, etc. Hay que tener cuidado, porque seguramente los datos no nos van a dar las respuestas a las preguntas que busquemos (en este caso, buscamos la calidad del código).
5. Similar a la siguiente.
6. Las fórmulas (manuales o automáticas), pueden haber tergiversado el significado de los datos originales, eso hay que tenerlo en cuenta.
7. Hay que ver si estamos trabajando con los datos de forma consistente. El que haya variaciones (ayer 5 fallos, y hoy 10), puede tener muchos significados. Además, es posible que errores en diversas etapas del proceso de recogida y cálculo hayan alterado los datos o pervertido su significado.

Como resultado, siguiendo el ejemplo de que ayer teníamos 5 defectos en unit testing, y hoy tenemos 10, las preguntas pueden llevarnos a varias conclusiones:

• Se han alterado los casos de prueba, o el número de unit testings existentes.
• Por algún motivo, se han ejecutado más casos de prueba o más pruebas unitarias.
• El proceso automatizado o manual, ha cambiado.
• Las fórmulas usadas o la forma de recogida ha cambiado.
• Nuestra calidad de código es la mitad de ayer.

Estaremos tentados de ir directamente a la última conclusión. Sin embargo, es posible que cualquiera de las anteriores (o muchas otras), sean realmente las conclusiones. Como ingenieros de software, es nuestra responsabilidad llevar a cabo correctamente tanto el proceso como la interpretación de los resultados.

Fuente: Interpreting the CMMI: A Process Improvement Approach (by  Margaret K. Kulpa and Kent A. Johnson )