Оценка надежности модульных программных средств
Предлагается методика оценки надежности программного средства, основанная на оценке надежности отдельно взятых модулей. Предложены метрики для оценки веса модуля. Предложена методика для оценки качества документации. Предложены метрики для оценки качества документации и установлена зависимость меж...
Saved in:
| Date: | 2010 |
|---|---|
| Main Authors: | , |
| Format: | Article |
| Language: | Russian |
| Published: |
Інститут програмних систем НАН України
2010
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/14626 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Оценка надежности модульных программных средств/ А.В. Анцыпов, В.В. Бахтизин// Пробл. програмув. — 2010. — № 2-3. — С. 307-311. — Бібліогр.: 5 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
nasplib_isofts_kiev_ua-123456789-14626 |
|---|---|
| record_format |
dspace |
| spelling |
nasplib_isofts_kiev_ua-123456789-146262025-02-10T01:13:51Z Оценка надежности модульных программных средств Estimation of reliability of modular software Анцыпов, А.В. Бахтизин, В.В. Методи та засоби програмної інженерії Предлагается методика оценки надежности программного средства, основанная на оценке надежности отдельно взятых модулей. Предложены метрики для оценки веса модуля. Предложена методика для оценки качества документации. Предложены метрики для оценки качества документации и установлена зависимость между качеством документации и надежностью программного средства. This paper suggests a method of reliability estimation of software. It is based on: single module reliability estimation. It suggests metrics for module weight estimation. It suggests a method of estimation of quality of documentation. It suggests metrics for quality of documentation estimation. The relationship was established between the quality of documentation and software reliability. 2010 Article Оценка надежности модульных программных средств/ А.В. Анцыпов, В.В. Бахтизин// Пробл. програмув. — 2010. — № 2-3. — С. 307-311. — Бібліогр.: 5 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/14626 681.3 ru application/pdf Інститут програмних систем НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Russian |
| topic |
Методи та засоби програмної інженерії Методи та засоби програмної інженерії |
| spellingShingle |
Методи та засоби програмної інженерії Методи та засоби програмної інженерії Анцыпов, А.В. Бахтизин, В.В. Оценка надежности модульных программных средств |
| description |
Предлагается методика оценки надежности программного средства, основанная на оценке надежности отдельно взятых модулей.
Предложены метрики для оценки веса модуля. Предложена методика для оценки качества документации. Предложены метрики для
оценки качества документации и установлена зависимость между качеством документации и надежностью программного средства. |
| format |
Article |
| author |
Анцыпов, А.В. Бахтизин, В.В. |
| author_facet |
Анцыпов, А.В. Бахтизин, В.В. |
| author_sort |
Анцыпов, А.В. |
| title |
Оценка надежности модульных программных средств |
| title_short |
Оценка надежности модульных программных средств |
| title_full |
Оценка надежности модульных программных средств |
| title_fullStr |
Оценка надежности модульных программных средств |
| title_full_unstemmed |
Оценка надежности модульных программных средств |
| title_sort |
оценка надежности модульных программных средств |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2010 |
| topic_facet |
Методи та засоби програмної інженерії |
| url |
https://nasplib.isofts.kiev.ua/handle/123456789/14626 |
| citation_txt |
Оценка надежности модульных программных средств/ А.В. Анцыпов, В.В. Бахтизин// Пробл. програмув. — 2010. — № 2-3. — С. 307-311. — Бібліогр.: 5 назв. — рос. |
| work_keys_str_mv |
AT ancypovav ocenkanadežnostimodulʹnyhprogrammnyhsredstv AT bahtizinvv ocenkanadežnostimodulʹnyhprogrammnyhsredstv AT ancypovav estimationofreliabilityofmodularsoftware AT bahtizinvv estimationofreliabilityofmodularsoftware |
| first_indexed |
2025-12-02T09:49:17Z |
| last_indexed |
2025-12-02T09:49:17Z |
| _version_ |
1850389517017546752 |
| fulltext |
Методи та засоби програмної інженерії
© А.В. Анцыпов, В.В. Бахтизин, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 2–3. Спеціальний випуск 307
УДК 681.3
ОЦЕНКА НАДЕЖНОСТИ
МОДУЛЬНЫХ ПРОГРАММНЫХ СРЕДСТВ
А.В. Анцыпов, В.В. Бахтизин
Белорусский государственный университет информатики и радиоэлектроники,
220027, Минск, Республика Беларусь, ул. П. Бровки, 6, тел.: +375 29 7566009
E-mail: ancipov@gmail.com
Предлагается методика оценки надежности программного средства, основанная на оценке надежности отдельно взятых модулей.
Предложены метрики для оценки веса модуля. Предложена методика для оценки качества документации. Предложены метрики для
оценки качества документации и установлена зависимость между качеством документации и надежностью программного средства.
This paper suggests a method of reliability estimation of software. It is based on: single module reliability estimation. It suggests metrics for
module weight estimation. It suggests a method of estimation of quality of documentation. It suggests metrics for quality of documentation
estimation. The relationship was established between the quality of documentation and software reliability.
Введение
В настоящее время деятельность многих организаций и предприятий напрямую зависит от правильной
обработки информации соответствующими программными средствами.
К настоящему времени более 90 стран мира адаптировали стандарты ISO 900x на национальном уровне
[1]. Во многих случаях заказчикам необходимо знать, каким образом на предприятии обеспечивается качество
разрабатываемого программного средства. В этом случае соответствие стандартам является гарантией качества
программного средства.
Одним из основных стандартов качества в области инженерии программного обеспечения в настоящее
время является стандарт ISO/IEC 9126-1:2001 – Software engineering – Product quality (Информационная
технология. Качество программного продукта) [2].
ISO/IEC 9126 регламентирует шесть основных характеристик качества программных средств:
функциональность, надежность, эффективность, практичность, сопровождаемость, мобильность.
Одной из основных характеристик качества программных средств является надежность [2, 3]. Оценка
надежности разрабатываемого программного средства является одной из важных задач, стоящих перед
разработчиком программного средства.
На надежность программного средства влияет очень много факторов, одним из которых является
качество документации. Под документацией понимается совокупность документов определяющих процедуры и
ресурсы, необходимые для управления и обеспечения программного проекта. В данной статье исследуется
зависимость надежности разрабатываемого программного средства от качества документации.
Оценка качества документации
Для количественной оценки качества документации предлагаются следующие метрики.
1. Соответствие документации программному средству. Документация должна соответствовать разра-
батываемому программному средству. Если обозначить А – количество документов (спецификация требований,
планы тестирования и т. п.) соответствующих разрабатываемому программному средству, В – общее
количество документов, которые должны соответствовать разрабатываемому программному средству, то
числовую оценку метрики можно найти по формуле
A
X
B
. При этом справедливо: 0 < А < В, 0 < X < 1.
2. Документирование выходных результатов. При разработке программного средства разработчик
должен документально оформить выходные результаты. Если обозначить А – количество документально
оформленных результатов, В – общее число выходных результатов, то числовую оценку метрики можно найти
по формуле
B
A
X . При этом справедливо: 0 < А < В, 0 < X < 1.
3. Документирование возникших проблем. При разработке программного средства разработчик должен
документально оформить возникающие проблемы и устранить несоответствия. Если обозначить А – количество
документально оформленных возникших проблем, В – общее число возникших проблем, то числовую оценку
метрики можно найти по формуле
A
X
B
. При этом справедливо: 0 < А < В, 0 < X < 1.
mailto:ancipov@gmail.com
Методи та засоби програмної інженерії
308
4. Документирование используемых стандартов и методов. При разработке программного средства
разработчик должен выбрать, адаптировать и использовать те стандарты, методы, языки программирования,
которые документально оформлены. Если обозначить А – количество документально оформленных стандартов,
методов, языков программирования, В – общее количество используемых стандартов, методов, языков
программирования, то числовую оценку метрики можно найти по формуле
A
X
B
. При этом справедливо:
0 < А < В, 0 < X < 1.
5. Документирование планов проведения работ. При разработке программного средства разработчик
должен разработать планы проведения работ процесса разработки. Планы должны включать все требования
связанные с разработкой, включая безопасность и защиту. Если обозначить А – количество документально
оформленных требований, В – общее количество требований, то числовую оценку метрики можно найти по
формуле
A
X
B
. При этом справедливо: 0 < А < В, 0 < X < 1.
Необходимо учитывать, что каждая метрика в различной степени влияет на качество документации.
В мировой практике принято использовать методы ранжирования с целью определения весовых
коэффициентов метрик. Каждый эксперт оценивает вес каждой метрики по шкале относительной значимости
в диапазоне от 0 до 1. В качестве общей меры оценки в данной работе используется средневзвешенное значение
веса i-й метрики
iV . Условие нормирования для
iV имеет вид
1
1.
mN
i
i
V
e
em
N
1
NN
1 1
,
ji
j
i
li
l i
v
V
v
где Nm – количество метрик, Ne – количество экспертов,
liv и
jiv – соответственно экспертная оценка
l-й и j-й метрики i-гo эксперта.
Зная значения метрик и их веса, качество документации разрабатываемого программного средства QПС
можно найти по формуле
mN
i
iiПС XVQ
1
,
где
iX – значение i-й метрики.
Оценка надежности программного средства
Зная качество документации разрабатываемого программного, следующим шагом является оценка его
надежности. Как правило, современные программные средства имеют модульную структуру. Оценка
надежности всего программного средства является достаточно сложной задачей. Существенно проще оценить
надежность отдельно взятых модулей, а потом дать общую оценку надежности всего программного средства.
При оценке надежности модуля необходимо учитывать не только количество ошибок, но также и
последствия, которые могут произойти в результате возникновения ошибки, и вероятность ввода k-го набора
данных, приведшего к ошибке. В соответствии с международным стандартом IEEE 1044.1-1995 Guide to
Classification for Software Anomalies (Классификация ошибок программного средства) [2] все ошибки можно
разбить на 6 основных групп, представленных в таблице.
Таблица. Классификация ошибок программного средства в соответствии со стандартом IEEE 1044.1-1995.
Название
ошибки
Описание
Priceless Ошибка, после возникновения которой модуль перестает функционировать
High Ошибка, после возникновения которой модуль функционирует, но функционирует неверно
Medium
Ошибка, после возникновения которой пользователь может продолжать использовать
модуль, но данная ошибка может нанести существенный урон данным
Low Ошибка, последствия которой носят незначительный характер
None
Ситуация, когда одна часть пользователей считает, что это нормальное поведение модуля,
а вторая часть, что произошла ошибка
Detrimental
Ситуация, когда возможно появление ошибки (примером такой ситуации может быть
постоянно растущий объем оперативной памяти, используемой модулем)
Кроме того, следует учесть ситуацию, когда ошибка при вводе k-го набора данных может не возникнуть.
Методи та засоби програмної інженерії
309
Предлагается следующая методика определения оценки надежности модуля. Каждому типу ошибки
экспертным путем присваивается вес jE , условие нормирования для jE имеет вид
6
0
1j
j
E
. Чем выше вес
ошибки, тем более серьезные последствия она несет. 0E соответствует ситуации отсутствия ошибки. Очевидно,
что значение 0E равно нулю. Тогда оценка надежности i – го модуля ip определяется по формуле
1
1 ( * )
D
i j k
k
p E b
, (1)
где D – количество наборов данных, введенных пользователем; jE – вес произошедшей k-й ошибки; причем
}6,5,4,3,2,1,0{j ; kb – вероятность ввода k-го набора данных.
Условие нормирования для kb имеет вид
1
1.
D
k
k
b
Приведем пример. Оцениваемый модуль должен выполнять три операции: получение всех записей из
базы данных, добавление новой записи в базу данных и удаление не нужной записи из базы данных. Пусть
вероятность получения всех записей равна 0.5, вероятность добавления новой записи равна 0.3 и вероятность
удаления не нужной записи равна 0.2. Допустим, что получение всех записей прошло без ошибок, добавление
новой записи прошло с ошибкой типа High (пользователь получил ответ об успешном завершении операции,
хотя на самом деле запись не была добавлена), а удаление не нужной записи прошло с ошибкой типа
Detrimental (запись была удалена, но процесс удаления занял продолжительный период времени). Веса ошибок
Priceless, High, Medium, Low, None, Detrimental соответственно равны 0.5, 0.3, 0.1, 0.05, 0.035, 0.015. Тогда
оценка надежности модуля будет равна
907,0)2.0*015.03.0*3.05.0*0(1 ip .
При оценке надежности всего программного средства необходимо учитывать, что различные модули в
различной степени влияют на надежность программного средства (например, ошибка, возникшая при
сохранении информации более критична, чем ошибка, возникающая при ее отображении).
Введем понятие веса модуля, как степени влияния отказа модуля на отказ всего программного средства.
Обозначим вес i-го модуля как is . Условие нормирования для is имеет вид
n
i
is
1
1 ,
где n – количество модулей в программном средстве. Чем ближе значение is к единице, тем больше отказ i-го
модуля влияет на отказ всего программного средства.
Оценка надежности разрабатываемого программного средства ПСP определяется по формуле
n
i
iiПС psP
1
)*( . (2)
Предлагается следующий набор метрик для оценки веса модуля. При этом в метриках основанных на
сравнении с базовыми аналогами (метрики 5, 6), будем считать, что аналоги разработаны персоналом такой же
квалификации и при той же организации процесса разработки.
Пусть программа содержит несколько модулей.
1. Метрика “Потребляемые ресурсы модулем”. Как правило, более весомый модуль потребляет и больше
ресурсов.
Если обозначить А – объем потребляемых ресурсов модулем (объем оперативной памяти и т. п.),
В – общий объем потребляемых программным средством ресурсов, то числовую оценку метрики можно найти
по формуле
B
A
X . При этом справедливо: 0 < А < В, 0 < X < 1.
2. Метрика “Время работы модуля”. Как правило, чем большее время находится модуль в работе, тем он
более весом.
Если обозначить А – время работы модуля, В – общее время выполнения всей задачи, то числовую
оценку метрики можно найти по формуле
B
A
X . При этом справедливо: 0 < А < В, 0 < X < 1.
3. Метрика “Частота использования модуля”. Вероятность появления ошибки возрастает с ростом
количества вызовов модуля, поэтому часто вызываемые модули более весомы нежели модули вызываемые
реже.
Если обозначить А – количество вызовов модуля, В – общее количество всех вызовов модулей, то
числовую оценку метрики можно найти по формуле
A
X
B
. При этом справедливо:
1
1 , 1.А B X
B
Методи та засоби програмної інженерії
310
4. Метрика “Зависимость модулей”. Как правило, в программном средстве модули связаны в
древовидную структуру, где неправильная работа одного модуля приводит к неправильной работе других
модулей.
Если обозначить А – количество модулей зависящих от данного модуля, В – общее количество всех
модулей, то числовую оценку метрики можно найти по формуле
A
X
B
. При этом справедливо:
0 , 0 1.А B X
5. Метрика “Объем модуля”. Как правило, наиболее весомые модули имеют больший объем кода.
Если обозначить А – объем модуля (например, число строк кода), B – объем кода аналогичного по
функциональности модуля, взятый из статистических данных организации-разработчика программного
средства, то числовую оценку метрики можно найти по формуле
, если
.
1, если
A
A B
X B
A B
При этом справедливо: 0 , 0 1.A X
6. Метрика “Команда разработки модуля”. Как правило, в разработке наиболее весомых модулей
принимает участие большее количество разработчиков.
Если обозначить А – количество разработчиков, принимающих участие в разработки модуля, B –
количество разработчиков, принимавших участие в создании аналогичного по функциональности модуля,
взятое из статистических данных организации-разработчика программного средства, то числовую оценку
метрики можно найти по формуле
, если
.
1, если
A
A B
X B
A B
При этом справедливо: 0 , 0 1.A X
Вес i-го модуля si определяется по формуле
1
1
( )
,
i
i
m
ij ij
j
i m
ij
j
V X
s
V
1
1,
m
ij
j
V
, (3)
где m – общее количество метрик; mi – количество метрик используемых для расчета значения веса i-го модуля
)( mmi ;
ijX – значение j-ой метрики, относящейся к i-му модулю;
ijV – весовой коэффициент j-ой метрики,
относящейся к i-му модулю, определяющийся по статистическим данным организации разработчика
программного средства или экспертным путем.
Зная надежность модулей ip и их веса is , по формуле (2) можно найти надежность всего программного
средства.
Зависимость надежности программного средства и качества документации
Проведен эксперимент, в рамках которого разрабатывалось программное средство, используемое при
проектировании оптоволоконных сетей. Разработка программного средства носила итерационный характер.
От первой и до финальной версии программного средства было выпущено сто промежуточных версий.
Для каждой версии программного средства была найдена его надежность и качество документации
(представленные на рисунке).
На рисунке видно, что с ростом качества документации, также возрастает и надежность разрабатыва-
емого программного средства.
Для установления зависимости качества документации и надежности разрабатываемого программного
средства проведен корреляционный анализ и определен нормированный коэффициент корреляции Браве –
Пирсона r [5].
100
1
2
100
1
2
100
1
)()(
)()(
i
i
i
i
i
ii
yyxx
yyxx
r
(4)
где xi – качество документации i-й версии программного средства, x – среднее значение качества
документации, yi – значение надежности i-й версии программного средства, y – среднее значение показателя
надежности.
Методи та засоби програмної інженерії
311
Рисунок. Сравнение значений надежности программного средства и качества документации
Коэффициент корреляции качества документации и надежности программного средства составил 0.913,
что говорит о высокой степени зависимости надежности программного средства и качества документации
разрабатываемого программного средства.
Для проверки значимости коэффициента корреляции находится показатель связности t [5]
1/
r
t
n
,
где r – коэффициента корреляции, n – количество версий разрабатываемого программного средства.
Для 0,05 получаем tкр=2.58 и t равное 9.13, так как t > tкр, следовательно зависимость между
качеством документации и надежностью программного средства следует считать значимой.
В данной работе предлагается методика оценки надежности программного средства, основанная на
оценке надежности отдельно взятого модуля, предложены метрики для оценки веса модуля, предложена
методика для оценки качества документации, предложены метрики для оценки качества документации
и установлена зависимость между качеством документации и надежностью программного средства.
Используя предложенную методику, у разработчика появляется возможность оценивать и контроли-
ровать надежность разрабатываемого программного средства. Достоинствами предложенной методики является
то, что она основана на общепризнанных мировых стандартах и проста в использовании.
1. Липаев В.В. Надежность программных средств. – М.: СИНТЕГ, 1998. – 280 с.
2. ISO/IEC 9126-1:2001 Software engineering – Product quality.
3. Бахтизин В.В., Глухова Л.А. Стандартизация и сертификация программного обеспечения. – Мн.: БГУИР, 2006. – 200 с.
4. IEEE Std 1044.1-1995 Guide to Classification for Software Anomalies.
5. Гайдышев И. Анализ и обработка данных. – Санкт-Петербург: Питер, 2001. – 232 c.
|