archivo

Archivo de la etiqueta: Edsger Dijkstra

En el año 1973, un informe de Barry Boehm, predijo que los costes de software terminarían sobrepasando los costes derivados del hardware.

En la década de los sesenta Edsger Dijkstra introdujo el concepto de crisis del software.

Este cambio de tendencia que hoy en día se puede pensar que era evidente, en aquellos momentos no lo era, ni mucho menos. De hecho el Departamento de Defensa de los Estados Unidos (a la vanguardia entonces del mundo TIC) esperaba justamente el resultado opuesto en el informe de Boehm y como consecuencia del mismo se inició un cambio de enfoque en las inversiones que realizaban, centradas en conseguir ordenadores centrales de cada vez más potencia.

Faltaban años todavía para el boom de los ordenadores personales (si bien desde años antes, ya existían determinados modelos que eran considerados de esta manera), dominaban los mainframes y el desarrollo de software era todavía muy artesanal y orientado a problemas concretos en la plataforma en la que se trabajaba (más que a soluciones reutilizables en diferentes entornos).

Los problemas derivados del desarrollo de software ya podían ser visibles entonces, de hecho, persisten actualmente. Tal vez la diferencia es que hoy en día se tienen más identificados e investigados los problemas y se manejan posibles soluciones, sin embargo su adecuada aplicación depende de muchos factores (entre los que destaca por encima de todos, el humano) y eso es lo que condiciona que todavía nos encontremos con la situación en la que nos encontramos.

La rigurosidad del testing debe depender del nivel de criticidad del sistema que se va a poner en producción, ya sea en primera instancia o como consecuencia de una evolución del mismo. Esta rigurosidad se tendrá que ver reflejada en todas las etapas de desarrollo del software y tiene como objetivo evitar que lleguen a producción errores que sean críticos para el sistema y que puedan provocar un coste en vidas humanas o unas pérdidas económicas que puedan poner en jaque la subsistencia de una organización.

Esta rigurosidad estará relacionada con el número de casos de prueba a los que se somete el software, desde la misma definición de las pruebas unitarias a las pruebas de carácter funcional, así como a la propia verificación de la bondad de la técnica utilizada.

Hoy en día existen implantaciones software en sistemas empotrados, sistemas de información, etc… que manejan todo tipo de cosas. Como cada vez está más extendida la automatización, cada vez son mayores los sectores donde el software maneja funciones críticas. Incluso funciones que se pueden considerar no críticas, como por ejemplo la web de una organización, cada vez tiene un mayor grado de criticidad tanto en cuanto la forma en que muchos clientes acceden a la misma es través de Internet.

Por tanto, cada día que pasa es más importante que un producto llegue a producción tras superar un umbral de calidad específico definido para el mismo que permita tener confianza en una reducción importante de la probabilidad de que se produzcan errores críticos.

Hacer un buen testing no es sencillo, así como seleccionar el conjunto finito de casos que se va a estudiar (incrementar la cardinalidad de ese conjunto depende de factores económicos y el presupuesto debería estar ajustado a la criticidad del producto), ya que de el mismo depende que posibles errores importantes se puedan colar en producción.

Sobre esto es conveniente recordar una cita muy conocida de Edsger Wybe Dijkstra en la que comenta que: “El testing de los programas puede ser muy efectivo para mostrar la presencia de errores, sin embargo resulta inadecuado para mostrar su ausencia”.

Ed Yourdon destaca dos variables como causantes de que la crisis del software siga hoy tan vigente como cuando Edsger Dijkstra hizo referencia a ella en la década de los 60.

Por un lado vuelve a destacar la falta de habilidades negociadoras que, por regla general, existe en quiénes negocian los contratos y las condiciones de los proyectos, de manera que se aceptan unos parámetros presupuestarios, de plazos y de calidad muy difíciles de cumplir y por otro el hecho de que las nuevas generaciones de desarrolladores no presten la atención que se merece a la experiencia de los más veteranos, lo que provoca que de manera reiterada se vuelva a caer en los mismos errores.

Yo llevo gestionando proyectos software desde hace ocho años y mientras que la tecnología avanza a un ritmo vertiginoso, los problemas de los proyectos de hoy son los mismos que los de ayer.