книги / Надежность программного обеспечения систем обработки данных

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

Достижения в области повышения надежности обору­ дования в настоящее время более ощутимы, чем в надеж­ ности ПО. Это объясняется рядом причин, среди которых можно выделить следующие.

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

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

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

Современные вычислительные системы обладают раз­

11

витым и достаточно сложным программным обеспече­ нием. Это положительное само по себе обстоятельство порождает огромные трудности по проверке и поддер­ жанию работоспособности таких систем.

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

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

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

В действительности большая часть ПО, рассматри­ ваемого в настоящее время как надежное, не является корректным. Можно считать систему надежной и при наличии в ней ошибок, но при условии, что:

12

1) ошибки программирования оставляют возмож­ ность правильного использования системы (например, неправильный вывод, который легко обнаруживается и исправляется пользователем);

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

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

Очевидно, что степень влияния структуры системы иа

еенадежность является такой же и для воздействия на

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

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

13

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

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

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

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

Приведенный выше анализ влияния структуры мате­ матического обеспечения на надежность позволяет сде­

15

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

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

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

включать в интерфейс взаимные проверки коррект­ ности отработки заданий.

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

1.2. ПОКАЗАТЕЛИ НАДЕЖНОСТИ

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

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

16

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

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

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

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

17

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

В качестве исходных предпосылок используются сле­ дующие утверждения:

1) в результате выполнения программы для каждого множества Ni входных данных получаем однозначный выходной результат;

2)множество Ni входных данных определяет все вы­ числения, выполняемые программой;

3)каждая ошибка в программе вызывает сбои для некоторой части входных данных;

4)пропуск программы с некоторым подмножеством входных данных представляет собой единичное наблю­ дение ее действия.

Тогда вероятность Я появления сбоя есть вероят­ ность того, что множество входных данных Nt, выработан­ ное для пропуска программы, таково, что порождает сбои. Р может быть выражено через вероятность Я< вы­ бора для работы множества Nt и переменную t/(:

где п — число всевозможных входов ПО

Надежность R для некоторого рабочего участка Я, может быть определена как

п

Для получения вероятности отказа ПО эксперимен­ тальным путем можно применить следующий подход. Если испытывается определенное ПО относительно п раз­

18

личных входов и относительно / и» них имеют место отка зы, то вероятность отказа ПО оценивается как

При равномерном распределении испытуемых входов во входном множестве и при достаточно большом п

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

Далее рассмотрим входное множество S„ и исполь­ зуемое множество SH. Вероятность отказа в S„ определя­

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

Здесь Р{, может быть получено на основании зависи­ мости (1.5).

Зависимость (1.6) представлена графиком на рис. 1.2, на котором по вертикальной оси представлена вероят­ ность отказа ПО во множестве S„, а по горизонтальной оси — количество устраненных ошибок. На рисунке по­ казано, что пи оценивается углом наклона прямой линии. Чем круче наклон прямой линии, тем меньше пи и, следо­ вательно, выше интенсивность устранения ошибок.

При полном устранении всех ошибок ПО становится надежным, т. е.

19

Количество устраненных неполадок

Рис I 2 Распределение отказов ПО (простой случай)

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

щих в используемом множестве, может быть представ­ лена в виде отношения п„.п,.

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

(18)

На рис. 1.3 представлены прямая линия а, удовлетво­ ряющая уравнению (1.6), и прямая линия Ь, удовлетво-

Количество устранением неполадок

Рис I 3 Распределение отказов ПО

20