Explosión del cohete Ariane (1996)

Uno de los acontecimientos que tiene mucho que ver con pruebas de software, es la del fallido lanzamiento del cohete Ariane, este hecho tuvo lugar el 4 de junio de 1996 Lanzado por la Agencia Espacial Europea, este estallo a los 38 segundos después de su despegue. El Ariane explotó en su primer viaje, después de una década de desarrollo, las perdidas se estimaron en aproximadamente 500 millones de dólares.

La causa de la explosión fue un error en el software. Un error no detectado por Falta de control de la calidad del software crítico del cohete. Todo sucedió porque un número real de 64 bits (coma flotante) relacionado con la velocidad horizontal del cohete se convirtió en un entero de 16 bits. Aunque encontrar el error no fue nada fácil.

Ese mismo año, en 1996, a Alain Deutsch, del INRIA, le encargaron averiguar cuál fue el error. Y para ello se puso manos a la obra usando herramientas que automatizaban el control de la calidad del software crítico

Automatizando la evaluación de la calidad del software crítico, del código fuente, encontró el error, y demostró la eficacia del análisis estático. Hoy en día el análisis estático del código es práctica usual, y prácticamente obligatoria, para controlar la calidad del software crítico, y del software embebido.

Recuperado de: https://www.javiergarzas.com/2013/05/top-7-de-errores-informaticos.html.

EXCESO DE RADIACIÓN EN EL THERAC-25 MATÓ A CINCO PACIENTES

Nada peor que un bug que acaba provocando la muerte de personas. Este es el caso de la máquina de radiación Therac-25 que por un error en su software de control suministró un exceso de radiación a varios pacientes provocando la muerte de al menos cinco de ellos.

La causa está en errores en el control de la concurrencia de las diferentes rutinas que se ejecutaban en paralelo, entre ellos un problema “clásico”, una race condition que inducía la máquina a emitir radiación a potencia máxima si una determinada secuencia de eventos inesperados se producía.

Que es una rece condition?

Es una condición de carrera (race condition) ocurre cuando dos o más procesos acceden un recurso compartido sin control, de manera que el resultado combinado de este acceso depende del orden de llegada.

Suponga, por ejemplo, que dos clientes de un banco realizan cada uno una operación en cajeros diferentes al mismo tiempo. El usuario A quiere hacer un depósito. El B un retiro.

El usuario A comienza la transacción y lee su saldo que es 1000. En ese momento pierde su turno de ejecución (y su saldo queda como 1000) y el usuario B inicia el retiro: lee el saldo que es 1000, retira 200 y almacena el nuevo saldo que es 800 y termina. El turno de ejecución regresa al usuario A el cual hace su depósito de 100, quedando saldo = saldo + 100 = 1000 + 100 = 1100. Como se ve, el retiro se perdió y eso le encanta al usuario A y B, pero al banquero no le convino esta transacción. El error pudo ser al revés, quedando el saldo final en 800.

Recuperado de: https://sites.google.com/site/osupaep2010/administracion-de-procesos/problemas-de-concurrencia/condiciones-de-carrera-o-competencia

Recuperado de: https://ingenieriadesoftware.es/grandes-errores-historia-software-informatico/