Coste de los errores en proyectos de software

0

En un proyecto de desarrollo hay muchos tipos de errores que se pueden cometer. Siempre solemos pensar que los errores en proyectos de software vienen porque un programador ha cometido un fallo. Pero si abrimos un poco la mente, veremos que hay muchos tipos de errores. Y además, dependiendo de cuando los detectemos el coste de solventarlos es muy diferente.

Tipos de Errores

Vamos a definir un error como cualquier cosa que haga que nuestro software no cumpla con las expectativas del cliente (ya sea interno o externo). Así podemos tener errores de muchos tipos. Desde los obvios errores de programación, hasta tomar mal los requisitos.

Una clasificación muy común para el origen de los errores es la siguiente:

  • Requisitos: No entender lo que pide negocio. O negocio no saber lo que pide. O que los requisitos se documentan mal y por ello el programador hace algo que no es lo correcto. O cualquier otro tipo de error relacionado con requisitos.
  • Diseño: Errores en el planteamiento del diseño de la aplicación que luego llevan a cambios cuando son detectados.
  • Código: Errores directamente en la programación. No porque el programador lo entienda mal, sino porque introduce un bug.
  • Otros: Errores por culpa del control de versiones, o por otros motivos que no están clasificados en los tres anteriores.

James Martin, publicó en 1984 “An Information Systems Manisfesto”, en el que calculaba el porcentaje de errores según la clasificación anterior. Los datos que se obtuvieron son demoledores:

  • Más de la mitad de los errores provienen de requisitos. Y más de la mitad de estos vienen por documentarlos mal y luego entenderse mal.
  • Menos del 10% vienen de errores de código.

Por lo tanto la mayoría de los errores vienen de las primeras fases del proyecto. Así que detectarlos lo antes posible es fundamental.

El estudio tiene ya su antiguedad, y seguro que los porcentajes han cambiado, pero en casi toda la bibliografía se sigue aceptando la frase de “Más de la mitad de los errores son por culpa de los requisitos”.

Coste de los errores

El coste de los errores depende sobretodo del momento en el que se detectan. Un error detectado en el momento en el que ocurre, tiene un coste muy bajo. El coste crece cuando pasa más tiempo entre que se produce y se detecta. El peor escenario posible es un error introducido al comenzar el proyecto y detectado una vez ya entregado. Esto en una metodología en cascada clásica no era tan raro de ver. De hecho era desafortunadamente algo común. Hablamos de un error en la toma de requisitos que se detecta después de puesto en producción. Estos errores pueden tener unos costes asombrosos, teniendo que rehacer mucho código.

En “Error Cost Escalation Through the Project Life Cycle” (Stecklein et al.), un artículo de la NASA, hace un estudio profundo del coste de los errores dependiendo del momento en el que se detectan. Las cifras que se entregan son escalofriantes:

  • Un error de software detectado al final del proyecto es aproximadamente 100 veces más caro que uno detectado durante la toma de requisitos.
  • Un error de software detectado en producción puede llegar a ser hasta 1000 veces más caro que uno detectado durante la toma de requisitos.
  • Si lo errores están relacionados con los sistemas, el factor de coste entre un error detectado al tomar requisitos y en producción puede llegar hasta más de 1.500 veces.

A resultados parecidos llega IBM, que indica que un error detectado durante el diseño es cien veces más barato de solventar que uno detectado en producción.

El peor error de todos

Los errores que provienen de la toma de requisitos, si no se tienen medidas puestas en marcha, tienden a perdurar hasta las últimas fases del proyecto. Por lo tanto estamos diciendo que los errores más probables son los que tienen a ser también los más costosos. Esto es un cóctel muy peligroso. De hecho James Martin en el mismo libro llegaba a la conclusión de que el 85% de los costes de solventar errores provenían de mala toma de requisitos.

Conclusiones

Si no tomamos cartas en el asunto nos encontraremos con que la mayoría de los errores vienen de la toma de requisitos. Y éstos son también los más caros porque suelen detectarse al final. ¿Cómo podemos ponerle remedio?

Hay dos caminos para reducir el coste de estos errores:

  1. Cometer menos errores: Lo que viene siendo dedicar más tiempo a la toma de requisitos. Esta era la solución clásica.
  2. Detectar antes los errores: Aquí las metodologías ágiles, las entregas iterativas, o las estrategias de Shift Left, pueden ser de utilidad. Esta es la tendencia actual. Es decir, asumimos que se cometerán errores en las primeras fases, pero en vez de invertir en evitarlos, invertimos en detectarlos lo antes posible.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios