Los programas de cómputo se escriben en lenguajes de programación y cada línea es una instrucción. Los programas que los humanos escribimos son código fuente. La cantidad de líneas utilizadas es una medida del tamaño y, por lo general, de la complejidad del programa.
El código fuente se pasa por otro programa, llamado compilador, para producir el código objeto en lenguaje de máquina, que la computadora entiende y ejecuta. En Costa Rica, sin duda, tenemos miles de millones de líneas de código que se ejecutan todos los días, algunas escritas por nuestros programadores, otras escritas por programadores en algún otro lugar del planeta.
Durante décadas, la calidad del software ha sido muy difícil de medir, y hasta hace poco solo se hacía cuando ya estaba en producción (contando y midiendo incidentes y problemas).
En el 2018 y el 2020, el Consorcio de Calidad de Software e Información (CISQ, por sus siglas en inglés) publicó estudios que estiman el costo de la mala calidad del software en EE. UU. en un 10 % del PIB. En Costa Rica, eso equivale a unos $6.000 millones, una cifra nada despreciable.
El costo de la mala calidad del software se calcula con base en los incidentes reportados. No hay ningún motivo para suponer que en Costa Rica ese costo sea menor, o mayor, pero sí es muy difícil cuantificarlo, dada la renuencia a notificar fallas.
No hay que ser sabio para concluir que es buena idea invertir en la calidad del software que compramos o desarrollamos. Mejorar la calidad, sin duda, aumenta el costo y el tiempo requeridos para su producción, pero reduce los problemas de ciberseguridad, interrupciones y frustraciones usualmente asociadas con la utilización de los paquetes de cómputo. Muchos de estos costos son difíciles de medir, por ejemplo, ¿cuánto cuesta la frustración del cliente que lo lleva a desechar una aplicación?
Claro que se han hecho esfuerzos en nuestro medio por mejorar la calidad del software; sin embargo, la gran mayoría han estado enfocados en el proceso de programación y en las pruebas, ojalá exhaustivas.
LEA MÁS: Infraestructura digital pública
Problema humano. El problema es que son ejecutados por humanos y los humanos nos equivocamos a cada rato. Los testeos únicamente sirven para demostrar la presencia de errores, nunca para demostrar su ausencia.
El software o contiene errores o no, ya que ni se gasta ni se rompe. Si tiene yerros, siempre los ha tenido, es decir, existen desde que se puso en producción la última vez (o sea, desde la última versión).
Hace diez años ISO publicó un modelo de calidad del software, el estándar ISO 2510 (calidad de software y datos), en el que se establecen ocho categorías: idoneidad de la funcionalidad, eficiencia del desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenimiento y portabilidad. Sin embargo, las medidas de estas categorías están relacionadas con el comportamiento de la aplicación, es decir, hay que esperar que esté en producción para ver qué tal está la calidad.
Por suerte, hace tres meses se publicó el estándar ISO 5055 (medidas automatizadas de la calidad del código fuente), que viene a complementar los estándares anteriores y permite medir cuatro categorías de calidad desde el código fuente, antes de entrar en producción y sin perjudicar la experiencia del usuario.
Este estándar mide 138 debilidades graves del software que deben eliminarse de una vez, no deben dejarse para más adelante. Algunas debilidades afectan a más de una categoría, por ejemplo, la fiabilidad. En otras palabras, causan que el programa se detenga, pero también son riesgos de seguridad por donde un hacker puede penetrar.
Hay debilidades en componentes individuales (programa, método, función, etc.), pero también en las interacciones entre los diferentes componentes, algunos incluso escritos en lenguajes diferentes.
Estas últimas suelen consumir más de la mitad de los esfuerzos de mantenimiento, aunque solo representan tal vez un 10 % del código. Una enorme proporción de todas las aplicaciones consisten en múltiples componentes que interactúan de manera compleja.
El estándar identifica y describe una a una las 138 debilidades e incluye una descripción de los patrones de detección de cada una, de manera que es relativamente sencillo construir una herramienta que las encuentre en el código fuente escrito en un lenguaje particular.
LEA MÁS: Dos iniciativas pendientes
Actuar a priori. Toda organización que cree sistemas debería verificar la inexistencia de defectos antes de entregar el programa a sus clientes (sean estos internos o externos) independiente del tamaño de la organización.
Es de esperar que muy pronto, cuando se adquiera un sistema de cómputo se exija el cumplimiento del estándar ISO 5055 y se defina el umbral de debilidades encontradas en cada característica (el límite más razonable parece ser cero, pero es concebible que en aras de la velocidad de entrega se acepten algunas deficiencias conocidas).
Junto con las pruebas de aceptación, se deberá exigir el resultado de la verificación del estándar. Es mucho más relevante esto último que tener acceso al código fuente. Es más, en muchos casos el acceso al código fuente es una maldición debido a la tentación irresistible de meterle las manos.
Actualmente, existen dos proveedores de herramientas para detectar las debilidades, ambos son patrocinadores de CISQ (CAST y Synopsys), pero cualquiera puede construir una herramienta de estas y solicitar a CISQ que certifique que verifica correctamente la presencia de las debilidades enumeradas por el estándar.
Este nuevo modelo provee la oportunidad de nunca más adquirir software sin medir la calidad antes de ponerlo en producción, lo cual previene una enorme cantidad de costosos problemas operativos.
En lo que respecta a las compras públicas de software, esto debería ser obligatorio, y en las instituciones donde insistan en desarrollo interno también deberían revisarlo antes de ponerlo en producción.
Nunca más deberían tomarse decisiones de si comprar o construir software sin tomar en cuenta la calidad; es totalmente irracional presuponer que la calidad es la misma para todas las alternativas. Más hora, que contamos con una manera ágil y eficiente de medirla antes de poner el software en producción.
El autor es ingeniero, presidente del Club de Investigación Tecnológica y organizador del TEDxPuraVida.