En aquellos negocios en los que las Tecnologías de la Información son críticas para la operación, disponer de una medida clara sobre cuánto daño nos ha hecho un problema en producción es un formidable reto. Si preguntamos a las partes interesadas (los míticos «stakeholders«), todos coinciden en su importancia pero discrepan drásticamente en su implementación.

¿Por qué es tan difícil cuantificar el efecto de los problemas software?
¿Es más difícil establecer el impacto y cuantificar error software que medir cuánto pica una guindilla?

Desde 1912, gracias a Wilbur Scoville y su Examen Organoléptico Scoville, tenemos una escala que nos permite saber cuánto nos va a picar una guidilla o chile. La medida se estableció en unidades … Scoville (SHU, del inglés «Scoville Heat Units») que indicaban cuántas veces había que diluir el extracto del chile en agua azucarada hasta que era indetectable por un jurado.

Escala Scoville SHU

En la actualidad se recurre a medir con precisión la cantidad de capsaicina (componente químico culpable del picor) mediante técnicas de laboratorio: mejora continua. Por cierto, la capsaicina no es soluble en agua … así que si necesitas aliviar el picor de un chile, mejor con leche.

¿Y qué pasa con el picor de una incidencia en los sistemas de información?
¿Cómo lo medimos?

Para poder contestar se necesita método, deberemos obtener nuestro «extracto de chile» equivalente para medir su pungencia.

Así, aplicando prácticas como la Integración Continua de software dispondremos de mecanismos para establecer relaciones de causa – efecto sobre los comportamientos de nuestros sistemas TI y podremos alinearlos con los elementos incorporados en la Gestión de Activos. Nos vamos acercando.

¿Qué nos aporta la Gestión de Activos software? Nos introduce en la dimensión «economía». Nos cuantifica el valor aportado por los diversos elementos de configuración, de forma que podemos establecer cuándo nuestra incidencia queda suficientemente diluida como para ser indetectable. Si lo queremos ver en términos de dinero, equivale a compensar el picor reconociendo una pérdida en euros (por ejemplo).

Mientras recorremos este camino, la detección temprana de anomalías es una auténtica vía rápida hacia el aseguramiento del valor esperado. Por ejemplo, si monitorizamos el “proceso de registro de nuevos clientes en la tienda online”, el valor añadido de este sensor emana del beneficio directo generado por este proceso. Os lo contamos con más detalle en nuestro artículo sobre Sondas automáticas de disponibilidad software.

Estas son las bases que proponemos desde Panel Sistemas para caminar hacia un método que culmine en una escala estándar de escozor software: las SHU, del inglés «Software Hurt Units» 😉

Scoville nos demostró hace mucho tiempo que si se quiere, se puede medir. Inciativas como el proyecto europeo Iceberg, participado por Deiser, son un clara señal de que se quiere y se puede. Nuestra particular contribución en este ámbito de la Calidad Software está publicada en forma de estudio para el cálculo del retorno de la inversión en pruebas software («ROI on Testing Investment»).

Para terminar, si en vuestra empresa habéis conseguido consolidar una escala (que no sea el número de llamadas en el Centro de Atención a Usuarios o los decibelios de los gritos del área de Operaciones) os animo a compartirlo con todos nosotros, porque …

… ¿Cuánto os pica un bug?

¿Cuánto nos pica un bug?