Вот после обнаружения ошибки в программе возник дурацкий(?) вопрос.
Упрощенная модель.
Пусть мы делаем прибор, например цифровой термометр с медным (платиновым...) датчиком.
Допустим, что используется некоторая аппроксимация (кусочно-линейная, полиномиальная...) не важно какая, важно, что контроллер (или что-либо еще...) вычисляет по программе.
Возникает вопрос - а может в какой-нибудь точке вычисления будут с ошибкой?
А может эта ошибка возникнет только на N-ном измерении.
А может она возникнет, если на входе будет некоторая последовательность?
А может она возникнет на контроллере из другой серии (фабрики)?
А может один из 10 контроллеров с глюком?
Вспомнилось, что вроде Пентиум какой-то был с арифметическим дефектом...
Еще миллион вариантов ошибок.
А если все это управляет чем-то дорогим (поезд, самолет, атомная станция)?
Или на основании этих измерений кого-то могут в тюрьму посадить (например, алкоголь в крови)?
Как тут жить? Будь прибор чисто аналоговым, понятно, как его калибровать и проверять. А тут?

Знаю, что имеет место специальная специальность по тестированию. Но это дорого и долго. Создают специальные программы по выявлению ошибок в программах. А если в программе тестирования ошибки?

Предупреждала, что вопрос идиотский...

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

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

Кроме спецальности по тестированью, есть еще и спецальность по программированю. Если программист опытный, он будет писать structured код, будет пользоватся metrics, requirement lists, etc. Есть tools которые в такой работе помогают, но естессно от ошибок разработчика никто и ничто не может застраховать. На каждый из Ваших "миллионых" failure modes существует достойный тест. А кто тестирует тестера, чем бы он не являлся? Тестер должен быть создан с большей гарантией на работоспособность чем то что он тестирует, и надо на это полагатся...

Tanya, Ваш вопрос сводится к вопросу "как делaть надежный дезайн, и как это проверить". Я уверен что Вы прекрасно знаете что единого ответа на это нет, более того, вы прекрасно знаете что использованье аналоговой техники не гарантирует работоспособность узла или аппарата... Да, ранние пентиумы делили позитивное число на себя и давали результат чуть менше одного, но значит ли это что откалиброванная аналоговая цепь не будет иметь неожидиностей для пользовотелей и разработчиков?

Как говорится, на "идиотский вопрос" даю "идиотский" ответ.

Посмотрите на тысячи примеров, где цифровые узлы cделаны "правельно", и следовали процессу. Сколько всего до сих пор работает... Hubble телескоп сидит в космосе 17 лет, его разберали/собитали три раза, в нем кучя разношерcтного кода от разных модификаций... Большенство из нас автомобилей таких старых не имеем! ВСЕ неполадки которые там были, а их было много, произошли от failure механических и движущихся компонентов, которые имееют ограниченую жизнь. Да, делать его дорого, но когда надо что б работало, надо платить соответственно... Про Советцкие работы я конечно не знаю, но уверен что на форуме есть люди которые могут дать соответсвущие примеры.

Еще вот помню одну сцену из fight club - сидит Tyler на самолете, говорит какой-то черной про свою работу на insurance компанию - if the cost of a recall is more than the cost of litigation, we don't do one. То есть многие разработчики сознательно недотестируют свое производство если затраты на тестированья больше чем судебный процесс и выплата компенсации... Он говорил про автомобильные фирмы. А "Как тут жить?" Жизнь вроде тоже риск...

Блин, ну и нафлудил. Срочно пойду завтракать, а то чего нибудь еще напишу... самому страшно стало!

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

Хорошее слово проскользнуло - дублирование! Это и есть основа всякой надежности. Важный объект? Жалко человеческие жизни (хотя, блин, кому их сейчас жалко ...)? Дорогое оборудование? Поставьте 3-и совершенно различные системы управления. Разное железо, разный софт написанный совершенно разными людьми, токо передаточная функция одинакова...Помните о воронке и снарядах???
P.S.: если мой разум не затуманило время, то что-то такое вспоминается, мол, в кибернетике есть теорема о получении сколь угодно надежной системы из компонентов с определенной (не бесконечной) надежностью... Если кто помнит - приведите. Сам на работе сижу (в субботу вечером то ) но очень хочу домой, так что лень "гуглить"...

...В тему (но, может, и не совсем...) вспомнился циничный рассказ героя книги Чака Паланика "Бойцовский клуб" (как раз по поводу ошибок при производстве автомобилей)



Когда читала, была поражена, что всё сводится к деньгам и никто не заботится о человеческих жизнях... Правда, в книге дело было на Западе ... Может, у нас не так? Я не в курсе...

Бойцовой клуб - это "Fight Club", o котором я как раз и говорил 3 поста выше... Great minds think alike

PS Нынче Вы тоже часть Запада. Занавес упал, у вас тоже капитализм...

Нормальный вопрос.
Где-то ходит список самых серьезных последствий программных ошибок. В десятку входит два случая проектирования систем в медицине, когда несколько раковых больных умерло от неправильно рассчитанной дозы облучения.
А близко к теме - мы 10 лет выпускали прибор с аппроксимацией логарифма, в котором была ошибка в одной точке. Откорректировать было невозможно - исходники были утеряны. Переписывать? Ни за что! К счастью, это не было связано с медициной.

Так вот, ответ - все должно быть протестировано. Другое дело, что 100% вероятности нет.
Метрологические приборы поверяются государственными органами (В частности, алкометры на специальных проливных станциях).
Так что "как жить?" - Делай как дОлжно и будь, что будет.

Один из этих лучаев - классический, о нем нас учили в универе - http://en.wikipedia.org/wiki/Therac-25
Известный случай когда неправельно был рассчитан переход от английских к метрическим измерениям для спутника для Марса (в конце 1990's) иллюстрировает выбор из троицы "быстрее, лучше, дешевле"... На тот момент руководство NASA хотело всех троих, вот и поручили разработку софта контрактару, и не проверели результат в соответствии со своими процессами... По этому спутник врезался в Марс, и угробил 200 лимонов.

Определение не помню, а суть в следующем: используя мажоритарные элементы (3, 5, 7 .... входов) для обобщения информации получаемой с идентичных блоков (один вход - один блок) можно получить ремонтоспособную систему с надёжностью превышающей надежность одиночных блоков. Вероятность одновременного отказа (Х+1)/2 блоков обратно пропорциональна Х (числу блоков).
Там мелкая засада есть - надёжность мажоритарного блока должна быть очень высокой.

Извольте:
Клод Шеннон "Построение надежной системы из ненадежных элементов". Речь шла об электромеханических реле.

"Другой задачей, которой он (Шеннон) занимался совместно с Е.Ф. Муром (E.F. Moore), было повышение надежности релейных цепей путем ведения избыточного числа элементов (каждый из которых ненадежен). Эта задача, опять же, сводится к передаче информации по зашумленному каналу. "