stringtranslate.com

Error de software

Un error de software es un error en el software de la computadora .

Un programa de computadora con muchos o graves errores puede ser descrito como "defectuoso" .

Los efectos de un error de software varían desde menores (como una palabra mal escrita en la interfaz de usuario ) hasta graves (como fallas frecuentes ).

Los errores de software se han relacionado con desastres. Los errores de software en la máquina de radioterapia Therac-25 fueron directamente responsables de las muertes de pacientes en la década de 1980. En 1996, el prototipo de cohete Ariane 5 de la Agencia Espacial Europea , valorado en 1.000 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 de a bordo. [1] En 1994, un helicóptero Chinook de la RAF se estrelló , matando a 29 personas; inicialmente se atribuyó a un error del piloto, pero más tarde se pensó que había sido causado por un error de software en el ordenador de control del motor . [2] El software con errores provocó el escándalo de la Oficina Postal Británica de principios del siglo XXI . [3]

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 cuestan a la economía estadounidense unos 59.000 millones de dólares anuales, o alrededor del 0,6 por ciento del producto interno bruto". [4]

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 sus operaciones.

Historia

Terminología

El metamorfismo de errores (del griego meta = "cambio", morph = "forma") se refiere a la evolución de un defecto en la etapa final de la implementación de un 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 errores'. [5]

Las diferentes etapas de un error en el ciclo de desarrollo pueden describirse como equivocación, [6] : 31  anomalía, [6] : 10  falla, [6] : 31  falla, [6] : 31  error, [6] : 31  excepción, [6] : 31  caída, [6] : 22  falla, bug, [6] : 14  defecto, incidente, [6] : 39  o efecto secundario.

Controversia

A veces, el uso de la palabra "bug" para describir el comportamiento del software es polémico debido a la percepción. Algunos sugieren que se debería abandonar el término y reemplazarlo por "defecto" o "error" .

Algunos sostienen que el término error implica que el defecto surgió por sí solo y presionan para que se utilice en su lugar el término defecto, ya que connota más claramente que fue causado por un ser humano. [7]

Algunos sostienen que el error puede utilizarse 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, [8] 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 alegra que estén solucionando lo que llaman errores, pero no estoy de acuerdo con su rotunda negación de que rastreen a los usuarios". [9]

Prevención

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

Prevenir errores lo más pronto posible en el proceso de desarrollo de software es un objetivo de inversión e innovación. [10] [11]

Soporte de idiomas

Los lenguajes de programación más nuevos tienden a estar diseñados para evitar errores comunes basados ​​en vulnerabilidades de lenguajes existentes. Las lecciones aprendidas de lenguajes más antiguos, como BASIC y C, se utilizan para informar el diseño de lenguajes posteriores, como C# y Rust .

Los lenguajes pueden incluir características como un sistema de tipos estáticos, espacios de nombres restringidos y programación modular . Por ejemplo, para un lenguaje compilado y tipado (como C ):

número flotante = "3";

es sintácticamente correcto, pero no supera la comprobación de tipos, ya que el lado derecho, una cadena, no se puede asignar a una variable de punto flotante. La compilación falla, lo que obliga a corregir este defecto antes de que se pueda reanudar el progreso del desarrollo. Con un lenguaje interpretado, no se produciría un error hasta más tarde, en el tiempo de ejecución.

Algunos lenguajes excluyen características que fácilmente conducen a errores, a costa de un rendimiento más lento; el principio es que, por lo general, es mejor escribir código más simple, más lento y correcto que código complicado y lleno de errores. Por ejemplo, Java no admite la aritmética de punteros, que, por lo general, es rápida, pero se considera peligrosa; es relativamente fácil provocar un error importante.

Algunos lenguajes incluyen funciones que agregan sobrecarga de tiempo de ejecución para evitar algunos errores. Por ejemplo, muchos lenguajes incluyen una verificación de límites de tiempo de ejecución y una forma de manejar condiciones fuera de límites en lugar de fallas.

Un lenguaje compilado permite detectar algunos errores tipográficos (como un identificador mal escrito) antes del tiempo de ejecución , lo cual ocurre antes en el proceso de desarrollo de software que en el caso de un lenguaje interpretado .

Técnicas

Las técnicas de programación como el estilo de programación y la programación defensiva tienen como objetivo evitar errores tipográficos.

Por ejemplo, un error puede deberse a un error tipográfico relativamente menor (error tipográfico) en el código. Por ejemplo, este código ejecuta una función foosolo si conditiones verdadero.

si (condición) foo();

Pero este código siempre se ejecuta foo:

si (condición); foo();

Una convención que tiende a prevenir este problema en particular es requerir llaves para un bloque incluso si tiene solo una línea.

si (condición) { foo();}

La aplicación de las convenciones puede ser manual (es decir, mediante revisión de código ) o mediante herramientas automatizadas.

Especificación

Algunos sostienen que escribir una especificación de programa que establezca el comportamiento de un programa puede prevenir errores.

Algunos sostienen que las especificaciones formales son poco prácticas excepto 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 durante las pruebas pueden proporcionar una estimación de la cantidad de errores que probablemente persistan. Esto se vuelve más confiable cuanto más tiempo se prueba y desarrolla un producto. [ cita requerida ]

Prácticas ágiles

El desarrollo ágil de software puede implicar lanzamientos frecuentes de software con cambios relativamente pequeños. Los defectos se revelan mediante la retroalimentación de los usuarios.

Con el desarrollo basado en pruebas (TDD), las pruebas unitarias se escriben mientras 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 completen con éxito.

Análisis estático

Las herramientas para el análisis de código estático ayudan a los desarrolladores a 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 a menudo al escribir software.

Instrumentación

Las herramientas para supervisar el rendimiento del software mientras se ejecuta, ya sea específicamente para encontrar problemas como cuellos de botella o para garantizar que funciona correctamente, pueden estar incorporadas en el código de forma explícita (tal vez de forma tan sencilla como una declaración que diga PRINT "I AM HERE"), o pueden proporcionarse como herramientas. A menudo resulta sorprendente descubrir dónde se dedica la mayor parte del tiempo a un fragmento de código, y esta eliminación de suposiciones puede hacer que se reescriba el código.

Código abierto

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 de código abierto popular tiene más posibilidades de tener pocos o ningún error que otro software, porque "si se le dan suficientes ojos, todos los errores son superficiales". [12] 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 comprendido y no documentado", porque "incluso si la gente está revisando el código, eso no significa que estén calificados para hacerlo". [13] 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 pioneros de la informática, describió su descubrimiento a finales de la década de 1940 de que “gran parte del resto de mi vida la iba a pasar buscando errores en mis propios programas”. [14]

Un programa conocido como depurador puede ayudar a un programador a encontrar código defectuoso examinando el funcionamiento interno de un programa, como ejecutar el código línea por línea y visualizar los valores de las variables.

Como alternativa al uso de un depurador, el código puede instrumentarse con lógica para generar información de depuración con el fin de rastrear la ejecución del programa y visualizar los valores. La salida suele ser a una consola , una ventana , un archivo de registro o una salida de hardware (es decir, un LED ).

Algunos sostienen que localizar un error es todo un arte.

No es raro que un error en una sección de un programa provoque fallos en otra sección, [ cita requerida ] lo que dificulta su seguimiento, en una parte aparentemente no relacionada del sistema. Por ejemplo, un error en una rutina de representación de gráficos que provoque un error en una rutina de entrada/salida de archivos.

A veces, la parte más difícil de la depuración es encontrar la causa del error. Una vez encontrada, corregir el problema a veces es fácil, por no decir trivial.

A veces, un error no es un defecto aislado, sino que representa un error de pensamiento o planificación por parte de los programadores. A menudo, un error lógico de este tipo requiere que se revise o reescriba una sección del programa.

Algunos sostienen que, como parte de la revisión del código , recorrerlo e imaginar o transcribir el proceso de ejecución a menudo puede encontrar errores sin llegar a reproducir el error como tal.

Por lo general, el primer paso para localizar un error es reproducirlo de forma fiable. Si no se puede reproducir el problema, un programador no puede encontrar la causa del error y, por lo tanto, no puede solucionarlo.

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 se produjo solo cuando el operador de la máquina introdujo muy rápidamente 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 siempre que se amplíe la configuración para ayudar a encontrar el error, como ejecutar el programa con un depurador; estos se denominan errores de Heisen (nombre humorístico que hace referencia al principio de incertidumbre de Heisenberg ).

Desde la década de 1990, en particular 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 . [15]

A menudo, los errores surgen durante la codificación, pero una documentación de diseño defectuosa puede provocar un error. En algunos casos, los cambios en el código pueden eliminar el problema aunque el código ya no coincida con la documentación.

En un sistema integrado , el software a menudo se modifica para solucionar un error de hardware, ya que es más económico que modificar el hardware.

Gestión

Ejemplo de historial de errores ( datos del proyecto GNU Classpath ). Un error nuevo inicialmente no está confirmado. Una vez que se confirma la reproducibilidad, se cambia a confirmado . Una vez que se resuelve el problema, se cambia a corregido .

Los errores se gestionan mediante actividades como documentar, categorizar, asignar, reproducir, corregir y publicar el código corregido.

A menudo se utilizan herramientas para rastrear errores y otros problemas con el software. Por lo general, el equipo de desarrollo de software utiliza herramientas diferentes para rastrear su carga de trabajo que el servicio de atención al cliente para rastrear los comentarios de los usuarios . [16]

A un elemento rastreado se le suele llamar error , defecto , ticket , problema , característica o, en el caso del desarrollo ágil de software , historia o épica . Los elementos suelen clasificarse por aspectos como gravedad, prioridad y número de versión .

En un proceso que a veces se denomina triage , se toman decisiones para cada error sobre si se debe corregir y cuándo hacerlo en función de información como la gravedad y la prioridad del error y factores externos como los cronogramas de desarrollo. El triage generalmente no incluye la investigación de la causa. El triage puede realizarse con regularidad. El triage generalmente consiste en revisar los errores nuevos desde el triage anterior y tal vez todos los errores abiertos. Los asistentes pueden incluir al gerente de proyecto, al gerente de desarrollo, al gerente de pruebas, al gerente de compilación y a expertos técnicos. [17] [18]

Gravedad

La gravedad es una medida del impacto que tiene el error. [19] Este impacto puede ser pérdida de datos, financiera, 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, una falla en un videojuego tiene un impacto diferente a una falla en un servidor bancario. Los niveles de gravedad pueden ser falla 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 . [20] La gravedad de un error puede ser una categoría separada de su prioridad para corregir, o las dos pueden cuantificarse y gestionarse por separado.

Un error lo suficientemente grave como para retrasar el lanzamiento del producto se denomina " show stopper" . [21] [22]

Prioridad

La prioridad describe la importancia de resolver el error en relación con otros errores. Las prioridades pueden ser numéricas, como del 1 al 5, o con nombre, como crítico , alto , bajo y diferido . Los valores pueden ser similares o idénticos a las clasificaciones de gravedad, aunque la prioridad sea un aspecto diferente.

La prioridad puede ser una combinación de la gravedad del error y el nivel de esfuerzo necesario para solucionarlo. Un error de baja gravedad pero fácil de solucionar puede tener mayor prioridad que un error de gravedad moderada que requiera mucho más esfuerzo para solucionarlo.

Parche

Los errores que tienen una prioridad suficientemente alta pueden justificar un lanzamiento especial, a veces denominado parche .

Versión de mantenimiento

Una versión de software que enfatiza la corrección de errores puede denominarse versión de mantenimiento , para diferenciarla de una versión que enfatiza nuevas características u otros cambios.

Problema conocido

Es una práctica habitual lanzar software con errores conocidos y de baja prioridad u otros problemas. Las posibles razones incluyen, entre otras:

Trascendencia

La cantidad y el tipo de daño que un error de software puede causar afecta la toma de decisiones, los procesos y las políticas en materia de 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 automotriz , dado que los fallos de software tienen el potencial de causar lesiones o incluso la muerte a personas, dicho software tendrá un escrutinio y un 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 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, en una aplicación de edición de fotografías.

Además del daño que causan 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 del esfuerzo de desarrollo en la corrección de errores. [25] En 2020, una investigación sobre los repositorios de GitHub mostró que la media es del 20 %. [26]

Costo

En 1994, el Centro de Vuelo Espacial 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. [27]

Otro estudio de 1990 informó que los procesos de desarrollo de software excepcionalmente buenos pueden lograr tasas de fallas de implementación tan bajas como 0,1 por 1000 SLOC. [28] Esta cifra se repite en la literatura como Code Complete de Steve McConnell , [29] y el estudio de la NASA sobre la complejidad del software de vuelo . [30] 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. [28]

Punto de referencia

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

Tipos

Algunos tipos de errores notables:

Error de diseño

Un error puede deberse a un diseño insuficiente o incorrecto según la especificación. Por ejemplo, dado que la especificación consiste en ordenar alfabéticamente una lista de palabras, puede producirse un error de diseño si el diseño no tiene en cuenta los símbolos, lo que daría como resultado una ordenación alfabética incorrecta de palabras con símbolos.

Aritmética

Las operaciones numéricas pueden generar resultados inesperados, procesamiento lento o fallas. [33] Un error de este tipo puede 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 por falta de conocimiento de cómo se manejan los cálculos mediante diferentes lenguajes de codificación de software, 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 , también conocido como error lógico, se caracteriza por un código que no falla con un error, pero no tiene el comportamiento esperado, como un bucle infinito , una recursión infinita , una comparación incorrecta en un condicional como usar el operador de comparación incorrecto y el error de un dígito .

Interfaz

Concurrencia

Recursos

Sintaxis

Trabajo en equipo

En política

Informe "Errores en el sistema"

En agosto de 2016, el Open Technology Institute, dirigido por el grupo New America , [38] publicó un informe titulado "Bugs in the System" (Errores en el sistema), en el que se afirma que los responsables de las políticas estadounidenses deberían realizar reformas para ayudar a los investigadores a identificar y abordar los errores de software. El informe "destaca la necesidad de reformas en el campo del descubrimiento y la divulgación de vulnerabilidades de software". [39] 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 ciberseguridad. [39]

Los investigadores gubernamentales, las empresas y los expertos en seguridad cibernética son los que suelen descubrir los fallos de software. El informe pide reformar las leyes sobre delitos informáticos y derechos de autor. [39]

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 para acciones que los investigadores de seguridad realizan rutinariamente mientras realizan investigaciones de seguridad legítimas, señala el informe. [39]

En la cultura popular

Véase también

Referencias

  1. ^ "Informe de la Junta de investigación sobre el fallo del vuelo 501 del ARIANE 5". Agencia Espacial Europea . Informe de la Junta de investigación del Ariane 501 (33–1996). 23 de julio de 1996.
  2. ^ Simon Rogerson (abril de 2002). «El desastre del helicóptero Chinook». IMIS Journal . 12 (2). Archivado desde el original el 15 de septiembre de 1993 . Consultado el 27 de mayo de 2024 .URL alternativa
  3. ^ "El escándalo de Correos arruinó vidas, según la investigación". BBC News . 14 de febrero de 2022.
  4. ^ "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 .
  5. ^ "Experiencia en pruebas: te: la revista para probadores profesionales". Testing Experience . Alemania: testingexperience: 42. Marzo de 2012. ISSN  1866-5705. (se requiere suscripción)
  6. ^ abcdefghi 610.12-1990: Glosario estándar IEEE de terminología de ingeniería de software . IEEE . 31 de diciembre de 1990. doi :10.1109/IEEESTD.1990.101064. ISBN 978-0-7381-0391-4.
  7. ^ "Novedades en SEI septiembre de 1999". SEI Interactive . 2 (3). Carnegie Mellon University : Software Engineering Institute . 1 de septiembre de 1999.
  8. ^ Gregg Keizer (21 de abril de 2011). "Apple se enfrenta a preguntas del Congreso sobre el seguimiento del iPhone". Computerworld .
  9. ^ Gregg Keizer (27 de abril de 2011). «Apple niega que esté rastreando a los usuarios de iPhone, pero promete cambios». Computerworld .
  10. ^ 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.
  11. ^ 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.
  12. ^ "Publicar pronto, publicar a menudo" Archivado el 14 de mayo de 2011 en Wayback Machine . Eric S. Raymond , La catedral y el bazar
  13. ^ "Wide Open Source" Archivado el 29 de septiembre de 2007 en Wayback Machine , Elias Levy , SecurityFocus , 17 de abril de 2000
  14. ^ "Citas de Maurice Wilkes". QuoteFancy . Consultado el 28 de abril de 2024 .
  15. ^ "Historia de PolySpace Technologies". christele.faure.pagesperso-orange.fr . Consultado el 1 de agosto de 2019 .
  16. ^ 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". Revista de ingeniería de calidad y pruebas de software . Vol. 4, núm. 3. págs. 20-24 . Consultado el 19 de diciembre de 2017 .
  17. ^ Rex Black (2002). Gestión del proceso de pruebas (2.ª ed.). Wiley India Pvt. Limited. pág. 139. ISBN 978-8126503131. Recuperado el 19 de junio de 2021 .
  18. ^ Chris Vander Mey (2012). Shipping Greatness - Lecciones prácticas sobre cómo crear y lanzar un software excepcional, aprendidas en el trabajo en Google y Amazon. O'Reilly Media . págs. 79–81. ISBN 978-1449336608.
  19. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (1 de octubre de 2020). "Modelo de extracción de características eficiente para mejorar el rendimiento de la validación de la detección de informes de errores duplicados en sistemas de clasificación de errores de software". Tecnología de la información y el software . 126 : 106344. doi :10.1016/j.infsof.2020.106344. S2CID  219733047.
  20. ^ "5.3. Anatomía de un insecto". bugzilla.org . Archivado desde el original el 23 de mayo de 2013.
  21. ^ Jones, Wilbur D. Jr., ed. (1989). "Show stopper". Glosario: acrónimos y términos de adquisiciones de defensa (4.ª ed.). Fort Belvoir, Virginia: Departamento de Defensa, Defense Systems Management College . p. 123. hdl :2027/mdp.39015061290758 – vía Hathitrust.
  22. ^ Zachary, G. Pascal (1994). ¡Derrota a todos!: la vertiginosa carrera para 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.
  23. ^ "El léxico de la A a la Z de la próxima generación de 1996: lanzamiento de Slipstream". Next Generation . N.º 15. Marzo de 1996. pág. 41.
  24. ^ Carr, Nicholas (2018). "'No es un error, es una característica'. ¿Truto o simplemente correcto?". wired.com .
  25. ^ 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.
  26. ^ Amit, Idan; Feitelson, Dror G. (2020). "La métrica de calidad del código de probabilidad de confirmación correctiva". arXiv : 2007.10912 [cs.SE].
  27. ^ "Una descripción general del laboratorio de ingeniería de software" (PDF) . Serie de laboratorios de ingeniería de software (SEL-94-005). Diciembre de 1994.
  28. ^ ab Cobb, Richard H.; Mills, Harlan D. (1990). "Software de ingeniería bajo control estadístico de calidad". IEEE Software . 7 (6): 46. doi :10.1109/52.60601. ISSN  1937-4194. S2CID  538311 – vía Universidad de Tennessee – Colección Harlan D. Mills.
  29. ^ McConnell, Steven C. (1993). Código completo . Redmond, Washington: Microsoft Press. pág. 611. ISBN. 978-1556154843– vía archive.org. (Cobb y Mills 1990)
  30. ^ 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.
  31. ^ 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". IEEE Transactions on Software Engineering . 41 (12): 1236–1256. doi : 10.1109/TSE.2015.2454513 . ISSN  0098-5589.
  32. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: una base de datos de fallas existentes para permitir estudios de pruebas controladas 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. Número de identificación del sujeto  12796895.
  33. ^ Anthony Di Franco; Hui Guo; Cindy Rubio-González (23 de noviembre de 2017). Un estudio exhaustivo de las características numéricas de los errores en el mundo real . 2017 32nd IEEE / ACM International Conference on Automated Software Engineering (ASE). IEEE . doi :10.1109/ASE.2017.8115662.
  34. ^ Kimbler, K. (1998). Interacciones de características en telecomunicaciones y sistemas de software. V. IOS Press. pág. 8. ISBN 978-90-5199-431-5.
  35. ^ Syed, Mahbubur Rahman (2001). Redes multimedia: tecnología, gestión y aplicaciones: Tecnología, gestión y aplicaciones. Idea Group Inc (IGI). pág. 398. ISBN 978-1-59140-005-9.
  36. ^ 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.
  37. ^ RFC 1263: "Las extensiones TCP se consideran dañinas" cita: "el tiempo necesario para distribuir la nueva versión del protocolo a todos los hosts puede ser bastante largo (de hecho, eterno). ... Si existe la más mínima incompatibilidad entre las versiones antiguas y las nuevas, puede resultar un caos".
  38. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. "Errores en el sistema" (PDF) . Open Policy Institute . Archivado (PDF) del original el 21 de septiembre de 2016 . Consultado el 22 de agosto de 2016 .
  39. ^ abcd 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" . Consultado el 23 de agosto de 2016 .
  40. ^ Ullman, Ellen (2004). El bicho . Picador . ISBN 978-1-250-00249-5.

Enlaces externos