Программист и ошибки — актуально во все времена

    Годы бегут, компьютеры становятся мощнее, листинги программ длиннее, а программисты всё ещё допускают те же самые ошибки (или же сталкиваются с ними)… Предлагаю разобраться с основными типами ошибок и причинами, по которым они происходят

    Чтобы максимально раскрыть смысл фразы "актуально во все времена", в качестве иллюстрирующих примеров будут приведены сведения времён старой доброй DOS :), поэтому материал рекомендуется к прочтению любителям ностальгии

    Какие же бывают типы ошибок?

    Тип №1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании

    • В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
    ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
    Однако в действительности работа данной функции должна иметь следующий вид:
    ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)

    В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена :)

    • В русифицированном варианте Norton Utilities (версия 7.0, фирма Symantec) в утилите форматирования sformat при задании опции:
    Системные файлы: [Не ставить…]
    при форматировании выдаётся сообщение:
    Системные файлы: Ставить
    и наоборот, при задании опции:
    Системные файлы: [Ставить…]
    при форматировании выдаётся сообщение:
    Системные файлы: Не ставить

    • Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из-за ошибки в программе – вместо требуемой в операторе запятой программист поставил точку. Вот как был записан этот оператор:
    DO 50 I = 12.525
    На самом же деле он должен был выглядеть следующим образом:
    DO 50 I = 12,525
    В программе на Фортране IV требовался цикл, а программист поставил точку, а в результате получилось присваивание значения 12,525 неявной переменной DO50I (пробелы в Фортране игнорируются) [ Спасибо за этот ценный комментарий-поправку хабраюзеру rexxer2 ]

    • Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.

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

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

    • Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» :)

    Тип №2. Ошибки, возникающие при вводе в компьютер неверных данных

    Весьма популярные ошибки, предотвращение которых известно под названием «защита от дурака»

    • В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.

    • Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами

    Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу.

    • Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.

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

    Тут, в принципе, всё обстоит точно так же, как и 20 лет назад: в процессе эксплуатации компьютерной системы возможно физическое повреждение накопителя, выход из строя блока питания, отключение электроэнергии, колебание напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жёстком диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером и многое другое. Для предотвращения ошибок данного типа используют системы, в которых одновременно работают несколько компьютеров, дублирующих друг друга, в компьютеры устанавливают два и более параллельно работающих накопителя (вспоминаем RAID-массивы), аппаратуру подключают к источникам бесперебойного питания, которые обеспечивают его работу при отключении электроэнергии или колебаниях напряжения электрической сети и т.д. и т.п.

    Тип №5. Выход из строя или сбои в работе измерительных приборов и датчиков, используемых при управлении какими-либо техническими системами и технологическими процессами

    • В июле 1985 года произошло преждевременное отключение компьютера одного из основных двигателей американского космического корабля «Челленджер» (Шаттл), едва не закончившееся катастрофой. Положение спас командир корабля, сумевший на двух работающих основных двигателях и двух менее мощных двигателях для маневрирования вывести «Челленджер» на орбиту. Причина же заключалась в том, что один из трёх бортовых компьютеров, управляющих двигателями (на каждый двигатель по компьютеру), был «обманут» вышедшим из строя датчиком, измеряющим температуру газа в двигателе. Для устранения подобных неполадок в будущем на следующих космических кораблях серии Шаттл были установлены датчики изменённой конструкции.

    • При запуске французской ракеты нового поколения «Ариан-5» примерно на 37-й секунде полёта компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты. Исходя из этой информации, компьютер начал корректировать траекторию полёта для того, чтобы компенсировать не существующую на самом деле погрешность. Ракета стала отклоняться от курса, что привело к возрастанию нагрузок на её корпус. В результате чрезмерных нагрузок верхняя часть ракеты отвалилась, и по команде с земли ракета была взорвана.

    Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор

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

    • Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением АСУ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации АСУ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
    Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.

    Подводим итоги

    Анализ приведённых типов ошибок показывает, что основными задачами, стоящими перед разработчиками программного обеспечения в плане повышения его надёжности, является:
    • устранение ошибок, допущенных при разработке программного обеспечения (1-й тип ошибок);
    • проектирование программного обеспечения с учётом человеческого фактора, то есть таким образом, чтобы оно было защищено от «дурака» (2-й тип ошибок). При этом «свалять дурака» могут не только пользователи, работающие за компьютером, но и приборы и датчики, от которых компьютер принимает информацию при управлении техническими или иными системами (5-й тип ошибок);
    • использование известных мер безопасности для снижения вероятности переноса компьютерных вирусов (3-й тип ошибок) с программами, передаваемыми в эксплуатацию (в практике распространения программ известны случаи, когда разработчики этих программ записывают дистрибутивы на заражённых вирусами компьютерах).

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

    Надеюсь, данный материал окажется полезным. Желаю всем делать поменьше ошибок, ведь это особенно актуально в нынешние кризисные времена :^)

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

    Комментарии 66

      +5
      Странно что программиста устроившего диверсию на заводе не посадили :-)
        +1
        Ещё больше странности, что это конец 80-х, начало 90-х… Тогда вроде не рабочим делали, а именно «дисквалифицировали без возможности восстановления».
          +10
          Да как раз тогда уже бардак был в стране полный.
          А программист наверное единственный в Тольятти был, который во всем этом разбирался :)
          0
          Думаю, что тогда статьи за это не нашлось.
            0
            За сабботаж можно было и к стенке стать, как шпион :-)
              0
              Его судили по статье 98 часть 2 УК

              Получил 3 года условно + выплаты в размере зарплаты рабочих конвейера за период вызванного им простоя. Поскольку экономика в СССР была в определенном смысле виртуальна, ущерб от невыпущенной продукции на него не повесили.

              Про перевод в рабочие (того самого конвейера — шоб знал) — тоже все верно.
                +1
                Может быть вы и имя знаете, и где почитать больше?
            –1
            Мне кажется это байка.
              –1
              Это известный достоверный факт
            0
            Самая плохая ошибка — допущенная в ТЗ
              0
              Ну дак, еще Брукс в Мифическом человеко-месяце говорил, что, чем раньше этап создания ПО, на котором допущена ошибка, тем сложнее и дороже будет ее исправить.
              0
              4 и 5 тип ошибок к программистам явно не относится, да и с вирусами вряд ли программисты что-то смогут сделать.
                0
                Могут контролировать целостность данных и обеспечить нормальное API для резервного копирования.
                  0
                  Ну почему не относится? Не напрямую, конечно, а косвенно. Аппаратный сбой запросто приведёт к неправильному функционированию ПО

                  Насчёт вирусов — и могут, и делают :) Даже опытный специалист может «влипнуть» в такую историю
                  Кстати, совсем недавно такой инцидент мирового масштаба произошёл, с вирусом Induc (Virus.Win32.Induc.a), под ударом оказалось огромное количество программ, которые стали детектироваться антивирусами как вредоносное ПО…
                  0
                  без тестирования сейчас наврядли вообще программы в производство запускаются
                    +3
                    не все можно предусмотреть.

                    вот еще примеры непредусмотрительности программистов feelovblog.ru/2008/03/09/elektronnye-vojny-ne-za-gorami/
                      0
                      IMHO, здесь тоже хватает исторических анекдотов. К примеру, вот об этом случае я читал ранее:

                      Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся “вверх ногами”.


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

                      Соответственно, вспоминаем про закон 13-го удара…
                        0
                        Мне больше нравится история про самолёт, который летал в районе Мёртвого моря. Высота над уровнем моря там является отрицательной величиной. В один момент значение высоты самолёта составило 0, где-то произошло деление на ноль и бортовой компьютер крашнулся :)
                      +1
                      Спасибо за статью =)
                      Ловите + в карму =)
                        –1
                        >Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
                        за такое надо пальцы отрубать прогерам :/
                          +1
                          ага, а летчик, прощелкавший клювом гору, это ок?
                          И уж если на то пошло не только прогерам, а менеджерам, тестерам, да много еще кому.
                          +1
                          А причём тут прогеры? Обычно данные вводит операторы. Не, может быть, что данные там в константах были зашиты, вот тогда точно надо отрывать :)
                            0
                            А проггеры тут при том, что
                            проектирование программного обеспечения с учётом человеческого фактора

                            Точнее, они не во всех примерах замешаны явно, зато все случаи касаются их косвенно

                            Каюсь, не совсем раскрыл я цель статьи, в результате многие задают вопросы «а при чём тут программисты?»
                            В двух словах: цель была показать все виды ошибок, с которыми могут столкнуться создатели программных продуктов. Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)

                            После публикации довольно-таки оперативно дописал в начале
                            а программисты всё ещё допускают те же самые ошибки (или же сталкиваются с ними)

                            но на этой фразе в скобках мало кто сфокусировал внимание…

                            Ну, значит учту этот момент в будущем :) Ложка дёгтя никогда не помешает
                              0
                              Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)

                              В истории с самолетом никакая программа не давала неправильных результатов и не получала неправильных входных данных.

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

                            Вообще интересная статья, спасибо :)
                              +1
                              Жаль, что из-за ошибок страдают люди.
                                +2
                                > Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего,
                                > из-за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую.
                                Все было ровно наоборот:
                                В программе на Фортране IV требовался цикл
                                DO 50 I = 12,525
                                А программист поставил точку, получился оператор присваивания неявной переменной DO50I (пробелы в Фортране игнорируются)
                                DO 50 I = 12.525
                                  0
                                  Спасибо, очень ценное замечание. Поменял строчки местами

                                  Даже тут не обошлось без ошибок )
                                    0
                                    Строчки-то вы поменяли, а текст видимо нет, написано «вместо требуемой в операторе точки программист поставил запятую». Тут тоже, как я понял нужно поменять )
                                      0
                                      Слегка подтормаживаю :) Как раз подправлял это место, сейчас вроде уже всё

                                      Хм, неплохо бы найти на Хабре кого-то, кто работал с Works 2.0 и Norton Utilities 7.0, а то у меня уже сомнения закрались и по поводу этих примеров…
                                        +1
                                        В примерах про MS Works и NU это ошибки не программеров, а авторов документации. Так что непонятно, зачем они в этой статье.
                                  +2
                                  Про Луну конечно повеселило :)) — ничего так «Вражеская ракетка» :))
                                    0
                                    Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.

                                    На эту тему я не встречал внятных публикаций, но предположительно заражен вирусом был компьютер, где хранились оцифрованные диагностические изображения. Причем вроде как нет особой уверенности, что это вообще был вирус, а не сбой оборудования.
                                      +2
                                      Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» :)


                                      Байка. Реальность такова: 5.10.1960 Луна действительно попала в поле зрения одного из радаров BMEWS, и выданные системой данные изумили операторов. Никакой тревоги поднято не было. И это не было первое дежурство ни данного радара, ни, тем более, всей системы. По результатам систему скорректировали, чтобы она игнорировала слишком далекие объекты.
                                        +1
                                        Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами

                                        В действительности причиной катастрофы стал комплекс причин, которые давно известны.
                                          0
                                          И? Посмотрел, там тоже написано про координаты
                                          Комплекс комплексом, но роковую роль сыграли неправильные координаты, поэтому я не совсем понял, при чём тут слова «в действительности» :) Предпосылки ввода неверной информации пилотами конечно интересны и как раз составляют «комплекс», но первопричина (суть примера) важнее
                                            +1
                                            Вы читали невнимательно. Были введены ПРАВИЛЬНЫЕ координаты. Просто экипажу забыли сообщить, что сегодня они летят фактически другим маршрутом. Теоретически, это наверняка прошло бы никем не замеченным, если бы не наложились другие факторы.

                                            Unknown to them, the coordinates had been modified earlier that morning to correct the error introduced years previously and undetected until now


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

                                            Сама ошибка — пока ее не исправили — никому годами не мешала.
                                              0
                                              Уяснил. Спасибо
                                          –4
                                          Я в шоке от работы американских программистов в НАСА, я бы их поувольнял без выплаты премий, а особо злостных заставил бы поатить стоимость потернного спутника. Почему они толком ничего не тестируют там? Такое ощущение что не ракету, а какой-то запорожец делают.
                                            +3
                                            Подозреваю, что Вы просто не очень представляете себе, насколько сложной задачей является тестирование таких систем.
                                            –2
                                            Не в тестировании решение проблем, а в создании языков, на которых труднее писать неправильные программы. Тот же Фортран провоцировал на ошибки; PL/1 позволял выполнить как программу вообще почти любой текст. Любимый многими (и мною) Perl не имеет внятной системы документирования и проверки передаваемых функциям аргументов; PHP, Javascript не требуют объявления переменных; С предоставляет неограниченный доступ к памяти.

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

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

                                              Я не буду спорить с оценкой того, насколько программирование с хорошими тестами (не модульными, а тестами вообще — полного спектра) дороже, чем программирование без тестирования — просто потому, что ни я, ни лично мне известные люди никогда не видели ни одной системы, стоящей упоминания, которая была бы сделана без тестирования. Возможно, без тестирования дешевле. Но таких систем, доведенный до внедрения, в природе нет.
                                              +2
                                              Ошибки так же неисчерпаемы, как и атом.
                                              Аксиома. В любой программе есть ошибки.
                                              Закон пропорциональности. Чем более программа необходима, тем больше в ней ошибок.
                                              Следствие. Ошибок не содержит лишь совершенно ненужная программа.
                                              Фундаментальный закон теории ошибок. На ошибках учатся.
                                              Следствие 1. Программист, написавший программу, становится ученым.
                                              Следствие 2. Чем больше программист делает ошибок, тем быстрее он делается ученым.
                                              Следствие 3. Крупный ученый-программист никогда не пишет правильные программы.
                                              Указание начинающему программисту. Если вы с первого раза сумели написать программу, в которой транслятор не обнаружил ни одной ошибки, сообщите об этом системному программисту. Он исправит ошибки в трансляторе.
                                              Закон необходимости ошибок. Программист может обнаружить ошибку только в чужой программе.
                                              Следствие. Ошибке не все равно, кто ее обнаружит.
                                                0
                                                Помню это, нам такое в школе на уроках информатики рассказывали
                                                  0
                                                  Законы Мёрфи — это вообще очень ценная коллекция умных мыслей :)

                                                  imho, книжка с ними вообще должна быть на столе каждого программиста, а лучше всего вообще у каждого человека
                                                  0
                                                  Каким образом Ариана-5 попала в ошибки датчиков, если проблема была в блоке управления?
                                                    0
                                                    Неправильный вопрос. Правильный вопрос: как вообще это попало в статью о программистских ошибках? Я не знаю подробностей об этом случае, но согласно описанию, которое дано выше, программа отработала корректно.
                                                      +1
                                                      подробности такие: скопипастили часть кода из предыдущей версии, которая летала на значительно меньшей скорости, а для полного счастья отключили обработчик переполнений, чтобы работало быстрее. продолжать надо? :)

                                                      en.wikipedia.org/wiki/Ariane_5_Flight_501
                                                        0
                                                        В таком варианте вопросов к уместности. Выходит, что история переврана в статье еще в одном пункте… :(
                                                          0
                                                          вот и я о том же :)
                                                          кстати, я слышал, что про фортран — это байка, т.е. баг такой был, но он никаких серьезных проблем не вызвал: catless.ncl.ac.uk/Risks/9.54.html#subj1
                                                          0
                                                          При чём тут датчики? Ну я опять же читаю вики (спасибо за ссылку :), этот момент описан:
                                                          Specifically, the Ariane 5's greater acceleration caused the back-up and primary inertial guidance computers to crash, after which the launcher's nozzles were directed by spurious data.
                                                            0
                                                            Вы опять все перепутали. Вы пишете:

                                                            получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты


                                                            В действительности датчики сработали корректно и передали ДОСТОВЕРНУЮ информацию. Но программа не смогла ее правильно обработать. И четко указана причина:

                                                            Ariane 5's flight path was considerably different and beyond the range for which the reused computer program had been designed
                                                      0
                                                      Спасибо за отличную статью! Прочитав комментарии заметил, что SCoon у нас специалист по всем серьезным программным ошибкам. :-) Видимо серьезно интересовался в свое время.

                                                      А на самом деле чужие истории — это всегда интересно. Особенно когда они касаются программирования, больших финансовых затрат и хочется сказать «Вау! Как я раньше этого не знал» — однозначно хочется знать.

                                                      Может SCoon сможет поделиться с нами в отдельном хабратопике интересными историями, которые мы еще не знаем?
                                                        0
                                                        Интересная статья, но название к ней мало подходит, так как к программистам многие ошибки не имеют отношения. У самих недавно был случай когда лег домен MS из-за ошибки в памяти сервера.
                                                        +1
                                                        Забавная статья, почти готовый сценарий для Mythbusters: практически в каждом пункте, о котором я что-нибудь знаю, причина переврана. По остальным пунктам пруфлинков в статье нет, поэтому, экстраполируя, представляю себе их качество.

                                                        Странно, что не включили летальный случай с race condition при определении дозы в рентгеновском аппарате.
                                                          0
                                                          Ну насчёт перевирания причин — я уже отписался в соседних комментариях. Причины-то наоборот совпадают, разве что происходило это, как выясняется, менее эффектно, без приукрас :)

                                                          Насчёт proof links — выкладываю, но это будут не гиперссылки + этих источников у меня на руках нет, поэтому я не видел особо смысла их указывать:
                                                          • Мейер Б., Бодуэн К. Методы программирования. В 2-х томах. Т. 2. Пер. франц. М.: Мир. 1982
                                                          • Душа твоя — космонавтика. Газета «Правда», 8 апреля 1989
                                                          • Батурин Ю. М. Проблемы компьютерного права. М.: Юрид. лит.
                                                          • Альфред З. Спектор. Управление процессами. Современный компьютер. Сборник научно-популярных статей. Пер. с англ. М.: Мир. 1986
                                                          • Батурин Ю. М., Жодзишский А. М. Компьютерная преступность и компьютерная безопасность. М.: Юрид. лит, 1991
                                                          • Компьютерное обеспечение для «Ариан-5» требует доводки. Газета «Финансовые известия», 62 (296), 1996
                                                            +1
                                                            Интересно, откуда у вас эти ссылки, если источников у вас нет? Вы записываете всю библиографическую инфу о том, что читаете? :)

                                                            Что касается Ariane 5, есть официальный отчёт комиссии расследования: [ОКР] esamultimedia.esa.int/docs/esa-x-1819eng.pdf

                                                            Исходя из него [ОКР 2.1, 3.1.m-p, 3.2], вывод в вашем посте о том, что «компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты», неверен. Компьютер получил от датчиков совершенно точную информацию, но в дальнейшем ошибки ПО, причём в функции, которая непосредственно на Ariane 5 не нужна произошло переполнение 16 битного целого со знаком, в которое загонялось 64 битное значение с плавающей запятой от датчика и инерционка стала давать неверные данные.

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

                                                            На самом деле проблема вашего поста в стиле подачи материала. Если бы вы не выбрали стиль жёлтой прессы («ААА! В Тибете йоги по 400 лет висят в пещерах кверх ногами!»), а написали бы только то, что происходило на самом деле, то статья была бы очень полезной.

                                                            В частности, по Ariane 5. Вы написали, что причина была в неисправности датчиков. Тогда как причина освещена в [ОКР 3.1.m]: "...but nevertheless retained for _commonality_ _reasons_ and allowed...". Т.е истинная причина: программисты не захотели причесать код и убрать лишнее.
                                                            Согласитесь, что эта причина — гораздо более обща и актуальна, чем неисправность датчиков: сколько раз мы сталкиваемся в ООП с Fragile base class или потомками, в которых доступны неактуальные методы из предков из-за того, что кому-то стало лень нормально скопипастить, отредактировать и оттестировать код вместо связывания через наследование похожих, но несвязываемых сущностей.

                                                            Извиняюсь за черезчур эмоциональный комментарий. :)
                                                          +2
                                                          вот почему им срочно потребовалось высадить людей на Луну!
                                                          Просто установили там систему чтобы правильно отвечала на вопрос «свой/чужой».
                                                          Теперь систему можно не переделывать. Программисты как всегда ленивы. А лень — двигатель прогресса!
                                                            +2
                                                            важная разработка — беспилотный самолет, управление с компа из центра.
                                                            первый испытательный запуск первого образца.
                                                            самолет взлетает, пролетает 10 метров и на полном ходу врезается в землю.
                                                            за секунду до этого выбегает главный программист с криком: «подождите, я знак перепутал...»
                                                              0
                                                              Возможно, вы будете смеятся, но один из безпилотных летатетльных аппаратов, совершая бреющий полёт над Мёртвым Морем, вдруг «сошёл с ума» и «убил себе о море». Как выяснилось создатели программного обеспечения не учли того, что абсолютная высота над уровнем моря может быть и отрицательной.
                                                              А один из моих приятелей был свидетелем того, как управляемая торпеда (по сути ракета только для воды) пыталась «вынырнуть» вместо того что бы «поднырнуть» — ошибка была найдена — переполюсовка при монтаже.
                                                                0
                                                                спасибо, посмеялся ;)

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

                                                            Самое читаемое