Общая математическая модель проявления ошибок в ПО. Гипотеза Джелинского-Моранды

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

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

Джелинский и Моранда сделали предположение – гипотезу [33]:

Интенсивность проявления ошибок пропорциональна числу оставшихся ошибок.

, где

k- некоторый коэффициент пропорциональности,

n- количество проявившихся ошибок,

N₀- начальное количество ошибок,

(N₀-n)- количество оставшихся ошибок.

Запишем уравнения Колмогорова для случайного процесса проявления ошибок и подставим в них значения интенсивности проявления ошибок в соответствии с гипотезой Джелинского – Моранды.

λ ₀ = N₀K, λ ₁ = (N₀ – 1)K, …… λ _n = (N₀ - n)

 

Особенности расчета надежности ПО. Методы повышения надежности ПО.

 

Особенности резервирования ПО

 

Надежность(безотказность) и безопасность.

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

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

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

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

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

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

Принципы аварийной защиты.

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

Здесь возможен достаточно широкий диапазон подходов, начиная от создания условий для отказоустойчивости системы, и кончая полным прекращением её функционирования с «мягким остановом» при возникновении отказа.

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

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

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

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

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

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

12Следующая ⇒

Поделиться: