stringtranslate.com

Ошибка программного обеспечения

Программная ошибка — это ошибка в программном обеспечении компьютера .

Компьютерную программу с большим количеством серьезных ошибок можно назвать ошибочной .

Последствия программной ошибки могут быть разными: от незначительных (например, неправильно написанное слово в пользовательском интерфейсе ) до серьезных (например, частые сбои ).

Ошибки программного обеспечения были связаны с катастрофами. Ошибки программного обеспечения в аппарате лучевой терапии Therac-25 были напрямую ответственны за смерть пациентов в 1980-х годах. В 1996 году прототип ракеты Ariane 5 Европейского космического агентства стоимостью 1 миллиард долларов США был уничтожен менее чем через минуту после запуска из-за ошибки в программе бортового компьютера управления. [1] В 1994 году вертолет Chinook Королевских ВВС потерпел крушение , в результате чего погибло 29 человек; первоначально вину за это возложили на ошибку пилота, но позже считалось, что причиной стала ошибка программного обеспечения в компьютере управления двигателем . [2] Ошибочное программное обеспечение стало причиной скандала в британском почтовом отделении начала 21-го века . [3]

В 2002 году исследование, проведенное по заказу Национального института стандартов и технологий Министерства торговли США , пришло к выводу, что «ошибки в программном обеспечении настолько распространены и настолько пагубны, что обходятся экономике США примерно в 59 миллиардов долларов в год, или около 0,6 процента валового внутреннего продукта» [4] .

Начиная с 1950-х годов некоторые компьютерные системы были разработаны для обнаружения или автоматического исправления различных ошибок программного обеспечения во время работы.

История

Терминология

Метаморфизм ошибки (от греч. meta = «изменение», morph = «форма») относится к эволюции дефекта на заключительном этапе развертывания программного обеспечения. Трансформация «ошибки», допущенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительном этапе цикла, называется «метаморфизмом ошибки». [5]

Различные стадии ошибки в цикле разработки можно описать как ошибку, [6] : 31  аномалию, [6] : 10  сбой, [6] : 31  отказ, [6] : 31  ошибку, [6] : 31  исключение, [6] : 31  сбой, [6] : 22  сбой, баг, [6] : 14  дефект, инцидент, [6] : 39  или побочный эффект.

Противоречие

Иногда использование термина bug для описания поведения программного обеспечения является спорным из-за восприятия. Некоторые предлагают отказаться от этого термина; заменить его на defect или error .

Некоторые утверждают, что слово «баг» подразумевает, что дефект возник сам по себе, и настаивают на использовании слова «дефект» , поскольку оно более четко указывает на то, что оно вызвано человеком. [7]

Некоторые утверждают, что ошибка может быть использована для сокрытия преднамеренного решения по дизайну. В 2011 году, после того как сенатор США Эл Франкен подверг ее проверке за запись и хранение местоположений пользователей в незашифрованных файлах, [8] Apple назвала такое поведение ошибкой. Однако Джастин Брукман из Центра демократии и технологий напрямую оспорил это изображение, заявив: «Я рад, что они исправляют то, что они называют ошибками, но я возражаю против их решительного отрицания того, что они отслеживают пользователей». [9]

Профилактика

Ошибка, вызванная программным сбоем, отображенная на двух экранах на станции La Croix de Berny во Франции

Целью инвестиций и инноваций является предотвращение ошибок на как можно более ранних этапах процесса разработки программного обеспечения . [10] [11]

Языковая поддержка

Новые языки программирования, как правило, разрабатываются с целью предотвращения распространенных ошибок, основанных на уязвимостях существующих языков. Уроки, извлеченные из старых языков, таких как BASIC и C, используются для информирования о дизайне более поздних языков, таких как C# и Rust .

Языки могут включать такие функции, как статическая система типов , ограниченные пространства имен и модульное программирование . Например, для типизированного, компилируемого языка (вроде C ):

число с плавающей точкой = "3";

синтаксически верна, но не проходит проверку типа, поскольку правая часть, строка, не может быть назначена переменной float. Компиляция завершается неудачей — что заставляет исправить этот дефект до возобновления процесса разработки. С интерпретируемым языком сбой не произойдет до более позднего времени выполнения.

Некоторые языки исключают функции, которые легко приводят к ошибкам, за счет снижения производительности – принцип заключается в том, что обычно лучше писать более простой, медленный и правильный код, чем сложный, с ошибками. Например, Java не поддерживает арифметику указателей , которая обычно быстра, но считается опасной; относительно легко вызвать серьезную ошибку.

Некоторые языки включают функции, которые добавляют накладные расходы во время выполнения, чтобы предотвратить некоторые ошибки. Например, многие языки включают проверку границ во время выполнения и способ обработки условий выхода за пределы границ вместо сбоя.

Компилируемый язык позволяет обнаруживать некоторые опечатки (например, неправильно написанный идентификатор) до начала выполнения , что происходит на более раннем этапе разработки программного обеспечения, чем для интерпретируемого языка.

Методы

Такие методы программирования, как стиль программирования и защитное программирование, предназначены для предотвращения опечаток.

Например, ошибка может быть вызвана относительно незначительной типографской ошибкой (опечаткой) в коде. Например, этот код выполняет функцию fooтолько если conditionis true.

если (условие) foo();

Но этот код всегда выполняется foo:

если (условие); foo();

Соглашение, которое позволяет предотвратить эту конкретную проблему, заключается в обязательном использовании фигурных скобок для блока, даже если он состоит всего из одной строки.

если (условие) { фу();}

Обеспечение соблюдения соглашений может осуществляться вручную (т. е. посредством проверки кода ) или с помощью автоматизированных инструментов.

Спецификация

Некоторые утверждают, что написание спецификации программы , описывающей ее поведение, может предотвратить ошибки.

Некоторые утверждают, что формальные спецификации нецелесообразны для чего-либо, кроме самых коротких программ, из-за проблем комбинаторного взрыва и неопределенности .

Тестирование программного обеспечения

Одной из целей тестирования программного обеспечения является поиск ошибок.

Измерения во время тестирования могут дать оценку количества оставшихся вероятных ошибок. Это становится тем надежнее, чем дольше продукт тестируется и разрабатывается. [ необходима цитата ]

Agile-практики

Agile разработка программного обеспечения может включать частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.

При разработке через тестирование (TDD) модульные тесты пишутся во время написания производственного кода, и производственный код не считается завершенным, пока все тесты не будут успешно завершены.

Статический анализ

Инструменты для статического анализа кода помогают разработчикам, проверяя текст программы за пределами возможностей компилятора, чтобы обнаружить потенциальные проблемы. Хотя в целом проблема поиска всех ошибок программирования с учетом спецификации неразрешима (см. проблему остановки ), эти инструменты используют тот факт, что программисты-люди склонны часто делать определенные виды простых ошибок при написании программного обеспечения.

Инструментарий

Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для поиска проблем, таких как узкие места , либо для обеспечения уверенности в правильной работе, могут быть встроены в код явно (возможно, просто как утверждение PRINT "I AM HERE"), или предоставлены в качестве инструментов. Часто бывает неожиданно обнаружить, где больше всего времени занимает фрагмент кода, и это удаление предположений может привести к переписыванию кода.

С открытым исходным кодом

Разработка с открытым исходным кодом позволяет любому изучать исходный код. Школа мысли, популяризированная Эриком С. Рэймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало или не иметь ошибок, чем другое программное обеспечение, потому что «при достаточном количестве глаз все ошибки неглубоки». [12] Однако это утверждение было оспорено: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малопонятном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не значит, что они имеют право это делать». [13] Примером ошибки программного обеспечения с открытым исходным кодом была уязвимость OpenSSL 2008 года в Debian .

Отладка

Отладка может быть важной частью жизненного цикла разработки программного обеспечения . Морис Уилкс , один из первых пионеров вычислительной техники, описал свое осознание в конце 1940-х годов, что «большую часть оставшейся жизни я собираюсь потратить на поиск ошибок в собственных программах». [14]

Программа, известная как отладчик, может помочь программисту обнаружить неисправный код, исследуя внутреннюю работу программы, например, выполняя код построчно и просматривая значения переменных.

В качестве альтернативы использованию отладчика код может быть оснащен логикой для вывода отладочной информации для отслеживания выполнения программы и просмотра значений. Вывод обычно осуществляется на консоль , в окно , файл журнала или на аппаратный вывод (например, светодиод ).

Некоторые утверждают, что обнаружение ошибки — это своего рода искусство.

Нередко ошибка в одном разделе программы приводит к сбоям в другом разделе, [ требуется ссылка ] , что затрудняет отслеживание, в, казалось бы, не связанной части системы. Например, ошибка в процедуре графического рендеринга приводит к сбою процедуры ввода-вывода файла .

Иногда самая сложная часть отладки — это поиск причины ошибки. После обнаружения исправить проблему иногда легко, если не тривиально.

Иногда ошибка не является изолированным недостатком, а представляет собой ошибку мышления или планирования со стороны программистов. Часто такая логическая ошибка требует переделки или переписывания раздела программы.

Некоторые утверждают, что пошаговый просмотр кода и представление или транскрипция процесса его выполнения в рамках проверки кода часто позволяют обнаружить ошибки, даже не воспроизводя их как таковые.

Обычно первым шагом в поиске ошибки является ее надежное воспроизведение. Если программист не может воспроизвести проблему, он не может найти причину ошибки и, следовательно, не может ее исправить.

Некоторые ошибки выявляются при вводе данных, которые программисту может быть сложно воссоздать. Одной из причин смертельных случаев на радиационной машине Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; потребовались дни практики, чтобы научиться это делать, поэтому ошибка не проявлялась при тестировании или когда производитель пытался ее воспроизвести. Другие ошибки могут перестать возникать всякий раз, когда настройка дополняется для помощи в поиске ошибки, например, при запуске программы с отладчиком; их называют гейзенбагами (шутливо названными в честь принципа неопределенности Гейзенберга ).

Начиная с 1990-х годов, особенно после катастрофы самолета Ariane 5 Flight 501 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода путем абстрактной интерпретации . [15]

Часто ошибки возникают во время кодирования, но неисправная проектная документация может стать причиной ошибки. В некоторых случаях изменения в коде могут устранить проблему, даже если код больше не соответствует документации.

Во встраиваемых системах программное обеспечение часто модифицируется для обхода аппаратной ошибки, поскольку это дешевле, чем модификация оборудования.

Управление

Пример истории ошибок ( данные проекта GNU Classpath ). Новая ошибка изначально неподтвержденная. После подтверждения воспроизводимости она изменяется на подтвержденную . После устранения проблемы она изменяется на исправленную .

Управление ошибками осуществляется посредством таких действий, как документирование, категоризация, назначение, воспроизведение, исправление и выпуск исправленного кода.

Инструменты часто используются для отслеживания ошибок и других проблем с программным обеспечением. Обычно команда разработчиков программного обеспечения использует разные инструменты для отслеживания своей рабочей нагрузки , а служба поддержки клиентов — для отслеживания отзывов пользователей . [16]

Отслеживаемый элемент часто называют bug , defect , ticket , issue , feature , или для гибкой разработки программного обеспечения story или epic . Элементы часто классифицируются по таким аспектам , как серьезность, приоритет и номер версии .

В процессе, который иногда называют сортировкой , для каждой ошибки делается выбор, следует ли ее исправлять и когда, на основе такой информации, как серьезность и приоритет ошибки, а также внешних факторов, таких как графики разработки. Обычно сортировка не включает расследование причины. Сортировка может происходить регулярно. Обычно сортировка состоит из обзора новых ошибок с момента предыдущей сортировки и, возможно, всех открытых ошибок. Участниками могут быть менеджер проекта, менеджер по разработке, менеджер по тестированию, менеджер по сборке и технические эксперты. [17] [18]

Серьёзность

Серьезность — это мера воздействия, которое оказывает ошибка. [19] Это воздействие может выражаться в потере данных, финансах, потере деловой репутации и напрасных усилиях. Уровни серьезности не стандартизированы, но различаются в зависимости от контекста, например, отрасли и инструмента отслеживания. Например, сбой в видеоигре имеет иное воздействие, чем сбой на банковском сервере. Уровни серьезности могут быть следующими: сбой или зависание , отсутствие обходного пути (пользователь не может выполнить задачу), наличие обходного пути (пользователь все равно может выполнить задачу), визуальный дефект (например, опечатка) или ошибка документации . Другой пример набора серьезностей: критический , высокий , низкий , блокирующий , тривиальный . [20] Серьезность ошибки может быть отдельной категорией по отношению к ее приоритету для исправления, или обе могут быть количественно оценены и управляться отдельно.

Ошибка, достаточно серьезная, чтобы задержать выпуск продукта, называется « остановкой шоу» . [21] [22]

Приоритет

Приоритет описывает важность устранения ошибки по отношению к другим ошибкам. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например критический , высокий , низкий и отложенный . Значения могут быть похожими или идентичными оценкам серьезности, хотя приоритет — это другой аспект.

Приоритет может быть комбинацией серьезности ошибки с уровнем усилий по ее исправлению. Ошибка с низкой серьезностью, но которую легко исправить, может получить более высокий приоритет, чем ошибка со средней серьезностью, требующая значительно больших усилий по ее исправлению.

Пластырь

Ошибки достаточно высокого приоритета могут потребовать специального выпуска, который иногда называют патчем .

Технический релиз

Выпуск программного обеспечения, в котором основное внимание уделяется исправлению ошибок, можно назвать выпуском с обслуживанием , чтобы отличать его от выпуска, в котором основное внимание уделяется новым функциям или другим изменениям.

Известная проблема

Распространенной практикой является выпуск программного обеспечения с известными, низкоприоритетными ошибками или другими проблемами. Возможные причины включают, но не ограничиваются:

Подразумеваемое

Объем и тип ущерба, который может нанести программная ошибка, влияет на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемые космические полеты , авиация , ядерная энергетика , здравоохранение , общественный транспорт или автомобильная безопасность , поскольку программные недостатки могут привести к травмам или даже смерти человека, такое программное обеспечение будет подвергаться гораздо более тщательному контролю и контролю качества, чем, например, веб-сайт интернет-магазина. В таких приложениях, как банковское дело, где программные недостатки могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также важнее, чем, скажем, приложение для редактирования фотографий.

Помимо ущерба, наносимого ошибками, часть их стоимости обусловлена ​​усилиями, вложенными в их исправление. В 1978 году Лиенц и др. показали, что в среднем проекты инвестируют 17 процентов усилий по разработке в исправление ошибок. [25] В 2020 году исследование репозиториев GitHub показало, что в среднем этот показатель составляет 20%. [26]

Расходы

В 1994 году Центр космических полетов имени Годдарда НАСА сумел сократить среднее количество ошибок с 4,5 на 1000 строк кода ( SLOC ) до 1 на 1000 SLOC. [27]

Другое исследование, проведенное в 1990 году, показало, что исключительно хорошие процессы разработки программного обеспечения могут достигать показателей отказов при развертывании всего лишь 0,1 на 1000 SLOC. [28] Эта цифра повторяется в литературе, такой как Code Complete Стива Макконнелла , [29] и исследование NASA Flight Software Complexity . [30] Некоторые проекты даже достигли нулевого уровня дефектов: прошивка в пишущей машинке IBM Wheelwriter , которая состоит из 63 000 SLOC, и программное обеспечение Space Shuttle с 500 000 SLOC. [28]

Бенчмарк

Для облегчения воспроизводимых исследований по тестированию и отладке исследователи используют тщательно подобранные тесты ошибок:

Типы

Некоторые заметные типы ошибок:

Ошибка проектирования

Ошибка может быть вызвана недостаточным или неправильным дизайном на основе спецификации. Например, учитывая, что спецификация заключается в алфавитном порядке списка слов, ошибка дизайна может возникнуть, если дизайн не учитывает символы; что приводит к неправильному алфавитному порядку слов с символами.

Арифметика

Числовые операции могут привести к неожиданному выводу, медленной обработке или сбоям. [33] Такая ошибка может быть вызвана неосведомленностью о качествах хранения данных, таких как потеря точности из-за округления , численно нестабильные алгоритмы, арифметическое переполнение и потеря значимости , или неосведомленностью о том, как вычисления обрабатываются различными языками программирования, такими как деление на ноль , которое в некоторых языках может вызывать исключение, а в других может возвращать особое значение, такое как NaN или бесконечность .

Поток управления

Ошибка потока управления , также известная как логическая ошибка, характеризуется кодом, который не завершается ошибкой, но и не имеет ожидаемого поведения, например, бесконечного зацикливания , бесконечной рекурсии , неправильного сравнения в условном выражении , например, использования неправильного оператора сравнения , и ошибки на единицу .

Интерфейс

Параллелизм

Ресурсообеспечение

Синтаксис

Командная работа

В политике

Отчет «Ошибки в системе»

Институт открытых технологий, которым руководит группа New America , [38] опубликовал отчет «Ошибки в системе» в августе 2016 года, в котором говорится, что политики США должны провести реформы, чтобы помочь исследователям выявлять и устранять ошибки в программном обеспечении. Отчет «подчеркивает необходимость реформ в области обнаружения и раскрытия уязвимостей программного обеспечения». [39] Один из авторов отчета заявил, что Конгресс не сделал достаточно для решения проблемы уязвимости программного обеспечения в киберпространстве, хотя Конгресс принял ряд законопроектов для борьбы с более масштабной проблемой кибербезопасности. [39]

Правительственные исследователи, компании и эксперты по кибербезопасности — это те люди, которые обычно обнаруживают недостатки программного обеспечения. В отчете содержится призыв к реформированию законов о компьютерных преступлениях и авторских правах. [39]

В докладе говорится, что Закон о компьютерном мошенничестве и злоупотреблениях, Закон об авторском праве в цифровую эпоху и Закон о конфиденциальности электронных коммуникаций криминализируют и устанавливают гражданско-правовые санкции за действия, которые исследователи безопасности регулярно совершают при проведении законных исследований в области безопасности. [39]

В популярной культуре

Смотрите также

Ссылки

  1. ^ "Отчет комиссии по расследованию аварии ARIANE 5 Flight 501". Европейское космическое агентство . Отчет комиссии по расследованию аварии Ariane 501 (33–1996). 23 июля 1996 г.
  2. Саймон Роджерсон (апрель 2002 г.). «Катастрофа вертолета «Чинук»». Журнал IMIS . 12 (2). Архивировано из оригинала 15 сентября 1993 г. Получено 27 мая 2024 г.Альтернативный URL-адрес
  3. ^ «Скандал в почтовом отделении разрушил жизни, сообщается в расследовании». BBC News . 14 февраля 2022 г.
  4. ^ "Ошибки в программном обеспечении дорого обходятся экономике США". 10 июня 2009 г. Архивировано из оригинала 10 июня 2009 г. Получено 24 сентября 2012 г.
  5. ^ "Testing experience : te : журнал для профессиональных тестировщиков". Testing Experience . Германия: testingexperience: 42. Март 2012. ISSN  1866-5705. (требуется подписка)
  6. ^ abcdefghi 610.12-1990: Стандартный глоссарий терминологии разработки программного обеспечения IEEE . ИИЭЭ . 31 декабря 1990 г. doi :10.1109/IEESTD.1990.101064. ISBN 978-0-7381-0391-4.
  7. ^ "Новости SEI сентябрь 1999". SEI Interactive . 2 (3). Университет Карнеги-Меллона : Институт программной инженерии . 1 сентября 1999.
  8. ^ Грегг Кейзер (21 апреля 2011 г.). «Apple сталкивается с вопросами Конгресса по поводу отслеживания iPhone». Computerworld .
  9. Грегг Кайзер (27 апреля 2011 г.). «Apple отрицает отслеживание пользователей iPhone, но обещает изменения». Computerworld .
  10. ^ Дорота Хейзинга; Адам Колава (сентябрь 2007 г.). Автоматизированное предотвращение дефектов: лучшие практики в управлении программным обеспечением. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  11. ^ Макдональд, Марк; Муссон, Роберт; Смит, Росс (2007). Практическое руководство по предотвращению дефектов . Microsoft Press. стр. 480. ISBN 978-0-7356-2253-1.
  12. ^ "Release Early, Release Frequency" Архивировано 14 мая 2011 г. в Wayback Machine , Эрик С. Рэймонд , Собор и базар
  13. ^ "Wide Open Source" Архивировано 29 сентября 2007 г., на Wayback Machine , Элиас Леви , SecurityFocus , 17 апреля 2000 г.
  14. ^ "Цитаты Мориса Уилкса". QuoteFancy . Получено 28 апреля 2024 г. .
  15. ^ "История PolySpace Technologies". christele.faure.pagesperso-orange.fr . Получено 1 августа 2019 г. .
  16. ^ Аллен, Митч (май–июнь 2002 г.). «Основы отслеживания ошибок: руководство для начинающих по составлению отчетов и отслеживанию дефектов». Журнал Software Testing & Quality Engineering . Том 4, № 3. стр. 20–24 . Получено 19 декабря 2017 г.
  17. ^ Рекс Блэк (2002). Управление процессом тестирования (2-е изд.). Wiley India Pvt. Limited. стр. 139. ISBN 978-8126503131. Получено 19 июня 2021 г. .
  18. ^ Крис Вандер Мей (2012). Доставка величия — Практические уроки по созданию и запуску выдающегося программного обеспечения, полученные на работе в Google и Amazon. O'Reilly Media . С. 79–81. ISBN 978-1449336608.
  19. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (1 октября 2020 г.). "Эффективная модель извлечения признаков для повышения производительности проверки обнаружения дублирующихся отчетов об ошибках в системах сортировки ошибок программного обеспечения". Information and Software Technology . 126 : 106344. doi : 10.1016/j.infsof.2020.106344. S2CID  219733047.
  20. ^ "5.3. Анатомия жука". bugzilla.org . Архивировано из оригинала 23 мая 2013 г.
  21. ^ Джонс, Уилбур Д. младший, ред. (1989). «Show stopper». Глоссарий: сокращения и термины оборонного приобретения (4-е изд.). Форт Белвуар, Вирджиния: Министерство обороны, Колледж управления оборонными системами . стр. 123. hdl :2027/mdp.39015061290758 – через Hathitrust.
  22. ^ Закари, Г. Паскаль (1994). Шоу-стоппер!: головокружительная гонка за создание Windows NT и следующего поколения в Microsoft . Нью-Йорк: The Free Press . С. 158. ISBN 0029356717– через archive.org.
  23. ^ "The Next Generation 1996 Lexicon A to Z: Slipstream Release". Next Generation . № 15. Март 1996. С. 41.
  24. ^ Карр, Николас (2018). «'Это не ошибка, это фича'. Банальность — или просто правильно?». wired.com .
  25. ^ Lientz, BP; Swanson, EB; Tompkins, GE (1978). «Характеристики сопровождения прикладного программного обеспечения». Communications of the ACM . 21 (6): 466–471. doi : 10.1145/359511.359522 . S2CID  14950091.
  26. ^ Амит, Идан; Фейтельсон, Дрор Г. (2020). «Метрика качества кода вероятности корректирующего подтверждения». arXiv : 2007.10912 [cs.SE].
  27. ^ "Обзор лаборатории программной инженерии" (PDF) . Серия "Лаборатория программной инженерии" (SEL-94-005). Декабрь 1994 г.
  28. ^ ab Cobb, Richard H.; Mills, Harlan D. (1990). «Инженерное программное обеспечение под статистическим контролем качества». IEEE Software . 7 (6): 46. doi :10.1109/52.60601. ISSN  1937-4194. S2CID  538311 – через University of Tennessee – Harlan D. Mills Collection.
  29. ^ Макконнелл, Стивен С. (1993). Code Complete . Редмонд, Вашингтон: Microsoft Press. стр. 611. ISBN 978-1556154843– через archive.org. (Кобб и Миллс 1990)
  30. ^ Джерард Хольцман (5 марта 2009 г.). "Приложение D – Сложность программного обеспечения" (PDF) . Заключительный отчет: исследование NASA по сложности программного обеспечения для полетов (ред. Дэниел Л. Дворак) . Программа технического совершенства Управления главного инженера NASA.
  31. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). «The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs». IEEE Transactions on Software Engineering . 41 (12): 1236–1256. doi : 10.1109/TSE.2015.2454513 . ISSN  0098-5589.
  32. ^ Джаст, Рене; Джалали, Дариуш; Эрнст, Майкл Д. (2014). «Defects4J: база данных существующих неисправностей для проведения контролируемых исследований по тестированию программ Java». Труды Международного симпозиума по тестированию и анализу программного обеспечения 2014 г. – ISSTA 2014 г. . стр. 437–440. CiteSeerX 10.1.1.646.3086 . doi :10.1145/2610384.2628055. ISBN  9781450326452. S2CID  12796895.
  33. ^ Энтони Ди Франко; Хуэй Го; Синди Рубио-Гонсалес (23 ноября 2017 г.). Всестороннее исследование характеристик реальных числовых ошибок . 2017 32-я Международная конференция IEEE / ACM по автоматизированной программной инженерии (ASE). IEEE . doi :10.1109/ASE.2017.8115662.
  34. ^ Кимблер, К. (1998). Взаимодействие функций в телекоммуникациях и программных системах V. IOS Press. стр. 8. ISBN 978-90-5199-431-5.
  35. ^ Сайед, Махбубур Рахман (2001). Мультимедийные сети: технология, управление и приложения: технология, управление и приложения. Idea Group Inc (IGI). стр. 398. ISBN 978-1-59140-005-9.
  36. ^ Ву, Чван-Хва (Джон); Ирвин, Дж. Дэвид (2016). Введение в компьютерные сети и кибербезопасность. CRC Press. стр. 500. ISBN 978-1-4665-7214-0.
  37. ^ RFC 1263: «Расширения TCP считаются вредоносными», цитата: «Время распространения новой версии протокола на все хосты может быть довольно долгим (фактически вечностью). ... Если есть хоть малейшая несовместимость между старой и новой версиями, может возникнуть хаос».
  38. ^ Уилсон, Энди; Шульман, Росс; Бэнкстон, Кевин; Герр, Трей. «Ошибки в системе» (PDF) . Институт открытой политики . Архивировано (PDF) из оригинала 21 сентября 2016 г. . Получено 22 августа 2016 г. .
  39. ^ abcd Розенс, Трейси (12 августа 2016 г.). «Киберреформы, необходимые для усиления обнаружения и раскрытия ошибок программного обеспечения: отчет New America – Homeland Preparedness News» . Получено 23 августа 2016 г.
  40. ^ Уллман, Эллен (2004). Ошибка . Пикадор . ISBN 978-1-250-00249-5.

Внешние ссылки