CC BY
62
_Доклады БГУИР_
2010 №4 (50)
ИНФОРМАТИКА
УДК 004.05
МЕТОДИКА ОЦЕНКИ НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ
А.В. АНЦЫПОВ, ВВ. БАХТИЗИН
Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220013, Беларусь
Поступила в редакцию 8 декабря 2009
Предлагается методика оценки надежности программных средств, основанная на: оценке надежности отдельно взятого модуля, оценке веса модуля, определении метрик для оценки веса модуля и отображении изменения надежности модулей в графическом виде.
Ключевые слова: качество программных средств, надежность программных средств, оценка надежности программных средств.
Введение
Сегодня деятельность многих организаций и предприятий напрямую зависит от правильной обработки информации соответствующими программными средствами. Поэтому к качеству современных программных средств предъявляются высокие требования.
Одним из основных стандартов качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEC 9126-1:2001 — Software engineering — Product quality (Информационная технология. Оценка программного продукта) [1].
Данный стандарт регламентирует шесть основных характеристик качества программных средств: функциональность, надежность, эффективность, практичность, сопровождае-мость, мобильность.
Оценка надежности модуля
Надежность является одной из основных характеристик качества программных средств [1, 3]. Оценка надежности разрабатываемого программного средства является одной из важных задач, стоящих перед разработчиком программного средства. Оценка надежности всего программного средства является достаточно сложной задачей. Существенно проще оценить надежность отдельно взятых модулей, а потом дать общую оценку надежности всего программного средства.
При оценке надежности модуля необходимо учитывать не только количество ошибок, но также и последствия, которые могут произойти в результате возникновения ошибки, и вероятность ввода k-го набора данных, приведшего к ошибке. В соответствии с международным стандартом IEEE 1044.1-1995 Guide to Classification for Software Anomalies (Классификация ошибок программного средства) [2] все ошибки можно разбить на шесть основных групп: Priceless — ошибка, после возникновения которой модуль перестает функционировать; High — ошибка, после возникновения которой модуль функционирует, но функционирует неверно; Medium — ошибка, после возникновения которой пользователь может продолжать использовать модуль, но данная ошибка может нанести существенный урон данным; Low — ошибка, последствия которой носят незначительный характер; None — ситуация, когда одна часть пользователей считает, что это нормальное поведение модуля, а вторая часть, что произошла ошиб-
ка; Detrimental — ситуация, когда возможно появление ошибки (примером такой ситуации может быть постоянно растущий объем оперативной памяти, используемой модулем). Кроме того, следует учесть ситуацию, когда ошибка при вводе k-го набора данных может не возникнуть.
В статье предлагается следующая методика определения оценки надежности модуля. Каждому типу ошибки экспертным путем присваивается вес Ej, условие нормирования для Ej 6
имеет вид . = 1. Е0 соответствует ситуации отсутствия ошибки. Очевидно, что значение Е0
j=o
в условии нормирования равно нулю. Чем выше вес ошибки, тем более серьезные последствия она несет. Тогда оценка надежности /-го модуля p/ определяется по формуле
d
А), а)
к=1
где D — количество наборов данных, введенных пользователем; Ej — вес ошибки, произошедшей после ввода к-то набора данных; причем /е {(). 1, 2, 3, 4, 5, 6}; Ь^ — вероятность ввода к-то набора данных.
d
Условие нормирования для bk имеет вид
к=1
Приведем пример. Банковскую компьютерную систему можно рассматривать как программное средство, где в качестве модулей выступают банкоматы, инфокиоски, серверы, обрабатывающие запросы пользователей, и прочее. В качестве исследуемого модуля возьмем банкомат. Пользователь банкомата может выполнить три операции: просмотр баланса на счету, снятие денег со счета и оплата коммунальных услуг. Пусть вероятность просмотра баланса равна 0,1, вероятность снятия денег равна 0,65 и вероятность оплаты коммунальных услуг равна 0,25. Допустим, что просмотр баланса произошел без ошибок, снятие денег произошло с ошибкой типа High (банкомат снял деньги со счета, но не выдал их пользователю), а оплата коммунальных услуг произошла с ошибкой типа Low (коммунальные услуги были оплачены, но пользователю не был выдан чек). Вес ошибок Priceless, High, Medium, Low, None, Detrimental соответственно равны 0,4; 0,25; 0,2; 0,1; 0,04; 0,01. Тогда оценка надежности модуля будет равна
рг = 1 - (0 - 0,1 + 0,25-0,65 + 0,1-0,25) = 0,8125.
При оценке надежности всего программного средства необходимо учитывать, что различные модули в различной степени влияют на надежность программного средства (например, ошибка, возникшая при сохранении информации более критична, чем ошибка, возникающая при ее отображении).
Введем понятие веса модуля как степени влияния отказа модуля на отказ всего программного средства.
n
Обозначим вес 7-го модуля как Условие нормирования для имеет вид ^ sj = 1, где
i~\
n — количество модулей в программном средстве. Чем ближе значение s/ к единице, тем больше отказ /-го модуля влияет на отказ всего программного средства.
Оценка надежности разрабатываемого программного средства РПС определяется по формуле
п
(2)
i=i
Метрики оценки веса модуля
Предлагается следующий набор метрик для оценки веса модуля. При этом в метриках, основанных на сравнении с базовыми аналогами (метрики 5, 6, 7), будем считать, что аналоги
разработаны персоналом такой же квалификации и при той же организации процесса разработки.
Пусть программа содержит несколько модулей.
1) Метрика "Потребляемые ресурсы модулем". Как правило, более весомый модуль потребляет и больше ресурсов.
Если обозначить: А — объем потребляемых ресурсов модулем (объем оперативной памяти и т.п.); В — общий объем потребляемых программным средством ресурсов, то числовую
оценку метрики можно найти по формуле Х=А/В. При этом справедливо: 0<А<В; 0<Х<1.
2) Метрика "Время работы модуля". Как правило, чем большее время находится модуль в работе, тем он более весом.
Если обозначить: А — время работы модуля; В — общее время выполнения всей задачи, то числовую оценку метрики можно найти по формуле Х=А/В. При этом справедливо 0<А<В; 0<Х<1.
3) Метрика "Частота использования модуля". Вероятность появления ошибки возрастает с ростом количества вызовов модуля, поэтому часто вызываемые модули более весомы, нежели модули, вызываемые реже.
Если обозначить: А — количество вызовов модуля; В — общее количество всех вызовов модулей, то числовую оценку метрики можно найти по формуле Х=А/В. При этом справедливо 1 <А<В; ИВ<Х<\.
4) Метрика "Зависимость модулей". Как правило, в программном средстве модули связаны в древовидную структуру, где неправильная работа одного модуля приводит к неправильной работе других модулей.
Если обозначить: А — количество модулей, зависящих от данного модуля; В — общее количество всех модулей, то числовую оценку метрики можно найти по формуле Х=А/В. При этом справедливо О<А<В; ()<Х< 1.
5) Метрика "Объем модуля". Как правило, наиболее весомые модули имеют больший объем кода.
Если обозначить: А — объем модуля (например, число строк кода); В — объем кода аналогичного по функциональности модуля, взятый из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
А
—, если А < В, В
1, если А >= В.
При этом справедливо 0<А: ()<Х< 1.
6) Метрика "Команда разработки модуля". Как правило, в разработке наиболее весомых модулей принимает участие большее количество разработчиков.
Если обозначить: А — количество разработчиков, принимающих участие в разработке модуля; В — количество разработчиков, принимавших участие в создании аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
А Л и
—, если Л < л, В
1, если А >= В.
При этом справедливо 0<А: 0<Х<1.
7) Метрика "Время, затраченное на разработку модуля". Как правило, на разработку наиболее весомого модуля затрачивается больше времени.
Если обозначить: А — время, затраченное на разработку модуля; В — время затраченное на разработку аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
х =
А А Р
—, если А<В, В
1, если А >= В.
При этом справедливо 0<А: ()<Х< 1.
8) Метрика "Квалификация команды разработчиков". Как правило, в разработке наиболее весомых модулей принимают участие более квалифицированные разработчики.
Если обозначить: А — уровень квалификации команды разработчиков, принимающих участие в разработке модуля (А — может быть определенно экспертным путем, ()<А< 1): В — уровень квалификации команды разработчиков, принимавших участие в создании аналогичного по функциональности модуля, взятый из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
А А Р
—, если А<В, В
1, еслиА>В.
При этом справедливо ()<А<\: 0<Х<1.
9) Метрика "Документирование модуля". Как правило, более весомые модули должны иметь больший объем документации.
Если обозначить: А — суммарный объем документов, описывающих анализируемый модуль; В — суммарный объем документов аналогичного по функциональности модуля, взятый из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
А А Р
—, если Л < л, В
1, если А> В.
При этом справедливо ()<А: ()<Х< 1.
10) Метрика "Тестовые наборы модуля". Как правило, более весомые модули имеют большее количество тестовых наборов данных.
Если обозначить: А — количество тестовых наборов разрабатываемого модуля; В — количество тестовых наборов аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
—, если А<В, В
1, если А> В.
При этом справедливо ()<А: ()<Х< 1.
11) Метрика "Время тестирования модуля". Как правило, более весомые модули тестируются более продолжительное время.
Если обозначить А — время тестирования разрабатываемого модуля; В — время тестирования аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
Х =
А А Р
—, если Л < л, В
1, если А> В.
При этом справедливо ()<А: ()<Х< 1.
Оценка веса модуля
Вес /-го модуля определяется по формуле
пц
ггц
2Х
-> (3)
г щ ' 47
У 1= 1
т
где ^ У^= 1; т — общее количество метрик; т^ — количество метрик, используемых для рас-
У=1
чета значения веса 7-го модуля (т,<т): Хи — значение /-и метрики, относящейся к 7-му модулю; Уу — весовой коэффициент]-й метрики, относящейся к /-му модулю, определяющийся по статистическим данным организации разработчика программного средства или экспертным путем.
Зная надежность модулей р/ и их веса s/, по формуле (2) можно найти надежность всего программного средства.
Отображение изменения надежности модулей в графическом виде
Разрабатываемые модули можно описать распределением модулей по уровням надежности и представить в виде матрицы-столбца (вектора надежности) Г=[/ДГХ1, где г — число уровней надежности модуля. Численное значение элементов вектора надежности Е показывает процент модулей, относящихся к /-му уровню надежности. К /-му уровню надежности будут принадлежать модули с надежностью в диапазоне [(/-1)/г; Иг). При этом/1 — процент модулей, уровень надежности которых близок к нулю; /г — процент модулей с уровнем надежности, близким к 1.
г
Условие нормирования вектора надежности имеет вид ^ = 1.
¿=1
В процессе итеративной разработки, как правило, количество ошибок модуля уменьшается, что приводит к росту надежности модулей и изменению элементов вектора надежности.
Пусть Еь Е2 — соответственно вектора надежности до и после очередной итерации разработки; -В=[6у]Гхг — матрица изменения надежности модулей. Значение элемента матрицы [6у]гхг показывает процент модулей, которые, находясь на /-м уровне надежности, после очередной итерации разработки перешли на /-й уровень.
Вектор Е2 будет равен матричному произведению матрицы В и вектора Еь
Пусть разрабатываемое программное средство состоит из 100 модулей, число уровней надежности равно пяти и вектор Е1 равен [0,2; 0,15; 0,25; 0,15; 0,25]5х1. Пусть на следующей итерации 5 модулей, находившихся на первом уровне, остались на нем же, 5 модулей перешли с первого уровня на третий, а 10 модулей перешли с первого уровня на четвертый. Тогда первый столбец матрицы В можно представить в виде
5 5 10
-;0:-;-:0
0,2-100 0,2-100 0,2-100
= 0,25:0:0,25:0,5:0
Аналогичным образом можно сформировать оставшиеся столбцы (в процессе разработки реального программного средства процесс генерации матрицы В можно автоматизировать, что избавит разработчика от монотонной работы). Матрица В для данной итерации равна
0,25 0 0 0 0
0 0,6 0,2 0 0
0,25 0 0,6 0 0,4
0,5 0,4 0 0,6 0
0 0 0,2 0,4 0,6
5 5
Тогда вектор Г2 будет равен [0,05; 0,14; 0,3; 0,25; 0,26]5 ь
В графическом виде матрица В представлена на рисунке, из кторого видно, что у 60% модулей, находящихся на третьем уровне надежности, после очередной итерации надежность не изменилась, у 20% модулей надежность улучшилось, и они перешли с третьего уровня на пятый, и у 20% модулей надежность ухудшилась, и они перешли с третьего уровня на второй.
Матрица В показывает изменение надежности программного средства в динамике. И дает более детальное представление об изменении надежности разрабатываемого программного средства.
Заключение
В данной работе предлагается методика оценки надежности программного средства, основанная на оценке надежности отдельно взятого модуля, оценке веса модуля, определении метрик для оценки веса модуля, а также представление изменений надежности модулей в графическом виде.
Используя предложенную методику, у разработчика появляется возможность оценивать и контролировать надежность разрабатываемого программного средства. Достоинствами предложенной методики является то, что она основана на общепризнанных мировых стандартах и проста в использовании.
Графическое представление матрицы изменения надежности
METHOD OF ESTIMATION OF SOFTWARE RELIABILITY
А.V. ANTSYPOV, V.V. BAKHTIZIN Abstract
This paper suggests a method of reliability estimation of software. It is based on: single module reliability estimation; module weight estimation, metrics definition for module weight estimation, and method of graphical presentation of module reliability variation.
Литература
1. ISO/IEC 9126-1:2001 Software engineering — Product quality.
2. IEEE Std 1044.1-1995 Guide to Classification for Software Anomalies.
3. Бахтизин В.В., Глухова Л.А. Стандартизация и сертификация программного обеспечения. Минск, 2006.
