La calidad en el software. ¿Es posible?

¿Por qué la calidad en la ingeniería informática siempre es una característica a sacrificar cuando vamos justos de tiempo/dinero? Es curioso como, en otras ramas de la ingeniería, nadie pondría en duda la importancia de la calidad. Hay una frase que un profesor de la asignatura de Calidad, Seguridad y Auditoría nos contó durante una clase: “¿Pasaríais por encima de un puente realizado por algún amigo que haya estudiado Ingeniería en Caminos, Canales y Puertos?”. La respuesta, salvo que no nos caiga bien (o nos caiga muy bien) nuestro amigo, es que sin duda, sí. Sin embargo, cuando cambiamos la pregunta por: “¿Os montaríais en un avión cuyo software fue desarrollado por un amigo que ha estudiado Ingeniería Informática?”, la respuesta es sencilla, si tú también has estudiado Informática, 10 de cada 10 veces contestarías que no. Esta es simplemente una ilustración de lo que significa calidad en el diseño e implementación software, o dicho de otra manera, de la falta de la misma.

¿Os montaríais en un avión cuyo software fue desarrollado por un amigo que ha estudiado Informática?.

Cuando se lideran proyectos, sobre todo si no se tiene una experiencia acumulada sobre los procesos de calidad que se han de seguir para asegurar una entrega con éxito, se cometen muchos errores que más tarde cuesta mucho dinero, tiempo y esfuerzo corregir. Cuando no se tiene un estándar de calidad para seguir, sea cual sea este, el estándar de calidad se convierte entonces en la experiencia de la persona que lidera el proyecto. Pero la experiencia tiene una desventaja, que no se transmite de persona a persona simplemente estudiándola, es necesario fallar, y fallar muchas veces donde ya otros han fallado para alcanzarla, algo que a mi parecer generará más pérdidas de dinero, tiempo y recursos que teniendo un plan de calidad desarrollado y listo para implementar por muy sencillo que sea.

Un estudio reflejó que un programador cometía, de media, 100 defectos por cada KLOC (1000 LOC) líneas de código introducidas.

Me gustaría empezar este artículo con un tres ejemplos que ilustran todo lo comentado anteriormente. 

En el metro de París se instaló un nuevo sistema comercial de subscripción “autoservicio” vía web. Un usuario introdujo una URL diferente en su navegador por error y miles de registros de datos confidenciales y personales se borraron. La URL ejecutaba una directiva de borrado que no estaba validada previamente. (Nota Sonia)

En Japón, un operador de la sociedad Mizuho tecleó erróneamente una orden de venta de 610,000 acciones a 1 yen, en vez de una orden de venta de 1 acción a 610,000 yenes en el software utilizado para el intercambio de acciones. La funcionalidad “cancelar” no estaba operativa, el resultado fue unas perdidas de 225 millones de US$ 

Playstation 3 sufre un error de conexión a nivel mundial por el cambio de mes. Error “8001050F”, se produjo cuando la consola trataba de dar el salto del último día de febrero al primero de marzo. 

Caídas de las aplicaciones, corrupción de datos, problemas de rendimiento y escalabilidad, seguridad… son sólo algunas de las pesadillas de toda empresa de software, porque además de las consecuencias lógicas que todo esto conlleva, existen otras indirectas relacionadas como pueden ser despidos, mala imagen, inseguridad en el cliente, etc. Sin embargo, los errores son inevitables. Para que nos hagamos una idea, un estudio reflejó que un programador cometía, de media, 100 defectos por cada KLOC (1000 LOC) líneas de código introducidas. Además, el éxito de las pruebas (detección de errores) es menor del 50% y normalmente, como mencionábamos al principio, se prescinde de las mismas (o de ciertos niveles de estas) a lo largo del desarrollo de un proyecto. Es interesante destacar que IBM realizó un experimento donde se sometió a presión extra a sus programadores durante un período de tiempo controlado, y comprobó que los defectos introducidos en el código se multiplicaban por 5 durante este período de tiempo. Si a este cóctel le sumamos que, las aplicaciones a medida que ganan madurez y funcionalidades, el número de casos de uso a probar se va multiplicando con el tiempo y la probabilidad de cubrir los mismos se va reduciendo, se antoja imposible que sólo con las pruebas podamos ser capaces de entregar un software de calidad.

Entonces… ¿la calidad no se consigue mejorando las pruebas? La respuesta es no, ¿por qué?, porque tras las pruebas no se conseguirá calidad salvo que a ellas llegue algo que ya tenga calidad. Entonces, ¿cuál puede ser una solución? Debemos trabajar con calidad desde el inicio del proyecto. Por supuesto, mejorar las pruebas es un complemento importante, pero es sólo una pieza del rompecabezas. Debemos romper el mito de la proporcionalidad inversa entre calidad y productividad: “Si se incrementa la calidad, la productividad se reduce”. Estos aspectos que deberían ser tomados como complementarios se toman, en general, como antagónicos. 

Hay un gráfico que me gustaría compartir que ilustra en 1994 la reducción de costes y el incremento de la productividad en el primer fabricante mundial de misiles Raytheon en EEUU. En él se puede observar como antes de 1988, el porcentaje de ROI que se reinvierte en subsanar errores introducidos en el código podía incluso acercarse al 50% en algún caso. A partir de 1988 se introducen procesos de calidad, y se puede observar como el porcentaje de dinero destinado a subsanar errores disminuye drásticamente frente al aumento de productividad de sus desarrolladores. Evidentemente, y como mencionamos antes, nunca será 0 ya que tenemos que ser conscientes de que los errores ocurren y siempre existirán, pero debemos mitigarlos en la medida de lo posible. 

No alt text provided for this image

Existen modelos que definen cómo han de ser los procesos de calidad, modelos difíciles de aplicar al principio, y que se componen de distintos niveles de madurez que cada empresa puede ir adaptando progresivamente, me refiero a la ISO 9001 o al modelo CMMI. Sin embargo, este artículo está más enfocado a aquellas empresas que no siguen un modelo definido pero que también quieren incorporar calidad a sus procesos sin perder el norte en el intento.

“Si se incrementa la calidad la productividad se reduce”, estos aspectos que deberían ser tomados como complementarios se toman, en general, como antagónicos. 

Recapitulando, me gustaría recalcar que no nos podemos centrar sólo en una parte del proceso, refiriéndose solamente a las pruebas, sino que debemos centrarnos en aumentar el framework de control a lo largo de todas las etapas que compone el proyecto. No olvidemos que estamos en un mundo agile y que cada iteración debería ser corta y capaz de aportar valor, que nos permita volver atrás sin crear mucho caos y que deje evolucionar el producto mientras obtenemos retroalimentación del mercado. A medida que nos alejamos del mundo “cascada” debemos de tener claro qué modelo de calidad se ha establecido en nuestra empresa y ser capaz de seguirlo y evolucionarlo según la experiencia recabada y sobretodo, escribirlo. Tiene que ser accesible para todos, gobernado por un grupo de personas directamente vinculado a dirección y dependiente exclusivamente de ella (la calidad no debe ser subjetiva) y que sirva de referencia para todos los miembros de la organización. No es necesario seguir un modelo de calidad ISO 9001 o CMMI para tener calidad, la calidad puede empezar por uno mismo.

Recent Posts

Recent Comments

Archives

Categories

Meta

josman Written by:

3 Comments

  1. February 15, 2020
    Reply

    Great content! Super high-quality! Keep it up! 🙂

  2. Gonzalo
    September 7, 2020
    Reply

    Un gran artículo, enhorabuena.

    • josman
      September 7, 2020
      Reply

      Muchas gracias Gonzalo. Intentaré ampliarlo con un segundo a artículo próximamente.

      Un saludo!

Leave a Reply

Your email address will not be published. Required fields are marked *