Las computadoras hoy en día hacen cosas maravillosas, permiten la existencia de la telefonía celular, toman decisiones, elaboran facturas, producen hipótesis, descubren tendencias. Todo esto no lo hacen por sí solas. Requieren del software (o programa de cómputo) que les dice qué hacer, cómo ejecutar las labores que se les piden. El software es el conjunto de instrucciones que las posibilita para llevar a cabo tal o cual labor.

El software lo escriben personas (en específico, programadores) que tienen el delicado trabajo de decirles a las computadoras qué cosas y cómo deben hacerlas, en un lenguaje que la máquina pueda entender (digamos, Java). Un software bien hecho (“de calidad”) es aquél que cumple con las especificaciones, con lo que se espera que haga (del mismo modo que de un martillo se espera que pueda clavar clavos).

El proceso de fabricación o manufactura de software se lleva a cabo por un equipo de trabajo que incluye entrevistadores (que extraen de los futuros usuarios del sistema sus especificaciones los requerimientos, lo que se espera que la aplicación haga, a qué otros sistemas se va a enlazar), analistas o diseñadores (que traducen los requerimientos a diseños lógicos qué información se guardará en qué tablas, qué funciones de negocio [”cosas útiles”] brindará el sistema a través de qué opciones de menú o comandos, qué verificaciones hará sobre los datos de entrada), programadores (que escriben comandos o instrucciones en lenguajes que la máquina entienda, o dan órdenes en SQL a manejadores de bases de datos, para así materializar el diseño) y probadores (verifican que el software haga lo que las especificaciones dicen, lo que el cliente pidió). Finalmente, el software se entrega, se capacita a los usuarios, se entregan los manuales de la aplicación.

¿Y cómo se mide la calidad de un software dado? Un software (u otra herramienta) es de calidad si hace lo que se espera de él—si cumple con sus especificaciones. Una aplicación se entrega con ciertas pruebas o demostraciones de que sí funciona, que cumple con lo que se dice de ella. El usuario la usa, y casi siempre mediante su uso cotidiano y repetido detecta errores. El software no cumple, no hace lo debido para ciertos casos y bajo ciertas condiciones –debería hacer esto bien, pero lo hace mal. Fundamentalmente, pues, la calidad de un software se mide mediante pruebas en su operación. Así se detectan errores o fallas: el software calcula mal, hace lo que no debe, o simplemente “truena” (suspende sus operaciones, mandando un mensaje de error). El número de fallas da una idea de la (falta de) calidad de un programa, aunque es claro que hay fallas pequeñas, inocuas o molestas solamente, medianas y grandes, catastróficas, imperdonables.

Aparte del número de fallas (mientras menos, más calidad), hay otras características que a menudo van asociadas con la calidad del software, pero que son más difíciles de medir. La ergonomía de un programa es su facilidad de uso. ¿Cómo medir si un programa es fácil de usar? Pues preguntándole a los que lo han usado. Bien, pero esto es subjetivo. Es como medir la belleza por votación. La reusabilidad de partes de un programa (volver a usar porciones ya probadas en otros programas nuevos) es muy útil, pues vuelvo a usar lo que ya inventé, probé y documenté. Pero, ¿cómo medirla? La mantenibilidad de un programa es su facilidad de mantener, de adecuar, de hacerle pequeños cambios. ¿Cómo medirla? No se sabe.

El proceso de fabricación del software busca que éste salga libre de errores (o lo que es lo mismo, que cumpla con sus especificaciones). ¿Hay algún método, algún estándar, alguna fórmula o certificación que diga cómo debo llevar a cabo mi proceso (de manufactura de software) para que éste salga libre de errores? No, desafortunadamente no lo hay. Nótese que en otras disciplinas sí lo hay: para calcular el área de un círculo, se emplea la fórmula área = pi por radio al cuadrado, y si hace bien las operaciones, no habrá error. ¿Y por qué en la manufactura del software no puedo hacer (nadie puede hacer) software libre de errores (salvo casos triviales)?

Porque nuestra ciencia es muy joven, hace 60 años empezó la Computación. No sabemos medir. Para que una disciplina sea considerada ciencia, decía Lord Kelvin (el de los grados Kelvin), debe saber medir los fenómenos que estudia. Así, la física mide la longitud: un metro es la distancia que recorre la luz en el vacío durante un intervalo de 1/299.792.458 de segundo, la energía se mide en julios (ó en kilowatts-hora), etcétera. Pero, ¿en qué se mide la velocidad de una computadora? En millones de instrucciones por segundo (MIPS). Ah, pero hay instrucciones chicas, medianas y grandes, otras se ejecutan traslapadamente (hay traslape en el tiempo en la ejecución de una parte de esta instrucción y otra parte de la instrucción que sigue). No, MIPS no es una buena medida, es subjetiva. Bueno, pero el tamaño de un programa se mide en bytes. Bien, pero ¿en qué se mide la portabilidad de un programa? (Fácil de llevar de un lugar a otro, de un sistema operativo a otro, de un navegador a otro). ¿La ergonomía de un software? ¿La complejidad de un programa, cómo se mide? No me refiero a complejidad en el sentido teórico, complejidad del orden en cuadrada, por ejemplo, sino a qué tan complejo o difícil de entender es un programa.

Hay programas difíciles de mantener, y otros que son fáciles de parchar. ¿Cómo se mide el mantenimiento de un programa? ¿Qué tan paralelo será un programa? Todos estos fenómenos, centrales a la computación, no sabemos medirlos. Otro requisito para que una disciplina sea considerada ciencia, según Lord Kelvin, es que deben existir ecuaciones de estado. Ecuaciones que nos digan “esto es igual a esto otro”. Por ejemplo, f = ma, o fuerza es igual a masa por aceleración (segunda ley de Newton). Estas ecuaciones nos están diciendo “la naturaleza no es caprichosa, si se le aplica a un cuerpo de cierta masa una fuerza de tal magnitud, deberá acelerar con una aceleración dada por la segunda ley de Newton”, o sea, dicen cómo se comporta la naturaleza. Pues bien, en computación no tenemos tales ecuaciones de estado, no sabemos qué ocurre cuantitativamente si aumentamos la complejidad de un programa, ¿en qué proporción disminuirá su mantenimiento? Esto se debe a la juventud de la computación, poco a poco se irán entendiendo mejor las dimensiones que estudia, cómo medirlas, y cómo se interrelacionan. Esto significa que, detectada una falla a la calidad (por ejemplo, mi programa es poco ergonómico, no es amigable), no está claro qué parámetros cambiar o qué parte de mi proceso de fabricación debo alterar para que ahora sea más fácil de usar. Porque no tengo una ecuación de estado que me guíe.

Entonces, cualquier receta que le quieran vender a usted para garantizar que ahora diseñará software libre de errores, es un timo.

Claro que hay recetas generales, como “contrata a las personas apropiadas, obtén todas las especificaciones del cliente, hay una prueba para cada especificación”, etcétera. Esto ayuda. También hay ciertas metodologías de diseño de software (diseño basado en componentes, diseño ágil, diseño basado en eventos…) que son estilos para producir software. Sus adherentes juran que siguiendo esas recetas se obtendrá software de buena calidad. Sí, a veces seguir una rutina asegura que los detalles no se nos escaparán. Ciertamente, estas escuelas o estilos ayudan o pueden ser útiles. Pero, dada una falla en el software, aún están lejos de indicar precisamente dónde debe corregirse éste. Y ciertamente no garantizan software libre de errores.

Se puede certificar la administración del proceso de manufacturar software. Que haya juntas. Que los acuerdos se escriban y se les de seguimiento. Que haya una bitácora de cambios. Que haya un ritual para hacer pruebas cada vez que se libera una nueva versión. Que haya un solo cambio (modificación al software) a la vez. Que los instrumentos o aparatos estén pintados de cierto color, y colocados en ciertas áreas. Un grupo de gentes bien disciplinado (adherente a estos procesos) producirá software con menos distracciones, con más uniformidad. Pero la generación de software es aún un proceso creativo, y se puede producir software de mala (o ínfima) calidad de manera rutinaria, por procesos bien establecidos, certificados, benditos por alguna asociación internacional. Sistematizar o estandarizar la rutina de la producción de software no es mala idea, pero sólo resuelve parte del problema.

A mí me ha dado buen resultado caminar sobre el código. Yo le muestro mi programa a otro programador (de mi mismo equipo, familiarizado con lo que tratamos de resolver y la terminología del caso) y le explico línea por línea lo que está haciendo, lo que el programa quiere lograr. Es como analizar un discurso antes de darlo. El otro programador puede detectar fallas, ver atajos o desventajas mientras yo le explico. Ciertamente puede llevarse mi programa para estudiarlo a detalle. O puedo dárselo una semana antes de la sesión de caminar sobre el código, para que ya venga con ideas y dudas específicas.

En resumen, no sabemos aún cómo medir las principales características del software, y los métodos que buscan la producción de software libre de errores son sólo ayudas, sobre todo en la parte administrativa.

Publicado en La Crónica de Hoy miércoles 21 de julio de 2010