Программная ошибка - Software bug

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

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

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

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

История

Среднеанглийское слово bugge является основой для терминов « bugbear » и « bugaboo », используемых для обозначения монстра.

Термин «ошибка» для описания дефектов был частью инженерного жаргона с 1870-х годов и предшествовал электронным компьютерам и компьютерному программному обеспечению; возможно, первоначально он использовался в аппаратной инженерии для описания механических неисправностей. Например, Томас Эдисон написал следующие слова в письме своему коллеге в 1878 году:

Так было со всеми моими изобретениями. Первый шаг — это интуиция, и она приходит со взрывом, затем возникают трудности — эта штука дает сбой, и [это] тогда «Жуки» — как называются такие маленькие недостатки и трудности — проявляют себя и месяцы напряженного наблюдения, изучения и труд необходимы, прежде чем будет достигнут коммерческий успех или неудача.

Baffle Ball , первая механическая игра в пинбол , рекламировалась как «свободная от ошибок» в 1931 году. Проблемы с военной экипировкой во время Второй мировой войны назывались ошибками (или глюками ). В книге, опубликованной в 1942 году, Луиза Дикинсон Рич , говоря о механизированной машине для резки льда , сказала: «Распиловка льда была приостановлена ​​до тех пор, пока не появится создатель, который выведет жуков из его любимицы».

Исаак Азимов использовал термин «жук» для обозначения проблем с роботом в своем рассказе « Поймай этого кролика », опубликованном в 1944 году.

Страница из журнала электромеханического компьютера Harvard Mark II с изображением мертвой бабочки, удаленной из устройства.

Термин «ошибка» был использован в отчете пионера компьютеров Грейс Хоппер , которая обнародовала причину неисправности в первом электромеханическом компьютере. Типичная версия этой истории такова:

В 1946 году, когда Хоппер уволили с действительной службы, она поступила на Гарвардский факультет в вычислительную лабораторию, где продолжила свою работу над Mark II и Mark III . Операторы проследили ошибку в Mark II до мотылька , пойманного в реле, придумав термин « ошибка » . Эта ошибка была тщательно удалена и записана в бортовой журнал. Исходя из первой ошибки, сегодня мы называем ошибки или сбои в программе ошибкой .

Хоппер не нашла ошибку, как она с готовностью признала. В бортовом журнале стояла дата 9 сентября 1947 года. Нашедшие его операторы, включая Уильяма «Билла» Бёрка, позднее работавшего в Военно- морской лаборатории вооружений , Дальгрен, Вирджиния , были знакомы с инженерным термином и забавлялись тем, что хранили насекомое с пометкой «Первый реальный случай обнаружения ошибки». Хоппер любил рассказывать эту историю. Этот бортовой журнал с прикрепленным мотыльком является частью коллекции Смитсоновского национального музея американской истории .

Родственный термин « отладка », по-видимому, также появился раньше, чем его использование в вычислительной технике: этимология этого слова в Оксфордском словаре английского языка содержит свидетельство 1945 года в контексте авиационных двигателей.

Представление о том, что программное обеспечение может содержать ошибки, восходит к заметкам Ады Лавлейс 1843 года об аналитической машине , в которых она говорит о возможности ошибочности программных «карточек» для аналитической машины Чарльза Бэббиджа :

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

Отчет "Ошибки в системе"

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

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

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

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

Хотя использование термина «ошибка» для описания ошибок программного обеспечения является обычным явлением, многие предлагают отказаться от него. Один из аргументов состоит в том, что слово «ошибка» оторвано от того значения, что человек вызвал проблему, и вместо этого подразумевает, что дефект возник сам по себе, что приводит к толчку отказаться от термина «ошибка» в пользу таких терминов, как «дефект» с ограниченным успехом. С 1970-х годов Гэри Килдалл несколько шутливо предложил использовать термин «грубая ошибка».

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

Различные этапы «ошибки» во всем цикле могут быть описаны как «ошибки», «аномалии», «сбои», «сбои», «ошибки», «исключения», «сбои», «глюки», «баги». , «дефекты», «инциденты» или «побочные эффекты».

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

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

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

Опечатки

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

Методологии разработки

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

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

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

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

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

Поддержка языков программирования

Языки программирования включают функции, помогающие предотвратить ошибки, такие как статические системы типов , ограниченные пространства имен и модульное программирование . Например, когда программист пишет (псевдокод) LET REAL_VALUE PI = "THREE AND A BIT", хотя это может быть синтаксически правильным, код не проходит проверку типа . Компилируемые языки улавливают это без запуска программы. Интерпретируемые языки перехватывают такие ошибки во время выполнения. Некоторые языки намеренно исключают функции, которые легко приводят к ошибкам, за счет снижения производительности: общий принцип заключается в том, что почти всегда лучше писать более простой и медленный код, чем непостижимый код, который работает немного быстрее, особенно учитывая, что затраты на обслуживание значительны. . Например, язык программирования Java не поддерживает арифметику указателей ; реализации некоторых языков, таких как Pascal и языки сценариев, часто имеют проверку границ массивов во время выполнения, по крайней мере, в отладочной сборке.

Анализ кода

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

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

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

Тестирование

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

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

Отладка

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

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

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

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

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

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

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

С 1990-х годов, особенно после катастрофы самолета Ariane 5 Flight 501 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода с помощью абстрактной интерпретации .

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

Контрольный показатель ошибок

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

  • эталон Сименс
  • ManyBugs — это тест на 185 ошибок C в девяти программах с открытым исходным кодом.
  • Defects4J — это тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие патчи, которые охватывают различные типы патчей.
  • BEARS — это тест неудачных сборок с непрерывной интеграцией, в котором основное внимание уделяется сбоям тестов. Он был создан путем мониторинга сборок из проектов с открытым исходным кодом на Travis CI .

Управление ошибками

Управление ошибками включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении — ошибки, запросы на усовершенствование и даже целые выпуски — обычно отслеживаются и управляются с помощью систем отслеживания ошибок или систем отслеживания проблем . Добавленные элементы могут называться дефектами, тикетами, проблемами или, следуя парадигме гибкой разработки , историями и эпиками. Категории могут быть объективными, субъективными или комбинированными, например, номер версии , область программного обеспечения, серьезность и приоритет, а также тип проблемы, например запрос функции или ошибка.

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

Строгость

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

приоритет

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

Релизы программного обеспечения

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

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

  • Крайний срок должен быть соблюден, а ресурсов недостаточно, чтобы исправить все ошибки к этому сроку.
  • Ошибка уже исправлена ​​в ближайшем выпуске, и она не имеет высокого приоритета.
  • Изменения, необходимые для исправления ошибки, обходятся слишком дорого или затрагивают слишком много других компонентов, что требует серьезного тестирования.
  • Можно подозревать или знать, что некоторые пользователи полагаются на существующее ошибочное поведение; предлагаемое исправление может привести к критическим изменениям .
  • Проблема заключается в области, которая устареет в следующем выпуске; исправлять не нужно.
  • «Это не баг, это фича». Возникло недопонимание между ожидаемым и воспринимаемым поведением или недокументированной функцией .

Типы

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

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

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

Арифметика

Логика

Синтаксис

  • Использование неправильного оператора, например, выполнение присваивания вместо проверки на равенство . Например, в некоторых языках x=5 установит значение x равным 5, а x==5 проверит, равен ли x в настоящее время 5 или другому числу. Интерпретируемые языки допускают сбой такого кода. Компилируемые языки могут обнаруживать такие ошибки до начала тестирования.

Ресурс

Многопоточность

Взаимодействие

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

  • Нераспространяемые обновления; например, программист изменяет "myAdd", но забывает изменить "mySubtract", который использует тот же алгоритм. Эти ошибки смягчаются философией « Не повторяйся ».
  • Комментарии устарели или неверны: многие программисты предполагают, что комментарии точно описывают код.
  • Различия между документацией и продуктом.

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

Объем и тип ущерба, который может причинить программная ошибка, естественным образом влияет на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемый космический полет или автомобильная безопасность , поскольку недостатки программного обеспечения могут привести к травмам или даже смерти человека, такое программное обеспечение будет подвергаться гораздо большему контролю и контролю качества, чем, например, веб-сайт онлайн-покупок. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий. Технологическому центру Software Assurance НАСА удалось сократить количество ошибок до менее чем 0,1 на 1000 строк кода ( SLOC ), но это было невозможно для проектов в деловом мире.

Согласно исследованию НАСА « Сложность полетного программного обеспечения », «исключительно хороший процесс разработки программного обеспечения может свести дефекты к минимуму до 1 дефекта на 10 000 строк кода».

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

Известные ошибки

Ряд программных ошибок стал широко известен, как правило, из-за их серьезности: примеры включают различные авиакатастрофы космических и военных самолетов. Возможно, самой известной ошибкой является проблема 2000 года , также известная как ошибка 2000 года, из-за которой опасались, что мировой экономический коллапс произойдет в начале 2000 года в результате того, что компьютеры думают, что это был 1900 год. (В конце концов , серьезных проблем не возникло.) Сбой в торговле акциями в 2012 году был связан с одной из таких несовместимостей между старым API и новым API.

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

  • Как в романе 1968 года « 2001: Космическая одиссея» , так и в соответствующем фильме 1968 года « 2001: Космическая одиссея » бортовой компьютер космического корабля HAL 9000 пытается убить всех членов экипажа. В последующем романе 1982 года « Одиссея 2 » и сопутствующем фильме 1984 года « 2010 » выясняется, что это действие было вызвано тем, что компьютер был запрограммирован с двумя противоречивыми целями: полностью раскрыть всю свою информацию и сохранить истинная цель полета в тайне от экипажа; этот конфликт заставил HAL стать параноиком и в конечном итоге склонным к убийству.
  • В английской версии песни Nena 1983 года 99 Luftballons (99 Red Balloons) из-за «ошибок в программном обеспечении» выпуск группы из 99 красных воздушных шаров ошибочно принимается за запуск ядерной ракеты противника, что требует эквивалентной реакции на запуск. , что привело к катастрофе.
  • В американской комедии 1999 года « Офисное пространство » трое сотрудников пытаются использовать озабоченность своей компании исправлением компьютерной ошибки Y2K, заражая компьютерную систему компании вирусом, который отправляет округленные пенни на отдельный банковский счет. План имеет неприятные последствия, поскольку у самого вируса есть собственная ошибка, из-за которой на счет преждевременно отправляются большие суммы денег.
  • Роман Эллен Ульман «Ошибка » 2004 года рассказывает о попытке программиста найти неуловимую ошибку в приложении базы данных.
  • Канадский фильм 2008 года Control Alt Delete рассказывает о программисте в конце 1999 года, пытающемся исправить ошибки в своей компании, связанные с проблемой 2000 года.

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

использованная литература

внешняя ссылка