El costo de la calidad de productos manufacturados es bien conocido por el productor y, a veces, solo especulado por el cliente. Cuando un consumidor dice “lo barato sale caro” está asumiendo una posición acerca de la calidad del producto en cuestión.
Yo tengo décadas de estar hablando de la calidad del software a todo el que pareciera que pudiera interesarle. Invariablemente, cuando toco el tema con ejecutivos de empresas o jerarcas de instituciones, se les dispara un switch en el cerebro y dejan de poner atención. Creo que finalmente esto está empezando a cambiar. El motivo es la ciberseguridad.
Si un caco se metió al sistema, no fue porque abrió una ventana cerrada, sino porque la ventana estaba abierta. A diferencia de la ingeniería industrial, la calidad del software no debe lidiar con materiales que se desgastan y rompen con el tiempo, al software el tiempo no lo afecta, el software nunca se rompe ni se gasta.
Supuestamente, en 1947, Grace Hopper, pionera de la computación (quien se retiró con el rango de almirante de la Marina de EE. UU.), descubrió una polilla dentro de la computadora, y se acuñó el término bug para referirse a una falta o falla en el sistema. Con los años, se tradujo a pulga y al software estando pulgoso, es decir, con errores y faltas. Desafortunadamente, la mayoría del software del planeta está pulgoso. La gran excepción, esperamos, es el software que controla cohetes, aviones, autos y otra maquinaria crítica.
El conocimiento requerido para demostrar que un software funciona correctamente existe, y parte de una especificación rigurosa de los requerimientos (sean funcionales o no). El problema es que este enfoque es muy caro y lento, y no sirve para satisfacer la siempre creciente demanda por más y mejores funcionalidades en el software.
Existen también metodologías basadas en buenas prácticas de desarrollo, y en la ejecución de pruebas exhaustivas (automatizadas), pero, al fin y al cabo, las pruebas de software solo sirven para demostrar la presencia de errores, nunca la ausencia de estos.
En grandes cifras
En julio del 2021 escribí acerca de medir la calidad del software antes de ponerlo en producción, esto, a raíz de un nuevo estándar ISO y de la publicación del segundo informe titulado Costo de la mala calidad del software en Estado Unidos 2020. En noviembre del 2022, el Consorcio de Calidad de Software de Información publicó el tercer informe bianual de la serie El costo de la baja calidad de software en EE. UU. 2022. El cambio de mala a baja calidad es únicamente debido a que ahora está mejor traducido. De hecho, todo el informe está traducido y disponible.
En el 2020, el estimado del costo de la baja calidad del software era de $2,08 billones (en inglés dicen trillones y se refiere a 1.012) en el 2022 se estimó en $2,41 billones lo cual significa un crecimiento del 10 al 10,5 % del PIB. Sigo creyendo que no hay ninguna razón para suponer que en Costa Rica el porcentaje sea diferente.
Las pérdidas debidas al cibercrimen, por vulnerabilidades contenidas en el software, crecieron un 64 % en EE. UU. entre el 2020 y el 2021, las del 2022 no se han determinado todavía. En Costa Rica, todos sabemos lo que sucedió en el 2022, lo que no sabemos es cuánto costó. En EE. UU. nunca se podrá cuantificar el costo del sufrimiento infligido a la población con la interrupción del oleoducto de Colonial Pipeline, o en Costa Rica a los usuarios de la CCSS y el Ministerio de Hacienda.
El costo de proyectos de software fallidos se ha mantenido constante en EE. UU. durante la última década (alrededor del 19 % de los proyectos) y representa un costo ligeramente superior al 1 % del PIB. Las razones son variadas, pero un tema consistente es la poca atención prestada a la calidad del software. Este año, crecieron notablemente los problemas de la cadena de suministro del software con componentes de terceros (especialmente software abierto, open source software, por sus siglas en inglés OSS) incluidos dentro de aplicaciones comerciales.
En el 2021, un 77 % de las organizaciones reportaron un aumento en el uso de OSS. Una aplicación de tamaño mediano (menos de 1 millón de líneas de código) integra de 200 a 300 componentes de terceros en promedio. El número de fallas causadas por debilidades en las partes de open source de una cadena de suministro de software aumentó en un 650 % entre el 2020 y el 2021.
Intereses
Con frecuencia se toman decisiones subóptimas en el desarrollo de software que mejoran el tiempo de entrega, el costo de corregir todas esas decisiones (no todas son conscientes) se denomina la deuda técnica (DT). Ese es en realidad el principal de la DT, los intereses son el costo extra que conlleva mantener dicho software debido a la complejidad extra introducida.
La DT estimada en EE. UU. pasó de $1,31 billones a $1,52 billones (un aumento de $200.000 millones) porque las deficiencias no se están solucionando mientras nuevas se están introduciendo. Se calculó, además, que en promedio los desarrolladores dedican un 33 % de su tiempo a la DT. Si tomamos en cuenta que el año pasado se escribieron 111.000 millones de líneas de código nuevas mientras el número de líneas desechadas es negligible, no resulta sorprendente el crecimiento de la DT.
Las recomendaciones contenidas en este último informe se basan en desarrollos recientes y soluciones emergentes para ayudar a mejorar la situación de la mala calidad del software que existe ahora y estabilizar y reducir el aumento en el costo de software de baja calidad en el futuro cercano. Dichas recomendaciones se centran en describir los diferentes estándares de calidad y taxonomías de problemas de software, enumerar herramientas para comprender, encontrar y corregir deficiencias de la DT y herramientas de inteligencia artificial y aprendizaje automático para ingeniería de software.
Las taxonomías de problemas de software son vastas y minuciosas, hay inventarios de debilidades (debidamente tipificadas) y de vulnerabilidades. Cabe destacar que una debilidad se convierte en vulnerabilidad cuando alguien descubre cómo aprovechar la debilidad para cometer una fechoría. Las nuevas herramientas de análisis de código fuente descubren tanto debilidades como vulnerabilidades en el software sin necesidad de ponerlo en producción.
Muchas veces cuando se adquiere software no se adquiere el código fuente, este permanece con el proveedor, pero el cliente puede (¿debe?) solicitar se entregue el resultado de correr un determinado analizador de código fuente.
En el Club de Investigación Tecnológica, a punto de cumplir 35 años, creemos necesario ayudar a los afiliados a comprender y utilizar el conocimiento contenido en este informe, por lo que no solo lo tradujimos y pusimos a disposición, sino también invitamos a Herb Krasner, el autor, a presentarlo en nuestra reunión mensual de marzo.
Está claro que la ciberseguridad es un subconjunto de la calidad del software. En buen software, no entra hacker.
