Error de programación - Software bug

Un error de software es un error, defecto o falla en un programa o sistema informático que hace que produzca un resultado incorrecto o inesperado, o que se comporte de forma no deseada. El proceso de encontrar y corregir errores se denomina " depuración " y, a menudo, utiliza técnicas o herramientas formales para identificar errores y, desde la década de 1950, algunos sistemas informáticos se han diseñado para disuadir, detectar o corregir automáticamente varios errores informáticos durante las operaciones.

La mayoría de los errores surgen de errores y errores cometidos en el diseño de un programa o su código fuente , o en los componentes y sistemas operativos utilizados por dichos programas. Algunos son causados ​​por compiladores que producen código incorrecto. Un programa que contiene muchos errores y/o errores que interfieren seriamente con su funcionalidad se dice que tiene errores (defectuoso). Los errores pueden desencadenar errores que pueden tener efectos dominó . Los errores pueden tener efectos sutiles o hacer que el programa se bloquee o congele la computadora. Otros errores califican como errores de seguridad y pueden, por ejemplo, permitir que un usuario malintencionado eluda los controles de acceso para obtener privilegios no autorizados .

Algunos errores de software se han relacionado con desastres. Los errores en el código que controlaba la máquina de radioterapia Therac-25 fueron directamente responsables de las muertes de pacientes en la década de 1980. En 1996, el prototipo de cohete Ariane 5 de la Agencia Espacial Europea , valorado en mil millones de dólares , tuvo que ser destruido menos de un minuto después del lanzamiento debido a un error en el programa informático de orientación a bordo. En junio de 1994, un helicóptero Chinook de la Royal Air Force se estrelló contra Mull of Kintyre , matando a 29. Esto inicialmente se descartó como un error del piloto, pero una investigación realizada por Computer Weekly convenció a una investigación de la Cámara de los Lores de que pudo haber sido causado por un error de software. en la computadora de control del motor de la aeronave .

En 2002, un estudio encargado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de EE . UU. concluyó que "los errores o errores de software son tan frecuentes y perjudiciales que le cuestan a la economía de EE. por ciento del producto interno bruto".

Historia

La palabra bugge del inglés medio es la base de los términos " bugbear " y " bugaboo " como términos usados ​​para un monstruo.

El término "error" para describir defectos ha sido parte de la jerga de ingeniería desde la década de 1870 y es anterior a las computadoras electrónicas y el software de computadora; es posible que se haya utilizado originalmente en ingeniería de hardware para describir fallas mecánicas. Por ejemplo, Thomas Edison escribió las siguientes palabras en una carta a un asociado en 1878:

Así ha sido en todos mis inventos. El primer paso es una intuición, y viene con un estallido, luego surgen las dificultades: esta cosa cede y [es] entonces cuando los "Bichos", como se llaman esas pequeñas fallas y dificultades, se muestran y meses de intensa observación, estudio. y el trabajo son requisitos antes de que se alcance el éxito o el fracaso comercial.

Baffle Ball , el primer juego de pinball mecánico , se anunció como "libre de errores" en 1931. Los problemas con el equipo militar durante la Segunda Guerra Mundial se denominaron errores (o fallas ). En un libro publicado en 1942, Louise Dickinson Rich , hablando de una máquina cortadora de hielo motorizada , dijo: "El corte de hielo se suspendió hasta que se pudiera traer al creador para quitarle los bichos a su amado".

Isaac Asimov usó el término "bicho" para relacionar problemas con un robot en su cuento " Catch That Rabbit ", publicado en 1944.

Una página del registro de la computadora electromecánica Harvard Mark II , que muestra una polilla muerta que se eliminó del dispositivo.

El término "error" fue utilizado en un relato por la pionera de la informática Grace Hopper , quien dio a conocer la causa de un mal funcionamiento en una de las primeras computadoras electromecánicas. Una versión típica de la historia es:

En 1946, cuando Hopper fue liberada del servicio activo, se unió a la Facultad de Harvard en el Laboratorio de Computación, donde continuó su trabajo en Mark II y Mark III . Los operadores rastrearon un error en el Mark II hasta una polilla atrapada en un relé, acuñando el término error . Este error se eliminó cuidadosamente y se grabó en el libro de registro. Partiendo del primer error, hoy llamamos error a los errores o fallas en un programa .

Hopper no encontró el error, como reconoció fácilmente. La fecha en el libro de registro era el 9 de septiembre de 1947. Los operadores que lo encontraron, incluido William "Bill" Burke, más tarde del Laboratorio de Armas Navales , Dahlgren, Virginia , estaban familiarizados con el término de ingeniería y mantuvieron divertido el insecto con la notación "Primer caso real de error encontrado". A Hopper le encantaba contar la historia. Este libro de registro, completo con polilla adjunta, es parte de la colección del Museo Nacional Smithsonian de Historia Estadounidense .

El término relacionado " depuración " también parece ser anterior a su uso en informática: la etimología de la palabra del Oxford English Dictionary contiene una certificación de 1945, en el contexto de los motores de aviones.

El concepto de que el software puede contener errores se remonta a las notas de 1843 de Ada Lovelace sobre el motor analítico , en las que habla de la posibilidad de que las "tarjetas" de programa para el motor analítico de Charles Babbage sean erróneas:

... igualmente debe haberse realizado un proceso de análisis para proporcionar a la Máquina Analítica los datos operativos necesarios ; y que aquí también puede residir una posible fuente de error. Dado que el mecanismo real es infalible en sus procesos, las tarjetas pueden darle órdenes incorrectas.

Informe "Errores en el sistema"

El Instituto de Tecnología Abierta, dirigido por el grupo New America, publicó un informe "Errores en el sistema" en agosto de 2016 que indica que los legisladores estadounidenses deberían hacer reformas para ayudar a los investigadores a identificar y abordar los errores de software. El informe "destaca la necesidad de una reforma en el campo del descubrimiento y divulgación de vulnerabilidades de software". Uno de los autores del informe dijo que el Congreso no ha hecho lo suficiente para abordar la vulnerabilidad del software cibernético, a pesar de que el Congreso aprobó una serie de proyectos de ley para combatir el problema más amplio de la seguridad cibernética.

Los investigadores del gobierno, las empresas y los expertos en seguridad cibernética son las personas que generalmente descubren fallas de software. El informe pide reformar las leyes de derechos de autor y delitos informáticos.

La Ley de Abuso y Fraude Informático, la Ley de Derechos de Autor del Milenio Digital y la Ley de Privacidad de las Comunicaciones Electrónicas criminalizan y crean sanciones civiles por acciones que los investigadores de seguridad realizan de manera rutinaria mientras realizan investigaciones de seguridad legítimas, según el informe.

Terminología

Si bien el uso del término "error" para describir errores de software es común, muchos han sugerido que debería abandonarse. Un argumento es que la palabra "error" está divorciada del sentido de que un ser humano causó el problema y, en cambio, implica que el defecto surgió por sí solo, lo que lleva a un impulso para abandonar el término "error" en favor de términos como "defecto", con éxito limitado. Desde la década de 1970 , Gary Kildall sugirió con cierto humor usar el término "error".

En ingeniería de software, el metamorfismo de errores (del griego meta = "cambio", morph = "forma") se refiere a la evolución de un defecto en la etapa final del despliegue de software. La transformación de un "error" cometido por un analista en las primeras etapas del ciclo de vida del desarrollo de software, que conduce a un "defecto" en la etapa final del ciclo, se ha denominado "metamorfismo del error".

Las diferentes etapas de un "error" en todo el ciclo pueden describirse como "errores", "anomalías", "fallas", "fallas", "errores", "excepciones", "bloqueos", "fallas", "errores" , "defectos", "incidentes" o "efectos secundarios".

Prevención

Error resultante de un error de software que se muestra en dos pantallas en la estación de La Croix de Berny en Francia.

La industria del software se ha esforzado mucho en reducir el número de errores. Éstas incluyen:

Errores tipográficos

Los errores suelen aparecer cuando el programador comete un error de lógica . Varias innovaciones en el estilo de programación y la programación defensiva están diseñadas para hacer que estos errores sean menos probables o más fáciles de detectar. Algunos errores tipográficos, especialmente de símbolos u operadores lógicos/ matemáticos , permiten que el programa funcione incorrectamente, mientras que otros, como la falta de un símbolo o un nombre mal escrito, pueden impedir que el programa funcione. Los lenguajes compilados pueden revelar algunos errores tipográficos cuando se compila el código fuente.

Metodologías de desarrollo

Varios esquemas ayudan a administrar la actividad del programador para que se produzcan menos errores. La ingeniería de software (que también aborda problemas de diseño de software) aplica muchas técnicas para prevenir defectos. Por ejemplo, las especificaciones formales del programa establecen el comportamiento exacto de los programas para que se puedan eliminar los errores de diseño. Desafortunadamente, las especificaciones formales no son prácticas para nada excepto para los programas más cortos, debido a problemas de explosión combinatoria e indeterminación .

Las pruebas unitarias implican escribir una prueba para cada función (unidad) que debe realizar un programa.

En el desarrollo basado en pruebas, las pruebas de unidad se escriben antes que el código y el código no se considera completo hasta que todas las pruebas se completan con éxito.

El desarrollo de software ágil implica lanzamientos de software frecuentes con cambios relativamente pequeños. Los defectos son revelados por los comentarios de los usuarios.

El desarrollo de código abierto permite que cualquier persona examine el código fuente. Una escuela de pensamiento popularizada por Eric S. Raymond como la ley de Linus dice que el software popular de código abierto tiene más posibilidades de tener pocos o ningún error que otro software, porque "con suficientes ojos, todos los errores son superficiales". Sin embargo, esta afirmación ha sido cuestionada: el especialista en seguridad informática Elias Levy escribió que "es fácil ocultar vulnerabilidades en un código fuente complejo, poco entendido e indocumentado", porque "incluso si las personas están revisando el código, eso no significa que están calificados para hacerlo". Un ejemplo de que esto realmente sucedió, accidentalmente, fue la vulnerabilidad OpenSSL de 2008 en Debian .

Soporte de lenguaje de programación

Los lenguajes de programación incluyen características para ayudar a prevenir errores, como sistemas de tipo estático, espacios de nombres restringidos y programación modular . Por ejemplo, cuando un programador escribe (pseudocódigo) LET REAL_VALUE PI = "THREE AND A BIT", aunque esto puede ser sintácticamente correcto, el código falla en una verificación de tipo . Los lenguajes compilados captan esto sin tener que ejecutar el programa. Los lenguajes interpretados detectan tales errores en tiempo de ejecución. Algunos lenguajes excluyen deliberadamente características que conducen fácilmente a errores, a expensas de un rendimiento más lento: el principio general es que casi siempre es mejor escribir código más simple y lento que código inescrutable que se ejecuta un poco más rápido, especialmente considerando que el costo de mantenimiento es sustancial . . Por ejemplo, el lenguaje de programación Java no admite la aritmética de punteros ; Las implementaciones de algunos lenguajes, como Pascal y los lenguajes de secuencias de comandos, a menudo tienen límites de tiempo de ejecución que verifican las matrices, al menos en una compilación de depuración.

Análisis de código

Las herramientas para el análisis de código ayudan a los desarrolladores al inspeccionar el texto del programa más allá de las capacidades del compilador para detectar posibles problemas. Aunque, en general, el problema de encontrar todos los errores de programación dada una especificación no tiene solución (consulte el problema de detención ), estas herramientas explotan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples a menudo cuando escriben software.

Instrumentación

Las herramientas para monitorear el rendimiento del software mientras se ejecuta, ya sea específicamente para encontrar problemas como cuellos de botella o para garantizar el funcionamiento correcto, pueden incorporarse en el código explícitamente (tal vez tan simple como una declaración que diga PRINT "I AM HERE"), o proporcionarse como instrumentos. A menudo es una sorpresa encontrar dónde la mayor parte del tiempo lo ocupa un fragmento de código, y esta eliminación de suposiciones puede hacer que el código se reescriba.

Pruebas

Los probadores de software son personas cuya tarea principal es encontrar errores o escribir código para respaldar las pruebas. En algunos proyectos, es posible que se gasten más recursos en las pruebas que en el desarrollo del programa.

Las mediciones durante las pruebas pueden proporcionar una estimación de la cantidad de posibles errores restantes; esto se vuelve más confiable cuanto más tiempo se prueba y desarrolla un producto.

depuración

El historial de errores típico ( datos del proyecto GNU Classpath ). Un nuevo error enviado por el usuario no está confirmado. Una vez que ha sido reproducido por un desarrollador, es un error confirmado . Los errores confirmados se corrigen más tarde . Los errores pertenecientes a otras categorías (irreproducibles, no se repararán, etc.) suelen ser una minoría

Encontrar y corregir errores, o depurar , es una parte importante de la programación de computadoras . Maurice Wilkes , uno de los primeros pioneros de la informática, describió su descubrimiento a fines de la década de 1940 de que pasaría gran parte del resto de su vida encontrando errores en sus propios programas.

Por lo general, la parte más difícil de la depuración es encontrar el error. Una vez que se encuentra, corregirlo suele ser relativamente fácil. Los programas conocidos como depuradores ayudan a los programadores a localizar errores ejecutando el código línea por línea, observando los valores de las variables y otras funciones para observar el comportamiento del programa. Sin un depurador, se puede agregar código para que los mensajes o valores se puedan escribir en una consola o en una ventana o archivo de registro para rastrear la ejecución del programa o mostrar valores.

Sin embargo, incluso con la ayuda de un depurador, localizar errores es un arte. No es raro que un error en una sección de un programa provoque fallas en una sección completamente diferente, lo que hace que sea especialmente difícil de rastrear (por ejemplo, un error en una rutina de procesamiento de gráficos que hace que falle una rutina de E/S de archivo ) , en una parte aparentemente no relacionada del sistema.

En ocasiones, un bug no es una falla aislada, sino que representa un error de pensamiento o de planificación por parte del programador. Dichos errores lógicos requieren que una sección del programa sea revisada o reescrita. Como parte de la revisión del código , recorrer el código e imaginar o transcribir el proceso de ejecución a menudo puede encontrar errores sin siquiera reproducir el error como tal.

Más típicamente, el primer paso para localizar un error es reproducirlo de manera confiable. Una vez que el error es reproducible, el programador puede usar un depurador u otra herramienta mientras reproduce el error para encontrar el punto en el que el programa se desvió.

Algunos errores son revelados por entradas que pueden ser difíciles de recrear para el programador. Una de las causas de las muertes de la máquina de radiación Therac-25 fue un error (específicamente, una condición de carrera ) que ocurrió solo cuando el operador de la máquina ingresó muy rápidamente a un plan de tratamiento; se necesitaron días de práctica para poder hacer esto, por lo que el error no se manifestó en las pruebas o cuando el fabricante intentó duplicarlo. Otros errores pueden dejar de ocurrir cada vez que se aumenta la configuración para ayudar a encontrar el error, como ejecutar el programa con un depurador; estos se llaman heisenbugs (nombrados con humor por el principio de incertidumbre de Heisenberg ).

Desde la década de 1990, particularmente después del desastre del vuelo 501 de Ariane 5 , aumentó el interés en las ayudas automatizadas para la depuración, como el análisis de código estático mediante interpretación abstracta .

Algunas clases de errores no tienen nada que ver con el código. La documentación o el hardware defectuosos pueden generar problemas en el uso del sistema, aunque el código coincida con la documentación. En algunos casos, los cambios en el código eliminan el problema aunque el código ya no coincida con la documentación. Los sistemas integrados con frecuencia solucionan errores de hardware, ya que hacer una nueva versión de una ROM es mucho más económico que remanufacturar el hardware, especialmente si son artículos básicos .

Punto de referencia de errores

Para facilitar la investigación reproducible sobre pruebas y depuración, los investigadores utilizan puntos de referencia seleccionados de errores:

  • el punto de referencia de siemens
  • ManyBugs es un punto de referencia de errores de 185 C en nueve programas de código abierto.
  • Defects4J es un punto de referencia de 341 errores de Java de 5 proyectos de código abierto. Contiene los parches correspondientes, que cubren una variedad de tipos de parches.
  • BEARS es un punto de referencia de fallas de compilación de integración continua que se enfoca en fallas de prueba. Ha sido creado mediante el seguimiento de compilaciones de proyectos de código abierto en Travis CI .

Gestión de errores

La gestión de errores incluye el proceso de documentación, categorización, asignación, reproducción, corrección y publicación del código corregido. Los cambios propuestos al software (errores, así como solicitudes de mejora e incluso lanzamientos completos) se rastrean y administran comúnmente mediante sistemas de seguimiento de errores o sistemas de seguimiento de problemas . Los elementos agregados pueden llamarse defectos, tickets, problemas o, siguiendo el paradigma de desarrollo ágil , historias y epopeyas. Las categorías pueden ser objetivas, subjetivas o una combinación, como el número de versión , el área del software, la gravedad y la prioridad, así como el tipo de problema, como una solicitud de función o un error.

Una clasificación de errores revisa los errores y decide si corregirlos y cuándo hacerlo. La decisión se basa en la prioridad del error y en factores como los cronogramas del proyecto. La clasificación no está destinada a investigar la causa de los errores, sino el costo de solucionarlos. El triaje ocurre regularmente y pasa por errores abiertos o reabiertos desde la reunión anterior. Los asistentes al proceso de selección suelen ser el director del proyecto, el director de desarrollo, el director de pruebas, el director de compilación y los expertos técnicos.

Gravedad

La gravedad es la intensidad del impacto que tiene el error en el funcionamiento del sistema. Este impacto puede ser la pérdida de datos, financiera, pérdida de buena voluntad y esfuerzo desperdiciado. Los niveles de gravedad no están estandarizados. Los impactos difieren según la industria. Una falla en un videojuego tiene un impacto totalmente diferente a una falla en un navegador web o un sistema de monitoreo en tiempo real. Por ejemplo, los niveles de gravedad del error pueden ser "bloqueo o bloqueo", "sin solución alternativa" (lo que significa que no hay forma de que el cliente pueda realizar una tarea determinada), "tiene solución alternativa" (lo que significa que el usuario aún puede realizar la tarea), "visual defecto" (por ejemplo, una imagen faltante o un botón o elemento de formulario desplazado) o "error de documentación". Algunos editores de software utilizan niveles de gravedad más calificados, como "crítico", "alto", "bajo", "bloqueador" o "trivial". La gravedad de un error puede ser una categoría separada de su prioridad de corrección, y los dos pueden cuantificarse y gestionarse por separado.

Prioridad

Controles de prioridad donde cae un error en la lista de cambios planificados. La prioridad la decide cada productor de software. Las prioridades pueden ser numéricas, como del 1 al 5, o con nombre, como "crítica", "alta", "baja" o "diferida". Estas escalas de clasificación pueden ser similares o incluso idénticas a las clasificaciones de gravedad , pero se evalúan como una combinación de la gravedad del error con su esfuerzo estimado para solucionarlo; un error de gravedad baja pero fácil de solucionar puede tener una prioridad más alta que un error de gravedad moderada que requiere un esfuerzo excesivo para solucionarlo. Las clasificaciones de prioridad pueden estar alineadas con los lanzamientos de productos, como la prioridad "crítica" que indica todos los errores que deben corregirse antes del próximo lanzamiento de software.

Lanzamientos de software

Es una práctica común lanzar software con errores conocidos de baja prioridad. Los errores de prioridad suficientemente alta pueden justificar una publicación especial de una parte del código que contiene solo módulos con esas correcciones. Estos se conocen como parches . La mayoría de los lanzamientos incluyen una combinación de cambios de comportamiento y varias correcciones de errores. Los lanzamientos que enfatizan la corrección de errores se conocen como lanzamientos de mantenimiento , para diferenciarlos de los lanzamientos principales que enfatizan las adiciones o cambios de características.

Las razones por las que un editor de software opta por no parchear o incluso corregir un error en particular incluyen:

  • Se debe cumplir una fecha límite y los recursos son insuficientes para corregir todos los errores antes de la fecha límite.
  • El error ya se solucionó en una próxima versión y no es de alta prioridad.
  • Los cambios necesarios para corregir el error son demasiado costosos o afectan a muchos otros componentes, lo que requiere una actividad de prueba importante.
  • Se puede sospechar, o saber, que algunos usuarios confían en el comportamiento de errores existente; una solución propuesta puede introducir un cambio importante .
  • El problema está en un área que quedará obsoleta con un próximo lanzamiento; arreglarlo es innecesario.
  • "No es un error, es una característica". Ha surgido un malentendido entre el comportamiento esperado y el percibido o la característica no documentada .

Tipos

En los proyectos de desarrollo de software, se puede introducir un "error" o "falla" en cualquier etapa. Los errores surgen de descuidos o malentendidos cometidos por un equipo de software durante la especificación, el diseño, la codificación, la entrada de datos o la documentación. Por ejemplo, un programa relativamente simple para ordenar alfabéticamente una lista de palabras, el diseño podría no tener en cuenta lo que debería suceder cuando una palabra contiene un guión . O al convertir un diseño abstracto en código, el codificador podría crear inadvertidamente un error de uno en uno y no clasificar la última palabra en una lista. Los errores pueden ser tan simples como un error de tipeo: un "<" donde se pretendía un ">".

Otra categoría de error se denomina condición de carrera que puede ocurrir cuando los programas tienen múltiples componentes ejecutándose al mismo tiempo. Si los componentes interactúan en un orden diferente al previsto por el desarrollador, podrían interferir entre sí y evitar que el programa complete sus tareas. Estos errores pueden ser difíciles de detectar o anticipar, ya que es posible que no ocurran durante cada ejecución de un programa.

Los errores conceptuales son la incomprensión de un desarrollador de lo que debe hacer el software. El software resultante puede funcionar según la comprensión del desarrollador, pero no lo que realmente se necesita. Otros tipos:

Aritmética

Lógica

Sintaxis

  • Uso del operador incorrecto, como realizar una asignación en lugar de una prueba de igualdad . Por ejemplo, en algunos idiomas, x=5 establecerá el valor de x en 5, mientras que x==5 verificará si x es actualmente 5 o algún otro número. Los lenguajes interpretados permiten que dicho código falle. Los lenguajes compilados pueden detectar tales errores antes de que comience la prueba.

Recurso

subprocesos múltiples

interfaz

  • Uso incorrecto de la API.
  • Implementación incorrecta del protocolo.
  • Manipulación incorrecta del hardware.
  • Suposiciones incorrectas de una plataforma en particular.
  • Sistemas incompatibles. Una nueva API o protocolo de comunicaciones puede parecer que funciona cuando dos sistemas usan versiones diferentes, pero pueden ocurrir errores cuando una función o característica implementada en una versión se cambia o falta en otra. En los sistemas de producción que deben ejecutarse continuamente, puede que no sea posible apagar todo el sistema para una actualización importante, como en la industria de las telecomunicaciones o Internet. En este caso, los segmentos más pequeños de un sistema grande se actualizan individualmente para minimizar la interrupción de una red grande. Sin embargo, algunas secciones pueden pasarse por alto y no actualizarse, y causar errores de compatibilidad que pueden ser difíciles de encontrar y reparar.
  • Anotaciones de código incorrectas

Trabajo en equipo

  • Actualizaciones no propagadas; por ejemplo, el programador cambia "myAdd" pero se olvida de cambiar "mySubtract", que usa el mismo algoritmo. Estos errores son mitigados por la filosofía Don't Repeat Yourself .
  • Comentarios desactualizados o incorrectos: muchos programadores asumen que los comentarios describen con precisión el código.
  • Diferencias entre documentación y producto.

Trascendencia

La cantidad y el tipo de daño que puede causar un error de software afecta naturalmente la toma de decisiones, los procesos y la política con respecto a la calidad del software. En aplicaciones como los vuelos espaciales humanos o la seguridad automotriz , dado que las fallas del software tienen el potencial de causar lesiones humanas o incluso la muerte, dicho software tendrá mucho más escrutinio y control de calidad que, por ejemplo, un sitio web de compras en línea. En aplicaciones como la banca, donde las fallas de software tienen el potencial de causar daños financieros graves a un banco oa sus clientes, el control de calidad también es más importante que, por ejemplo, una aplicación de edición de fotografías. El Centro de Tecnología de Garantía de Software de la NASA logró reducir la cantidad de errores a menos de 0,1 por 1000 líneas de código ( SLOC ), pero no se consideró factible para proyectos en el mundo empresarial.

Según un estudio de la NASA sobre " Complejidad del software de vuelo ", "un proceso de desarrollo de software excepcionalmente bueno puede reducir los defectos a un mínimo de 1 defecto por cada 10 000 líneas de código".

Además del daño causado por los errores, parte de su costo se debe al esfuerzo invertido en solucionarlos. En 1978, Lientz y col. mostró que la mediana de los proyectos invierte el 17 por ciento del esfuerzo de desarrollo en la corrección de errores. En una investigación de 2020 sobre los repositorios de GitHub , se mostró que la mediana es del 20 %.

Errores conocidos

Una serie de errores de software se han vuelto bien conocidos, generalmente debido a su gravedad: los ejemplos incluyen varios accidentes de aviones militares y espaciales. Posiblemente, el error más famoso es el problema del año 2000 , también conocido como el error Y2K, en el que se temía que el colapso económico mundial ocurriría a principios del año 2000 como resultado de que las computadoras pensaran que era 1900. (Al final , no se produjeron problemas importantes.) La interrupción del comercio de acciones de 2012 involucró una incompatibilidad de este tipo entre la antigua API y una nueva API.

En la cultura popular

  • Tanto en la novela de 1968 2001: A Space Odyssey como en la correspondiente película de 1968 2001: A Space Odyssey , la computadora a bordo de una nave espacial, HAL 9000 , intenta matar a todos los miembros de su tripulación. En la novela de seguimiento de 1982, 2010: Odyssey Two , y la película de 1984 que la acompaña, 2010 , se revela que esta acción fue causada porque la computadora había sido programada con dos objetivos en conflicto: revelar completamente toda su información y mantener el verdadero propósito del secreto de vuelo de la tripulación; este conflicto hizo que HAL se volviera paranoico y eventualmente homicida.
  • En la versión en inglés de la canción de Nena 1983 99 Luftballons (99 globos rojos) como resultado de "errores en el software", el lanzamiento de un grupo de 99 globos rojos se confunde con el lanzamiento de un misil nuclear enemigo, lo que requiere una respuesta de lanzamiento equivalente. , resultando en una catástrofe.
  • En la comedia estadounidense de 1999 Office Space , tres empleados intentan explotar la preocupación de su empresa por corregir el error informático Y2K infectando el sistema informático de la empresa con un virus que envía centavos redondeados a una cuenta bancaria separada. El plan fracasa ya que el propio virus tiene su propio error, que envía grandes cantidades de dinero a la cuenta de forma prematura.
  • La novela de 2004 The Bug , de Ellen Ullman , trata sobre el intento de un programador de encontrar un error escurridizo en una aplicación de base de datos.
  • La película canadiense de 2008 Control Alt Delete trata sobre un programador de computadoras que a fines de 1999 lucha por corregir errores en su empresa relacionados con el problema del año 2000.

Ver también

Referencias

enlaces externos