Crisis del software

Existen múltiples causas que originan la crisis del software. Una de ellas es que el desarrollo de un software es un proceso relativamente “nuevo”, del cual no se tiene personal lo suficientemente capacitado, debido a una pobre implementación de los procesos más organizados. Por otro lado, debido a que el software es el conjunto de programas o instrucciones de una computadora, y que por lo tanto, no es un elemento de carácter físico; es poco probable que resulte exitoso el segundo primer intento de elaboración, ya que el personal encargado de su realización no posee total claridad de los requerimientos de su cliente, lo que a su vez, vuelve en exceso complicado hacer un diseño detallado de requerimientos, pues es importante mencionar que su calidad se mide con respecto a su funcionamiento.

En muchos casos la automatización representa retribuciones económicas directas, pero para casos específicos puede ser difícil notar una diferencia ya que la retribución que se obtiene no es precisamente monetaria, sino que puede aumentar la velocidad de producción o volverla más flexible. En cualquier situación el desarrollo de software es una actividad capaz de añadir valores.

En 1981 Barry Boehm estimó que el costo total del software en Estados Unidos fue del 2% del producto interno bruto en 1980 lo que representa $40 billones. Después en 1985 el costo total se elevó a $70 billones en Estados Unidos y $140 billones en todo el mundo. Para 1999 Boehm y Sullivan estimaron que el costo en 1998 aumentó a los $300 - 400 billones en Estados Unidos y casi el doble a nivel mundial. El costo total del software es una parte muy importante ya que no solo involucra el desarrollo del mismo, sino que también contempla el costo del mantenimiento una vez que se entrega y se encuentra funcionando. Es aquí donde se pueden encontrar la mayoría de los problemas ya que generalmente los proyectos carecían de una planeación y se trabajaba con mucha informalidad.[2]

En los años ‘60s las personas empezaban a notar que las técnicas que se utilizaban para programar habían quedado obsoletas, incluso algunos todavía creían que la programación de software debía considerarse un arte, como una actividad que debía ser más creativa que tradicional y disciplinada. Otro de los problemas es que muchos programadores no obtuvieron una educación formal y por lo tanto habían aprendido experimentando.

En conjunto provocaban que los resultados se obtuvieran pasada la fecha de entrega, los programas no funcionaban de manera correcta, era difícil realizar cambios y se excedían los plazos y costos planeados. La mayor parte de los errores se encuentran en una mala redacción del código (38.33%), le siguen los errores de diseño (24.17%), los de documentación (13.33%), de requerimientos (12.50%) y de correcciones mal implementadas (11.67%). Estos porcentajes nos dicen que el mayor número de errores provienen de la redacción del código, pero un error generado en la recolección de requerimientos puede propagarse al diseño y al código, incluso puede no aparecer hasta después de haber entregado el producto. En la mayoría de los casos es más barato arreglar un error en el código que arreglar un error de requerimientos ya que este afecta de manera directa el diseño y el código. Una buena práctica sería aplicar actividades que prevengan errores de requerimientos, desgraciadamente se dedica muy poco tiempo a la recolección de requerimientos y las especificaciones.[3]

Para evitar errores de este tipo lo mejor que se puede hacer es realizar revisiones formales ya que cuantos más errores se puedan encontrar antes de escribir el código menos impacto tendrán en el mismo, la fase de pruebas y en la respectiva documentación. Muchas fallas en proyectos son atribuidas a un código mal escrito, pero en muchos casos estas acusaciones no están bien fundamentadas o el software no es completamente culpable. A veces los errores tienen un origen más simple, un mal manejo del software, mala comunicación o falta de entrenamiento.

Tanto en sus inicios, como en la época actual, una gran cantidad de proyectos de software tuvieron diversos problemas con respecto al tiempo y presupuesto que se le había estimado, causando accidentes que más allá de costos, involucraban daños a propiedades, y en el peor de los casos, la muerte de personas.

Algunos ejemplos son:

• Accidente de un F-18 (1986): En abril de 1986 un avión de combate se estrelló por culpa de un giro descontrolado atribuido a una expresión “if then”, para la cual no había una expresión “else”, debido a que los desarrolladores del software lo consideraron innecesario.[4]

• Muertes por el Therac-25 (1985-1987): El Therac-25 fue una máquina de radioterapia que causó la muerte de varios pacientes en diversos hospitales de Estados Unidos y Canadá, debido a las radiaciones de alto poder aplicadas sin control, las cuales fueron atribuidas a la falta de control de calidad del software médico.[4]

• Sobrecosto, retraso y cancelación en el sistema del Bank of America (1986): En mayo del año 1986, este banco invirtió 23 millones de dólares en un sistema computarizado llamado MasterNet, el cual servía para contabilidad y reportes de fideicomisos. No obstante, para que el sistema funcionara, se tuvo que invertir 60 millones de dólares más, por lo que finalmente el sistema fue cancelado.[4]