Algunas consideraciones sobre la evaluación de la calidad del producto software

Estos últimos meses hemos estado muy ocupados en una empresa bastante grande con un importante e interesante proyecto, cuyo objetivo es definir el modelo, e implantar la infraestructura, para evaluar de manera automática la calidad de los numerosos productos software que desarrollan un número considerable de proveedores externos, fábricas software en su mayoría.

La situación de partida es que trabajar con empresas de desarrollo externas (lo que se suele conocer como externalización, outsourcing, nearshoring u otros) permite a las empresas cuya línea de negocio no es el desarrollo software (y si es, por ejemplo, el transporte, la energía, etc.) centrarse en su negocio, gestionar los desarrollos como un servicio externo y beneficiarse de empresas especializadas. Lo cual suena bastante bien, y ciertamente lo es, aunque que como siempre suele ocurrir nada es perfecto y necesita de ciertas puntualizaciones y ajustes.

Aunque los desarrollos se pasen a empresas externas por lo general (no siempre pero si en la mayoría de las ocasiones) el paso a producción queda centralizado en la empresa cliente y esta debe determinar la calidad de los productos software que se le entregan antes de pasarlos a producción en su CPD (centro de proceso de datos), para asegurarse de que cumplen el nivel de calidad (funcionalidad, mantenibilidad, rendimiento, etc.) requerido. Lo que nos lleva a un primer problema: determinar la calidad de un producto software es complicado, más aún si su proceso de desarrollo es desconocido para quien lo evalúa, más si las entregas son muy numerosas, en paralelo, y cómo no, han de estar en producción en poco tiempo (nuestro caso ahora y en todas las otras ocasiones que hemos desarrollado proyectos como este).

La manera más rápida y fiable de tener visibilidad sobre el producto es recogiendo métricas del mismo (es decir, midiendo el producto mas que los procesos que se han seguido para desarrollarlo, y que dicho así parece una trivialidad pero que es la base desde la que muchos argumentan – argumentamos – que apoyarse sólo en modelos de calidad de procesos -como CMMI- no da plena seguridad sobre la calidad del producto, que es en realidad la importante en situaciones como esta).

Pero claro, de nuevo, no podía ser tan fácil… realizar mediciones software de manera periódica sin una infraestructura adecuada puede ser tan costoso en tiempo que puede hacer que no tenga sentido medir. Recuerdo que hace años nos ocurría este problema; de manera puntual utilizábamos para obtener métricas herramientas como el módulo de calidad de Together, pero sólo podíamos hacerlo para auditar el producto unas pocas veces, por el tiempo que llevaba tomar las mediciones, que además se hacían de manera muy manual y que para obtener conclusiones había que sintetizar de manera laboriosa.

Hoy en día es posible automatizar gran parte de la medición de la calidad del producto (el análisis estático de código, mantenibilidad, código duplicado, complejidad ciclomática, cobertura de las pruebas, la compilación del proyecto, el lanzamiento de las pruebas, el control de incidencias, el estilo de programación, las excepciones no controladas, y un largo etc.). Y además con herramientas de software libre muy fiables, posibilitando infraestructuras altamente productivas que permiten evaluar la calidad del software de manera diaria y totalmente automatizada.

Pero la cosa no acaba ahí. Superado esto debemos estar atentos a otra amenaza: la automatización genera tanta información en tampoco poco tiempo que en ocasiones esto puede ser peor que no tener información. Esto implica disponer de herramientas de síntesis, históricos, indicadores, tendencias, escalado de información, etc. (lo que en ocasiones se conoce como cuadro de mando). Definir un cuadro de mando sobre la calidad del producto (al que se suele añadir la del proceso) desde cero puede ser muy complejo… la buena noticia es que existen modelos como PSM (Practical Software and Systems Measurement) que ayudan en esta tarea, si bien la implementación y la infraestructura para automatizar todo es una importante tarea a tener en cuenta.

Con todo podemos decir que en la actualidad es realista, y necesario, disponer de una infraestructura automática que implemente un modelo de medición de la calidad, en un periodo razonable y proporcionando un gran beneficio.

A modo de conclusión final, de buenas prácticas o recomendaciones que al menos en nuestra experiencia nos parecen importantes, destacar que:

• La evaluación cuantitativa del producto:
• Es un método necesario no solo en el desarrollo, también si este se externaliza, más aún si somos responsables de la puesta en producción.
• Permite identificar síntomas para poder aplicar soluciones correctas.
• Aporta argumentos sólidos para defender y concienciar sobre la mejora del proceso.
• La periodicidad del muestreo la dicta la complejidad del método/infraestructura de medición (cuanto más costoso -> periodicidad disminuye).
• Una gran cantidad de pasos a producción, o un importante proceso de mejora en, por ejemplo, una fábrica software, necesitará de una alta periodicidad en la medición, así podremos controlar los efectos de las mejoras (“que arreglar algo no rompa otra cosa”), etc.
• Es fácil recopilar un excesivo volumen de información… y no saber qué hacer con ella.
• Es necesario decidir qué mostrar, cuándo y a quién. Niveles de abstracción e información.
• El proceso de definición de métricas es incremental y ha de ser mejorado continuamente.
• También existe la opción, muy usada e idónea en ocasiones, de externalizar también la actividad de evaluar la calidad del producto.

Y que nunca se debe perder de vista el objetivo final, que será, por ejemplo, alinear objetivos de negocio con planes de mejora, incrementar la productividad y rentabilidad del desarrollo, aumentar la calidad del software y la satisfacción del usuario, crear una ventaja competitiva respecto a la competencia, etc.

.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023