Hispanopedia Wiki
Un error de software es un defecto ( bug ) en un programa informático . Un programa informático con muchos errores o errores graves puede describirse como defectuoso .
Los efectos de un error de software varían desde leves (como una palabra mal escrita en la interfaz de usuario ) hasta graves (como bloqueos frecuentes ).
En 2002, un estudio encargado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de los Estados Unidos concluyó que "los errores de software son tan frecuentes y perjudiciales que le cuestan a la economía estadounidense unos 59 mil millones de dólares anuales, o alrededor del 0,6 por ciento del producto interno bruto". [ 1 ]
Desde la década de 1950, algunos sistemas informáticos han sido diseñados para detectar o corregir automáticamente diversos errores de software durante su funcionamiento.
Historia
El término «bug» para describir un defecto ha sido jerga de ingeniería desde al menos la década de 1870, mucho antes de las computadoras electrónicas y el software. Por ejemplo, Thomas Edison escribió las siguientes palabras en una carta a un colega en 1878:
Así ha sido en todos mis inventos. El primer paso es una intuición, que surge de repente; luego aparecen las dificultades: el invento falla y es entonces cuando aparecen los "errores" —como se denominan a estos pequeños fallos y dificultades—, y se requieren meses de intensa observación, estudio y trabajo antes de alcanzar el éxito o el fracaso comercial. [ 2 ]
Los problemas con el equipo militar durante la Segunda Guerra Mundial se denominaban fallos o errores. [ 3 ]
Isaac Asimov utilizó el término "bug" (bicho) para referirse a problemas con un robot en su cuento " Catch That Rabbit " (Atrapa a ese conejo), publicado en 1944.
La contralmirante Grace Hopper , pionera de la informática en la Armada de los Estados Unidos, popularizó una historia sobre una polilla que causó un problema en una de las primeras computadoras electromecánicas . [ 4 ] Mientras Hopper trabajaba en las Mark II y Mark III como profesora de Harvard alrededor de 1947, los operadores rastrearon un error en la Mark II hasta una polilla atrapada en un relé. La polilla fue retirada del mecanismo y pegada en un libro de registro con la nota "Primer caso real de error encontrado". [ 5 ] Según se informa, los operadores, incluido William "Bill" Burke, más tarde del Laboratorio de Armas Navales de Dahlgren, Virginia , [ 6 ] estaban familiarizados con el término de ingeniería y probablemente hicieron un juego de palabras al fusionar los dos significados de "bug" (biológico y técnico). Incluso si se trata de una broma, la historia indica que el término se usaba comúnmente en el campo de la informática en ese momento. [ 7 ] [ 8 ] [ 9 ] [ 10 ]
Terminología
La metamorfosis 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 metamorfosis de errores . [ 11 ]
Las diferentes etapas de un error en el ciclo de desarrollo pueden describirse como error, [ 12 ] : 31 anomalía, [ 12 ] : 10 falla, [ 12 ] : 31 fallo, [ 12 ] : 31 error, [ 12 ] : 31 excepción, [ 12 ] : 31 bloqueo, [ 12 ] : 22 fallo, error, [ 12 ] : 14 defecto, incidente, [ 12 ] : 39 o efecto secundario.
Ejemplos
Se ha relacionado la existencia de fallos informáticos con desastres naturales.
- Los fallos de software en la máquina de radioterapia Therac-25 fueron directamente responsables de las muertes de pacientes en la década de 1980. [ 13 ]
- En 1996, el prototipo del cohete Ariane 5 de la Agencia Espacial Europea, valorado en 1.000 millones de dólares , fue destruido menos de un minuto después de su lanzamiento debido a un fallo en el programa informático de guiado a bordo. [ 14 ]
- En 1994, un helicóptero Chinook de la RAF se estrelló , causando la muerte de 29 personas; inicialmente se atribuyó a un error del piloto, pero posteriormente se pensó que había sido causado por un fallo de software en la computadora de control del motor . [ 15 ]
- Un software defectuoso provocó el escándalo de la Oficina Postal Británica a principios del siglo XXI . [ 16 ]
Controversia
En ocasiones, el uso del término «bug» para describir el comportamiento del software resulta controvertido debido a la percepción. Algunos sugieren que se abandone el término, argumentando que «bug» implica que el defecto surgió espontáneamente, y abogan por utilizar «defecto» en su lugar, ya que indica con mayor claridad que son causados por un ser humano. [ 17 ]
Algunos sostienen que el término "bug" podría utilizarse para encubrir una decisión de diseño intencionada. En 2011, tras ser objeto de críticas por parte del senador estadounidense Al Franken por registrar y almacenar la ubicación de los usuarios en archivos sin cifrar, [ 18 ] Apple calificó este comportamiento como un bug. Sin embargo, Justin Brookman, del Centro para la Democracia y la Tecnología, cuestionó directamente esta interpretación, afirmando: "Me alegra que estén corrigiendo lo que ellos llaman bugs, pero discrepo de su rotunda negación de que rastreen a los usuarios". [ 19 ]
Prevención
Prevenir errores lo antes posible en el proceso de desarrollo de software es un objetivo de inversión e innovación. [ 20 ] [ 21 ]
Soporte de idiomas
Los lenguajes de programación más recientes suelen diseñarse para prevenir errores comunes basados en las vulnerabilidades de los lenguajes existentes. Las lecciones aprendidas de lenguajes más antiguos, como BASIC y C, se utilizan para el diseño de lenguajes posteriores, como C# y Rust .
Un lenguaje compilado permite detectar algunos errores tipográficos (como un identificador mal escrito) antes de la ejecución, lo que supone una etapa más temprana en el proceso de desarrollo de software que en el caso de un lenguaje interpretado .
Los lenguajes pueden incluir características como un sistema de tipos estático , espacios de nombres restringidos y programación modular . Por ejemplo, para un lenguaje compilado y tipado (como C ):
número flotante = "3";
La sintaxis es correcta, pero falla la comprobación de tipos, ya que el lado derecho, una cadena, no se puede asignar a una variable de tipo float. La compilación falla , lo que obliga a corregir este defecto antes de que se pueda reanudar el desarrollo. Con un lenguaje interpretado, el fallo no se produciría hasta que se ejecutara la instrucción (mucho más tarde, si es que llegaba a ocurrir, durante la ejecución).
Algunos lenguajes excluyen características que fácilmente generan errores, a costa de un rendimiento más lento. El principio es que, por lo general, es mejor escribir código correcto, aunque más lento, que código complicado y propenso a errores. Por ejemplo, Java no admite la aritmética de punteros , que puede ser muy rápida, pero puede provocar corrupción de memoria o fallos de segmentación si no se usa con mucha precaución.
Algunos lenguajes incluyen características que añaden sobrecarga en tiempo de ejecución para prevenir errores comunes. Por ejemplo, muchos lenguajes incluyen comprobación de límites en tiempo de ejecución y una forma de recuperarse de errores de acceso fuera de límites en lugar de que el programa falle.
Técnicas
Las pautas de estilo y la programación defensiva pueden prevenir errores tipográficos (erratas) que pasan desapercibidos.
Por ejemplo, la mayoría de los lenguajes de programación de la familia C permiten omitir las llaves alrededor de un bloque de instrucciones si solo hay una instrucción. El siguiente código ejecuta la función foosolo si conditiones verdadero:
si (condición) foo();
Pero este código siempre se ejecuta foo:
si (condición); foo();
El uso de llaves, incluso si no son estrictamente necesarias, previene este error de manera confiable:
si (condición) { foo(); }La aplicación de las convenciones puede ser manual (es decir, mediante la revisión del código ) o mediante herramientas automatizadas como los analizadores de código (linters ).
Especificación
Algunos sostienen que escribir una especificación de programa , que defina el comportamiento previsto del mismo, puede prevenir errores. Otros , sin embargo, argumentan que las especificaciones formales resultan poco prácticas salvo para los programas más cortos, debido a problemas de explosión combinatoria e indeterminación .
Pruebas de software
Uno de los objetivos de las pruebas de software es encontrar errores. Las mediciones realizadas durante las pruebas pueden proporcionar una estimación del número de errores que probablemente queden. Esta estimación se vuelve más fiable cuanto más tiempo se prueba y desarrolla un producto. [ 22 ]
Prácticas ágiles
El desarrollo ágil de software puede implicar lanzamientos frecuentes con cambios relativamente pequeños. Los defectos se detectan mediante la retroalimentación de los usuarios.
Con el desarrollo guiado por pruebas (TDD, por sus siglas en inglés), las pruebas unitarias se escriben a medida que se escribe el código de producción, y el código de producción no se considera completo hasta que todas las pruebas se hayan escrito y se hayan completado con éxito.
Análisis estático
Las herramientas de análisis estático 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. Si bien, en general, el problema de encontrar todos los errores de programación a partir de una especificación no tiene solución (véase el problema de la parada ), estas herramientas aprovechan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples al escribir software.
Instrumentación
Las herramientas para monitorizar el rendimiento del software durante su ejecución, ya sea para detectar problemas como cuellos de botella o para garantizar su correcto funcionamiento, pueden integrarse explícitamente en el código (quizás con una simple instrucción PRINT "I AM HERE") o proporcionarse como herramientas externas. A menudo sorprende descubrir que la mayor parte del tiempo la consume un fragmento de código, y la eliminación de estas suposiciones podría obligar a reescribir dicho código.
Código abierto
El desarrollo de código abierto permite que cualquiera examine el código fuente. Una escuela de pensamiento popularizada por Eric S. Raymond como la ley de Linus dice que el software de código abierto popular tiene más posibilidades de tener pocos o ningún error que otro software, porque "con suficientes ojos, todos los errores son superficiales". [ 23 ] Sin embargo, esta afirmación ha sido cuestionada: el especialista en seguridad informática Elias Levy escribió que "es fácil ocultar vulnerabilidades en código fuente complejo, poco entendido y no documentado", porque, "incluso si las personas están revisando el código, eso no significa que estén calificadas para hacerlo". [ 24 ] Un ejemplo de un error de software de código abierto fue la vulnerabilidad OpenSSL de 2008 en Debian .
Depuración
La depuración puede ser una parte importante del ciclo de vida del desarrollo de software . Maurice Wilkes , uno de los primeros pioneros de la informática, describió su comprensión a finales de la década de 1940 de que "una buena parte del resto de mi vida la iba a pasar buscando errores en mis propios programas". [ 25 ]
Por lo general, el primer paso para localizar un error es reproducirlo de forma fiable. Si no se puede reproducir el problema, el programador no puede encontrar la causa del error y, por lo tanto, no puede solucionarlo.
Algunos errores se revelan mediante datos de entrada difíciles de reproducir. Una de las causas de las muertes en la máquina de radiación Therac-25 fue un error (específicamente, una condición de carrera ) que ocurría solo cuando el operador introducía un plan de tratamiento con mucha rapidez; se necesitaban días de práctica para poder hacerlo, por lo que el error no se manifestó en las pruebas ni cuando el fabricante intentó reproducirlo. Otros errores pueden dejar de ocurrir cuando se modifica la configuración para facilitar su detección, por ejemplo, ejecutando el programa con un depurador; a estos se les llama errores de Heisenberg (nombre que hace referencia al principio de incertidumbre de Heisenberg ).
En ocasiones, un error no es un fallo aislado, sino que representa un error de razonamiento o planificación por parte de los programadores. A menudo, este tipo de error lógico requiere que se revise o reescriba una sección del programa, un proceso conocido como refactorización de código .
Una revisión del código , que consiste en recorrerlo paso a paso e imaginar o transcribir el proceso de ejecución, a menudo puede encontrar errores sin necesidad de reproducir el fallo en sí.
Un programa conocido como depurador puede ayudar a un programador a encontrar código defectuoso examinando el funcionamiento interno de un programa, como por ejemplo ejecutando el código línea por línea y visualizando los valores de las variables.
Como alternativa al uso de un depurador, se puede instrumentar el código con lógica para generar información de depuración que permita rastrear la ejecución del programa y visualizar los valores. La salida suele dirigirse a la consola , una ventana , un archivo de registro o una salida de hardware , que puede controlar un LED indicador .
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 estático de código mediante interpretación abstracta . [ 26 ]
En un sistema embebido , el software a menudo se modifica para solucionar un fallo de hardware, ya que las modificaciones de software pueden ser más económicas y menos perjudiciales que modificar el hardware.
Gestión
Los errores se gestionan mediante actividades como la documentación, la categorización, la asignación, la reproducción, la corrección y la publicación del código corregido.
Las herramientas se utilizan a menudo para rastrear errores y otros problemas con el software. Por lo general, el equipo de desarrollo de software utiliza herramientas diferentes para controlar su carga de trabajo que el servicio al cliente para controlar los comentarios de los usuarios . [ 27 ]
Un elemento rastreado suele denominarse error , defecto , incidencia , problema , característica o, en el desarrollo ágil de software , historia o épica . Los elementos suelen clasificarse según aspectos como la gravedad, la prioridad y el número o números de versión afectados.
En un proceso a veces denominado triaje , se toman decisiones para cada error sobre si corregirlo y cuándo hacerlo, basándose en información como la gravedad y la prioridad del error, así como en factores externos como los cronogramas de desarrollo. El triaje generalmente no incluye una investigación de la causa. El triaje puede realizarse periódicamente y, como mínimo, consiste en revisar los nuevos errores detectados desde el triaje anterior, pudiendo extenderse a todos los errores abiertos. Entre los participantes pueden figurar el director del proyecto, el director de desarrollo, el director de pruebas, el director de compilación y expertos técnicos. [ 28 ] [ 29 ]
Gravedad
La gravedad es una medida del impacto que tiene el error. [ 30 ] Este impacto puede ser pérdida de datos, pérdidas financieras, pérdida de buena voluntad y esfuerzo desperdiciado. Los niveles de gravedad no están estandarizados, sino que difieren según el contexto, como la industria y la herramienta de seguimiento. Por ejemplo, un fallo en un videojuego tiene un impacto diferente al de un fallo en un servidor bancario. Ejemplos de descripciones de niveles de gravedad son: fallo o bloqueo , sin solución alternativa (el usuario no puede realizar una tarea), tiene solución alternativa (el usuario aún puede realizar la tarea), defecto visual (un error ortográfico, por ejemplo) o error de documentación . Otro ejemplo de conjunto de gravedades: crítico , alto , bajo , bloqueador , trivial . [ 31 ] La gravedad de un error puede ser la misma categoría que su prioridad para ser corregido, o ambos pueden cuantificarse y gestionarse por separado.
Un error lo suficientemente grave como para retrasar el lanzamiento del producto se denomina un impedimento crítico . [ 32 ] [ 33 ]
Prioridad
La prioridad describe la importancia de resolver un error en relación con otros errores. Las prioridades pueden ser numéricas, del 1 al 5, o denominativas, como crítica , alta , baja y aplazada . Los valores pueden ser similares o idénticos a las clasificaciones de gravedad, aunque la prioridad sea un aspecto diferente.
La prioridad puede depender de la gravedad del error y del esfuerzo necesario para solucionarlo. Un error de baja gravedad pero fácil de corregir puede tener mayor prioridad que uno de gravedad moderada que requiere mucho más esfuerzo.
Parche
Un error de prioridad suficientemente alta puede justificar una versión especial para corregirlo. Dicha versión a veces se denomina parche .
Versión de mantenimiento
Una versión de software que se centra en la corrección de errores puede denominarse versión de mantenimiento , para diferenciarla de una versión que se centra en nuevas funciones u otros cambios.
Problema conocido
Es práctica común lanzar software con errores conocidos de baja prioridad u otros problemas. Las posibles razones incluyen, entre otras:
- Hay que cumplir con un plazo y los recursos son insuficientes para corregir todos los errores antes de la fecha límite [ 34 ].
- El error ya está corregido en una próxima versión y no es de alta prioridad.
- Es posible que se sospeche, o se sepa, que algunos usuarios dependen del comportamiento defectuoso existente; una solución propuesta podría introducir un cambio incompatible.
- El problema se encuentra en un área que quedará obsoleta con una próxima versión; solucionarlo es innecesario.
- "No es un error, es una característica" [ 35 ] Existe un malentendido entre el comportamiento esperado y el real o las características no documentadas .
Trascendencia
La magnitud y el tipo de daño que puede causar un error de software influyen en la toma de decisiones, los procesos y las políticas relativas a la calidad del software. En aplicaciones como los vuelos espaciales tripulados , la aviación , la energía nuclear , la atención médica , el transporte público o la seguridad automotriz , dado que los fallos de software pueden causar lesiones o incluso la muerte, este software estará sujeto a un escrutinio y control de calidad mucho mayores que, por ejemplo, un sitio web de compras en línea. En aplicaciones como la banca, donde los fallos de software pueden causar graves daños financieros a un banco o a sus clientes, el control de calidad también es más importante que, por ejemplo, en una aplicación de edición de fotos.
Además del daño causado por los errores, parte de su costo se debe al esfuerzo invertido en corregirlos. En 1978, Lientz et al. demostraron que la media de los proyectos invierte el 17 por ciento de su esfuerzo de desarrollo en la corrección de errores. [ 36 ] En 2020, una investigación sobre repositorios de GitHub mostró que la media es del 20 por ciento. [ 37 ]
Métrica
En 1994, el Centro de Vuelos Espaciales Goddard de la NASA logró reducir su número promedio de errores de 4,5 por cada 1000 líneas de código ( SLOC ) a 1 por cada 1000 SLOC. [ 38 ]
Otro estudio de 1990 informó que los procesos de desarrollo de software excepcionalmente buenos pueden lograr tasas de fallos de despliegue tan bajas como 0,1 por cada 1000 SLOC. [ 39 ] Esta cifra se repite en la literatura, como en Code Complete de Steve McConnell , [ 40 ] y en el estudio de la NASA sobre la complejidad del software de vuelo . [ 41 ] Algunos proyectos incluso alcanzaron cero defectos: el firmware de la máquina de escribir IBM Wheelwriter , que consta de 63 000 SLOC, y el software del transbordador espacial , con 500 000 SLOC. [ 39 ]
Para facilitar la investigación reproducible sobre pruebas y depuración, los investigadores utilizan conjuntos de datos de referencia seleccionados de errores:
- el punto de referencia de Siemens [ 42 ]
- ManyBugs es un conjunto de datos comparativos de 185 errores de C en nueve programas de código abierto. [ 43 ]
- Defects4J es un conjunto de datos comparativos de 341 errores de Java de 5 proyectos de código abierto. [ 44 ] Contiene los parches correspondientes, que abarcan diversos tipos de parches. Se ha utilizado ampliamente para la investigación sobre la reparación automática de programas. [ 45 ]
Tipos
Algunos tipos de errores notables:
Error de diseño
Un error puede deberse a un diseño insuficiente o incorrecto según las especificaciones. Por ejemplo, si las especificaciones indican ordenar alfabéticamente una lista de palabras, podría producirse un error de diseño si este no tiene en cuenta los símbolos, lo que resultaría en una ordenación alfabética incorrecta de las palabras que los contienen.
Aritmética
Las operaciones numéricas pueden generar resultados inesperados, procesamiento lento o bloqueos. [ 46 ] Este tipo de error puede deberse a la falta de conocimiento de las características del almacenamiento de datos, como la pérdida de precisión por redondeo , algoritmos numéricamente inestables , desbordamiento y subdesbordamiento aritmético , o a la falta de conocimiento de cómo se manejan los cálculos en diferentes lenguajes de programación, como la división por cero, que en algunos lenguajes puede generar una excepción y en otros puede devolver un valor especial como NaN o infinito .
Flujo de control
Un error de flujo de control , o error lógico, se caracteriza por un código que no falla con un error, pero no tiene el comportamiento esperado, como bucles infinitos , recursión infinita , comparación incorrecta en una condición , como usar el operador de comparación incorrecto , y el error de desplazamiento de uno .
Interfaz
- Uso incorrecto de la API.
- Implementación incorrecta del protocolo.
- Manejo incorrecto del hardware.
- Suposiciones incorrectas sobre 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 cambia o falta en otra. En sistemas de producción que deben funcionar continuamente, apagar todo el sistema para una actualización importante puede no ser posible, como en la industria de las telecomunicaciones [ 47 ] o internet. [ 48 ] [ 49 ] [ 50 ] En este caso, se actualizan individualmente segmentos más pequeños de un sistema grande para minimizar las interrupciones en la red. Sin embargo, algunas secciones podrían pasarse por alto y no actualizarse, lo que causaría errores de compatibilidad que pueden ser difíciles de encontrar y corregir.
- Anotaciones de código incorrectas.
Concurrencia
- Interbloqueo : una tarea no puede continuar hasta que finalice una segunda, pero al mismo tiempo, la segunda no puede continuar hasta que finalice la primera.
- Condición de carrera : múltiples tareas simultáneas compiten por los recursos.
- Errores en secciones críticas , exclusiones mutuas y otras características del procesamiento concurrente . El intervalo entre el momento de la verificación y el momento del uso (TOCTOU) es una forma de sección crítica no protegida.
Recursos
- Desreferenciación de puntero nulo .
- Utilizar una variable no inicializada .
- Utilizar una instrucción válida en un tipo de datos incorrecto (ver decimal empaquetado / decimal codificado en binario ).
- Violaciones de acceso .
- Las fugas de recursos se producen cuando un recurso finito del sistema (como la memoria o los identificadores de archivos ) se agota debido a asignaciones repetidas sin liberación.
- Desbordamiento de búfer , en el que un programa intenta almacenar datos más allá del límite de la memoria asignada. Esto puede o no provocar una violación de acceso o de almacenamiento . Con frecuencia, se trata de fallos de seguridad .
- Recursión excesiva que, aunque lógicamente válida, provoca un desbordamiento de pila .
- Error de uso de memoria liberada, que se produce cuando se utiliza un puntero después de que el sistema haya liberado la memoria a la que hace referencia.
- Error de doble liberación.
Sintaxis
- El uso de un token incorrecto , como realizar una asignación en lugar de una prueba de igualdad , puede ser problemático. Por ejemplo, en algunos lenguajes, `x=5` asigna el valor 5 a `x`, mientras que `x==5` comprueba si `x` es actualmente 5 u otro número. Los lenguajes interpretados permiten que este tipo de código falle. Los lenguajes compilados pueden detectar estos errores antes de que comience la prueba.
Trabajo en equipo
- Actualizaciones no propagadas: por ejemplo, cuando un programador modifica "myAdd" pero olvida modificar "mySubtract", que utiliza el mismo algoritmo. Estos errores se mitigan con la filosofía de "No te repitas ".
- Comentarios desactualizados o incorrectos: muchos programadores dan por sentado que los comentarios describen el código con precisión.
- Diferencias entre la documentación y el producto.
En política
Informe sobre "Errores en el sistema"
El Open Technology Institute, dirigido por el grupo New America , [ 51 ] publicó en agosto de 2016 un informe titulado "Bugs in the System" (Errores en el sistema) en el que afirmaba que los legisladores estadounidenses deberían implementar reformas para ayudar a los investigadores a identificar y abordar los errores de software. El informe "subraya la necesidad de reformas en el ámbito del descubrimiento y la divulgación de vulnerabilidades de software". [ 52 ] Uno de los autores del informe señaló que el Congreso no ha hecho lo suficiente para abordar la vulnerabilidad del software cibernético, a pesar de haber aprobado varias leyes para combatir el problema general de la ciberseguridad. [ 52 ]
Los investigadores gubernamentales, las empresas y los expertos en ciberseguridad son quienes suelen descubrir las fallas de software. El informe aboga por la reforma de las leyes sobre delitos informáticos y derechos de autor. [ 52 ]
La Ley de Fraude y Abuso Informático, la Ley de Derechos de Autor del Milenio Digital y la Ley de Privacidad de las Comunicaciones Electrónicas penalizan y establecen sanciones civiles para las acciones que los investigadores de seguridad realizan habitualmente al llevar a cabo investigaciones legítimas sobre seguridad, según el informe. [ 52 ]
En la cultura popular
- En los videojuegos, el término " glitch " se usa a veces para referirse a un error de software. Un ejemplo es el glitch y la especie no oficial de Pokémon MissingNo.
- Tanto en la novela de 1968, 2001: Una odisea del espacio , como en la película homónima , la computadora de a bordo de la nave espacial, HAL 9000 , intenta matar a todos los miembros de la tripulación. En la novela posterior de 1982, 2010: Odisea dos , y en la película de 1984, 2010: El año en que contactamos , se revela que esta acción fue causada por la programación de la computadora con dos objetivos contradictorios: revelar toda su información y mantener en secreto el verdadero propósito del vuelo para la tripulación; este conflicto provocó que HAL se volviera paranoico y, finalmente, homicida.
- En la versión inglesa de la canción de Nena de 1983, 99 Luftballons (99 Globos Rojos), como resultado de "fallos 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 y resulta en una catástrofe.
- En la comedia estadounidense de 1999 , Office Space , tres empleados intentan (sin éxito) explotar la preocupación de su empresa por el error informático del año 2000 utilizando un virus informático que envía fracciones redondeadas de un centavo a su cuenta bancaria, una técnica conocida desde hace mucho tiempo que se describe como " rebanar salami" .
- La novela de 2004, The Bug , de Ellen Ullman , trata sobre el intento de un programador de encontrar un error difícil de detectar en una aplicación de base de datos. [ 53 ]
- La película canadiense de 2008, Control Alt Delete, trata sobre un programador informático que a finales de 1999 lucha por solucionar los errores de su empresa relacionados con el problema del año 2000 (Y2K).
Véase también
- Antipatrón : solución a un problema que puede ser de uso común, pero que generalmente es una mala elección.
- Corrección automática de errores : reparación automática de errores de software.
- Programa de recompensas por detección de errores : se ofrecen premios por informar sobre errores de software.
- Eliminación de fallos : procedimiento de mejora del diseño del chip
- Fallo de hardware : defecto de ingeniería en un dispositivo fabricado.
- ISO/IEC 9126 – Antigua norma ISO e IEC que clasifica un error como defecto o no conformidad.
- Lista de errores de software
- Clasificación ortogonal de defectos : análisis de fallos de software
- Problema de pista de carreras : falla en un sistema o proceso debido a dependencia recursiva.
- RISKS Digest – Publicación periódica editada por un comité de la ACM.
- Fallo por evento único : Fallo electrónico causado por radiación.
- Indicador de defectos de software : patrón correlativo en el código fuente.
- Regresión de software : error de software en el que las funciones dejan de funcionar.
- Deterioro del software : Degradación o pérdida de la funcionalidad del software con el tiempo.
- VUCA : volatilidad, incertidumbre, complejidad y ambigüedad en el liderazgo.
Referencias
- ↑ "Los fallos de software le cuestan caro a la economía estadounidense" . 10 de junio de 2009. Archivado del original el 10 de junio de 2009. Consultado el 24 de septiembre de 2012 .
- ↑ Edison a Puskas, 13 de noviembre de 1878, Documentos de Edison, Laboratorio Nacional Edison, Servicio de Parques Nacionales de EE. UU., West Orange, NJ, citado en Hughes, Thomas Parke (1989). American Genesis: A Century of Invention and Technological Enthusiasm, 1870-1970 . Penguin Books. pág. 75. ISBN 978-0-14-009741-2.
- ↑ "Los portaaviones modernos son el resultado de 20 años de experimentación inteligente" . Life . 29 de junio de 1942. pág. 25. Archivado del original el 4 de junio de 2013. Consultado el 17 de noviembre de 2011 .
- ↑ Prueba FCAT NRT , Harcourt, 18 de marzo de 2008
- ↑ "Libro de registro con error informático" . americanhistory.si.edu . Consultado el 16 de agosto de 2024 .
- ↑ Anales de la Historia de la Computación del IEEE, Vol. 22, Número 1, 2000
- ↑ James S. Huggins. "Primer error informático" . Jamesshuggins.com. Archivado del original el 16 de agosto de 2000. Consultado el 24 de septiembre de 2012 .
- ↑ " Error archivado el 23 de marzo de 2017 en Wayback Machine ", The Jargon File , ver. 4.4.7. Consultado el 3 de junio de 2010.
- ↑ " Libro de registro con error informático archivado el 23 de marzo de 2017 en Wayback Machine ", Museo Nacional de Historia Americana, Instituto Smithsonian.
- ↑ " El primer "error informático ", Centro Histórico Naval. Pero tenga en cuenta que la computadora Harvard Mark II no estuvo terminada hasta el verano de 1947.
- ↑ "Testing experience : te : la revista para testers profesionales". Testing Experience . Alemania: testingexperience: 42. Marzo de 2012. ISSN 1866-5705 . (Se requiere suscripción)
- 1 2 3 4 5 6 7 8 9 610.12-1990: Glosario estándar de terminología de ingeniería de software de IEEE . IEEE . 31 de diciembre de 1990. doi : 10.1109/IEEESTD.1990.101064 . ISBN 978-0-7381-0391-4.
- ↑ Leveson, Nancy G. ; Turner, Clark S. (1 de julio de 1993). "Una investigación de los accidentes de Therac-25" . Computer . 26 ( 7). IEEE Computer Society : 18– 41. Bibcode : 1993Compr..26g..18L . doi : 10.1109 / MC.1993.274940 . eISSN 1558-0814 . ISSN 0018-9162 . LCCN 74648480. OCLC 2240099. S2CID 9691171 .
- ↑ "Informe de la comisión de investigación sobre el fallo del vuelo 501 de Ariane 5" . Agencia Espacial Europea . Informe de la comisión de investigación del vuelo 501 de Ariane ( 33–1996 ). 23 de julio de 1996.
- ↑ Simon Rogerson (abril de 2002). "El desastre del helicóptero Chinook" . Revista IMIS . 12 (2). Archivado del original el 10 de abril de 2016. Recuperado el 27 de mayo de 2024 .URL alternativa
- ↑ "El escándalo de Correos arruinó vidas, según una investigación" . BBC News . 14 de febrero de 2022.
- ↑ Humphrey, Watts S. (1 de abril de 1999). "Noticias en SEI: ¿errores o defectos?" (PDF) . Noticias en SEI . Software Engineering Institute . Página 73 de 154 en archivo PDF. Archivado (PDF) del original el 15 de octubre de 2023. Recuperado el 2 de febrero de 2025 .(enlace desde el archivo de noticias de SEI de 1999 )
- ↑ Gregg Keizer (21 de abril de 2011). "Apple se enfrenta a preguntas del Congreso sobre el seguimiento del iPhone" . Computerworld .
- ↑ Gregg Keizer (27 de abril de 2011). "Apple niega rastrear a los usuarios de iPhone, pero promete cambios" . Computerworld .
- ↑ Dorota Huizinga; Adam Kolawa (septiembre de 2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
- ↑ McDonald, Marc; Musson, Robert; Smith, Ross (2007). Guía práctica para la prevención de defectos . Microsoft Press. pág . 480. ISBN 978-0-7356-2253-1.
- ↑ Dey, Soumen; Chakraborty, Ashis Kumar (diciembre de 2024). "Estimación de la fiabilidad del software mediante modelado sesgado por tamaño" . Journal of Applied Statistics . 51 (16): 3386– 3406. Bibcode : 2024JApSt..51.3386D . doi : 10.1080/02664763.2024.2352751 . ISSN 1360-0532 . PMC 11610320. PMID 39628856 .
- ↑ "Lanza pronto, lanza a menudo" Archivado el 14 de mayo de 2011 en Wayback Machine , Eric S. Raymond , La catedral y el bazar
- ↑ "Código abierto" Archivado el 29 de septiembre de 2007 en Wayback Machine , Elias Levy , SecurityFocus , 17 de abril de 2000
- ↑ "Citas de Maurice Wilkes" . QuoteFancy . Consultado el 28 de abril de 2024 .
- ↑ "Historia de PolySpace Technologies" . christele.faure.pagesperso-orange.fr . Consultado el 1 de agosto de 2019 .
- ↑ Allen, Mitch (mayo-junio de 2002). "Conceptos básicos de seguimiento de errores: una guía para principiantes sobre cómo informar y rastrear defectos" . Software Testing & Quality Engineering Magazine . Vol. 4, n.º 3, págs. 20-24 . Consultado el 19 de diciembre de 2017 .
- ↑ Rex Black (2002). Managing The Testing Process (2.ª ed.). Wiley India Pvt. Limited. pág. 139. ISBN 978-8126503131. Consultado el 19 de junio de 2021 .
- ↑ Chris Vander Mey (2012). Shipping Greatness - Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon . O'Reilly Media . pp. 79–81 . ISBN 978-1449336608.
- ↑ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (1 de octubre de 2020). "Modelo eficiente de extracción de características para la mejora del rendimiento de validación de la detección de informes de errores duplicados en sistemas de clasificación de errores de software" . Information and Software Technology . 126 106344. doi : 10.1016/j.infsof.2020.106344 . S2CID 219733047 .
- ↑ "5.3. Anatomía de un error" . bugzilla.org . Archivado del original el 23 de mayo de 2013.
- ↑ Jones, Wilbur D. Jr., ed. (1989). "Show stopper" . Glosario: acrónimos y términos de adquisición de defensa (4.ª ed.). Fort Belvoir, Virginia: Departamento de Defensa, Defense Systems Management College . pág. 123. hdl : 2027/mdp.39015061290758 – vía Hathitrust.
- ↑ Zachary, G. Pascal (1994). ¡Un éxito rotundo!: la vertiginosa carrera por crear Windows NT y la próxima generación en Microsoft . Nueva York: The Free Press . pág. 158. ISBN 0029356717– vía archive.org.
- ↑ "Léxico de la próxima generación de 1996 de la A a la Z: Lanzamiento de Slipstream". Next Generation . N.° 15. Marzo de 1996. pág. 41.
- ↑ Carr, Nicholas (2018). "«No es un error, es una característica». ¿Un cliché o simplemente acertado? . wired.com .
- ↑ Lientz, BP; Swanson, EB; Tompkins, GE (1978). "Características del mantenimiento del software de aplicación" . Communications of the ACM . 21 (6): 466– 471. doi : 10.1145/359511.359522 . S2CID 14950091 .
- ↑ Amit, Idan; Feitelson, Dror G. (2020). "The Corrective Commit Probability Code Quality Metric". arXiv : 2007.10912 [ cs.SE ].
- ↑ "Descripción general del laboratorio de ingeniería de software" (PDF) . Serie de laboratorios de ingeniería de software (SEL-94-005): 22293. Diciembre de 1994. Bibcode : 1994ntrs.rept22293.
- 1 2 Cobb, Richard H.; Mills, Harlan D. (1990). "Software de ingeniería bajo control estadístico de calidad" . IEEE Software . 7 (6): 46. Bibcode : 1990ISoft...7f..45C . doi : 10.1109/52.60601 . ISSN 1937-4194 . S2CID 538311 – vía University of Tennessee – Harlan D. Mills Collection.
- ↑ McConnell, Steven C. (1993). Code Complete . Redmond, Washington: Microsoft Press. pág. 611. ISBN 978-1556154843– vía archive.org.
(Cobb y Mills 1990)
- ↑ Gerard Holzmann (5 de marzo de 2009). "Apéndice D – Complejidad del software" (PDF) . Informe final: Estudio de la NASA sobre la complejidad del software de vuelo (Daniel L. Dvorak (Ed.)) . Programa de excelencia técnica de la Oficina del Ingeniero Jefe de la NASA.
- ↑ Heckman, Sarah; Williams, Laurie (2008). "Sobre el establecimiento de un punto de referencia para evaluar las técnicas de priorización y clasificación de alertas de análisis estático" (PDF) . Universidad Estatal de Carolina del Norte . Recuperado el 2 de mayo de 2026 .
- ↑ Le Goues, Claire ; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs" . IEEE Transactions on Software Engineering . 41 (12): 1236–1256 . Bibcode : 2015ITSEn..41.1236L . doi : 10.1109/TSE.2015.2454513 . ISSN 0098-5589 .
- ↑ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). «Defects4J: una base de datos de fallos existentes para permitir estudios de pruebas controladas para programas Java». Actas del Simposio Internacional de Pruebas y Análisis de Software de 2014 – ISSTA 2014. págs. 437–440 . CiteSeerX 10.1.1.646.3086 . doi : 10.1145/2610384.2628055 . ISBN 9781450326452. S2CID 12796895 .
- ↑ Martinez, Matias; Durieux, Thomas; Sommerard, Romain; Xuan, Jifeng; Monperrus, Martin (agosto de 2017). "Reparación automática de errores reales en Java: un experimento a gran escala en el conjunto de datos defects4j". Ingeniería de Software Empírica . 22 (4): 1936– 1964. arXiv : 1811.02429 . doi : 10.1007/s10664-016-9470-4 . ISSN 1573-7616 .
- ↑ Anthony Di Franco; Hui Guo; Cindy Rubio-González (23 de noviembre de 2017). Un estudio exhaustivo de las características de los errores numéricos del mundo real . 32.ª Conferencia Internacional IEEE / ACM sobre Ingeniería de Software Automatizada (ASE) de 2017. IEEE . doi : 10.1109/ASE.2017.8115662 .
- ↑ Kimbler, K. (1998). Feature Interactions in Telecommunications and Software Systems V. IOS Press. p. 8. ISBN 978-90-5199-431-5.
- ↑ Syed, Mahbubur Rahman (2001). Multimedia Networking: Technology, Management, and Applications: Technology, Management, and Applications . Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9.
- ↑ Wu, Chwan-Hwa (John); Irwin, J. David (2016). Introducción a las redes informáticas y la ciberseguridad . CRC Press. pág. 500. ISBN 978-1-4665-7214-0.
- ↑ RFC 1263 : "Las extensiones TCP se consideran perjudiciales". Cita: "El tiempo necesario para distribuir la nueva versión del protocolo a todos los hosts puede ser bastante largo (de hecho, indefinido). ... Si existe la más mínima incompatibilidad entre las versiones antiguas y nuevas, puede producirse el caos".
- ↑ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. "Bugs in the System" (PDF) . Open Policy Institute . Archivado (PDF) del original el 21 de septiembre de 2016. Recuperado el 22 de agosto de 2016 .
- 1 2 3 4 Rozens, Tracy (12 de agosto de 2016). "Se necesitan reformas cibernéticas para fortalecer el descubrimiento y la divulgación de errores de software: informe de New America – Homeland Preparedness News" . Recuperado el 23 de agosto de 2016 .
- ^ Ullman, Ellen (2004). El bicho . Picador . ISBN 978-1-250-00249-5.
Enlaces externos
- " Enumeración de debilidades comunes " – una página web especializada en errores, en NIST.gov.
- Tipo BUG de Jim Gray – otro tipo de Bug
- Imagen del "primer error informático" en la Wayback Machine (archivada el 12 de enero de 2015).
- "¡ El primer error informático! " – un correo electrónico de 1981 sobre el error del almirante Hopper
- " Hacia la comprensión de los errores de compilación en GCC y LLVM ". Un estudio de 2016 sobre errores en compiladores.
- Errores de software
