Общая характеристика моделей надежности программных средств

                                                     (73)

                                                   (74)

Если предположить, что термины  “исправление” и “ошибка” идентичны, то тогда модель для оценивания общего количества ошибок в программе, предложенная специалистами из IBM и основанная на приведенных выше объяснениях, записывается следующим образом:

                                                  (75)

где ИЗМ_i  - общее количество исправлений, внесенное в модули (или, другими словами, общее количество ожидаемых ошибок), а коэффициенты 23 и 2 – среднее количество исправлений на модуль для групп MИM и ИM, соответственно.

Прогноз основывается на запланированном  количестве исправлений в старых модулях и на количестве добавляемых модулей (СИМ_i, НМ_i) для реализации новых требуемых функций ПО. Если количество действительно внесенных исправлений меньше, чем предсказанное количество исправлений, то можно сделать вывод, что в ПО существует еще некое количество необнаруженных ошибок. Модель фирмы IBM позволяет сделать следующие выводы:

• на этапе пассивного сопровождения ПО (ИM_i = 0, СИМ_i невелико) количество исправляемых модулей и количество исправлений внутри модулей быстро убывает от версии к версии;
• количество ожидаемых ошибок в следующей версии может увеличится по сравнению с прошлой версией, если достаточно много старых модулей было изменено (СИМ), и/или было добавлено много новых модулей (НМ). 
• Добавление новых модулей оказывает более сильное влияние на рост числа новых ошибок, чем исправления, вносимые в старые модули; в то же время, если есть возможность создать новый модуль вместо изменения старых модулей (5 или более), то это снижает ожидаемое количество ошибок.  Другими словами, на некотором этапе сопровождения ПО изменение уже существующих модулей теряет свою эффективность, и требуется добавление вместо этого нового модуля.

 

2 Эмпирические модели надежности ПС

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

 

Модель сложности

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

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

В качестве структурных характеристик  модуля ПС используются:

1. отношение действительного числа дуг к максимально возможному числу дуг, получаемому искусственным соединением каждого узла с любым другим узлом дугой;
2. отношение числа узлов к числу дуг;
3. отношение числа петель к общему числу дуг.

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

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

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

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

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

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

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

1) Одним из наиболее простых критериев оценки сложности программ является ее длина - количество операторов (команд).

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

2) Цикломатическое число.

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

Дадим понятие цикломатического числа  для потокового графа программ.

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

G = (V, E) ,       (76)

где V представляет собой совокупность вершин графа, а Е -  совокупность дуг.

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

Цикломатическое число для потокового графа, представлено на рисунке  3, определяется следующим образом

Z (G) = E – V + 2     (77)

где: E – количество дуг графа, V – количество вершин.

 

Рисунок 3. Управляющий граф программы

 

Для графа на рисунке 3 цикломатическое число будет равно:

Z (G) = 17 – 12 + 2 = 7.

 

3) Мера сложности Холстеда .

Холстед кроме измерения длины  программы предложил также учитывать  количество операндов и число появления в процессе выполнения операторов и операндов. Он ввёл следующие меры:

η₁ – число различных операторов;

η₂ – число различных операндов;

η₁ + η₂ = η – словарь программы;

N₁ – число появлений операторов;

N₂ – число появлений операндов.

N₂ +N₁ = N – длина программы.

 

Тогда теоретическая длина программы:

N = η₁ log ₂ η₁ +  η₂ log ₂ η₂     (78)

Холстед ввел такую меру сложности, как объем программы:

V = N  log₂ η      (79)

Сложность программы  определяется по формуле [80 ]:

E =  η₁ N₂ N log ₂ η/ 2 η₂    (80)

Величина Е соответствует усилию, затрачиваемому на кодирование и понимание программы.

Эксперименты показали , что число ошибок в неоттестированных программах пропорционально E^2/3, где E – мера сложности Холстеда:

E₀ = K * E^2/3 ,      (81)

K = 1/3200

В прошедших стадию тестирования и  отладки программах это отношение  сохраняется, но коэффициент пропорциональности K принимает меньшие значения.

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

 

Модель, определяющая время доводки программ

 Эта модель используется для ПС, которые имеют иерархическую структуру, т.е. ПС как система может содержать подсистемы, которые состоят из компонентов, а те, в свою очередь, состоят из V модулей. Таким образом, ПС может иметь  различных уровней композиции. На любом уровне иерархии возможна взаимная зависимость между любыми парами объектов системы. Все взаимозависимости рассматриваются в терминах зависимости между парами модулей.

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

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

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

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

• фиксировать все ошибки нулевого порядка в каждом модуле, затем  фиксировать все ошибки первого  порядка и т.д.

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

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

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

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

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