книги / Надежность программного обеспечения систем обработки данных
..pdfряющая уравнению (1.8). Точка пересечения двух линий отражает состояние, когда за счет внесения дополнитель ных ошибок надежные характеристики программы ие улучшаются, несмотря на то, что имеет место обнару жение и устранение ошибок. Однако в фактически отла живаемой программе значение К изменяется в окрест ности точки пересечения и, следовательно, предполага ется, что линии становятся кривыми (пунктир на ри сунке) .
Программное обеспечение становится совершенным тогда, когда
(1.9)
т. е. в точке, где прямая линия Ь пересекает горизонталь ную ось.
Наличие представленного выше механизма обеспечи вает возможность предсказания развития процесса устра нения ошибок. С точки зрения надежности ПО, чем мень
ше значение — • К, тем быстрее можно провести устране
ние ошибок и тем выше будет надежность. Из уравне ния (1.9) следует, что
т (I щ
Эту величину можно назвать «индексом оставшихся ошибок». Если степень устранения ошибок находится в диапазоне, обозначенном прямой линией Ь, то можно вычислить ряд количественных параметров надежности ПО и дать гарантию возможности его использования по назначению.
В качестве технических требований на разработку надежного ПО рекомендуются следующие критерии:
корректность программного обеспечения — число серьезных ошибок в программе и время, необходимое для их устранения;
обслуживаемость системы — степень влияния ошибок программного обеспечения на обслуживаемость системы; >безотказность системы — частота системных отказов,
вызываемых ошибками программного обеспечения.
С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:
21
1) разработанное программное обеспечение в началь ной стадии эксплуатации может потребовать менее жест ких критериев и большего времени для его совершенство вания;
2) после выпуска новой версии некоторое время потре буются также менее строгие критерии качества ПО;
3)имеют место разбросы, вызываемые различием в условиях применения и использования ПО;
4)эффективность работ по исправлению ошибок, проводимых разработчиками ПО, зависит от частоты проявления ошибок, что в свою очередь завнснт от ин формации, поступающей от пользователя;
5)необходимость соблюдения ограничений по быстро действию и производительности, если таковые диктуются
пользователем.
Таким образом, надежность ПО представляется через определение вероятности отказа в отношении входного множества данных и через наблюдение интенсивности изменения вероятности отказа по мере устранения оши бок. Приведенные показатели в силу их количественной интерпретации могут быть использованы в качестве стандартных оценок программного обеспечения.
1.3. ЗАДАЧИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
С ЗАДАННЫМ УРОВНЕМ НАДЕЖНОСТИ
Основные задачи, решаемые в целях обеспечения надежности систем на этапе проектирования, могут быть условно разделены на три группы.
П е р в а я г р у п п а — обоснование требований по надежности. Эта группа задач решается на начальном этапе проектирования и предусматривает предваритель ную проработку укрупненной структуры системы, обосно вание принципов ее построения и последующего при менения.
В общем перечне требований, предъявляемых к вновь разрабатываемой системе ПО, должны быть специально выделены количественные требования надежности. При формулировании требований надежности необходимо иметь в виду, что достигнутый уровень надежности в зна чительной мере определяет эффективность использова ния систем. Наличие тесной связи надежности и эффек тивности применения свидетельствует о том, что задача обоснования требований надежности не может рассмат
22
риваться в отрыве от других характеристик системы, т. е. решение этой задачи должно основываться на иссле довании систем с применением методов оптимизации.
Решение задачи оптимизации с учетом структурных, технических и эксплуатационных характеристик иа на чальном этапе проектирования позволяет получить неко торые приближенные оценки с учетом возможного раз броса значений исходных параметров. В ходе проектиро вания требования по надежности системы могут быть
изменены с |
учетом достигнутого уровня надежности. |
В т о р у ю |
г р у п п у задач составляют задачи проек |
тирования системы с заданным уровнем надежности. При решении этих задач необходимо исследовать эффек тивность возможных способов обеспечения надежности с целью выбора наиболее приемлемого. Высокий уро вень надежности системы может быть достигнут за счет выполнения следующих мер: применения типовых про ектных решений; использования модульной структуры системы; соблюдения стандартов программирования и до кументирования; организации контроля функциониро вания системы путем взвимной межмодульной проверки. Для успешного решения задачи обеспечения надежности проектируемой системы необходимо соблюдать совокуп ность перечисленных мероприятий.
Т р е т ь ю г р у п п у задач составляют задачи коли чественной оценки надежности выбранного варианта ре ализации системы. К ним относятся выбор исходных данных, структурный анализ надежности, расчет достиг нутого уровня надежности и оценка точности получен ных результатов.
Как отмечалось ранее, основными проблемами прог раммного обеспечения в настоящее время являются вы сокая стоимость и ненадежность в работе. Современные системы ПО являются достаточно сложными и требуют существенных затрат на их создание и эксплуатацию. В связи с этим стоимость системы является одной из важнейших характеристик.
В полную стоимость системы ПО включаются не толь ко расходы на проведение анализа, разработки, коди рования, отладки н документирования, но и стоимость работы и эксплуатационные расходы в течение всего полезного времени использования программ. Высокая стоимость ПО в значительной мере объясняется пробле мами обеспечения надежности.
Поиск путей снижения стоимости ПО за счет повыше
23
ния производительности труда программистов ие дает ощутимых результатов. Попытки интенсификации труда программистов в ряде случаев приводят к увеличению стоимости ПО за счет последующего устранения нена дежности. Одним из предпочтительных путей снижения стоимости ПО является уменьшение затрат на тестиро вание и поддержку. Это может быть достигнуто ие только за счет разработки специальных средств автомати зации процедур тестирования и поддержки, сколько за счет четкой аккуратной разработки ПО, а также обеспе чения надежности с самого начала разработки.
|
Вопросы к главе 1 |
1 |
Сформулируйте определение надежности ПО |
2. |
В чем состоят основные отличия между надежностью аппаратура |
3 |
и надежностью ПО? |
Сущность сбоя аппаратуры и программной ошибки |
|
4. Дайте определение корректности ПО |
|
Б |
Сформулируйте «слабые» стороны введенных показателей надеж |
ности ПО.
6. Сущность количественной оценки надежности ПО
7 Перечислите н охарактеризуйте задачи проектирования с заданным уровнем надежности
Г л а в а 2
ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Несмотря на то что трудности разработки ПО сопро вождают вычислительные машины с момента их появле ния, только недавно началось интенсивное изучение про цесса разработки ПО, его развития н специфической продукции этапов разработки.
Анализ первых полученных результатов позволяет утверждать, что имеет место множество факторов, сдер живающих производство и использование систем ПО. Не претендуя на полноту охвата, отметим наиболее су щественные, на наш взгляд, факторы:
1) большое количество ошибок, сопровождающих разработку элементов систем программного обеспече ния;
2)трудность в использовании: ряд свойств (возмож ностей систем) отвергается пользователями как громозд кие и неудобные в эксплуатации;
3)большая сложность при создании и эксплуатации
систем ПО. Отсутствие обозримой логической структуры
24
сложных систем является следствием их постоянного
увядания, |
т. |
е. |
потери эксплуатационных качеств; |
4) |
некоторое |
количество систем ПО терпит крах в |
|
эксплуатации |
из-за |
низкой надежности. |
Далеко не полный перечень перечисленных выше факторов наводит на мысль о необходимости изучения проблем качества и надежности систем ПО. Одной из существенных причин проявления перечисленных выше факторов является тенденция большей части программис тов (особенно умудренных опытом) производить изящ ные программы. Подтверждением этого факта является то обстоятельство, что редко удается модифицировать продукт ручного труда талантливых программистов. Вторая причина — слабое управление контролем качест ва труда программистов. Если бы сегодня была предло жена система контроля качества программ, то вряд ли такая ревизия была бы встречена программистами с эн тузиазмом. В качестве третьей причины можно отметить тенденцию набирать штаты разработчиков, скорее, с учетом полного количественного, чем качественного охвата работы. В-четвертых, существующая методология документирования разработок ПО и система стандарти зации недостаточно отработаны и пока еще слабо спо собствуют производству качественного и надежного ПО.
Основными факторами, определяющими качество и надежность проектируемой системы ПО, являются стои мость и время разработки. Существует и множество других факторов, важных с точки зрения надежности проектируемых систем программного обеспечения. Рас смотрим классификационную схему факторов, определя ющих надежность систем ПО.
Совокупность факторов, определяющих надежность, можно условно разделить на три группы: общие факторы; факторы, связанные с разработкой ПО, и эксплуатацион ные факторы (рис. 2.1). Знание этих групп факторов важно для совершенствования процесса проектирования ПО с целью сокращения до минимума количества ошибок, встречающихся в программах.
2.1.ГРУППА ОБЩИХ ФАКТОРОВ
Вгруппу общих факторов, определяющих надеж ность программного обеспечения, объединены крупные проблемные вопросы, решение которых в основном опре-
25
Рис 2 I Совокупность фвкторов, определяющих надежность ПО
деляет переход к индустриальным методам разработ ки ПО
Управление разработкой. Несмотря на то что програм мирование существует как наука уже свыше 30 лет, во просы руководства разработкой и оценкой ПО нельзя считать решенными В первые годы появления ЭВМ, обеспечивающих обработку экономической информации, управление разработкой ПО едва лн представляло собой какую-либо организованную деятельность. В результате время разработки программ часто было чрезмерно боль шим, документации практически не существовало, про цесс отладки был достаточно длительным и трудоемким. В последнее десятилетие положение постепенно улуч шается, так как стало ясно, какие большие издержки связаны с бесконтрольностью разработки ПО.
При использовании вычислительной техники в широ ких масштабах с заменой традиционных методов расчета методами, основанными на использовании ЭВМ, вопросы техники программирования, квалификации персонала и управление работой в значительной мере оказывают влияние на производство качественного ПО. Опыт фирмы БОИНГ [10] показал, что из 687 прогонов программ продолжительностью 83 часа на машине CDC 6600 только 14% прогонов были безошибочными. Кроме того, 39% прогонов, признанных вначале успешными, оказались в последующем непригодными из-за ошибок в данных, программах, из-за неисправностей носителей информации. Влияние этих ошибок сказалось на стоимости и сроках выпуска продукции.
Качество разработанного ПО оказалось значительно ниже производственных требований, а его низкая на дежность вела к повышению стоимости вычислительных работ Недостаточная надежность ПО была вызвана следующими причинами:
недостатками в подготовке инженерного и руководя щего персонала по технологии использования вычисли тельных машин;
недостатками по контролю выдачи и изменения про грамм,
недостатками в организации связи между разработ чиками и пользователями программ,
недостатками в методах контроля, недостатками в документации.
Программа обучения с целью снижения ошибок до приемлемого уровня была разработана отдельно для ин
27
женеров и для руководителей. Курс обучения руководя щего персонала состоял из следующих дисциплин:
а) методы использования вычислительных машин, включая матричную алгебру для решения уравнений, вопросы структурной эластичности материалов, оборудо вание вычислительных машин, языки программирования, основы создания больших систем вычислительных про грамм, построенных по модульному принципу и исполь зующих языки высокого уровня;
б) планирование задания, анализ существующих программ по относительным и абсолютным критериям, по надежности, с оценкой их вычислительных возмож ностей, сетевые графики, методы упрощения структур для машинного анализа;
в) методы подготовки и управления данными, кон троль качества работ и автоматический контроль; г) взаимный доступ и совместная работа вычисли
тельных машин, режим разделения времени.
Курс инженеров был направлен на лучшее исполь зование вычислительной техники для анализа. Курс включал математические основы, расчета (матричная алгебра, системы линейных уравнений, Фортран), струк турную механику и анализ, а также неклассическое при менение существующих программ.
Сотни программистов и пользователей применяли оди наковые программы. При этом было установлено, что:
отсутствовало различие между разрабатываемым и используемым вариантами программ;
варианты программ выдавались непосредственно раз работчиками пользователям;
не было четких наименований и нумерации программ; отсутствовала методика сохранения всех разработан
ных вариантов; ие было гарантии, что изменения, сделанные програм
мистом, были в интересах пользователей, а ие самого программиста;
не было средств для сохранения нужных вариантов н устранения устаревших;
не было лица, ответственного за целостность всех программ.
Для устранения указанных недостатков был назначен ответственный за выдачу и изменение программ, который присваивает имена и назначает номера рабочим и эта лонным лентам.
Эталонная лента доступна для чтения лишь инжене
28
рам и программистам. Если рабочая лента разрушается, то создается новая лента, на которую переносится ста рый номер. Это исключает необходимость информиро вать пользователя о смене номеров Будучи однажды созданной, рабочая лента никогда не изменяется Кор рекция ошибок осуществляется за счет увеличения числа вариантов программ, реализуемых на новых лентах. Старые варианты сохраняются, пока не будет установле но, что они перестали использоваться.
Изменения в управляющей программе проводятся по следующей процедуре. Программист, осуществляющий изменения, работает с копией кодового источника с эта лонной ленты Перед реализацией изменений ответствен ный исполнитель просматривает модернизированные кар ты и кодовый источник иа своей эталонной ленте с тем, чтобы создать новые рабочие и эталонные ленты. И лишь затем создаются каталог и файлы.
Информация о создаваемых и используемых програм мах производится посредством публикации, в которой со держатся имя и номер программы; имя и номер телефона создателя и руководителя, ответственных за программу; приводится список документов, имеющих отношение к программе; сообщаются номера лент и другая информа ция, необходимая для прогона; указывается область при менения программы и отличие ее от старой.
При осуществлении контроля введена следующая система правил:
проверка справедливости расчетов отделена от провер ки логики программы;
если программа разбита иа отдельные модули, то н проверяются они отдельно;
результаты проверок фиксируются в документах.
Вруководящих документах излагаются вопросы тео рии, кодирования, проверки и использования. Для инже неров н программистов дается методика, иа которой основана программа В части кодирования излагается структура программы и приводится информация для ее модификации. Основной вид документации дается на ма кроуровне в потоковых диаграммах со ссылкой иа кодовый источник. Подробные диаграммы обычно не используются.
Взаглавии программы указываются ее имя, список лиц, разрабатывавших и модифицировавших программу, система ссылок, организация данных и требование к па мяти. В подпрограмме указана цель, приводится обосно вание метода или ссылка на метод, массив данных и опре
29
деления. В общей части даются пояснения к коду и объяс няется местное использование переменных. Преимущест во такой современной формы документации в том, что каждый массив содерхит относящиеся к нему ссылки.
Вразделе «проверка» содержится описание контрольных
итестовых испытаний Материалы по использованию освобождают пользователя и разработчика от необхо димости частого общения. Описаны программы, включен ные в раздел «кодирование». В разделе «использование» содержится описание целей и возможностей программы, дается изложение теорий и принципов построения про
граммы, доступ к операционной системе, управление, форматы, описания, ограничители, диагностика и исправ ление ошибок, оценка времени работы, объем входных и выходных данных, связь с другими программами, примеры.
Для усовершенствования системы управления разра боткой была проведена инвентаризация программ с клас сификацией их в три группы:
контролируемые программы, находящиеся в исполь зовании и постоянно сохраняемые;
устаревшие программы, но находящиеся пока в поль зовании;
неконтролируемые и неиспользуемые программы.
В течение первого года все программы были или по ставлены в первую гзуппу, или убраны. Для важных программ была подготовлена документация. Измененные программы были собраны в пакеты и использованы в ин тервале от трех до шести месяцев.
У инженеров н программистов существовало много частных вариантов программ. Были приняты меры к ис ключению таких вариантов. Имя и номер всякой работав шей программы анализировались операционной системой. Записывались имя липа, использовавшего эту программу, й информация, относицаяся к программе. Полученные данные о времени работы анализировались каждый ме сяц с целью исключения ненужных вариантов. Переход от программ третьей группы к программам первой груп пы был осуществлен sa один год.
После введения описанных мер контроля, носящих, скорее, административный, чем технический характер, ошибки в кодирование составлявшие одну на десять ис полнений разных про'рамм, снизились до одной на три сотни исполнений. Таг, в одной из программ, состоящей из семи тысяч команд было всего 10 ошибок за 15 меся
30