Realmente, por aquellos entonces, más que ISO 25000 hablábamos de ISO 9126 (la norma antecesora).
En los años previos, principalmente del 2005 al 2006, yo había participado en varias implantaciones de entornos para obtener métricas. Los primeros años con herramientas muy asíncronas como Together y posteriormente con herramientas lanzadas desde Maven, como PMD, CheckStyle, etc. (de esto algo te conté ya en “Mi personal y particular historia con las métricas de calidad software. Y saca de aquí lo que pueda valerte”)
En 2007 nos tocó trabajar en un proyecto (de una administración pública regional, más concretamente) que empezó como una implantación de automatización de métricas (caja blanca – estáticas) basadas en Maven, de hecho, algo te conté muy brevemente en este blog a raíz de aquel proyecto, en 2007, casi en directo.
Pero después de terminar esa primera fase del proyecto… se necesitaba más. Tener muchas métricas de calidad del proyecto fue un gran salto para gestionar la calidad de las entregas de los proveedores… pero no era suficiente. Se necesitaba un cuadro de mando, un escalado de valores, recoger en unos pocos números los datos de muchas métricas. Y ahí entra la ISO 25000.
El cuadro de mando de la ISO 25000
En vez de inventarnos un cuadro de mando tomamos el que ya define la ISO 25000 (como te decía, llamada ISO 9126 por aquellos tiempos). Si no conoces muy bien la norma, te dejo aquel post resumen de Cómo estandarizar la evaluación de la calidad del producto software… la ISO 9126 y la ISO 25000 (1/2)
La ISO 25000, propone una jerarquía de atributos de calidad. Que mejor ejemplo para explicártelo que uno real, un extracto de uno de nuestros documentos de trabajo, el de la figura de abajo.
Las dos primeras columnas representan una de las “patas” del árbol de la ISO 25000, concretamente la del atributo “Mantenibilidad”. Hay otras muchas “patas” en la ISO 25000, como la seguridad, la fiabilidad, etc. Pero en este caso nos vamos a centrar en la “Mantenibilidad”.
La teoría de la ISO 25000 llevada a la realidad de las herramientas de métricas
La mantenibilidad (independientemente de la ISO 25000) está muy relacionada con la productividad de un equipo a la hora e mantener el software (es decir, está relacionada con los €). Si la mantenibilidad es baja se necesitarán más horas para hacer cambios, evolucionar, o solucionar problemas en el software.
Y normalmente la mantenibilidad se ve en los fuentes (caja blanca – estática), desde donde se aprecia si hay “programación fea” y “diseño feo”.
De eso que llamo “cosas feas” ya hemos hablado muchas veces, siendo solo unos ejemplos de muchos, recuerda aquello de duplicar, o copy pegar, código no es una buena idea, o que un case o switch con muchas clausulas, o muchos ifs anidados, tampoco es una buena idea o los “bad smells” en general.
El problema de la ISO 25000 es que solo se queda a nivel de las dos primeras columnas de la anterior tabla, de ahí para abajo el trabajo es tuyo. Por ello, lo que hicimos fue relacionar las herramientas típicas en Java para evaluar calidad respecto de la mantenibilidad (columna 3 y 4) con las dimensiones de la ISO 25000 respecto de la mantenibilidad (columnas 1 y 2).
Hasta ese momento, no habíamos encontrado que nadie “se mojase” para relacionar las columnas 1 y 2 de la ISO 25000 con la 3 y 4. Todo lo que leíamos por ahí eran múltiples excusas y miles de maneras de por qué no hacerlo, pero ninguna propuesta ni solución.
Buscando un único número para la ISO 25000 desde muchas métricas
No obstante, aunque en la tabla queda muy bonito el problema (aparte de programar todo esto y montar el entorno) era la calibración. De los resultados de todas y cada una de las múltiples métricas (columna 4) había que obtener un único número, para las columnas 1 y 2 de la ISO 25000. Y cada métricas de la columna 4 se mueve en un rango diferente, unas de – 1 a 1, otras de 0 a infinito, etc. La media de valores no era la solución, lo que hicimos fue calibrar con trapecios.
Los trapecios son funciones por partes, en el eje de las X el valor de la métrica, el rango en que se mueve, y en el de las Y la calibración de 0 a 100, siendo 0 la menos calidad y 100 la máxima.
Son funciones por partes o trapecios porque las métricas de calidad software, de mantenibilidad, no siempre se comportan de manera lineal. Eso ya te lo había contado aquí, pero te lo resumo con un ejemplo: el % de comentarios en una clase, si es cero es baja calidad, si es un 10% ya pinta mejor, pero si es un 90% suena a código comentado, así que mal. Es decir, no es lineal.
Los cuadros de mando en base la ISO 25000 se usaron e implantaron en numerosos proyectos. Afortunadamente hoy ya son muchas las herramientas que ya vienen con cuadros de mando de ISO 25000.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024