¿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.
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.
Estos tres ejemplos 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.
- En Japón, un operador de la sociedad Mizuho tecleó erróneamente una orden de venta de 610,000 acciones a 1 yen, en lugar 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, lo que resultó en pérdidas por valor de 225 millones de USD.
- Playstation 3 sufre un error de conexión a nivel mundial por el cambio de mes. El 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 o seguridad son solo 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 de 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 en 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 solo 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 solo una pieza del rompecabezas. Y 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.
El siguiente gráfico ilustra la reducción de costes y el incremento de la productividad en 1994 del primer fabricante mundial de misiles Raytheon en EE.UU. Se puede observar cómo antes de 1988 el porcentaje de ROI que se reinvierte en subsanar errores introducidos en el código podía incluso acercarse a 50 % en algún caso. A partir de 1988 se introducen procesos de calidad, y se puede observar cómo 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.
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.
Recapitulando, me gustaría recalcar que no nos podemos centrar solo en una parte del proceso, las pruebas, sino que debemos centrarnos en aumentar el framework de control a lo largo de todas las etapas que componen 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 capaces de seguirlo y evolucionarlo según la experiencia recabada y, sobre todo, escribirlo.
Tiene que ser accesible para todos, gobernado por un grupo de personas directamente vinculado a la 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. Y para terminar, no es necesario seguir un modelo ISO 9001 o CMMI; la calidad puede empezar por uno mismo.
Este artículo fue publicado por primera vez en el blog de Josman Pérez Expósito.
2 comentarios
Esta muy bien el articulo, sin embargo, ante todo definiría que significa que un software tenga calidad. Sin esta definición es difícil hablar de como gestionar la calidad de un producto.
Gracias por tus comentarios, Jorge. Tienes razón, primero se debería definir qué estándar de calidad entendemos por aceptable, ya que la calidad es subjetiva. De ahí que necesitemos unos marcos de trabajo definidos para poder referirnos a ellos e intentar cuantificarla. En cualquier caso, en el artículo, aunque menciono la ISO 9001 o CMMI, en realidad no quería profundizar tanto en este aspecto y sí en un concepto que, aunque subjetivo, sea mínimo para poder permitirnos hablar de calidad suficiente.