Устойчивость к ошибкам программного обеспечения это

Устойчивость
к ошибкам— это мера способности системы
программного обеспе­чения продолжать
функционирование при наличии ошибок.

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

59. Раскрыть понятие динамической избыточности

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

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

60. Аналитические модели надежности

Модели
надежности программных средств (МНПС)
подразделяются на аналитические
и эмпирические.
Ана­литические модели дают возможность
рассчитать количествен­ные показатели
надежности, основываясь на данных о
поведении программы в процессе
тестирования (измеряющие и оцениваю­щие
модели).

Аналитическое
моделирование надежности
ПС включает
че­тыре
шага:

1)

определение предположений, связанных
с процедурой тестирования
ПС;

2)

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

3)

выбор параметров моделей с использованием
полученных данных;

4)

применение модели — расчет количественных
показателей надежности
по модели.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Проект к данной лекции Вы можете скачать здесь.

Корректность и устойчивость

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

Корректность — это способность программной системы работать в строгом соответствии со своей спецификацией. Отладка — процесс, направленный на достижение корректности.

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

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

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

Почему так трудно создавать корректные и устойчивые программные системы? Все дело в сложности разрабатываемых систем. Когда в 60-х годах прошлого века фирмой IBM создавалась операционная система OS-360, то на ее создание потребовалось 5000 человеко-лет, и проект по сложности сравнивался с проектом высадки первого человека на Луну. Сложность нынешних сетевых операционных систем, систем управления хранилищами данных, прикладных систем программирования на порядок превосходит сложность OS-360, так что, несмотря на прогресс, достигнутый в области технологии программирования, проблемы, стоящие перед разработчиками, не стали проще.

Жизненный цикл программной системы

Под » жизненным циклом » понимается период от замысла программного продукта до его «кончины». Обычно рассматриваются следующие фазы этого процесса:

Проектирование Разработка Развертывание и Сопровождение

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

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

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

Три закона программотехники

Первый закон (закон для разработчика)

Корректность системы — недостижима. Каждая последняя найденная ошибка является предпоследней.

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

Второй закон (закон для пользователя)

Не бывает некорректных систем. Каждая появляющаяся ошибка при эксплуатации системы — это следствие незнания спецификации системы.

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

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

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

Третий закон (закон чечако)

Если спецификацию можно нарушить, она будет нарушена. Новичок (чечако) способен «подвесить» любую систему.

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

Надежный код

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

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

Создание надежного кода

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

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

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

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

Корректность методов

Спецификации метода можно задавать по-разному. Определим их здесь через понятия предусловий и постусловий метода, используя символику триад Xoара, введенных Чарльзом Энтони Хоаром — выдающимся программистом и ученым.

Пусть P(x,z) — метод P с входными аргументами x и выходными z. Пусть Q(y) — некоторое логическое условие (предикат) над переменными y. Предусловием метода P(x,z) будем называть предикат Pre(x), заданный на входах метода. Постусловием метода P(x,z) будем называть предикат Post(x,z), связывающий входы и выходы метода. Для простоты будем полагать, что метод P не изменяет своих входов x в процессе своей работы. Теперь несколько определений:

Определение 1 ( частичной корректности ). Метод P(x,z) корректен (частично, или условно) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для метода P(x,z), запущенного на входе x, гарантируется выполнение предиката Post(x,z) при условии завершения метода на этом входе.

Условие частичной корректности записывается в виде триады Хоара, связывающей метод с его предусловием и постусловием:

[Pre(x)]P(x,z)[Post(x,z)]

Определение 2 ( полной корректности ). Метод P(x,z) корректен (полностью, или тотально) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для метода P(x,z), запущенного на входе x, гарантируется его завершение и выполнение предиката Post(x,z) в точке завершения метода.

Условие полной корректности записывается в виде триады Хоара, связывающей программу с ее предусловием и постусловием:

{Pre(x)}P(x,z){Post(x,z)}

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

Корректная программа говорит своим клиентам: если вы хотите вызвать меня и ждете гарантии выполнения постусловия после моего завершения, то будьте добры гарантировать выполнение предусловия на входе. Задание предусловий и постусловий методов — это такая же важная часть работы программиста, как и написание самого метода. На языке C# пред- и постусловия обычно задаются в теге summary, предшествующем методу, и являются частью XML-отчета. К сожалению, технология работы в Visual Studio не предусматривает возможности автоматической проверки предусловия перед вызовом метода и проверки постусловия после его завершения с выбрасыванием исключений в случае их невыполнения. Программисты, для которых требование корректности является важнейшим условием качества их работы, сами встраивают такую проверку в свои программы. Как правило, подобная проверка обязательна на этапе отладки и может быть отключена в готовой системе, в корректности которой программист уже уверен. А вот проверку предусловий важно
оставлять и в готовой системе, поскольку истинность предусловий должен гарантировать не разработчик метода, а клиент, вызывающий метод. Клиентам же свойственно ошибаться и вызывать метод в неподходящих условиях.

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

Инварианты и варианты цикла

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

Рассмотрим цикл в форме, к которой можно привести все виды циклов:

Init(x,z); while(B)S(x,z);

Здесь B — условие цикла while, S — его тело, а Init — группа предшествующих операторов, задающая инициализацию цикла. Реально ни один цикл не обходится без инициализирующей части. Синтаксически было бы правильно, чтобы Init являлся бы формальной частью оператора цикла. В операторе for это частично сделано — инициализация счетчиков является частью цикла.

Определение 3 ( инварианта цикла ). Предикат Inv(x, z) называется инвариантом цикла while, если истинна следующая триада Хоара:

{Inv(x, z)& B}S(x,z){Inv(x,z)}

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

Для любого цикла можно написать сколь угодно много инвариантов. Любое тождественное условие (2*2 =4) является инвариантом любого цикла. Поэтому среди инвариантов выделяются так называемые подходящие инварианты цикла. Они называются подходящими, поскольку позволяют доказать корректность цикла по отношению к его пред- и постусловиям. Как доказать корректность цикла? Рассмотрим соответствующую триаду:

{Pre(x)} Init(x,z); while(B)S(x,z);{Post(x,z)}

Доказательство разбивается на три этапа. Вначале доказываем истинность триады:

(*)      {Pre(x)} Init(x,z){RealInv(x,z)}

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

(**)      {RealInv(x, z)& B} S(x,z){ RealInv(x,z)}

На последнем шаге доказывается, что наш инвариант обеспечивает решение задачи после завершения цикла:

(***)      ~B & RealInv(x, z) -> Post(x,z)

Это означает, что из истинности инварианта и условия завершения цикла следует требуемое постусловие.

Определение 4 ( подходящего инварианта ). Предикат RealInv, удовлетворяющий условиям (*), (**), (***) называется подходящим инвариантом цикла.

С циклом связано еще одно важное понятие — варианта цикла, используемое для доказательства завершаемости цикла.

Определение 5 ( варианта цикла ). Целочисленное неотрицательное выражение Var(x, z) называется вариантом цикла, если выполняется следующая триада:

{(Var(x,z)= n) & B} S(x,z){(Var(x,z)= m) & (m < n)}

Содержательно это означает, что каждое выполнение тела цикла приводит к уменьшению значения его варианта. После конечного числа шагов вариант достигает своей нижней границы, и цикл завершается. Простейшим примером варианта цикла является выражение n — i для цикла

for(i = 1; i <= n;  i++) S(x, z);.

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

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

class Simple
  {
      double[] x;
      public Simple(double[] x)
      {
          this.x = x;
      }
      public double Sum1()
      {
      //Init:
          double S = 0;
          int i = 0;
          while (i < x.Length)
          {
              S += x[i]; i++; 
          }
          return S;
      }
      public double Sum2()
      {
      //Init:
          double S = 0;
          int i = 0;
          while (i < x.Length -1)
          {
               i++; S += x[i];
          }
          return S;
      }
      public double Sum3()
      {
      //Init:
          double S = 0;
          int i = 0;
          while (i < x.Length -1)
          {
              S += x[i]; i++;
          }
          return S;
      }
      public double Sum4()
      {
      //Init:
          double S = x[0];
          int i = 1;
          while (i < x.Length)
          {
              S += x[i]; i++;
          }
          return S;
      }
  }

Ограничимся рассмотрением метода Sum1. В качестве предусловия выберем следующий предикат Pre(x):

Pre(x): (x - массив элементов типа double) && ( x.Length >= 0)

В качестве подходящего инварианта цикла выберем предикат Inv(x, S, i):

Содержательно инвариант говорит, что на каждом шаге цикла S представляет сумму элементов начального отрезка массива. В качестве постусловия метода Post(x, S) выберем предикат:

Постусловие отражает требование к методу — по его завершению S должно представлять сумму элементов массива. Нетрудно строго доказать, что метод Sum1 корректен по отношению к заданным спецификациям — предусловию и постусловию. Другими словами, справедлива истинность триады Хоара:

{Pre(x)} Sum1{Post(x, S)}

Формального доказательства приводить не буду. Понятно, что инициализация обеспечивает истинность инварианта, поскольку по определению для пустого множества функция ? равна нулю. Выполнение тела цикла сохраняет истинность инварианта, а из условия завершаемости цикла и истинности инварианта следует предусловие. В момент завершения цикла счетчик цикла i принимает значение x.Length.

Очевидно, что имеет место завершаемость цикла, вариантом которого является выражение x.Length — i.

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

Метод Sum4 также корректен по отношению к тем же предикатам. Небольшое отличие существует в предусловии, требующем, чтобы массив был не пуст. Методы Sum2 и Sum3 вычисляют сумму части массива и не гарантируют корректности по отношению к заданным спецификациям. Хотя, конечно, можно изменить предусловие и постусловие так, чтобы методы были корректны по отношению к ним. Другое дело, устроит ли пользователя такая спецификация. Еще раз повторяю, без спецификации нельзя говорить о корректности.

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

Из данных определений можно сделать важные выводы:

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

Основными причинами ошибок программного обеспечения являются:

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

Источниками ошибок (угрозами надежности) программного обеспечения являются:

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

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

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

Методы предупреждения ошибок концентрируются на отдельных этапах процесса продектирования программного обеспечения и включают в себя:

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

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

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

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

• Временная избыточность. Использование части производительности ЭВМ для контроля исполнения и восстановления работоспособности ПО после сбоя.
• Информационная избыточность. Дублирование части данных информационной системы для обеспечения надёжности и контроля достоверности данных.
• Программная избыточность включает в себя: взаимное недоверие — компоненты системы проектируются, исходя из предположения, что другие компоненты и исходные данные содержат ошибки, и должны пытаться их обнаружить; немедленное обнаружение и регистрацию ошибок; выполнение одинаковых функций разными модулями системы и сопоставление результатов обработки; контроль и восстановление данных с использованием других видов избыточности.

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

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

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

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

Существуют две стратегии при проектировании тестов:

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

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

Однако, исчерпывающее тестирование всех веток алгоритма любой серьёзной программы для всех вариантов входных данных

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

• предлагаемых изменений;
• найденных дефектов;
• утвержденных корректировок;
• реализованных изменений;
• пользовательских версий.

ПРИМЕР:
Рассмотрим применение описанных выше методов повышения надёжности программного обеспечения при разработке автоматизированной информационной системы комбината хлебопродуктов (АИС КХП).
Предупреждение ошибок — лучший путь повышения надёжности программного обеспечения. Для его реализации была разработана методика проектирования систем управления предприятиями, соответствующая спиральной модели жизненного цикла ПО. Методика предусматривает последовательное понижение сложности на всех этапах анализа объекта. При декомпозиции АИС были выделены уровни управления системы, затем подсистемы, комплексы задач и так далее, вплоть до отдельных автоматизируемых функций и процедур. Методика базируется на методах структурно-функционального анализа (SADT), диаграммах потоков данных (DFD), диаграммах «сущность-связь» (ERD), методах объектно-ориентированного анализа (OOA) и проектирования (OOD).
На основании методов обнаружения ошибок были разработаны следующие средства повышения надёжности ПО:

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

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

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

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

Для обеспечения качества программного обеспечения АИС КХП на этапе развития и сопровождения системы разработан комплекс программных средств, обеспечивающий:

• управление версиями ПО;
• регистрацию поставок;
• сопровождение заявок клиентов.

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