Error de programación

Un error de software es un error, falla o falla en un programa o sistema de computadora que hace que produzca un resultado incorrecto o inesperado, o que se comporte de manera no intencional. El proceso de búsqueda y corrección de 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 también 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 en 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 un efecto dominó . Los errores pueden tener efectos sutiles o hacer que el programa se bloquee o congele la computadora. Otros errores se califican como errores de seguridad y pueden, por ejemplo, permitir que un usuario malintencionado eluda los controles de acceso para obtener privilegios no autorizados . ^[1]

Algunos errores de software se han relacionado con desastres. Los errores en el código que controlaban la máquina de radioterapia Therac-25 fueron directamente responsables de la muerte de pacientes en la década de 1980. En 1996, el prototipo del cohete Ariane 5 de la Agencia Espacial Europea , valorado en 1.000 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 guía a bordo. En junio de 1994, un helicóptero Chinook de la Royal Air Force se estrelló en Mull of Kintyre , matando a 29 personas. Esto fue inicialmente descartado como un error del piloto, pero una investigación de Computer Weekly convenció a una investigación de la Cámara de los Lores de que podría haber sido causado por un error de software. en la computadora de control del motor de la aeronave . ^[2]

En 2002, un estudio encargado por los EE.UU. Departamento de Comercio 's Instituto Nacional de Estándares y Tecnología concluyó que "los errores de software o errores, son tan frecuentes y tan perjudicial que cuestan a la economía de Estados Unidos un estimado de $ 59 mil millones al año, o aproximadamente 0,6 por ciento del producto interno bruto ". ^[3]

Historia

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

El término "error" para describir defectos ha sido parte de la jerga de la ingeniería desde la década de 1870 y es anterior a las computadoras electrónicas y los programas informáticos; 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: ^[5]

Así ha sido en todos mis inventos. El primer paso es una intuición, y viene con un estallido, luego surgen las dificultades, esto cede y [es] entonces que los "Bichos", como se les llama a esas pequeñas fallas y dificultades, se manifiestan y meses de intensa observación, estudio y la mano de obra es un requisito antes de que se alcance el éxito o el fracaso comercial. ^[6]

Baffle Ball , el primer juego de pinball mecánico , fue anunciado como "libre de errores" en 1931. ^[7] Los problemas con el equipo militar durante la Segunda Guerra Mundial se denominaron errores (o fallas ). ^[8] En un libro publicado en 1942, Louise Dickinson Rich , hablando de una máquina cortadora de hielo motorizada , dijo: "Se suspendió el aserrado de hielo hasta que se pudiera traer al creador para eliminar los errores de su amada". ^[9]

Isaac Asimov usó el término "error" para referirse a 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 fue removida del dispositivo.

El término "error" fue utilizado en un relato de la pionera de las computadoras Grace Hopper , quien dio a conocer la causa de un mal funcionamiento en una de las primeras computadoras electromecánicas. ^[10] 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 pegó en el libro de registro. A partir de la primer fallo, que hoy llamamos los errores o fallos en un programa de un insecto . ^[11]

Hopper no encontró el error, como reconoció de inmediato. La fecha en el libro de registro era el 9 de septiembre de 1947. ^{[12] [13] [14]} Los operadores que lo encontraron, incluido William "Bill" Burke, más tarde del Laboratorio de Armas Navales , Dahlgren, Virginia , ^[15] estaban familiarizados con el término de ingeniería y entretenidamente guardó el insecto con la anotación "Se encontró el primer caso real de error". A Hopper le encantaba contar la historia. ^[16] Este libro de registro, completo con la polilla adjunta, es parte de la colección del Museo Nacional Smithsonian de Historia Estadounidense . ^[13]

El término relacionado " depuración " también aparece como anterior a su uso en el cálculo: el Diccionario de Inglés de Oxford ' etimología de la palabra s contiene un certificado del 1945, en el contexto de los motores de aviación. ^[17]

El concepto de que el software podría contener errores se remonta a 1843 notas de Ada Lovelace en el motor de análisis , en el que se habla de la posibilidad de "tarjetas" Programa de Charles Babbage 's motor analítico de ser errónea:

... igualmente se debe haber realizado un proceso de análisis para proporcionar al Motor Analítico los datos operativos necesarios ; y que aquí también puede haber una posible fuente de error. Concedido 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, ^[18] publicó un informe "Errores en el sistema" en agosto de 2016 indicando 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 reforma en el campo del descubrimiento y divulgación de vulnerabilidades de software". ^[19] 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 ha aprobado una serie de proyectos de ley para combatir el problema más amplio de la seguridad cibernética. ^[19]

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

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 penalizan y crean sanciones civiles por acciones en las que los investigadores de seguridad participan habitualmente mientras realizan una investigación de seguridad legítima, según el informe. ^[19]

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 llevó a un impulso para abandonar el término "error" en favor de términos como "defecto", con éxito limitado. ^[20] Desde la década de 1970, Gary Kildall sugirió con cierto humor utilizar el término "pifia". ^{[21] [22]}

En ingeniería de software, el metamorfismo de error (del griego meta = "cambio", morph = "forma") se refiere a la evolución de un defecto en la etapa final de implementación del 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 de error". ^[23]

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

Prevención

La industria del software se ha esforzado mucho en reducir el número de errores. ^{[24] [25]} Estos incluyen:

Errores tipográficos

Los errores suelen aparecer cuando el programador comete un error lógico . Varias innovaciones en estilo de programación y 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 un símbolo que falta 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 más que los programas más cortos, debido a problemas de indeterminación y explosión combinatoria .

La prueba unitaria implica escribir una prueba para cada función (unidad) que debe realizar un programa.

En el desarrollo basado en pruebas, las pruebas unitarias se escriben antes del código y el código no se considera completo hasta que todas las pruebas se completan correctamente.

El desarrollo de software ágil implica lanzamientos de software frecuentes con cambios relativamente pequeños. Los defectos se revelan mediante los comentarios de los usuarios.

El desarrollo de código abierto permite que cualquiera pueda examinar 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". ^[26] 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 la gente está revisando el código, eso no lo hace". No significa que estén calificados para hacerlo ". ^[27] Un ejemplo de que esto sucedió realmente, accidentalmente, fue la vulnerabilidad de OpenSSL de 2008 en Debian .

Soporte de lenguaje de programación

Los lenguajes de programación incluyen funciones 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 detectan esto sin tener que ejecutar el programa. Los lenguajes interpretados detectan estos 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 aritmética de punteros ; las implementaciones de algunos lenguajes como Pascal y los lenguajes de scripting a menudo tienen una verificación de los límites del tiempo de ejecución de 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 problemas potenciales. Aunque en general el problema de encontrar todos los errores de programación dada una especificación no se puede resolver (ver problema de detención ), estas herramientas aprovechan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples a menudo al escribir software.

Instrumentación

Las herramientas para monitorear el desempeño del software mientras se está ejecutando, ya sea específicamente para encontrar problemas como cuellos de botella o para garantizar el funcionamiento correcto, pueden estar incrustadas en el código explícitamente (tal vez tan simple como una declaración que diga PRINT "I AM HERE"), o proporcionarse como herramientas. A menudo es una sorpresa descubrir dónde se lleva la mayor parte del tiempo a un fragmento de código, y esta eliminación de suposiciones podría hacer que el código se reescribiera.

Pruebas

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

Las mediciones durante las pruebas pueden proporcionar una estimación del número de posibles errores restantes; esto se vuelve más confiable cuanto más tiempo se prueba y se desarrolla un producto. ^{[ cita requerida ]}

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 que pertenecen a otras categorías (irreproducibles, no se solucionarán, etc.) suelen ser minoría

Encontrar y corregir errores, o depurar , es una parte importante de la programación informática . Maurice Wilkes , uno de los pioneros de la informática, describió a fines de la década de 1940 que se dio cuenta de que gran parte del resto de su vida la dedicaría a encontrar errores en sus propios programas. ^[28]

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 características 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, la localización de errores es una especie de arte. No es raro que un error en una sección de un programa cause fallas en una sección completamente diferente, ^{[ cita requerida ]} lo que hace que sea especialmente difícil de rastrear (por ejemplo, un error en una rutina de renderizado de gráficos que causa una E / S de archivo rutina para fallar), en una parte aparentemente no relacionada del sistema.

A veces, un error no es un defecto aislado, sino que representa un error de pensamiento o planificación por parte del programador. Tales errores lógicos requieren que se revise o se reescriba una sección del programa. 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 ni 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 descarrió.

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 entró muy rápidamente en 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 por interpretación abstracta . ^[29]

Algunas clases de errores no tienen nada que ver con el código. La documentación o el hardware defectuosos pueden provocar 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 embebidos con frecuencia trabajan en torno a los errores de hardware, ya que para hacer una nueva versión de una ROM es mucho más barato que la refabricación del hardware, especialmente si son artículos de consumo .

Benchmark 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 ^[30] es un punto de referencia de 185 errores de C en nueve programas de código abierto.
• Defects4J ^[31] 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 parche. ^[32]
• BEARS ^[33] es un punto de referencia de fallos de compilación de integración continua que se centra en los fallos de prueba. Ha sido creado monitoreando compilaciones a partir de proyectos de código abierto en Travis CI .

Manejo de errores

La gestión de errores incluye el proceso de documentar, categorizar, asignar, reproducir, corregir y publicar el código corregido. Los cambios propuestos en el software (errores y solicitudes de mejora e incluso versiones completas) se controlan y administran comúnmente mediante sistemas de seguimiento de errores o sistemas de seguimiento de problemas . ^[34] Los elementos agregados pueden denominarse defectos, tickets, incidencias o, siguiendo el paradigma del 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.

Gravedad

La gravedad es el impacto que tiene el error en el funcionamiento del sistema. Este impacto puede ser pérdida de datos, financiero, pérdida de buena voluntad y esfuerzo inútil. Los niveles de gravedad no están estandarizados. Los impactos difieren en 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 de los errores pueden ser "bloqueo o bloqueo", "sin solución" (lo que significa que no hay forma de que el cliente pueda realizar una tarea determinada), "tiene solución" (lo que significa que el usuario aún puede realizar la tarea), "visual defecto "(por ejemplo, una imagen que falta 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". ^[35] La gravedad de un error puede ser una categoría separada de su prioridad de reparación, y los dos pueden cuantificarse y gestionarse por separado.

Prioridad

La prioridad controla dónde cae un error en la lista de cambios planificados. La prioridad la decide cada productor de software. Las prioridades pueden ser numéricas, como 1 a 5, o nombradas, como "crítica", "alta", "baja" o "diferida". Estas escalas de calificación pueden ser similares o incluso idénticas a las calificaciones de gravedad , pero se evalúan como una combinación de la gravedad del error con su esfuerzo estimado para corregirlo; un error de gravedad baja pero fácil de corregir puede tener una prioridad más alta que un error de gravedad moderada que requiere un esfuerzo excesivo para corregirlo. Las clasificaciones de prioridad pueden estar alineadas con las versiones del producto, como la prioridad "crítica" que indica todos los errores que deben corregirse antes de la próxima versión del software.

Lanzamientos de software

Es una práctica común lanzar software con errores conocidos de baja prioridad. La mayoría de los grandes proyectos de software mantienen dos listas de "errores conocidos": los que conoce el equipo de software y los que se deben informar a los usuarios. ^{[ cita requerida ]} La segunda lista informa a los usuarios sobre errores que no se han solucionado en una versión específica y se pueden ofrecer soluciones . Los lanzamientos son de diferentes tipos. Los errores de prioridad suficientemente alta pueden justificar una publicación especial de parte del código que contiene solo módulos con esas correcciones. Estos se conocen como parches . La mayoría de las versiones incluyen una combinación de cambios de comportamiento y varias correcciones de errores. Las versiones que enfatizan la corrección de errores se conocen como versiones de mantenimiento . Las versiones que enfatizan las adiciones / cambios de funciones se conocen como versiones principales y, a menudo, tienen nombres para distinguir las nuevas funciones de las antiguas.

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. ^[36]
• 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 importante actividad de prueba.
• Puede sospecharse, o saberse, que algunos usuarios confían en el comportamiento de errores existente; una solución propuesta puede introducir un cambio radical .
• El problema está en un área que quedará obsoleta con una próxima versión; arreglarlo es innecesario.
• "No es un error". Ha surgido un malentendido entre el comportamiento esperado y el percibido, cuando dicho malentendido no se debe a una confusión derivada de fallas de diseño o documentación defectuosa.

Tipos

En los proyectos de desarrollo de software, se puede introducir un "error" o una "falla" en cualquier etapa. Los errores surgen de descuidos o malentendidos realizados 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 alfabetizar una lista de palabras, el diseño puede fallar en considerar 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 por uno y no clasificar la última palabra de una lista. Los errores pueden ser tan simples como un error de escritura: un "<" donde se pretendía un ">".

Otra categoría de error se llama condición de carrera que puede ocurrir cuando los programas tienen varios 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 un malentendido por parte del desarrollador de lo que debe hacer el software. El software resultante puede funcionar de acuerdo con el entendimiento del desarrollador, pero no lo que realmente se necesita. Otros tipos:

Aritmética

• División por cero .
• Desbordamiento o subdesbordamiento aritmético .
• Pérdida de precisión aritmética por redondeo o algoritmos numéricamente inestables .

Lógica

• Bucles infinitos y recursividad infinita .
• Error de uno por uno , contando uno de más o muy pocos al hacer un bucle.

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 comprobará 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

• Desreferencia de puntero nulo .
• Usando una variable no inicializada .
• Usar una instrucción válida en el tipo de datos incorrecto (ver decimal empaquetado / decimal codificado en binario ).
• Violaciones de acceso .
• Fugas de recursos, donde un recurso del sistema finito (como la memoria o los identificadores de archivos ) se agota por la asignación repetida sin liberación.
• Desbordamiento de búfer , en el que un programa intenta almacenar datos más allá del final del almacenamiento asignado. Esto puede conducir o no a una infracción de acceso o de almacenamiento . Estos se conocen como errores de seguridad .
• Recurrencia excesiva que, aunque lógicamente válida, provoca un desbordamiento de pila .
• Use-after-free error, donde se usa un puntero después de que el sistema ha liberado la memoria a la que hace referencia.
• Doble error gratuito.

Multi-hilo

• Interbloqueo , donde la tarea A no puede continuar hasta que finalice la tarea B, pero al mismo tiempo, la tarea B no puede continuar hasta que finalice la tarea A.
• Condición de carrera , donde la computadora no realiza tareas en el orden previsto por el programador.
• Errores de concurrencia en secciones críticas , exclusiones mutuas y otras características del procesamiento concurrente . Time-of-check-to-time-of-use (TOCTOU) es una forma de sección crítica desprotegida.

Interfaz

• Uso incorrecto de la API. ^[37]
• Implementación incorrecta del protocolo.
• Manejo incorrecto del hardware.
• Supuestos incorrectos 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 funcionar continuamente, puede que no sea posible apagar todo el sistema para una actualización importante, como en la industria de las telecomunicaciones ^[38] o en Internet. ^{[39] [40] [41]} En este caso, los segmentos más pequeños de un sistema grande se actualizan individualmente para minimizar la interrupción en 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 ^[42]

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 se mitigan con 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 viajes espaciales tripulados 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 serios daños financieros a un banco o sus clientes, el control de calidad también es más importante que, digamos, una aplicación de edición de fotografías. El Centro de Tecnología de Garantía de Software de la NASA logró reducir el número de errores a menos de 0.1 por 1000 líneas de código ( SLOC ) ^{[ cita requerida ]} pero esto 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 hasta un mínimo por cada 10.000 líneas de código". ^[43]

Aparte del daño causado por los errores, parte de su costo se debe al esfuerzo invertido en solucionarlos. En 1978, Lientz y al. mostró que la mediana de los proyectos invierte el 17 por ciento del esfuerzo de desarrollo en la corrección de errores. ^{[44] Una} investigación en 2020 sobre repositorios de GitHub mostró que la mediana es del 20%. ^[45]

Errores conocidos

Varios errores de software se han vuelto bien conocidos, generalmente debido a su gravedad: los ejemplos incluyen varios accidentes espaciales y de aviones militares. Posiblemente el error más famoso es el problema del año 2000 , también conocido como error Y2K, en el que se temía que el colapso económico mundial ocurriera 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 implicó una de esas incompatibilidades entre la API anterior y una API nueva.

En la cultura popular

• Tanto en la novela de 1968 2001: A Space Odyssey como en la película correspondiente 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 por la computadora que 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 Red Balloons) 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 del año 2000 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 virus en sí 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 elusivo en una aplicación de base de datos. ^[46]
• La película canadiense de 2008 Control Alt Delete trata sobre un programador de computadoras a fines de 1999 que luchaba por corregir errores en su empresa relacionados con el problema del año 2000.

Ver también

• Anti-patrón
• Programa de recompensas por errores
• Eliminación de fallas
• ISO / IEC 9126 , que clasifica un error como defecto o no conformidad
• Clasificación de defectos ortogonales
• Problema de hipódromo
• Resumen de RIESGOS
• Indicador de defectos de software
• Regresión de software
• Podredumbre de software
• Corrección automática de errores

Referencias

1. Mittal, Varun; Aditya, Shivam (1 de enero de 2015). "Desarrollos recientes en el campo de la corrección de errores" . Procedia Informática . Congreso Internacional de Computación, Comunicación y Convergencia (ICCC 2015). 48 : 288-297. doi : 10.1016 / j.procs.2015.04.184 . ISSN  1877-0509 .
2. Prof. Simon Rogerson . "El desastre del helicóptero Chinook" . Ccsr.cse.dmu.ac.uk. Archivado desde el original el 17 de julio de 2012 . Consultado el 24 de septiembre de 2012 .
3. "Los errores de software le cuestan caro a la economía estadounidense" . 10 de junio de 2009. Archivado desde el original el 10 de junio de 2009 . Consultado el 24 de septiembre de 2012 .
4. Personal de Computerworld (3 de septiembre de 2011). "Polilla en la máquina: depuración de los orígenes de 'error ' " . Computerworld . Archivado desde el original el 25 de agosto de 2015.
5. "¿Sabías que? Edison acuñó el término" error " " . 1 de agosto de 2013 . Consultado el 19 de julio de 2019 .
6. Edison a Puskas, 13 de noviembre de 1878, documentos de Edison, Laboratorio Nacional de Edison, Servicio de Parques Nacionales de EE. UU., West Orange, Nueva Jersey, citado en Hughes, Thomas Parke (1989). American Genesis: Un siglo de inventos y entusiasmo tecnológico, 1870-1970 . Libros de pingüinos. pag. 75. ISBN 978-0-14-009741-2.
7. "Baffle Ball" . Base de datos de Pinball de Internet. (Ver imagen del anuncio en la entrada de referencia)
8. "Los portaaviones modernos son el resultado de 20 años de experimentación inteligente" . Vida . 29 de junio de 1942. p. 25. Archivado desde el original el 4 de junio de 2013 . Consultado el 17 de noviembre de 2011 .
9. Dickinson Rich, Louise (1942), Llevamos al bosque , JB Lippincott Co, pág. 93, LCCN  42024308 , OCLC  405243 , archivado desde el original el 16 de marzo de 2017.
10. Prueba FCAT NRT , Harcourt, 18 de marzo de 2008
11. "Danis, Sharron Ann:" Contralmirante Grace Murray Hopper " " . ei.cs.vt.edu. 16 de febrero de 1997 . Consultado el 31 de enero de 2010 .
12. " 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.
13. " Libro de registro con error informático archivado el 23 de marzo de 2017 en la Wayback Machine ", Museo Nacional de Historia Estadounidense, Institución Smithsonian.
14. " El primer" error informático ", Centro Histórico Naval. Pero tenga en cuenta que lacomputadora Harvard Mark II no estuvo completa hasta el verano de 1947.
15. IEEE Annals of the History of Computing, Vol 22 Número 1, 2000
16. James S. Huggins. "Primer error informático" . Jamesshuggins.com. Archivado desde el original el 16 de agosto de 2000 . Consultado el 24 de septiembre de 2012 .
17. Revista de la Royal Aeronautical Society . 49, 183/2, 1945 "Varió ... a través de la etapa de prueba de tipo y prueba de vuelo y 'depuración' ..."
18. Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. "Errores en el sistema" (PDF) . Instituto de Política Abierta . Archivado (PDF) desde el original el 21 de septiembre de 2016 . Consultado el 22 de agosto de 2016 .
19. Rozens, Tracy (12 de agosto de 2016). "Reformas cibernéticas necesarias para fortalecer el descubrimiento y la divulgación de errores de software: informe de New America - Homeland Preparedness News" . Consultado el 23 de agosto de 2016 .
20. "Noticia en el Archivo SEI 1999" . cmu.edu . Archivado desde el original el 26 de mayo de 2013.
21. Shustek, Len (2 de agosto de 2016). "En sus propias palabras: Gary Kildall" . Gente notable . Museo de Historia de la Computación . Archivado desde el original el 17 de diciembre de 2016.
22. Kildall, Gary Arlen (2 de agosto de 2016) [1993]. Kildall, Scott ; Kildall, Kristin (eds.). "Conexiones informáticas: personas, lugares y eventos en la evolución de la industria de las computadoras personales" (Manuscrito, parte 1). Familia Kildall: 14-15. Archivado desde el original el 17 de noviembre de 2016 . Consultado el 17 de noviembre de 2016 .
23. "Testing Experience: te: la revista para probadores profesionales". Experiencia de prueba . Alemania: testingexperience: 42. Marzo de 2012. ISSN  1866-5705 . (requiere suscripción)
24. Huizinga, Dorota; Kolawa, Adam (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Prensa de la Sociedad de Computación Wiley-IEEE. pag. 426. ISBN 978-0-470-04212-0. Archivado desde el original el 25 de abril de 2012.
25. McDonald, Marc; Musson, Robert; Smith, Ross (2007). La guía práctica para la prevención de defectos . Microsoft Press. pag. 480 . ISBN 978-0-7356-2253-1.
26. "Lanzamiento temprano, lanzamiento a menudo" Archivado el 14 de mayo de 2011 en Wayback Machine , Eric S. Raymond , The Cathedral and the Bazaar
27. "Wide Open Source" Archivado el 29 de septiembre de 2007 en Wayback Machine , Elias Levy , SecurityFocus , 17 de abril de 2000
28. Citas de Maurice Wilkes
29. "Historia de PolySpace Technologies" . christele.faure.pagesperso-orange.fr . Consultado el 1 de agosto de 2019 .
30. Le Goues, Claire; Holtschulte, Neal; Smith, Edward K .; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "Los puntos de referencia ManyBugs e IntroClass para la reparación automatizada de programas C" . Transacciones IEEE sobre ingeniería de software . 41 (12): 1236-1256. doi : 10.1109 / TSE.2015.2454513 . ISSN  0098-5589 .
31. Solo, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: una base de datos de fallas existentes para permitir estudios de prueba controlados para programas Java". Actas del Simposio internacional de 2014 sobre pruebas y análisis de software - ISSTA 2014 . págs. 437–440. CiteSeerX  10.1.1.646.3086 . doi : 10.1145 / 2610384.2628055 . ISBN 9781450326452. S2CID  12796895 .
32. Sobreira, Víctor; Durieux, Thomas; Madeiral, Fernanda; Monperrus, Martin; de Almeida Maia, Marcelo (2018). "Disección de un conjunto de datos de errores: Anatomía de 395 parches de Defects4J". 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER) . págs. 130-140. arXiv : 1801.06393 . doi : 10.1109 / SANER.2018.8330203 . ISBN 978-1-5386-4969-5. S2CID  4607810 .
33. Madeiral, Fernanda; Urli, Simon; Maia, Marcelo; Monperrus, Martin; Maia, Marcelo A. (2019). "BEARS: un punto de referencia de errores de Java extensible para estudios de reparación automática de programas". 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) . págs. 468–478. arXiv : 1901.06024 . doi : 10.1109 / SANER.2019.8667991 . ISBN 978-1-7281-0591-8. S2CID  58028949 .
34. Allen, Mitch (mayo-junio de 2002). "Conceptos básicos de seguimiento de errores: una guía para principiantes para informar y rastrear defectos" . Revista de Ingeniería de Calidad y Pruebas de Software . Vol. 4 no. 3. págs. 20-24 . Consultado el 19 de diciembre de 2017 .
35. "5.3. Anatomía de un error" . bugzilla.org . Archivado desde el original el 23 de mayo de 2013.
36. "El léxico de la siguiente generación de 1996 de la A a la Z: versión Slipstream". Próxima Generación . No. 15. Imagine Media . Marzo de 1996. p. 41.
37. Monperrus, Martin; Bruch, Marcel; Mezini, Mira (2010). "Detección de llamadas a métodos perdidos en software orientado a objetos" . ECOOP 2010 - Programación orientada a objetos (PDF) . Apuntes de conferencias en informática. 6183 . págs. 2-25. doi : 10.1007 / 978-3-642-14107-2_2 . ISBN 978-3-642-14106-5. S2CID  16724498 .
38. Kimbler, K. (1998). Las interacciones de características en telecomunicaciones y software de los sistemas V . IOS Press. pag. 8. ISBN 978-90-5199-431-5.
39. Syed, Mahbubur Rahman (1 de julio de 2001). Redes multimedia: tecnología, gestión y aplicaciones: tecnología, gestión y aplicaciones . Idea Group Inc (IGI). pag. 398. ISBN 978-1-59140-005-9.
40. Wu, Chwan-Hwa (John); Irwin, J. David (19 de abril de 2016). Introducción a las redes informáticas y la ciberseguridad . Prensa CRC. pag. 500. ISBN 978-1-4665-7214-0.
41. RFC 1263: Cita "Extensiones TCP consideradas perjudiciales": "el tiempo para distribuir la nueva versión del protocolo a todos los hosts puede ser bastante largo (de hecho, para siempre) ... Si existe la más mínima incompatibilidad entre las versiones antiguas y nuevas , puede resultar el caos ".
42. Yu, Zhongxing; Bai, Chenggang; Seinturier, Lionel; Monperrus, Martín (2019). "Caracterización del uso, evolución e impacto de las anotaciones de Java en la práctica" . Transacciones IEEE sobre ingeniería de software : 1. arXiv : 1805.01965 . doi : 10.1109 / TSE.2019.2910516 . S2CID  102351817 .
43. Dvorak, Daniel L. 1 Estudio de la NASA sobre la complejidad del software de vuelo .
44. Lientz, BP; Swanson, EB; Tompkins, GE (1978). "Características del mantenimiento del software de aplicación". Comunicaciones de la ACM . 21 (6): 466–471. doi : 10.1145 / 359511.359522 . S2CID  14950091 .
45. Amit, Idan; Feitelson, Dror G. (2020). "La métrica de calidad del código de probabilidad de compromiso correctivo". arXiv : 2007.10912 [ cs.SE ].
46. Ullman, Ellen (2004). El error . Picador . ISBN 978-1-250-00249-5.

enlaces externos

• " Enumeración de debilidades comunes ": una página web de expertos que se centra en errores, en NIST.gov
• Tipo de error de Jim Gray - otro tipo de error
• Imagen del "primer error informático" en 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 del compilador en GCC y LLVM ". Un estudio de 2016 sobre errores en compiladores