Algunos sistemas informáticos se denominan críticos (safety-critical en inglés) por su relevancia: un fallo en uno de estos sistemas puede tener consecuencias catastróficas, ya sea en pérdida de vidas humanas, daños económicos u otros tipos de pérdidas irreparables. Normalmente, este tipo de sistemas suelen encontrarse en el sector médico, aeroespacial (cohetes, satélites, transbordadores, sondas, …), militar, financiero, energético o de las comunicaciones.

l pantallazo azul: quizás no el más grave, pero uno de los errores más conocidos.

El pantallazo azul: quizás no el error más grave de la informática, pero sí uno de los mensajes de error más conocidos (al menos, por los usuarios de Windows).

Los sistemas críticos requieren de un proceso de desarrollo totalmente orientado a garantizar la calidad del producto final: aquí no valen improvisaciones ni cambios en las especificaciones en el último minuto. Todo tiene que ser probado y verificado para que no haya posibilidad de error. El resultado tiene un nivel de calidad muy superior al que estamos acostumbrados a nivel de usuario pero, como es de suponer, a un coste mucho más elevado. Y obviamente, no siempre se pueden construir usando las mismas herramientas que en una aplicación de usuario. No es casual que los abogados de Sun Microsystems incluyeran este párrafo en los acuerdos de usuario final (EULA) relacionados con la tecnología Java:

La tecnología Java no es tolerante a fallos y no está diseñada, fabricada o prevista para su uso o reventa como mecanismo de control reto de equipamiento en condiciones peligrosas que requiera tolerancia a fallos, como en la gestión de una instalación nuclear, la navegación de aviones o los sistemas de comunicación, tráfico aéreo, mecanismos de soporte vital o sistemas de armamento, donde el fallo de la tecnología Java pudiera conducir directamente a la muerte, daños personales o daño físico o ambiental severo.

Sin embargo, a pesar de todas estas precauciones, en algunas ocasiones los accidentes ocurren. Y no estamos hablando del impreciso “error informático”* que sirve de chivo expiatorio para diluir la responsabilidad ante una metedura de pata colosal. En algunos accidentes, el análisis post-mortem ha permitido identificar la raíz del problema y la causa es un error de software o de hardware. A continuación hablamos de algunas de estas tragedias:

  • El año 1991, durante la primera Guerra del Golfo, un error de redondeo hizo que un sistema de defensa anti-misiles Patriot instalado en Arabia Saudita no detectara un misil atacante que mató a 28 personas.
  • El año 1994, un profesor de matemáticas detectó un error en las operaciones de división de números de punto flotante en el procesador Intel Pentium. A parte de un daño considerable a su imagen, la substitución de los procesadores defectuosos tuvo un coste de 475 millones de dólares.
  • En 1995, el cohete Arianne 5 de la Agencia Espacial Europea sufrió una explosión 40 segundos después del despegue. El error pudo atribuirse a un fallo en un sistema de control inercial, donde un número de punto flotante de 64 bits se convirtió a un entero de 16 bits, causando una excepción por “overflow”. 7 billones de dólares y 10 años de trabajo destruidos en unos segundos.
  • El año 1999, el satélite Mars Climate Orbiter se estrelló contra la superficie de Marte cuando intentaba entrar en órbita, con un coste de 655 millones de dólares. La causa fue un problema en el intercambio de información entre dos subsistemas software del satélite, que estaban utilizando unidades de medida diferentes para representar las distancias (kilómetros y millas).
  • En el año 2012, la firma de inversión Knight Capital Group perdió 440 millones de dólares  (10 millones por minuto) por un error en su software de inversiones financieras, que realizó transacciones sin controlar que estaban generando pérdidas en lugar de beneficios. Es lo que pasa cuando tu código de prueba acaba en el entorno de producción.

Todos estos errores han tenido consecuencias muy severas. Pero puede que aún haya otro “error” informático, en este caso de diseño, con consecuencias mucho más profundas. Se trata de la decisión de codificar los strings como una cadena de caracteres acabados en “null” (null-terminated string en inglés) en el lenguaje C. Se prefirió dicha estrategia en lugar de utilizar las cadenas “tipo Pascal”, donde las primeras posiciones indican explícitamente el  número de caracteres que contiene la cadena. A pesar de sus grandes ventajas, esta decisión ha conllevado una gran cantidad de problemas no previstos en su día: bugs, ataques de buffer overflow, … Haciendo números, quizás la suma de todos estos problemas ha tenido (y tendrá) un coste superior a todas las catástrofes mencionadas.

Por último, aunque no sea un sistema crítico ni siquiera un error (más bien un síntoma de otros errores), hay un problema que merece una mención especial: el aborrecido pantallazo azul (Blue Screen of Death o BSOD, en inglés). Esta pantalla aparece ante un fallo irrecuperable del sistema en algunas versiones de Windows… ¡hasta en Windows 8!. La frecuencia de su aparición la han elevado a la categoría de hito cultural con su propia entrada en Wikipedia.

* Igualito que el típico “error humano” cuando el causante ha fallecido durante el accidente: es fascinante lo rápido que se le atribuye la responsabilidad a algo o alguien que no puede protestar.

via iNFoRMáTiCa++ http://ift.tt/1jQ7W1I

Advertisements