Разработка программно–алгоритмических средств для определения надёжности программного обеспечения на основании моделирования работы системы типа "клиент

,(А.12)

где pн – нижняя доверительная граница вероятности безотказной работы ПО при однократном прохождении набора стохастических входных данных; gн – доверительная вероятность; n – число проходов при тестировании.

Пусть, например, n=150 прохождений со случайными исходными данными. Исходы всех тестов положительные (ошибок не обнаружено), т.е. количество отказов ПО равно нулю. Необходимо определить нижнюю доверительную границу вероятности безотказной работы ПО при одном прохождении, при gн = 0,9.

Согласно (А.11) имеем pн = 0.985.

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

Пусть вероятность того, что при одном тесте ошибка не будет обнаружена, оценивается как 1 – r/N. Вероятность того, что при n независимых тестах ошибка не будет обнаружена, равна (1 – r/N)n. Если ошибочных символов в ПО больше чем один, то вероятность их обнаружения одним тестом будет еще больше, так как эта оценка является оценкой снизу.

Пусть n = 150; r/N = 0,3. Тогда вероятность обнаружения ошибки в ПО

p = 1 – (1 – r/N)150 = 1 – 1,72×10–20 @ 1.

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

Модель избыточности

Можно попробовать использовать подход, предложенный в статье [24] для описания эффективности защиты ПО от сбоев посредством введения в нее избыточного кода. Эффективность защиты (в расчете на которую в ПО вводится избыточный код, который снижает функциональные характеристики ПО, в частности, быстродействие и требует больших ресурсов (например, для использования образцового в этом отношении языка JAVA нужно как минимум 128 Мб ОЗУ)), априорно определим как вероятность P (являющейся функцией времени T периодичности работы программного модуля) нужности (срабатывания) защиты. Эта вероятность в рассматриваемом случае может быть выражена произведением вида:

P = Pe * Pr * Pd,(А.13)

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

Pr – вероятность того, что защита от этого сбоя сработает;

Pd – вероятность того, что сообщение о сбое будет получено и обработано (т.е. что диагностика сработает).

По сути данной задачи речь идет о двух типах случайных событий:

1. событии (нежелательном) состоящем в том, что произошел прогнозируемый сбой;

2. событии (желательном) состоящем в том, что защита сработает.

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

e – интенсивность (то есть вероятностью возникновения в единицу времени) возникновения ошибки (сбоя);

lr – интенсивностью отказа (не срабатывания) защиты, характеризующая надежность защиты;

ld – интенсивность срабатывания диагностики, характеризующая надежность системы диагностики Pd.

Тогда сомножители, входящие в формулу (А.13), можно представить в следующем виде:

(А.14) (А.15) (А.16)

где T – периодичность работы программного модуля;

a, b – вероятности ошибок 1–го и 2–го рода диагностики.

Диагностика представляет собой устройство (или программу), обеспечивающее оповещение оператора о сбое и принятии решения о дальнейшей работе. Исправный диагностический модуль по аналогии с размыкателем характеризуется двумя ошибками: ошибка 1–го рода – ложное срабатывание (например, выключение без наличия сбоя), ошибка 2–го рода – отсутствие срабатывания при наличии сбоя. Защита не эффективна в обоих случаях.

Подстановка (А.13) – (А.15) в (А.12) дает выражение:

,(А.17)

где

Функция (А.16) достигает максимума при значении T равном:

(А.18)

Значение T* представляет собой оптимальное время T защищенности программы. Таким образом, этот метод позволяет определить оптимальную периодичность работы программы, при которой защита с заданными характеристиками e, lr, ld дает оптимальный эффект. Либо можно оценить одну из характеристик e, lr, ld при заданных остальных и заданном T*.

Например, оценим T*:

e – один раз в месяц, т.е. равна 3,7e–7;

lr = e;

ld – один раз в минуту, т.е. равен 0,017.

Тогда T* = 59 с.

Теперь, оценим ld при следующих условиях:

T* = 60 с;

e – один раз в год, т.е. равна 3,3e–8;

lr = e.

Тогда из (А.17) имеем

Получаем ld = 1,67e–02 1/с или один раз в минуту.

Модель Дюэна

Модель рассмотрена в работе [20]. Эта модель была предложена для оценки роста надежности. Для этого рассматривается отношение интенсивности обнаружения ошибок к общему времени тестирования. В основу модели положены следующие предположения:

обнаружение любой ошибки равновероятно;

общее число ошибок N(t), обнаруженных к произвольному моменту t, распределено по закону Пуассона со средним значением n(t) = a×tb.

Из этого следует, что

Из МНК получают следующую оценку для a и b:

где

Xi = ln(ti), Yi = ln(i/ti),

Для использования этой модели требуется только знание моментов времени ti проявления ошибок.

Метод Холстеда оценки числа оставшихся в ПО ошибок

Модель рассмотрена в работе [20]. На сегодняшний момент это единственная модель, с помощью которой можно оценить число ожидаемых (то есть потенциальных) ошибок в ПО еще на этапе составления ТЗ на ПО.

Для программы вводится понятие длины программы N и объем программы (в битах) V:

N = n1×log2n1 + n2×log2n2,

V = N×log2(n1 + n2),(А.19)

где n1 – число различных операций (например, таких как IF, =, DO, PRINT и т.п.); n2 – число различных переменных и констант.

Далее рассматривается потенциальный объем программы (в битах) V*:

,(А.20)

где

– только число входных и выходных переменных.

Величина

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

Еще вводится понятие уровня программы L, который определяется как отношение потенциального объема V* к объему V:

L = V*/V.

Также вводятся величины:

E = V/L = V2/V*,

l = L×V*

– уровень языка программирования. Значения l для некоторых языков программирования: Ассемблер – 0,88; Фортран – 1,14; PL–1 – 1,53; С/С++ – 1,7; Pascal – 1,8; JAVA – 1,9.

Из этого следует, что

V = (V*)2/l.(А.21)

Оценка времени, затрачиваемое на разработку ПО:

T = E/S = (V*)3/(l×S) (А.22)

где S – параметр Страуда (психофизиологическая характеристика времени, необходимого человеческому мозгу для выполнения элементарной мыслительной операции. S лежит в пределах от 5 до 20 различий в секунду. Холстедом используется значение S = 18, характеризующее процесс программирования как довольно напряженную умственную работу).

Используя (А.21) можно оценить выигрыш во времени разработки при переходе от одного языка программирования l1 к другому языку l2:

Например, выигрыш при переходе с C/C++ на JAVA составит около 10%, а с ассемблера на JAVA – 50%.

Основное предположения этой модели:

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

мозг человека может обработать одновременно и безошибочно 7±2 объектов (гипотеза Миллера).

Тогда, взяв нижнюю границу в 5 объектов и добавив еще один объект, мы получим максимальное число

= 6 различных входных и выходных параметров для потенциально безошибочной программы. Тогда потенциальный объем V0* по (17): V0* = (6+2) ×log2(6+2) = 24 логических бита.

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

Это означает, что на каждые 3000 бит объема V* приходится одна ошибка. Тогда для реального объема ПО из (П1.20) следует, что число ошибок в ПО:

(А.23)

Модель IBM

Модель рассмотрена в работе [20]. Эта модель предназначена для оценки количества вносимых ошибок в сопровождаемом ПО, находящемся в эксплуатации, при его модификации. Модель построена на данных сопровождения 19 версий ОС OS/360 фирмы IBM.