Está en la página 1de 15

Ingeniería informática

Éxitos y Fracasos en la Ingeniería Informática

Juan Jose Ortiz Perez


© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

Facultad De Ingeniería Informática


Fundación Universitaria Internacional de la Rioja – UNIR Colombia
Aritmética En Computadores
Ing. Javier Ricardo Luna Pineda
Septiembre 2021
Ingeniería informática

Introducción

El presente trabajo contiene la selección de un producto (aplicación) exitoso y otro


fracasado en Colombia y el mundo, sobre la línea de Ingeniería Informática, desarrollados en
la misma época histórica.

De igual manera se establece que proceso siguieron las personas que construyeron los
productos exitosos, contrastado con el producto que fracaso a partir del análisis de los pasos
del proceso en cada uno de ellos.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)
Ingeniería informática

Tabla de Contenido

Éxitos y Fracasos en la Ingeniería Informática ..................................................................... 4


Producto de Éxito - WhatsApp ............................................................................................. 5
Producto Fracaso 1 - Knight Capital Group ........................................................................ 6
Producto Fracaso 2 - Therac-25 ............................................................................................ 9
Referencias.............................................................................................................................. 15
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)
Ingeniería informática

Éxitos y Fracasos en la Ingeniería Informática

En los sistemas de información se pueden presentar errores, estos pueden ser de


muchas modalidades y distintas especificaciones, de tal manera que, los costos de estos
errores mayoritariamente son muy altos monetariamente; los sistemas de información están
inmersos en casi todos los eventos de la sociedad y el entorno, por eso afecta tanto cuando las
cosas no resultan como lo esperamos.

A continuación se presenta un caso de éxito en el software a nivel mundial y dos casos de


fracasos que llevaron a pérdidas descomunales.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)
Ingeniería informática

Producto de Éxito - WhatsApp

Según la historia de WhatsApp, este inició en 2009 y desde entonces es una


aplicación que no ha dejado de crecer y cada vez cuenta con más éxito. Esta, es una
aplicación de mensajería instantánea que funciona en multiplataforma permitiendo a los
usuarios con sistema iOS o Android, intercambiar mensajes de texto, imágenes, vídeo y audio
de forma gratuita; además de la mensajería básica, WhatsApp ofrece opciones de chat en
grupo, poder compartir contactos, archivos y ubicación

Para utilizarla solo se necesita tener un número de celular y un servicio de datos o una
conexión WiFi. Con los años ha ido implementando nuevas funciones útiles que, muchos
desconocemos.

Oficialmente, WhatsApp se creó en el 2009, gracias a la idea de uno de sus fundadores, Jan
Koum. En primera instancia, él quería crear una aplicación que le permitiera enviar
notificaciones a amigos, pero luego la idea cambió y el objetivo se convirtió en crear una
aplicación de mensajería instantánea. Brian Acton, quien sería el co fundador de la
aplicación, se involucró en el proyecto gracias a Koum, quien después de un partido de
Frisbee, le pidió que fuera su socio y que juntos pusieran en marcha el proyecto. Algo a lo
que él en principio no estaba muy seguro.
Para el otoño de 2009, WhatsApp no tuvo un crecimiento significativo, pero Koum
convenció a Acton para que se uniera a él. Cuando Acton quiso empezar a buscar un trabajo
fijo, porque no veía frutos del proyecto, Koum le dijo que le diera unos meses para que la
aplicación tenga mayor demanda y llegaran al éxito.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

En octubre de 2009, Acton contactó a varios viejos amigos de Yahoo!, contándoles su


proyecto y reunió us$ 250,000 dólares en fondos iniciales. Esto sirvió para que Acton sea
nombrado como cofundador y reciba acciones de la empresa.

Actualmente cuentan con más de 2000 millones de usuarios a nivel mundial y es propiedad
de Mark Zuckerberg, el creador de Facebook. Dicha compra se dio en el año 2014, luego de
que Zuckerberg cerrara el trato con una suma total de $ 19 mil millones de dólares.
Ingeniería informática

Producto Fracaso 1 - Knight Capital Group

El 1 de agosto de 2012, Knight Capital implementó una nueva actualización de software en


sus servidores de producción. Alrededor de las 08:01 a. M., El personal de la empresa recibió
97 notificaciones por correo electrónico que indicaban que Power Peg, un sistema interno
desaparecido que se usó por última vez en 2003, estaba configurado incorrectamente.

Esta fue la primera señal de advertencia.

El daño

A las 09:00 AM, la Bolsa de Valores de Nueva York abrió para la negociación y el primer
inversor minorista del día de Knight Capital colocó una instrucción para comprar o vender
sus participaciones de inversión.

Solo 45 minutos después, los servidores de Knight Capital habían ejecutado 4 millones de
transacciones, perdiendo a la compañía $ 460 millones y colocándola al borde de la
bancarrota. Algunas acciones de la Bolsa de Nueva York se dispararon más de un 300%, ya
que los algoritmos de negociación de alta frecuencia de otras empresas aprovecharon el error.

Finalmente, Knight Capital fue multada con $ 12 millones adicionales por la Comisión de
Bolsa de Valores, debido a varias violaciones de las regulaciones de gestión de riesgos
financieros.

Qué salió mal


© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

Bolsas de valores 101

Una bolsa de valores funciona emparejando a una persona que quiere comprar una acción con
otra persona que quiere vender esa acción. El vendedor indicará un precio de oferta, que es
cuánto está dispuesto a vender, y el comprador indicará un precio de oferta, que es cuánto
está dispuesto a pagar. La diferencia entre estos dos valores se conoce como diferencial de
oferta / demanda y, por lo general, ronda unos pocos centavos.
Ingeniería informática

La sabiduría financiera convencional también establece que una persona debe comprar
acciones cuando el precio es bajo y vender cuando el precio es alto.

Desafortunadamente, un algoritmo implementado en uno de los servidores de producción de


Knight fue diseñado para hacer exactamente lo contrario, lo más rápido posible. El programa
Power Peg fue diseñado para comprar una acción a su precio de venta y luego venderla
inmediatamente nuevamente al precio de oferta, perdiendo el valor del diferencial. Aunque
unos pocos centavos pueden no parecer mucho, cuando una computadora ejecuta miles de
operaciones por segundo, rápidamente se acumulan pérdidas catastróficas.

Compra caro, vende bajo


En un entorno de prueba, Power Peg aumentaría el precio de las acciones, lo que permitiría a
QA verificar que otras características del software funcionaran correctamente.

En un entorno de producción, Power Peg daría como resultado que los empleados de nivel C
pasaran sus fines de semana buscando frenéticamente inversores de Wall Street para cubrir
un agujero negro multimillonario que acaba de aparecer en el presupuesto.

Causa de la falla

La causa del fallo se debió a múltiples factores. Sin embargo, uno de los más importantes fue
que una bandera que se había utilizado anteriormente para habilitar Power Peg se reutilizó
para su uso en una nueva funcionalidad. Esto significaba que el programa creía que estaba en
un entorno de prueba y ejecutaba operaciones lo más rápido posible, sin preocuparse por
perder el valor del diferencial.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

En segundo lugar, el equipo de desarrollo no pudo implementar el programa actualizado en


uno de los ocho servidores de producción. Este servidor ahora tenía una versión
desactualizada del software y una bandera que indicaba que Power Peg debería estar
habilitado.

Finalmente, Power Peg había estado obsoleto desde 2003, pero aún permanecía en la base de
código unos ocho años después. En 2005, se modificó el código Power Peg que
inadvertidamente desactivó los controles de seguridad que habrían evitado tal escenario. Sin
embargo, esta actualización se implementó en un sistema de producción en ese momento, a
Ingeniería informática

pesar de que no se hizo ningún esfuerzo para verificar que la funcionalidad Power Peg aún
funcionaba.

Código muerto

El informe de la Comisión de Intercambio de Seguridad destacó muchos otros factores. Los


factores más condenatorios son que no hubo una revisión formal del código o un proceso de
control de calidad, y que no se implementaron procesos para verificar que el software se haya
implementado correctamente. Además, no se establecieron umbrales de capital
preestablecidos para detener el comercio automatizado después de una cierta cantidad de
pérdidas.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)
Ingeniería informática

Producto Fracaso 2 - Therac-25

Causa Sobredosis de Radiación

Therac-25 es un ejemplo extremo de lo que puede salir mal con los sistemas de software y las
devastadoras consecuencias que los errores pueden tener en la gente normal.

Aunque la mayoría de nosotros no trabajaremos en sistemas críticos para la seguridad, los


errores de software aún pueden tener un impacto significativo en nuestros usuarios. La
mayoría de nosotros habrá experimentado una falla en el software durante una presentación
de diapositivas importante, una aplicación en nuestros teléfonos que falla en medio de una
actividad o una filtración de datos que filtra nuestras credenciales a todo Internet.

¿Qué es lo peor que podría salir mal en su aplicación?

Hace setenta años, Grace Hopper descubrió el primer error informático: una polilla estaba
atascada entre los relés de la computadora Harvard Mark II en la que estaba trabajando. La
noción de errores se describió anteriormente en otros campos, pero el descubrimiento de la
polilla fue el primer uso del término "depuración" en el campo de las computadoras.

El Therac-25 era una máquina de radioterapia fabricada por AECL en los años 80, que
ofrecía un revolucionario modo de tratamiento dual. También fue diseñado desde el principio
para utilizar sistemas de seguridad basados en software en lugar de controles de hardware.

La eliminación de estas medidas de seguridad de hardware tuvo consecuencias trágicas, ya


© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

que las condiciones de carrera en el código base provocaron la muerte de tres pacientes y
causaron lesiones debilitantes a al menos otros tres pacientes. El fabricante finalmente se
convirtió en el blanco de varias demandas de las familias de las víctimas y quedó sujeto a un
retiro de Clase I de la FDA, una situación que solo ocurre si la agencia cree que existe un
riesgo significativo de muerte o lesiones graves a través del uso continuo de un dispositivo
médico.
Ingeniería informática

¿Qué es la Radiación?

La radiación es tóxica para las células vivas y, en cantidades suficientemente grandes, hará
que mueran. Por ejemplo, las células cancerosas pueden morir con una dosis de radiación que
se dirige específicamente al área afectada. Sin embargo, se debe tener cuidado para
asegurarse de que la dosis no sea demasiado grande, ya que esto mataría el tejido circundante
sano y podría provocar lesiones graves o la muerte del paciente.

El Therac-25 era un acelerador lineal con dos modos de funcionamiento. En primer lugar,
podría disparar un rayo de electrones de baja energía de flujo, que no penetran mucho en el
cuerpo y, por lo tanto, son adecuados para matar tejidos superficiales, como en el cáncer de
piel. El segundo modo de funcionamiento emite radiación a través de un haz de fotones de
rayos X de mayor energía. Estas partículas viajan más lejos y son las más adecuadas para
tratar tejidos más profundos, como el cáncer de pulmón.

Diseño Revolucionario

El funcionamiento en modo dual fue realmente revolucionario en ese momento. Los


hospitales no necesitarían mantener dos máquinas separadas, lo que reduciría sus costos de
mantenimiento, y la logística podría simplificarse, ya que los pacientes no necesitarían ser
trasladados de una habitación a otra.

El modo de baja potencia utiliza imanes de barrido para difundir el haz de electrones,
mientras que el modo de alta potencia se activa girando cuatro componentes en el haz. Este
proceso tardó alrededor de 8 segundos en completarse y, luego, se propagaría y dirigiría un
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

rayo de la fuerza adecuada hacia su objetivo.

Software, no Hardware, para Controles de Seguridad

Therac-25 se basó en controles de software para cambiar entre modos, en lugar de hardware
físico. Los modelos anteriores usaban circuitos separados para monitorear la intensidad de la
radiación y enclavamientos de hardware para garantizar que los imanes esparcidos estuvieran
colocados correctamente. El uso de software en su lugar reduciría en teoría la complejidad y
reduciría los costos de fabricación.
Ingeniería informática

Mensaje de Error 54 de Avería

En el transcurso de varias semanas, un técnico de radiología se había vuelto muy rápido


escribiendo comandos en la máquina Therac-25. Un fatídico día, accidentalmente ingresó 'x'
para X-Ray en lugar de 'e' para Electron, por lo que presionó la tecla hacia arriba para elegir
el modo correcto. Al iniciar el programa, la máquina se apagó, mostrando el error "Mal
funcionamiento 54". Debido a la frecuencia con la que ocurrieron otras fallas y que la “pausa
del tratamiento” generalmente indicaba un problema de baja prioridad, el técnico reanudó el
tratamiento.

El paciente estaba recibiendo su noveno tratamiento e inmediatamente supo que algo había
ido terriblemente mal. Informó que escuchó un zumbido, que luego se determinó que era la
máquina que emitía radiación a su máxima capacidad, y sintió como si alguien hubiera
vertido café caliente sobre su baño.
Después de unos días, el paciente sufrió parálisis debido a la sobreexposición a la radiación y
finalmente murió a causa de más complicaciones. El fabricante creía que la causa principal se
debía a una descarga eléctrica, y la máquina se volvió a poner en servicio a pesar de que una
compañía eléctrica verificó que este no era el problema y que se habían informado incidentes
similares a AECL anteriormente.

Reproduciendo el error

El error finalmente se reprodujo cuando el mismo técnico operó la máquina en otro paciente,
que también murió por sobreexposición a la radiación. El físico del hospital estaba
convencido de que había un problema con la máquina que esparcía imanes y, después de
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

muchas pruebas y errores, logró reproducir el problema al realizar la entrada de datos con una
rapidez increíble.

La dosis de radiación administrada fue tan grande que el físico tuvo que ajustar la
sensibilidad de su equipo de detección. La dosis estaba en el rango de 10-20,000 rads, que era
más de 100 veces la dosis esperada y más que suficiente para matar a un adulto.
Ingeniería informática

Condiciones de carrera

La intención del operador era utilizar el rayo de baja potencia, mientras que en realidad el
rayo de alta potencia se había utilizado sin los imanes de expansión en su lugar, entregando
una dosis mucho más alta de lo esperado. Esto se debió a una condición de carrera dentro del
código base, que en realidad había estado presente en el modelo anterior, Therac-20, pero que
se había evitado mediante controles de seguridad de hardware.

El software constaba de varias rutinas que se ejecutaban al mismo tiempo. Tanto la rutina de
entrada de datos como la del controlador de teclado compartían una sola variable, que
registraba si el técnico había completado la introducción de comandos.

Una vez que la fase de entrada de datos se marcó como completa, comenzó la fase de
configuración del imán. Sin embargo, si se aplicó una secuencia específica de ediciones en la
fase de Entrada de datos durante la fase de configuración del imán de 8 segundos, la
configuración no se aplicó al hardware de la máquina, debido al valor de la variable de
finalización. La interfaz de usuario mostraría el modo incorrecto al usuario, quien confirmaría
el tratamiento potencialmente letal.

En realidad, este error siempre había estado presente en el código base de Therac-20, un
hecho que solo se descubrió 2 meses después de la retirada de la FDA. Las características de
seguridad del hardware en ese modelo significaban que la condición de error nunca se había
detectado, y el código se copió al Therac-25 con la suposición cultural de que había sido
probado en batalla.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

Desbordamiento de bytes

Un error de concurrencia adicional provocó el último incidente conocido, que se debió a un


desbordamiento en una variable compartida de un byte.

Antes de disparar un haz de electrones, el operador debe colocar la máquina con precisión
para apuntar al área de tratamiento. A continuación, el operador verifica los parámetros
mediante las pulsaciones de teclas y se pulsa "set" para mover el hardware a la posición
correcta.
Ingeniería informática

Durante la verificación, la variable Class3 determina si el hardware está configurado


correctamente. Un valor distinto de cero indica falla, mientras que un valor cero indica que
todo está configurado correctamente y que el tratamiento puede continuar.

Debido a que el código de configuración se ejecutó cientos de veces y un byte solo puede
contener 255 valores posibles, en el intento 256 de configuración, la variable compartida se
establecería en 0.

Si en este momento exacto, el operador tenía la mala suerte de presionar el botón


"configurar", el programa continuaría por una ruta de código que dispararía un rayo de rayos
X concentrado, ya que la variable Class3 indicaría que el hardware se configuró
correctamente. Esto sucedió y administró una dosis letal de radiación al paciente.

Secuelas

Peor aún, un memorando interno de la FDA declaró que AECL no tenía especificaciones
formales de software o plan de prueba para su dispositivo.

Además, el software no fue evaluado por evaluadores independientes, lo que puede haber
ayudado a combatir los prejuicios culturales dentro de la organización. También se utilizó un
simulador de hardware para la mayor parte del desarrollo, debido a las dificultades de probar
de forma segura el hardware real.

Para llevar
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

Hay varios mensajes para llevar de todo el asunto.

En primer lugar, los usuarios ignorarán los mensajes de error crípticos, especialmente si
ocurren con frecuencia. “Mal funcionamiento 54” no transmite la severidad del estado de la
máquina, y el usuario promedio ciertamente no consultará el manual físico adjunto para
averiguar qué significa.
Ingeniería informática

En segundo lugar, la usabilidad a veces puede obstaculizar la seguridad. En este caso hubiera
sido preferible, aunque ciertamente molesto, haber obligado al usuario a volver a ingresar
comandos en el caso de que cometieran un error, y revisar los comandos antes de ejecutarlos.

Una nota final es que en los sistemas críticos para la seguridad, el código debe estar sujeto a
un análisis formal de partes independientes de quienes lo desarrollaron. También se necesita
algún nivel de prueba automatizada a nivel de unidad, en lugar de solo probar el sistema
como un todo.
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)
Ingeniería informática

Referencias

LYNCH. 04 de septiembre de 2021. Los peores errores informáticos de la historia:


condiciones de carrera en Therac-25. https://www.bugsnag.com/blog/bug-day-race-
condition-therac-25.

LYNCH. 04 de septiembre de 2021. Los peores errores informáticos de la historia: pérdida


de 460 millones de dólares en 45 minutos. https://www.bugsnag.com/blog/bug-day-460m-
loss
© Fundación Universitaria Internacional de La Rioja (UNIR Colombia)

También podría gustarte