УДК 681.3 05
Б. Я. Кавалерчик
НАДЕЖНОСТЬ ПРОГРАММНОГО
обеспечения и УСЛОВИЯ
эксплуатации
Взедение
Одним из основных недостатков многих автоматизи-
рованных систем обработки информации (АСОИ) яв-
ляется низкая надежность. Согласно приведенным в
[1] статистическим данным, в условиях реальной экс-
плуатации более трети заданий завершается аварийно,
причем частота аварийного завершения примерно оди-
накова для вычислительных центров (ВЦ) с различ-
ным характером выполняемых работ. Кроме аварийных
завершений, регистрируемых операционными системами
(ОС), достаточно часто встречаются «зависания» ОС,
аварийные отключения ЭВМ (например, по данным [2],
число перегрузок ОС ЕС ЭВМ по разным причинам
оценивается в среднем как 6... 10 раз в сутки), по-
лучение неверных результатов из-за ошибок персона-
ла и т. п. Работники служб эксплуатации многих ВЦ
обычно дают оценки, что от 10 до 50 % заданий за-
вершается безрезультатно, поэтому пригодится много-
кратно повторять выполнение одних и тех же работ.
Кроме того, из-за низкой надежности АСОИ прихо-
дится тратить много времени на копирование и вос-
становление информации.
В журналах учета работы ЭВМ непроизводительные
расходы машинного времени, связанные с низкой на-
дежностью АСОИ, обычно относятся к времени ре-
шения задач. В результате многократные повторения
работ приводят к увеличению средних затрат машин-
ного времени и удорожанию решения задач. Сущест-
вующие формы статистической отчетности, показатели
полезного времени работы и среднесуточной загрузки
также не способствуют достоверному учету всех не-
производительных затрат машинного времени.
В условиях реальной эксплуатации низкая надеж-
ность АСОИ приводит к неуверенности в выполнении
расчетов в срок (при повторном просчете программы
вероятность аварийного завершения обычно значитель-
но увеличивается), вызывает взаимные обвинения служб
программирования, эксплуатации и технического об-
служивания в плохой работе, создает нервозную об-
становку на ВЦ. во многих случаях приводит к неоп-
равданному росту вычислительных мощностей и .уве-
личению плановых сроков решения задач.
Важность проблемы повышения надежности АСОИ
вызвала появление большого числа работ по надеж-
ности и качеству программного обеспечения (ПО). Од-
нако имеющиеся данные (наработка на отказ состав-
ляет сотни часов для типичного ПО [3] и тысячи ча-
сов для комплексов серийно тиражируемых программ
и со временем, по мере устранения ошибок, резко
возрастает [4, с. 85]) соответствуют более высоким
показателям надежности, чем фактические на многих
ВЦ.
Столь значительную разницу в показателях надеж-
ности можно объяснить только тем, что при оценках
надежности ПО не учитываются какие-то факторы, ока-
зывающие на нее сильное влияние.
В данной статье рассматривается влияние условий
эксплуатации на надежность ПО и предлагаются ме-
тоды и технологии, позволяющие значительно повы-
сить эксплуатационные качества и надежность ПО.
Неоднозначность оценок надежности ПО
В соответствии с определением Г. Майерса [5]
(«В ГЮ имеется ошибка, если оно не выполняет того,
что пользователю разумно от него ожидать. Отказ
ПО — это проявление ошибки в нем»), наличие ошиб-
ки является функцией собственно ПО и неформальных
ожиданий пользователей, которым, как правило, без-
различно, по какой причине результаты получены с
опозданием или неверны; из-за ошибок при кодировав
20
«Микропроцессорные средства и системы» № з} 1987;
нии алгоритма, ошибок в ОС или ошибок оператора
ЭВМ. По определению в принципе включаются также
отказы, вызываемые взаимодействия-
ми ПО со всеми элементами внешней
среды (аппаратура, носители информации, персо-
нал и др.).
Однако при оценке надежности ПО обычно считает-
ся, что отказы возникают вследствие взаимодействия
данных и ошибок в программе [6, с. 227]. При этом
предполагается, что все остальные элементы внешней
среды, взаимодейс!вуюшие с ПО, являются безотказ-
ными. Пренебрегать отказами, связанными с этими
элементами, можно только на начальных стадиях жиз-
ненного цикла ПО, когда из-за большого числа невы-
явленных ошибок отказы, связанные с взаимодействием
программ и данных, встречаются гораздо чаще осталь-
ных отказов. Для отлаженных, эксплуатируемых про-
грамм доля отказов при взаимодействии с исходными
данными со временем резко уменьшается и в основном
проявляются отказы при остальных взаимодействиях.
Далее надежность ПО, вызываемую взаимодействия-
ми с потоком исходных данных и остальными элемен-
тами внешней среды, будем называть соответственно
программной (ПН) и эксплуатационной
(ЭН) надежностью.
Эксплуатационная надежность наиболее важна для
широкого класса задач со сравнительно простыми ал-
горитмами (это облегчает обеспечение Г1Н) и обра-
боткой больших объемов информации и интенсивным
использованием внешних устройств (задачи АСУ,
многие диалоговые системы и др.).
Почему же из всех взаимодействий ПО в большин-
стве работ рассматривается только одно — взаимодей-
ствие с исходными данными? По-видимому, это свя-
зано с исторически сложившимся отношением к про-
грамме как к некоторому абстрактному математиче-
скому построению. При этом, по существу, игнориру-
ется, что npoipaMMa — не просто реализация некоторо-
го алгоритма, преобразующего исходные данные в вы-
ходные, а элемент сложной технической системы. Ссе
элементы системы (ОС, используемые СУБД и ППП,
ЭВМ. внешние устройства, носители информации, тер-
миналы, каналы связи, другие выполняемые одновре-
менно программы, персонал) имеют вполне определен-
ную надежность и достаточно сложно взаимодейству-
ют друг с другом.
Отнесение программных средств к продукции произ-
водственно-технического назначения позволяет во мно-
гом использовать накопленный в технике опыт для
оценки надежности ПО.
В соответствии с ГОСТ 27.002-83 * [7] надежность —
это «свойство объекта сохранять во времени в уста-
новленных пределах значения всех параметров, харак-
теризующих способность выполнять требуемые функ-
ции в заданных режимах и условиях применения...».
Таким образом, ГОСТ прямо требует определять на-
дежность с учетом условий эксплуатации. Разработчи-
ки при оценке надежности ПО обычно исключают от-
казы, связанные с условиями эксплуатации, так как
в технических заданиях и спецификациях они, как
правило, не оговариваются. Формально позицию раз-
работчиков можно оправдать. Однако на практике это
[фиводит к оценке надежности для идеальных
уел о в и й э кс п л у а т а ци и.
Условия использования многих видов техники харак-
теризуются понятиями нормальной (с соблюде-
нием всех инструкций) и рядовой (когда инструк-
ции соблюдаются не в полном объеме) эксплуатации.
Опыт показывает, что, например, наработка на отказ
тракторов в рядовой эксплуатации в 1,5... 2,5 раза
* Впервые данный ГОСТ (точнее, предшествовавший ему
ГОСГ 13377-75) для определения основных понятий и показа-
телей надежности ПО еще до отнесения программных средств
к продукции производственно-технического назначения был,
по-видимому, применен В. В. Липаевым,
меньше, чем в нормальной [8]. Во многих случаях ПО
также работает в условиях рядовой эксплуатации, ког-
да техническое состояние ЭВМ и устройств, качество
носителей и каналов связи ниже требуемых соответст-
вующими нормативными документами, а персонал име-
ет недостаточную квалификацию. К сожалению, такие
нарушения часто вызываются не только субъективными,
но и объективными причинами, для устранения которых
требуется длительное время.
В результате получается, что оценки надежности
разработчика соответствуют идеальным условиям экс-
плуатации, а у пользователя ПО работает даже не в
нормальных, а в рядовых условиях.
Разработчики при оценках надежности ПО учитыва-
ют в основном ПН. Пользователи же ПО на практи-
ке ощущают как ПН, так и ЭН, причем во многих
случаях отказы, связанные с условиями эксплуатации,
являются доминирующими. Именно влиянием ЭН и
вызывается отменявшаяся выше разница в показате-
лях надежности. Кстати, в |1| отмечается, что боль-
шинство зафиксированных аварийных завершений вы-
зывается причинами, внешними но отношению к про-
граммам.
Поскольку разработка ПО ведется для удовлетворе-
ния конкретных потребноеIей пользователей, необходи-
мые потребительские качества, в том числе и надеж-
ность, гак же как и для любых других видов продук-
ции производственно-технического назначения, должны
быть обеспечены в реальных условиях эксплуатации.
Для создания программных средств, их эффективной
массовой эксплуатации необходим инженерный подход:
обязательно участие инженеров, конструкторов и тех-
нологов.
Два подхода к обеспечению ЭН
Рассмотрим для определенности методы обеспечения
ЭН при взаимодействии ПО с одним из наименее на-
дежных элементов внешней среды — магнитными но-
сителями (МН).
Обратимся сначала к подходу математика. Анализи-
руя процесс выполнения различных программ на ЭВМ,
он видит, что при чтении информации с МН в неко-
торых случаях программы выдают какое-то диагно-
стическое сообщение и аварийно завершаются. Ситуа-
ция, как правило, устойчива, т. е. при попытке еще
раз выполнить программу она повторяется. Более
того, обычно аварийно завершаются и другие програм-
мы. работающие с данным носителем. Отсюда дела-
ется вывод, что массив данного носителя прочитать
невозможно, т. е. он «разрушен». Далее возникает
привычная для математика задача выбора оптимальных
стратегий резервирования информационных носителей
[9|.
С точки зрения инженера для повышения надежно-
сти любой системы в первую очередь необходимо иск-
лючить или свести к минимуму взаимодействие с наи-
менее надежными элементами *.
Минимизация взаимодействия может проводиться
разными способами.
1. При разработке алгоритмов и технологических
процессах решения задач обычно не ставится цель
уменьшения числа обращений к МН. Для повышения
ЭН необходимо на стадии постановки обращать осо-
бое внимание на уменьшение работы с МН. Целесооб-
разно использовать специальные методы для разработ-
ки программ, настраивающихся на имеющуюся кон-
фигурацию ЭВМ it размер доступной программе опе-
ративной памяти [10].
2. Анализ файлов АССИ показывает, что цифра 0
и символ «пробел» составляют основную часть хра-
нимой на МН информации. Применение компактных
форм представления данных позволяет в 3... 9 раз
уменьшить объем, занимаемый информацией на МН,
* Подход, связанный с повышением надежности этих элемен-
тов {в данном конкретном случае МН), в статье не рассмат-
ривается.
сократить время выполнения программ в 1,5. ..Зраза
и, как следствие, значительно повысить ЭН [11].
3. Перспективными представляются методы типа
интегрированного мультипрограммирования, позволяю-
щие системными средствами значительно уменьшить
число операций ввода-вывода путем синхронизации
выполнения нескольких информационно связанных про-
грамм. При этом загрузка каналов обмена уменьша-
ется в несколько раз с одновременным увеличением
производительности вычислительной системы в
2... 9 раз [12].
Названные способы позволяют существенно умень-
шить работу с МП. Однако специфика многих задач
такова, что объемы ввода-вывода информации с МН
остаются большими. Поэтому естественно еше раз об-
ратиться к технологии работы при возникновении не-
исправимой ошибки ввода с МН. Обычно считается,
что при наличии такой ошибки носитель «разрушен»
и необходимо начинать всю работу сначала. С пози-
ции инженера это не слишком логично. Ведь, если в
пути произойдет поломка автомобиля, после ремонта
и устранения неисправности не начинают путь снача-
ла. а продолжают двигаться вперед с того места, на
котором остановились. Нельзя ли аналогичным обра-
зом поступать при выполнении программ? Рассмотрим
более близкую аналогию.
Пусть имеется несколько экземпляров книги, причем
в каждом экземпляре нечетко отпечатано несколько
страниц. Номера этих страниц случайны. Как мы чи-
таем книгу? Берем первый экземпляр книги, читаем
подряд до первой нечеткой страницы. Затем берем
второй экземпляр книги, находим страницу, которую
не смогли прочитать в первом экземпляре, и продол-
жаем читать. При этом, естественно, никто не начи-
нает читать второй экземпляр книги сначала.
Несложно показать, что при наличии к экземпляров кни-
ги, содержащей п страниц, вероятность наличия во
всех к экземплярах нечетких страниц (разных) при-
мерно в 11к—1 раз выше, чем вероятность того, что во
всех экземплярах какая-то страница отпечатана не-
четко.
Точно так же, как книга состоит из страниц, файлы
на МН состоят из б токов информации, и приведенная
аналогия показывает пути разработки эффективных тех-
нологий работы с МН.
Рассмотрим, как реализуется ввод информации при
наличии двух тождественных файлов (основного и
копии). Сначала основной фай а читается до первого
разрушенного блока. Зятем на копии файла произво-
дится подпол к блоку который в основном файле раз-
рушен (при этом предыдущие блоки пропускаются, т. е.
безразлично, разрушены они или ист), и продолжается
ввод информации с копии файла до обнаружения раз-
рушенного блока. После этого осуществляется переход
на основной файл и т. п. При таком способе инфор-
мацию невозможно прочитать только при наличии бло-
ка, разрушенного одновременно в обоих файлах. Даже
при наличии такого блока, вероятность чего достаточно
мала, потерянным окажется не весь файл, а только
отдельный блок. Аналогично организуется работа с
МН и при хранении к копий файла. Как показывает
несложная оценка, при использовании пред-
лагаемой технологии чтения информации
с МН надежность по сравнению с обыч-
ными методами повышается на н е с к о л ь-
к о порядков [13].
Для реализации предлагаемой технологии обработ-
ки неисправимых ошибок ввода с МН разработаны
стандартные программы, которые переданы в ГосФАП
(per. № П004839) и используются па многих ВЦ.
Отмечавшееся отождествление понятия «разрушен-
ного» файла с реально существующим наличием раз-
рушенных блоков в файле вызвано, по-видимому, от-
сутствием ПО, позволяющего реализовать работу с
файлами, содержащими разрушенные блоки.
В данном случае недостаточно инженерным был под-
ход разработчиков систем управления вводом-выводом.
Кстати, в макрокомандах ввода-вывода, а также в
языках высокого уровня во многих операционных си-
стемах предусмотрена возможность использования соб-
ственной подпрограммы обработки ошибок ввода-вы-
вода. Однако ич-за сложности и. главное, непривычно-
сти программирования данная возможность, как пра-
вило не используется.
Например, в операционной системе ОС ЕС ЭВМ есть
очень близкая средство-программа динамической ре-
конфигурации устройств, обеспечивающая при обнару-
жении неисправимых ошибок ввода-вывода динамиче-
ское перемещение томов МН на другое устройство.
Однако эта программа практически обрабатывает толь-
ко отказы устройств, так как, если ощибка связана с
носителем, т. е. какой-либо блок разрушен, то его
невозможно прочитать и на другом устройстве. Для
повышения ЭН при работе с МН необходимы сред-
ства замены не устройств, а томов. Отметим, что
операторам ЭВМ рекомендуется в некоторых случаях
при копировании файлов на МН «обманывать» опера-
ционную систему и использовать замену тома для
восстановления файла из двух, в каждом из которых
есть разрушенные блоки, но в разных местах []4].
Многие взаимодействия ПО с внешней средой осуще-
ствляются через операционные системы. Поэтому, как
и в случае взаимодействия с МН, повышения ЭН
можно достичь путем совершенствования ОС или раз-
работки средств, раширяюших их возможности.
Все сказанное не является отрицанием математиче-
ского подхода или упреком математикам. Работы по
оптимальному резервированию МН безусловно полез-
ны. Однако очень плохо, что крайне мало работ инже-
нерного и технологического плана: как для каждого
вида взаимодействий ПО с внешней средой повысить
ЭН, как разработать технологии, позволяющие про-
граммно преобразовывать отказы в автоматически уст-
ранимые сбои?
Тестирование и отладка взаимодействий ПО с внеш-
ней средой
Так же, как и для взаимодействия программы с ис-
ходными данными, для выявления и устранения ошибок
взаимодействия со всеми элементами внешней среды
необходимо проводить тестирование и отладку.
В частности, в дополнение к 15 категориям тестов в
[15], для обеспечения ЭН необходимо тестировать
взаимодействия ПО со следующими элементами внеш-
ней среды.
1. Операционная система. Как известно, ОС содер-
жат ряд ошибок, поэтому следует проверить, что пре-
дусмотренные режимы работы ПО не вызывают про-
явления ошибок ОС.
2. Аналотчно взаимодействию с ОС необходимо те-
стировать взаимодействия ПО с используемыми СУБД
и ППП.
3. Другие задачи которые будут эксплуатироваться
на ЭВМ параллельно с тестируемой. Взаимодействие
может проявляться как непосредственно, так и из-за
резкого возрастания числа сбоев при повышении за-
грузки ЭВМ [16]t
4. Внешние устройства и носители информации: сле-
дует определить, достаточны ли аппаратные и систем-
ные средства обработки сбоев, или требуются специ-
альные методы и программы.
5. Терминалы: проверить ситуации включения (вы-
ключения) части или всех терминалов перед запуском
и в процессе работы системы, отказа терминала во
время работы и т. п. Например, автору известен ряд
тиражируемых диалоговых систем, в которых терми-
нал, выключенный в момент запуска системы, в даль-
нейшем невозможно подключить. В эксплуатации та-
кой режим работы крайне неудобен.
6. Каналы связи: тестировать ситуации обрыва и
восстановления связи и работу при различных уров-
нях помех.
7. Оператор ЭВМ. Следует учитывать, что оператор
будет работать в сложной обстановке, получая запро-
сы, указания сообщения от тестируемой программы
и от всех других программ, одновременно выполняе-
мых на ЭВМ.
8. Пользователи, работающие за терминалами. Не-
обходимо проверять работу системы с необученным
пользователем и пользователем, делающим всевозмож-
ные действия за терминалом.
При тестировании взаимодействий с людьми (п. 7, 8)
нужно следить, чтобы возможные ошибки (например,
ввод не до конца набранной директивы) и значения
по умолчанию соответствовали наиболее безопасной
реакции системы.
Взаимодействия с внешней средой в реальных усло-
виях эксплуатации существенно влияют как на надеж-
ность и временные характеристики системы, так и на
другие виды тестирования. Как правило, характери-
стики системы оказываются заметно хуже, чем по
обычной оценке разработчика. Например, только за
счет аппаратурной и системной обработки сбоев на
МН время выполнения операций ввода-вывода, ча-
сто определяющее в общем времени выполнения про-
грамм, увеличивается в 2...3 раза [17].
Заключение
Для повышения эксплуатационных качеств ПО, по-
лучения реальных оценок надежности можно рекомен-
довать следующие методы:
1. Четкое определение условий эксплуатации в тех-
нических заданиях и спецификациях.
2. Применение при разработке ПО специальных ме-
тодов повышения надежности (минимизация взаимо-
действий с ненадежными элементами системы; исклю-
чение взаимодействий с другими элементами в областях
их низкой надежности и неработоспособности; миними-
зация времени работы и др.).
3. Разработка для всех взаимодействий технологий
работы в аварийных ситуациях, обеспечивающих пре-
образование отказов в автоматически устраняемые
сбои, и включение в состав ОС или прикладных про-
грамм специальных модулей, реализующих эти техно-
логии.
4. Выбор рациональных технологий эксплуатации
программных средств.
5. Тестирование взаимодействий ПО со всеми эле-
ментами внешней среды.
6. Оценка надежности и временных характеристик
ПО с учетом всех видов отказов и при минимально
допустимых значениях надежности отдельных элемен-
тов.
В статье рассмотрен только один аспект создания
ПО — обеспечение ЭН. Необходимо, на наш взгляд, для
всех этапов жизненного цикла ПО рассмотреть ана-
логи в технике. Это позволит во многом перенести бо-
гатый опыт, накопленный в машиностроении и дру-
гих отраслях, на разработку и эксплуатацию ПО.
Имеется ряд примеров, показывающих перспектив-
ность такого подхода. Так, при организации производ-
ства программных средств на программостроительном
предприятии производительность труда рабочего за
счет специализации не менее чем в 10 раз превышает
производительность труда программиста при разработ-
ке аналогичных программных средств [18]. Для по-
вышения эффективности разработки прикладных про-
грамм с успехом начинает применяться макетирование,
с давних пор принятое в инженерных разработках
119].
Однако на этом пути имеется много препятствий,
главное из которых — негативное отношение многих
программистов. Большинство программистов имеет
традиционное университетское математическое обору-
дование и часто просто не поедставляет инженерных
и технологических проблем, Например, задачи АСУ
считаются самыми простыми и наименее престижными.
А ведь эти задачи отнюдь не просты. Просты только
алгоритмы расчетов, В отличие от других вадач, на-
пример выполнения научно-технических расчетов, ос-
новные проблемы связаны на с алгоритмами, а с тех-
нологией обработки информации, вопросами обеспе-
чения достоверности и надежности.
В настоящее время в теории программирования и
технологии разработки ПО есть серьезные достижения,
а эксплуатационные, потребительские качества ПО,
технология обработки информации явно не соответст-
вуют современному уровню. В решении этих задач
в первую очередь требуется инженерный подход.
Телефон для справок: 27-01-25. г. Минск.
ЛИТЕРАТУРА
1. Трейманис М. О. Об одном классе аварийных
ситуаций/'/Программированис.— 1983-^JVb 4.— С. 90.
2. Волосков И. И., Гусев В. В., К У ш н е р Э. Ф.
Программа рестарта операционной системы ЕС
ЭВМ//Управляющие системы и машины.—1978.—
№ 3.— С. 46—49.w
3. М у с а Дж. Д. Изменение и обеспечение надежно-
сти программных средств//ТИИЭР.—-1980.— Т. 68,
№ 9.™ С. 113-128.
4. Л и п а е в В. В. Надежность программного обес-
печения АСУ.—М.: Энергоиздат, 1981.—241 с.
5. М а й е р с Г. Надежность программного обеспече-
ния.— М.: Мир, 1980.—360 с.
6. Л и и а е в В. В. Качество программного обеспече-
ния.— М.: Финансы и статистика, 1983.-^-263 с.
7. Надежность в технике. Термины и определения.
ГОСТ 27.002—83.— М.: Изд-во стандартов, 1983.—
30 с.
8. Стопалов С. Г. О неоднозначности опенок на-
дежности изделия//Надежность и контроль качест-
1 ва.—1981.—JSfb 1.—С. 10—15.
9. Методы повышения достоверности и сохранности
! информации в АСУ//В. В. Кульба, А. Г. Мамиконов,
1 В. П Пелихов, А. В. Шелков//Автоматика и теле-
механика.—1985.—№ 2.— С. 5—33.
10. К а в а л е р ч и к Б. Я. О повышении эксплуатаци-
онной надежности программного обеспечения//Уп-
равляющие системы и машины.—1982.—№ 5.—
С. 71—76.
11. К а в а л е р ч и к Б. Я., Гришкан В. И. О повы-
шении производительности вычислительных си-
стем/управляющие системы и машины.—1986.—
№ 4,— С. 23—27.
12. Анд он Ф. И., Дерецкий В. А., По л я ч е н-
к о Б. Е. Интегрированное мультипрограммирова-
ние в ОС ЕС//Управляющие системы и машины.—
1982.—№ 5.—С, 58—02.
13. К а в а л е р ч и к Б. Я. Об одной эффективной стра-
тегии резервирования информационных массивов в
АСУ//Мехэнизация и автоматизация управления.—
1983.—№ 1.—С. 27—29.
14 Рейт борт И. М. Пособие для оператора ЕС
ЭВМ.—М.: Статистика, 1979.—192 с.
15. Майерс Г. Искусство тестирования программ.—
М.: Финансы и статистика, 1982.—176 с.
16. Б у р а ч е н к о Ю. Т. Анализ статистических дан-
ных о сбоях технических средств ЭВМ//Надеж-
ность и контроль качества.—1981.—№ 4.— С. 56—59.
17. Г а г а н о в П. Г., Просвир нин В. Н. Надеж-
ность операций обмена информацией с внешними
запоминающими устройствами ЭВМ//'Надежность
и контроль качества. —1984.— № 10.—С. 30—36.
18. Карась И. 3. Опыт функционирования промыш-
ленного предприятия по производству програм-
мных средств // Микропроцессорные средства и си-
- стемы.—1985.—№ 1.—С. 36—41.
19. Г р о м о в Г. Р. Национальные информационные ре-
сурсы: проблемы промышленной эксплуатации.—
М.: Наука, 1985.—240 с.
Статья поступила 2? октября 1986 г,
