Complementando CMMi con TMMI: Analizando el retorno de la inversión

A propósito del fuerte impulso a la capacitación y certificación de organizaciones e individuos en nuestro país, vale la pena poner en perspectiva los logros obtenidos, por ejemplo, en áreas de mejora de procesos de software, donde la meta es alcanzar cierto nivel de madurez ya sea en Moprosoft o CMMI.

En el caso de éste último, abundaremos particularmente sobre algunos elementos que apoyarían en el análisis del retorno de la inversión, desde el punto de vista de las pruebas, a través de la aplicación de un proceso basado en algún Modelo Especializado en Pruebas como TMMi (Test Maturity Model integration), el cual podría visualizarse como una opción natural para cubrir principalmente las áreas de Validación y Verificación contempladas en el nivel 3 de CMMI.

Recordando que en Diciembre del 2010 se liberó finalmente la versión 3.1, versión ya completa, de TMMi es muy reciente su liberación y por ende las empresas no podían certificarse en TMMi, pues al no estar completamente definido (faltaban por desarrollar los niveles 4 y 5), tampoco existía un proceso formal para realizar assessments. Sin embargo esas posibilidades están cada vez más cerca.

Para aquellas organizaciones que han optado por buscar la mejora de sus procesos de prueba basándose en TMMi, les hago énfasis en la importancia de que luego de realizar un assessment, un consultor los ayude a trazar un plan de mejora tomando en consideración no sólo aspectos técnicos sino también el retorno de la inversión que ese plan requerirá. Esto hará más rentable y viable el esfuerzo de mejora de procesos.

Aún cuando TMM (Testing Maturity Model) ha sido su principal fuente, TMMi se basa además en aspectos de CMMI y en estándares internacionales tal como el de la IEEE[3], entre otras fuentes, incluso una parte importante de la terminología de pruebas empleada se basa en el ISTQB.

Como ya hemos comentado anteriormente, el modelo TMMi se basa en una estructura de 5 niveles que son:

Inicial. No existe como tal un proceso definido para pruebas, éstas son concebidas como parte del debugging. La organización no cuenta con un entorno estable para el soporte de los procesos.

Administrado. Las pruebas se convierten en un proceso administrado y claramente independiente del debugging. Considera las siguientes áreas clave: políticas y estrategia de prueba, planeación de prueba, monitoreo y control de prueba, diseño y ejecución de prueba, ambiente de prueba.

Definido. Las pruebas se encuentran totalmente integradas en el ciclo de vida de desarrollo del software, dejando de representar una fase aislada posterior a la codificación. Considera: organización de prueba, programa de entrenamiento para prueba, ciclo de vida de prueba, prueba no funcional, revisiones de pares (peer review).

Medido. En este nivel, las pruebas ya son un proceso perfectamente definido y medible. Aquí entran áreas como: medición de prueba, evaluación de la calidad del software y revisiones de pares avanzada.

Optimizado. La organización es capaz de llevar un control sistemático de costos y efectividad del proceso de pruebas, es capaz de continuar mejorando sus procesos. Se apoya en áreas como prevención de defectos, optimización del proceso de prueba, y control de calidad.

La relación de TMMi con CMMI hace a este modelo especializado en pruebas especialmente interesante para aquellas empresas que cuentan con cierto nivel de madurez en CMMI y que desean ya sea subcontratar las pruebas o bien, implantar su propio proceso basados en TMMi.

Como bien sabemos, entre algunas de las áreas de proceso que habría que implantar para alcanzar por ejemplo, el nivel 3 de CMMI, se encuentran primordialmente la de Verificación y la de Validación, (e incluso la de Integración de Producto), las cuales podrían alcanzarse mediante el desarrollo de un proceso basado en algún Modelo Especializado en Pruebas, como TMMi, el cual a su vez debiera contemplar la definición de métricas de producto.

Estas métricas que se obtienen de las pruebas pueden ser de gran utilidad para medir el retorno de la inversión (trátese de la inversión hecha para implantar tanto un modelo de mejora de desarrollo o uno especializado en pruebas). Es decir, podemos contar con elementos que nos lleven a definir cuánto tiempo nos llevará recuperar lo invertido en mejorar nuestros procesos de desarrollo. Para ello debemos conocer:

• ¿Cómo estamos?
• ¿Qué tanto nos cuesta hacer las cosas como las hemos venido haciendo?
• ¿Qué problemas tenemos y cuánto tiempo y costo nos implica resolverlos?
• ¿Cuánto esfuerzo hay que aplicar para corregir problemas (re-trabajo)?
• ¿Quienes cometen más errores?
• ¿Cuánta capacitación necesitamos para mejorar?

Por otro lado, como resultado de la evaluación de varios productos de software que realizamos durante los concursos llevados a cabo en 2007 y 2008 sobre productos de software mexicanos, mostramos en ediciones anteriores, cómo el no probar adecuadamente incrementa los costos de mantenimiento, lo cual a su vez merma las utilidades y dificulta la inversión en otros rubros estratégicos para las organizaciones.

Es importante por lo tanto, poner especial énfasis en las métricas de pruebas, de manera que podamos realizar las actividades necesarias para bajar costos, mejorar la productividad, mejorar la calidad del software y los procesos que permitieron desarrollarlo, asegurando así un notorio retorno de la inversión en el corto plazo.

Algunos ejemplos de métricas de pruebas que pudieran ser de utilidad son:

Cantidad de defectos potenciales.

• Problemas en requerimientos, diseño, documentación, inadecuada corrección de defectos, errores en planes de pruebas, en casos de prueba.

Densidad de defectos

• Densidad = Cantidad de defectos / tamaño del software (ya sea que se mida en líneas de código, puntos de función, etc.)

Cantidad de defectos removidos

• Por etapa en la que fueron removidos- antes o después de las pruebas, durante el deployment, etc.
• Por causa raíz (código, base de batos, ambiente, datos de prueba, etc.)
• Eficiencia en la remoción de defectos
• Tasa de remoción de defectos por desarrollador/por período
• Tasa de remoción de defectos por ciclo de prueba
• Tiempos de respuesta en la corrección de defectos
• Cantidad de defectos por severidad (1. Muy Alta, 2.Alta, 3.Media, 4.Baja, 5.Mejora)
• Cantidad de defectos por desarrollador
• Cantidad de defectos pospuestos

Comportamiento del producto comparando resultados de pruebas regresivas y progresivas

• Esfuerzo empleado en remoción de defectos y costos asociados (correcciones, re-trabajo, análisis de defectos, etc.)
• Cantidad y costo de errores que pasan a producción
• Ahorros estimados en mantenimiento

Una expectativa natural al implantar un modelo como CMMI, es que permita mejorar el proceso de desarrollo, y que implícitamente mejore además la calidad del producto. Sin embargo, aún cuando esto pareciera tener cierta lógica, no siempre ocurre así. Quizás en buena medida porque el principal objetivo oculto que ciertas organizaciones persiguen, no se focaliza en obtener una mejora como tal de sus procesos, sino simplemente en obtener mejores credenciales para vender. Lo cual no es precisamente malo, pero sí nos debiera llevar a evaluar qué tan bien estamos aplicando nuestras estrategias corporativas, en relación a lo que buscamos en el mediano y largo plazo.

Por lo anterior, se esperaría entonces que la aplicación sistemática de un Modelo de Calidad Especializado en Pruebas, contribuya en alto grado a la mejora de calidad de un producto de software; y si este modelo de pruebas (TMMi) a su vez es uno que contiene áreas y prácticas alineadas a las manejadas por el modelo de desarrollo que nosotros o nuestros clientes hemos adoptado (CMMI), nos allanará el camino, incluso aún cuando se trate de la aplicación de algún proceso de pruebas basado en su modelo predecesor TMM, o hasta en algún otro modelo de pruebas que maneje áreas semejantes.