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

12 8 Зависимость количества протестированных дуг от числа входов

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

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

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

Было выполнено моделирование для пяти структур, отличающихся количеством дуг, при 50 входах Резуль­ таты представлены на рис 12 9. В качестве вертикальной оси было выбрано процентное содержание остаточных ошибок в связи с тем, что число ошибок в каждой из структур (первоначальных и добавленных) менялось

232

12 9 Связь между остаточными ошибками и сложностью

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

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

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

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

На рис 12 10 приведена зависимость процента оста­ точных ошибок от сложности, мерой которой выступает

253

12 10 Влияние сложности на количество остаточных ошибок

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

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

12 II Влияние сложности на количество протестированных дуг

2М

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

чением сложности.

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

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

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

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

Одна из таких моделей базируется на свойствах внут­ ренней и внешней связности модулей Для использования

256

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

элемент D,, представляет собой вероятность того, что i—й модуль будет изменяться, если модуль j изменяется при условии рассмотрения взаимосвязи модулей вне кон­ текста всей программы Величины S, и S, представляют собой оценку внутренней связности модулей, а С,/ — внешнюю связность модулей

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

1) нахождение совокупности уникальных путей на графе между парой модулей,

2)вычисление вероятности выбора путей;

3)вычисление взаимосвязи между двумя модулями на основе Вероятности выбора путей. Эта Связь определяет вероятность изменения одного модуля на основе изменения другого модуля.

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

Вопросы к главе 12

1.Сформулируйте основные задами и принципы моделирования оценки надежности ПО

2В чем состоит возможность и необходимость применения статистики при оценке надежности ПО’

3В чем заключаются особенности конструирования модели на базе теории надежности технических систем’

4Дайте сравнительную оценку приведенных моделей оценки надеж иости иа базе теории надежности технических систем

256

** *

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

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

использование устаревшей технологии проектирования программной продукции:

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

мной продукции; повышение требований к надежности и качеству про­

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

низкий уровень автоматизации проектных работ в про­ изводстве программной продукции.

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

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

257

ник» сроков завершения проектов и перерасходу выделен­ ных -средств.

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

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

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

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

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

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

238

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

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

ипроверки данных процесса. Функциональные дожиты процесса могут предусматривать определение бешвиеч-

ных циклов, неверных окончаний циклов, незаконных и не­ верных ветвей.

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

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

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

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

260