Un error de software es un error, falla o falla en el diseño, desarrollo u operación de un software de computadora que hace que produzca un resultado incorrecto o inesperado, o que se comporte de manera 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. Desde la década de 1950, algunos sistemas informáticos se han diseñado para detectar o corregir automáticamente diversos errores de software durante las operaciones.
Los errores en el software pueden surgir de errores cometidos al interpretar y extraer los requisitos de los usuarios, planificar el diseño de un programa , escribir su código fuente y de la interacción con humanos, hardware y programas, como sistemas operativos o bibliotecas . Un programa con muchos errores, o graves, a menudo se describe como con errores . Los errores pueden desencadenar errores que pueden tener efectos dominó . Los efectos de los errores pueden ser sutiles, como el formateo de texto no deseado, hasta efectos más obvios, como provocar que un programa falle , congelar la computadora o causar daños al hardware. Otros errores se consideran errores de seguridad y podrían, por ejemplo, permitir a un usuario malintencionado eludir 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 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 del cohete Ariane 5 de la Agencia Espacial Europea, valorado en mil millones de dólares, fue destruido menos de un minuto después del lanzamiento debido a un error en el programa informático de guía a bordo. [2] En 1994, un helicóptero Chinook de la RAF se estrelló , matando a 29 personas; Inicialmente se atribuyó esto a un error del piloto, pero luego se pensó que había sido causado por un error de software en la computadora de control del motor . [3] El software con errores provocó el escándalo de la Oficina de Correos británica de principios del siglo XXI , el error judicial más extendido en la historia jurídica británica. [4]
En 2002, un estudio encargado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de Estados Unidos concluyó que "los errores de software son tan frecuentes y tan perjudiciales que le cuestan a la economía estadounidense aproximadamente 59 mil millones de dólares al año, o aproximadamente 0,6 por ciento del producto interno bruto". [5]
La palabra bugge en inglés medio es la base de los términos "bugbear" y "bugaboo" como términos utilizados para un monstruo. [6]
El término "error" para describir defectos ha sido parte de la jerga de ingeniería desde la década de 1870 [7] y es anterior a la electrónica y las computadoras; Es posible que se haya utilizado originalmente en ingeniería de hardware para describir fallas mecánicas. Por ejemplo, Thomas Edison escribió en una carta a un asociado en 1878: [8]
... surgen dificultades, esto cede y [es] entonces cuando se manifiestan los "bichos" -como se llaman estas pequeñas fallas y dificultades [9]
Baffle Ball , el primer juego de pinball mecánico , se anunció como "libre de errores" en 1931. [10] Los problemas con el equipo militar durante la Segunda Guerra Mundial se denominaron errores (o fallos ). [11] 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 insectos a su amada". [12]
Isaac Asimov utilizó el término "bicho" para relacionarse con problemas con un robot en su cuento " Atrapa a ese conejo ", publicado en 1944.
El término "error" fue utilizado en un relato de la pionera en informática Grace Hopper , quien publicó la causa de un mal funcionamiento en una de las primeras computadoras electromecánicas. [13] Una versión típica de la historia es:
En 1946, cuando Hopper fue liberado del servicio activo, se unió a la Facultad de Harvard en el Laboratorio de Computación, donde continuó su trabajo en el Mark II y el 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 fue eliminado cuidadosamente y grabado en el libro de registro. A partir del primer error, hoy llamamos error a los errores o fallas en un programa . [14]
Hopper no estuvo presente cuando se encontró el error, pero se convirtió en una de sus historias favoritas. [15] La fecha en el libro de registro era el 9 de septiembre de 1947. [16] [17] [18] Los operadores que lo encontraron, incluido William "Bill" Burke, más tarde del Laboratorio de Armas Navales , Dahlgren, Virginia , [19 ] estaban familiarizados con el término de ingeniería y, divertidos, mantuvieron el insecto con la notación "Primer caso real de error encontrado". Este libro de registro, completo con la polilla adjunta, es parte de la colección del Museo Nacional Smithsonian de Historia Estadounidense . [17]
El término relacionado " debug " también parece ser anterior a su uso en informática: la etimología de la palabra en el Oxford English Dictionary contiene una certificación de 1945, en el contexto de los motores de avión. [20]
El concepto de que el software podría contener errores se remonta a las notas de Ada Lovelace de 1843 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 se deberá haber realizado un proceso de análisis para dotar al Motor Analítico de los datos operativos necesarios; y que aquí también puede radicar una posible fuente de error. Dado que el mecanismo real es infalible en sus procesos, las tarjetas pueden darle órdenes equivocadas.
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 de la sensación de que un ser humano causó el problema y, en cambio, implica que el defecto surgió por sí solo, lo que llevó a abandonar el término "error" en favor de términos como "defecto", con éxito limitado. [21]
El término "error" también puede usarse para encubrir una decisión de diseño intencional. En 2011, después de recibir el escrutinio del senador estadounidense Al Franken por registrar y almacenar las ubicaciones de los usuarios en archivos no cifrados, [22] Apple calificó el comportamiento como un error. Sin embargo, Justin Brookman del Centro para la Democracia y la Tecnología cuestionó directamente esa descripción, afirmando: "Me alegro de que estén solucionando lo que ellos llaman errores, pero me opongo a su firme negación de que rastreen a los usuarios". [23]
En ingeniería de software , el metamorfismo del error (del griego meta = "cambio", morph = "forma") se refiere a la evolución de un defecto en la etapa final del despliegue del software. La transformación de un "error" cometido por un analista en las primeras etapas del ciclo de vida de desarrollo de software, que conduce a un "defecto" en la etapa final del ciclo, se ha denominado "metamorfismo del error". [24]
Las diferentes etapas de un "error" en todo el ciclo pueden describirse como "errores", "anomalías", "fallos", "fallos", "errores", "excepciones", "bloqueos", "fallos", "errores". , "defectos", "incidentes" o "efectos secundarios". [24]
La industria del software se ha esforzado mucho en reducir el número de errores. [25] [26] Estos incluyen:
Los errores suelen aparecer cuando el programador comete un error lógico . 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 , 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 .
Varios esquemas ayudan a gestionar la actividad del programador para que se produzcan menos errores. La ingeniería de software (que también aborda cuestiones de diseño de software) aplica muchas técnicas para prevenir defectos. Por ejemplo, las especificaciones formales de los programas establecen el comportamiento exacto de los programas para que se puedan eliminar los errores de diseño. Las especificaciones formales no son prácticas para nada que no sean 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 unitarias se escriben antes del código y el código no se considera completo hasta que todas las pruebas se completen exitosamente.
El desarrollo ágil de software implica lanzamientos frecuentes de software con cambios relativamente pequeños. Los defectos se revelan a través de 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". [27] 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 comprendido e indocumentado", porque, "incluso si la gente está revisando el código, eso no Eso no significa que estén calificados para hacerlo". [28] Un ejemplo de un error de software de código abierto fue la vulnerabilidad OpenSSL de 2008 en Debian .
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 no pasa 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 fácilmente generan 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 para verificar las matrices, al menos en una compilación de depuración.
Las herramientas de 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 tiene solución (ver problema de detención ), estas herramientas explotan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples cuando escriben software.
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 su correcto funcionamiento, pueden estar incorporadas explícitamente en el código (quizás tan simple como una declaración que diga PRINT "I AM HERE") o proporcionarse como herramientas. A menudo es una sorpresa descubrir dónde ocupa la mayor parte del tiempo un fragmento de código, y esta eliminación de suposiciones podría provocar que el código se reescriba.
Los probadores de software son personas cuya tarea principal es encontrar errores o escribir código para respaldar las pruebas. En algunos esfuerzos, es posible que se gasten 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 desarrolla un producto. [ cita necesaria ]
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 finales de la década de 1940 que se dio cuenta de que pasaría gran parte del resto de su vida buscando errores en sus propios programas. [29]
Normalmente, la parte más difícil de la depuración es encontrar el error. Una vez encontrado, corregirlo suele ser relativamente fácil. Los programas conocidos como depuradores ayudan a los programadores a localizar errores ejecutando código línea por línea, observando valores de 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 todo un arte. No es raro que un error en una sección de un programa cause fallas en una sección completamente diferente, [ cita necesaria ] , lo que hace que sea especialmente difícil de rastrear (por ejemplo, un error en una rutina de representación de gráficos que causa una E/S de archivo rutina falle), 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. Estos errores lógicos requieren que se revise o 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 reproducir el error como tal.
Lo más habitual es que el primer paso para localizar un error sea reproducirlo de forma fiable. 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 se revelan mediante entradas que pueden resultar 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 ocurría sólo cuando el operador de la máquina entraba 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 ni 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 errores de Heisen (llamados con humor por el principio de incertidumbre de Heisenberg ).
Desde la década de 1990, particularmente después del desastre del vuelo 501 del 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 . [30]
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 integrados frecuentemente solucionan errores de hardware, ya que hacer una nueva versión de una ROM es mucho más barato que remanufacturar el hardware, especialmente si son artículos básicos .
Para facilitar una investigación reproducible sobre pruebas y depuración, los investigadores utilizan puntos de referencia seleccionados 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, solicitudes de mejora e incluso versiones completas) comúnmente se rastrean y administran mediante sistemas de seguimiento de errores o sistemas de seguimiento de problemas . [33] Los elementos agregados pueden denominarse 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 de desarrollo. La clasificación no pretende investigar la causa de los errores, sino más bien el coste de solucionarlos. La clasificación se realiza periódicamente y analiza los errores abiertos o reabiertos desde la reunión anterior. Los asistentes al proceso de clasificación suelen ser el director de proyecto, el director de desarrollo, el director de pruebas, el director de construcción y los expertos técnicos. [34] [35]
La gravedad es la intensidad del impacto que tiene el error en el funcionamiento del sistema. [36] 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. Un fallo en un videojuego tiene un impacto totalmente diferente al de un fallo en un navegador web o en un sistema de seguimiento 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 manera 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". [37] La gravedad de un error puede ser una categoría separada de su prioridad de corrección, y las dos pueden cuantificarse y gestionarse por separado.
La prioridad controla dónde se encuentra 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 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 solucionar puede obtener 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 las versiones de productos, como la prioridad "crítica" que indica todos los errores que deben corregirse antes de la próxima versión del software.
Un error lo suficientemente grave como para retrasar o detener el lanzamiento del producto se denomina "show stopper" [38] o "showstopper bug". [39] Se llama así porque "detiene el espectáculo": provoca fallas inaceptables en el producto. [39]
Es una práctica común publicar software con errores conocidos y de baja prioridad. Los errores de prioridad suficientemente alta pueden justificar una publicación especial de parte del código que contiene sólo 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 múltiples correcciones de errores. Las versiones que enfatizan la corrección de errores se conocen como versiones de mantenimiento , para diferenciarlas de las versiones principales que enfatizan la adición o cambios de funciones.
Las razones por las que un editor de software opta por no parchar o incluso corregir un error en particular incluyen:
En el desarrollo de software, se puede introducir un error o error en cualquier etapa. Los errores surgen de la supervisión o malentendido por parte de un equipo de software durante la especificación, el diseño, la codificación, la configuración, la entrada de datos o la documentación. Por ejemplo, en un programa relativamente simple para alfabetizar una lista de palabras, el diseño podría no 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 sin darse cuenta un error de uno en uno que puede ser un "<" donde se pretendía "<=" y no poder ordenar la última palabra de una lista.
Otra categoría de error se denomina condición de carrera y 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í e impedir 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 una mala comprensión por parte del desarrollador de lo que debe hacer el software. El software resultante puede funcionar según lo que entiende el desarrollador, pero no según lo que realmente se necesita. Otros tipos:
En las operaciones con valores numéricos, pueden surgir problemas que resulten en resultados inesperados, ralentización de un proceso o bloqueos. [42] Estos pueden deberse a una falta de conocimiento de las cualidades del almacenamiento de datos, como una pérdida de precisión debido al redondeo , algoritmos numéricamente inestables , desbordamiento y subdesbordamiento aritmético , o a una falta de conocimiento de cómo los cálculos son manejados por diferentes software. lenguajes de codificación como la división por cero , que en algunos idiomas puede generar una excepción y en otros puede devolver un valor especial como NaN o infinito .
Los errores de flujo de control son aquellos que se encuentran en procesos con lógica válida, pero que conducen a resultados no deseados, como bucles infinitos y recursividad infinita , comparaciones incorrectas para declaraciones condicionales como el uso del operador de comparación incorrecto y errores uno por uno (contar uno). demasiadas o muy pocas iteraciones al realizar un bucle).
La cantidad y el tipo de daño que puede causar un error de software afecta naturalmente la toma de decisiones, los procesos y las políticas con respecto a la calidad del software. En aplicaciones como los vuelos espaciales tripulados , la aviación , la energía nuclear , la atención sanitaria , el transporte público o la seguridad del automóvil , dado que los fallos 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 bancaria, donde las fallas de software tienen el potencial de 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, una aplicación de edición de fotografías.
Aparte del daño causado por los errores, parte de su costo se debe al esfuerzo invertido en solucionarlos. En 1978, Lientz et al. mostró que la mediana de los proyectos invierte el 17 por ciento del esfuerzo de desarrollo en la corrección de errores. [47] En 2020, la investigación sobre los repositorios de GitHub mostró que la mediana es del 20%. [48]
En 1994, el Centro de Vuelos Espaciales Goddard de la NASA logró reducir su número promedio de errores de 4,5 por 1000 líneas de código ( SLOC ) a 1 por 1000 SLOC. [49]
Otro estudio realizado en 1990 informó que procesos de desarrollo de software excepcionalmente buenos pueden lograr tasas de falla de implementación tan bajas como 0,1 por 1000 SLOC. [50] Esta cifra se repite en literatura como Code Complete de Steve McConnell , [51] y el estudio de la NASA sobre la complejidad del software de vuelo . [52] 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. [50]
Se han hecho conocidos varios errores de software, generalmente debido a su gravedad: por ejemplo, varios accidentes de aviones espaciales y militares. Posiblemente el error más famoso sea el problema del año 2000 o error Y2K, que provocó que muchos programas escritos mucho antes de la transición de las fechas 19xx a 20xx funcionaran mal, por ejemplo, al tratar una fecha como "25 de diciembre de 2004" como si fuera de 1904, mostrando " 19100" en lugar de "2000", y así sucesivamente. Un enorme esfuerzo a finales del siglo XX resolvió los problemas más graves y no hubo mayores consecuencias.
La interrupción del comercio de acciones de 2012 implicó una de esas incompatibilidades entre la antigua API y una nueva API.
El Open Technology Institute, dirigido por el grupo New America , [53] publicó un informe "Errores en el sistema" en agosto de 2016 afirmando que los responsables políticos estadounidenses deberían realizar reformas para ayudar a los investigadores a identificar y abordar errores de software. El informe "destaca la necesidad de una reforma en el campo del descubrimiento y divulgación de vulnerabilidades de software". [54] 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. [54]
Los investigadores gubernamentales, las empresas y los expertos en seguridad cibernética son las personas que suelen descubrir fallas de software. El informe pide reformar las leyes sobre delitos informáticos y derechos de autor. [54]
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 que los investigadores de seguridad realizan habitualmente mientras realizan investigaciones de seguridad legítimas, según el informe. [54]
{{cite web}}: CS1 maint: unfit URL (link)(Ver imagen del anuncio en la entrada de referencia)
(Cobb y Mills 1990)
