LA ACTITUD HACIA LA CALIDAD - Watts Humphrey

(Traducción libre)

En esta columna se analiza la actitud hacia la calidad y cómo los profesionales de software y los directivos deben cambiar su punto de vista acerca de la calidad de si queremos progresar en temas de calidad y seguridad del software. La calidad es clave para el desempeño del software, sea que nos preocupemos por la funcionalidad, facilidad de uso, fiabilidad, seguridad, u otro. […]

La actitud hacia las pruebas

A lo largo del tiempo en que he estado escribiendo programas, los programadores han creído que al lograr eliminar los errores durante las pruebas (testing), los programas funcionarán. Si bien esto suele ser cierto, no siempre es así. Esta diferencia es la fuente de muchos de los problemas de calidad y seguridad del software.

Nuestros programas se utilizan a menudo de manera imprevista y es imposible poner a prueba incluso a los programas pequeños en todos los aspectos en que se podrían utilizar. Para poder apreciar el problema del testing, considere el laberinto simple descrito en la Figura 1. Las esquinas resaltadas indican las posibles ramificaciones. Una ruta de ejemplo, de la esquina A a la B está indicada por las flechas. Considerando sólo los caminos a seguir hacia adelante, y haciendo caso omiso de los bucles, existen 252 posibles caminos de la esquina A a la B, en esta matriz de 5 por 5. Esta matriz tiene solamente 25 ramas. Para 100 ramas, necesitaríamos una matriz de 10 por 10, con lo que habrían 184.756 posibles caminos hacia adelante.

Programas más útiles tienen muchas más de 100 instrucciones de ramificación. Por ejemplo, uno de mis programas en C++ tiene 996 líneas de código (LOC) y 104 ramas. Se trata de una rama por cada diez instrucciones. Incluso, si los grandes programas tuvieran diez ramificaciones por cada mil líneas de código (KLOC), un programa de 1.000.000 LOC tendría 10.000 sucursales. Para una matriz cuadrada de 100 por 100 con 10.000 ramas, existe el astronómico valor de 2.28 x 10 58 posibles caminos hacia adelante, de la esquina A a la esquina B. Pocos desarrolladores estarían dispuestos a ejecutar 252 pruebas, mucho menos 2,28 x 1058 pruebas.

Figura 1: Posibles caminos a través de una matriz

Un breve análisis muestra que la prueba de este número de caminos es imposible. Por ejemplo, si simultáneamente se ejecutasen un millón de pruebas en un segundo durante 24 horas al día en un millón de computadoras, tomaría más tiempo que el ciclo de vida del universo para ejecutar todas estas pruebas. Incluso entonces, sólo se habrían puesto a prueba un conjunto de valores de datos.

Dado que es imposible probar exhaustivamente grandes programas, nos enfrentamos a la siguiente pregunta: "¿Es realmente necesario todo este testing?" Para responder a esta pregunta, debemos considerar cuántos defectos existen en los típicos sistemas de software grandes. Hoy en día sabemos cuántos defectos inyectan los desarrolladores experimentados. En promedio, inyectan un defecto por cada diez líneas de código. Un análisis de los datos de más de 8,000 programas escritos por 810 desarrolladores profesionales se muestra en la Tabla 1.

La tasa promedio de inyección de estos desarrolladores es de 120 defectos por KLOC, o un defecto por cada ocho líneas de código. Incluso el top 10% de los desarrolladores inyectaron 29 defectos / KLOC y el 1% inyectó 11 defectos / KLOC. Incluso a la velocidad de inyección del top 1% de los desarrolladores, un sistema de 1,000,000 LOC entrarían al proceso de compilación y testing con 11,000 defectos. Los desarrolladores más típicos tendrían 120.000 defectos en sus productos.

Tabla 1: Tasas de inyección de defectos para 810 desarrolladores de software experimentados

Grupo Defectos Promedio por KLOC (miles de líneas de código)

Todos 120.8

Cuartil Superior 61.9

10% Superior 28.9

1% Superior 11.2

Es por eso que la mayoría de programas grandes, incluso después de compilación y pruebas, tienen de 10 a 20 defectos por KLOC cuando entran a la etapa de pruebas del sistema (system testing). Para un sistema de 1,000,000 LOC, eso significaría entre 10,000 y 20,000 defectos. Con las prácticas actuales, los grandes sistemas de software se encuentran plagados de defectos, y muchos de estos defectos no se pueden encontrar incluso por las pruebas más extensas. Es evidente que, aunque el testing es esencial, por sí sólo no puede proporcionar la calidad que necesitamos, para tener sistemas seguros.

Por lo tanto, el primer cambio de actitud necesario para los profesionales de software y sus directivos es el de aceptar el hecho de que las pruebas por sí solas no producirán los sistemas de la calidad. Además, dado que el software defectuoso no puede ser seguro, el testing por sí solo tampoco producirá sistemas seguros.

La actitud derrotista

La actitud siguiente que tenemos que cambiar se refiere a la viabilidad de producir software seguro y de alta calidad. Muchos expertos en software le dirán que no existe el software libre de defectos. Su obvia conclusión es que tenemos que aprender a vivir con los productos de software de baja calidad e inseguros. Mientras que la discusión previa sobre el testing le pudiera haber convencido de que esta actitud es correcta, en realidad no lo es. Lo que estos profesionales le están diciendo en realidad es que no hay manera de probar que un sistema de software se encuentre libre de defectos.

Por desgracia, es cierto que no hay manera de probar que un sistema de software sea libre de defectos. Pero eso también es verdad para cualquier otro tipo de productos. No hay manera de probar que un automóvil o un avión o cualquier otro producto sean libres de defectos, pero no aceptamos eso como una excusa por automóviles o aviones de mala calidad. La

cuestión no es demostrar que un producto de software está libre de defectos, sino más bien demostrar que hemos tomado todas las medidas y utilizado todos los métodos disponibles para hacer que el producto esté lo más cercano a encontrarse libres de defectos. Existen muchas maneras de hacer esto, las que han demostrado ser altamente eficaces en muchos otros ámbitos técnicos. A pesar de ser métodos simples, no son fáciles. Requieren medición, análisis, gran cantidad de atención personal, y, sobre todo, la convicción de que la calidad es absolutamente esencial.

La visión actual común de que es imposible producir software libre de defectos es una excusa para no esforzarnos en hacer un trabajo de calidad. Una forma más sutil de esta actitud es apoyarse exclusivamente de herramientas para identificar los errores. ¿Cuántas veces algún programador le ha dicho que un nuevo entorno de desarrollo, lenguaje, depurador (debugger) o analizador es la respuesta para resolver los problemas de calidad y seguridad? Pero entonces, incluso después de utilizar todos estos vistosos gadgets, los productos resultantes todavía tienen defectos y no son seguros. El problema es la actitud, y ninguno que cuente con alguna herramienta o gadget para manejar la calidad producirá software grande seguro y de calidad.

La actitud de calidad

Tener la actitud correcta puede hacer una enorme diferencia. Existe una creciente evidencia de que el software libre de defectos es posible. Algunos grupos de desarrollo están produciendo software de gran escala que no han tenido defectos encontrados por sus usuarios. Si bien estos productos en realidad pueden tener defectos ocultos, para todos los propósitos prácticos, son libres de defectos. Hoy en día, pocos equipos de desarrollo pueden producir este software de manera consistente.

La tarea pendiente

Tenemos que aprender de estos métodos y prácticas de calidad y extenderlas hacia nuestras necesidades de software de alta prioridad. Hoy en día, es una necesidad crítica aplicar estas prácticas de calidad comprobada en los sistemas realmente complejos e interconectados, que soportan la infraestructura crítica de la nación.

Lo que debe quedar claro de esta discusión es que no nos hemos esforzado lo suficiente para producir software libre de defectos, por lo que realmente no podemos saber si lograr estos productos de alta calidad sea posible o no. … [En otro artículo se analizarán] los métodos de calidad que la gente está utilizando hoy en día para producir software de calidad excepcional, y los pasos necesarios para extender estas prácticas en los sistemas realmente masivos, que serán comunes en el futuro. Estos sistemas deben ser seguros y, para ser seguros, deben ser esencialmente libres de defectos. Aprender cómo producir consistentemente estos sistemas es nuestro reto para el futuro.

Link al artículo original:

http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsnew20043.cfm