Что такое программа обеспечения надежности

Обновлено: 12.05.2024

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

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

Обоснование проблемы

Проблема надежности программного обеспечения относится, похоже, к категории "вечных". В посвященной ей монографии Г.Майерса [1], выпущенной в 1980 году (американское издание - в 1976), отмечается, что, хотя этот вопрос рассматривался еще на заре применения вычислительных машин, в 1952 году, он не потерял актуальности до настоящего времени. Отношение к проблеме довольно выразительно сформулировано в книге Р.Гласса ([2]): "Надежность программного обеспечения - беспризорное дитя вычислительной техники". Следует далее отметить, что сама проблема надежности программного обеспечения имеет, по крайней мере, два аспекта: обеспечение и оценка (измерение) надежности. Практически вся имеющаяся литература на эту тему, включая упомянутые выше монографии, посвящена первому аспекту, а вопрос оценки надежности компьютерных программ оказывается еще более "беспризорным". Вместе с тем очевидно, что надежность программы гораздо важнее таких традиционных ее характеристик, как время исполнения или требуемый объем оперативной памяти, однако никакой общепринятой количественной меры надежности программ до сих пор не существует.

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

Причины сложившейся ситуации

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

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

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

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

Вероятностный подход к проблеме надежности

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

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

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

Компьютерная программа как объект исследования

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

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

Надежность и правильность программы

Программа считается правильной, если она не содержит ошибок. Такая программа не дает неверных результатов, т.е. она абсолютно надежна. Этот факт породил ложное представление о том, что число ошибок в программе можно считать наиболее естественной мерой надежности ([1]). Было выполнено довольно много работ, в которых предлагались различные методы оценки числа оставшихся в программе ошибок по результатам ее тестирования, в том числе метод "засорения" известными ошибками, однако, как показывают приводимые ниже соображения, количество ошибок в программе не имеет никакого отношения к ее надежности:

1. Число ошибок в программе - величина "ненаблюдаемая", наблюдаются не сами ошибки, а результат их проявления.

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

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

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

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

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

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

Модель последовательности испытаний Бернулли

Рассмотрим для простоты класс программ, имеющих единственный вход и выход, т.е. не содержащих бесконечных циклов. Фазу выполнения программы от начала до завершения будем называть запуском. Все возможные результаты запуска разобьем на два класса: правильные и неправильные (ошибочные). Будем считать, что любой результат всегда можно отнести к одному из этих классов. (Ясно, что по этому вопросу возможны разногласия между изготовителями программы и пользователями, однако будем предполагать, что имеется какой-то общий критерий, например, "клиент всегда прав".) Рассмотрим классическую вероятностную модель последовательности испытаний Бернулли. Пространство элементарных событий в этой модели содержит 2 n точек, где n - число испытаний (в данном случае под испытанием подразумевается запуск программы). Каждый запуск программы имеет два исхода: правильный и неправильный. Обозначим вероятность неправильного исхода р, а вероятность правильного - (1-p). Вероятность того, что из n запусков К приведут к неправильному результату, выражается хорошо известной формулой биномиального распределения ([4]).

где С(n,k) - число сочетаний. Вероятность р априори неизвестна, но по результатам запусков известны n и k. Величина В как функция р имеет максимум при

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

значения которой (от 0 до 1) согласуются с общепринятым смыслом термина надежность: например, если все запуски окончились с ошибочным результатом (k = n), то надежность - нулевая.

Наиболее существенное предположение в данной модели состоит в том, что запуски программы считаются независимыми. Это означает, что результаты предыдущих запусков не дают никакой информации о результатах следующего. Ясно, что это предположение на практике выполняется не всегда: например, повторный запуск с теми же входными данными даст, очевидно, тот же самый результат. *

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

Некоторые следствия

Формула (3) позволяет оценить надежность программы по результатам ее запусков. Следует особо остановиться на двух предельных случаях: k = n (нулевая надежность) и k = 0 (абсолютная надежность). В обоих случаях результаты не следует интерпретировать буквально: нет никаких гарантий того, что очередной запуск приведет к тому же реультату, что и предыдущие. Однако с точки зрения пользователя эти случаи совершенно разные. Если нулевая надежность свидетельствует о том, что программа явно непригодна для эксплуатации, то показатель абсолютной надежности не должен вводить в заблуждение: такой вывод нельзя делать по результатам даже очень большого числа запусков. Следует подчеркнуть, что для оценки надежности в этом случае необходимо рассмотреть другие вероятностные модели.

Из формулы (3) следует, что оценка надежности программы растет с увеличением числа ее запусков по гиперболическому закону. Это подтверждает интуитивно ясное соображение о том, что программа тем надежнее, чем больше опыт ее эксплуатации, который зависит как от интенсивности использования программы, так и от тиража компьютера, на котором она запускается. Таким образом, надежность программ для персональных компьютеров типа IBM РС, общий тираж которых составляет в настоящее время около 100 миллионов, на несколько порядков выше аналогичных программ для специализированных процессоров (если, конечно, такие программы действительно существуют и эксплуатируются).

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

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

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

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

В заключение автор выражает глубокую признательность сотруднику математического отдела НИИСИ РАН А.В. Коганову за весьма полезные дискуссии, а также надежду, что затронутый вопрос заинтересует читателей журнала.

Литература

1. Г. Майерс. Надежность программного обеспечения. Москва, Мир, 1980.

2. Р. Гласс. Руководоство по надежному программированию. Москва, Финансы и статистика, 1982.

3. В. Турский. Методология программирования. Москва, Мир, 1981.

4. В. Феллер. Введение в теорию вероятностей и ее приложения. Т.1. Москва, Мир, 1967

* Отметим, что последовательность испытаний Бернулли - не единственная возможная формализация описываемого процесса. Кроме того, при более пристальном анализе нельзя не обнаружить, что k является функцией n. Тем не менее, даже эта модель дает хорошие качественные результаты. Более тонкие модели заинтересовавшийся читатель сможет найти в статье А. Коганова и С. Романюка "Экономический подход к понятию надежности", которая будет помещена в следующем номере журнала (прим. ред.)

Содержание

Основные положения

Формализации показателей качества программных средств посвящена группа нормативных документов. В международном стандарте ISO 9126:1991, при отборе минимума стандартизируемых показателей выдвигались и учитывались следующие принципы:

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

Выделены характеристики, которые позволяют оценивать ПС с позиции пользователя, разработчика и управляющего проектом. Рекомендуется 6 основных характеристик качества ПС, каждая из которых детализируется несколькими (всего 21) субхарактеристиками (рис.1):

  • Функциональная пригодность детализируется:
    • пригодностью для применения,
    • точностью,
    • защищенностью,
    • способностью к взаимодействию
    • согласованностью со стандартами и правилами проектирования;
    • Надежность рекомендуется характеризовать:
      • уровнем завершенности (отсутствия ошибок),
      • устойчивостью к ошибкам и перезапускаемостью;
      • Применимость предлагается описывать:
        • понятностью,
        • обучаемостью
        • простотой использования;
        • Эффективность рекомендуется характеризовать:
          • ресурсной и временной экономичностью;
          • Сопровождаемость характеризуется:
            • удобством для анализа,
            • изменяемостью,
            • стабильностью
            • тестируемостью;
            • Переносимость предлагается отражать:
              • адаптируемостью,
              • структурированностью,
              • замещаемостью
              • внедряемостью.

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

              Близким к описанному стандарту по идеологии, структуре и содержанию является стандарт ГОСТ 28195-89. На верхнем, первом уровне выделено 6 показателей - факторов качества:

              1. надежность,
              2. корректность,
              3. удобство применения,
              4. эффективность,
              5. универсальность
              6. сопровождаемость.

              Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240.


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

              В стандарте ГОСТ 28806-90 формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в стандарте 28195-89.

              Функциональная пригодность

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

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

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

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

              Корректность программы

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

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

              Надежность программы

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

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

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

              Классификация сбоев и отказов

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

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

              Устойчивость и восстанавливаемость работоспособного состояния ПС

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

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

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

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

              Наработка на отказ

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

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

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

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

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

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

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

              Читайте также: