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

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

Программное обеспечение становится совершенным тогда, когда

(1.9)

т. е. в точке, где прямая линия Ь пересекает горизонталь­ ную ось.

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

ше значение — • К, тем быстрее можно провести устране­

ние ошибок и тем выше будет надежность. Из уравне­ ния (1.9) следует, что

т (I щ

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

В качестве технических требований на разработку надежного ПО рекомендуются следующие критерии:

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

обслуживаемость системы — степень влияния ошибок программного обеспечения на обслуживаемость системы; >безотказность системы — частота системных отказов,

вызываемых ошибками программного обеспечения.

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

21

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

2) после выпуска новой версии некоторое время потре­ буются также менее строгие критерии качества ПО;

3)имеют место разбросы, вызываемые различием в условиях применения и использования ПО;

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

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

пользователем.

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

1.3. ЗАДАЧИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

С ЗАДАННЫМ УРОВНЕМ НАДЕЖНОСТИ

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

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

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

22

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

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

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

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

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

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

Поиск путей снижения стоимости ПО за счет повыше­

23

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

ности ПО.

6. Сущность количественной оценки надежности ПО

7 Перечислите н охарактеризуйте задачи проектирования с заданным уровнем надежности

Г л а в а 2

ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

2)трудность в использовании: ряд свойств (возмож­ ностей систем) отвергается пользователями как громозд­ кие и неудобные в эксплуатации;

3)большая сложность при создании и эксплуатации

систем ПО. Отсутствие обозримой логической структуры

24

сложных систем является следствием их постоянного

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

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

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

2.1.ГРУППА ОБЩИХ ФАКТОРОВ

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

25

деляет переход к индустриальным методам разработ­ ки ПО

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

При использовании вычислительной техники в широ­ ких масштабах с заменой традиционных методов расчета методами, основанными на использовании ЭВМ, вопросы техники программирования, квалификации персонала и управление работой в значительной мере оказывают влияние на производство качественного ПО. Опыт фирмы БОИНГ [10] показал, что из 687 прогонов программ продолжительностью 83 часа на машине CDC 6600 только 14% прогонов были безошибочными. Кроме того, 39% прогонов, признанных вначале успешными, оказались в последующем непригодными из-за ошибок в данных, программах, из-за неисправностей носителей информации. Влияние этих ошибок сказалось на стоимости и сроках выпуска продукции.

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

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

недостатками по контролю выдачи и изменения про­ грамм,

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

недостатками в методах контроля, недостатками в документации.

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

27

женеров и для руководителей. Курс обучения руководя­ щего персонала состоял из следующих дисциплин:

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

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

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

тельных машин, режим разделения времени.

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

Сотни программистов и пользователей применяли оди­ наковые программы. При этом было установлено, что:

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

варианты программ выдавались непосредственно раз­ работчиками пользователям;

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

ных вариантов; ие было гарантии, что изменения, сделанные програм­

мистом, были в интересах пользователей, а ие самого программиста;

не было средств для сохранения нужных вариантов н устранения устаревших;

не было лица, ответственного за целостность всех программ.

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

Эталонная лента доступна для чтения лишь инжене­

28

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

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

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

При осуществлении контроля введена следующая система правил:

проверка справедливости расчетов отделена от провер­ ки логики программы;

если программа разбита иа отдельные модули, то н проверяются они отдельно;

результаты проверок фиксируются в документах.

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

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

29

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

Вразделе «проверка» содержится описание контрольных

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

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

Для усовершенствования системы управления разра­ боткой была проведена инвентаризация программ с клас­ сификацией их в три группы:

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

устаревшие программы, но находящиеся пока в поль­ зовании;

неконтролируемые и неиспользуемые программы.

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

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

После введения описанных мер контроля, носящих, скорее, административный, чем технический характер, ошибки в кодирование составлявшие одну на десять ис­ полнений разных про'рамм, снизились до одной на три сотни исполнений. Таг, в одной из программ, состоящей из семи тысяч команд было всего 10 ошибок за 15 меся­

30