CC BY
434
УСТАНОВКИ И МЕТОДИКИ ИССЛЕДОВАНИЯ
УДК 681.3.068
Н.В.Василенко, В.А.Макаров
ОЦЕНКА НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
A new model of the evaluation of software reliability, based on the estimation of processing and the results of the program product testing is proposed. The reliability estimation model, based on Poisson's heterogeneous models, is adapted. New concepts — reliability matrix and reliability class are introduced.
В международном стандарте ISO 9126:1991 [1] надежность выделена как одна из шести основных характеристик качества программного обеспечения (ПО) наряду с функциональной пригодностью, применимостью, эффективностью, сопровождаемостью и переносимостью. Но как узнать, насколько надежен программный продукт, выпущенный фирмой, специализирующейся на разработке ПО? Как измерить его надежность?
Согласно стандартному словарю терминов программного инжиниринга [2] надежность программного обеспечения есть способность системы или компонента выполнять требуемые функции в заданных условиях на протяжении указанного периода времени.
Для обеспечения надежности программ предложено множество подходов, включая организационные методы разработки, различные технологии и технологические программные средства, что требует, очевидно, привлечения значительных ресурсов. Однако отсутствие общепризнанных критериев надежности не позволяет ответить на вопрос, насколько надежнее становится программное обеспечение при соблюдении предлагаемых процедур и технологий и в какой степени оправданы затраты. Таким образом, приоритет задачи оценки надежности должен быть выше приоритета задачи ее обеспечения, чего на самом деле не наблюдается.
К настоящему времени разработаны различные модели надежности программного обеспечения, представляющие собой математические модели, построенные для оценки зависимости надежности программного обеспечения от некоторых определенных параметров (модели Шумана, Ла Падула, Джелинского — Моранды, Шика — Волвертона, Мусса, Миллса, Липова, Коркорэна, Нельсона, модель преходных вероятностей, простая интуитивная модель и др. [3]). Однако ни одна из предложенных моделей не используется на практике по той причине, что их применение неудобно или нецелесообразно. Отметим основные недостатки существующих моделей.
1. Модели оперируют с функциями, зависящими от времени проявления ошибок. А количество ошибок, выявляемых при тестировании и эксплуатации, зависит от времени только косвенно, так как время лишь в некоторых случаях влияет на разнообразие условий (количество различных, проявляющих ошибки условий) для тестируемого модуля.
2. При построении моделей не рассматриваются вопросы, связанные с характеристиками тестов, например полнотой теста, распределением появления входных наборов.
3. Значение полученных оценок во многих моделях зависит не только от свойств ПО, но и от принятого плана и методики испытания, что искажает полученные оценки. Например, в модели Нельсона не определено понятие эксперимента, а различные его трактовки приведут к совершенно разным результатам.
4. Некоторые модели, например модель Джелинского — Моранды, дают достаточно грубую, непригодную для использования оценку надежности.
5. В ряде моделей сказывается большое влияние субъективного фактора. Например, модель Миллса требует предварительно задать предполагаемый уровень ошибок в программе, что основывается исключительно на интуиции и опыте человека, проводящего оценку.
6. В некоторых моделях (например, в модели Коркорэна) требуется априорная информации или данные предшествующего периода функционирования однотипных программных средств.
Все упомянутые модели основаны на результатах тестирования (испытания) ПО. Но все активнее обсуждается вопрос обеспечения надежности в процессе разработки. Следует признать, что разумно оценивать надежность, не только как результат испытаний ПО, но и как организацию процесса создания надежного программного продукта. Предлагается определять надежность ПО на основе двух оценок: оценки процесса его разработки и оценки результатов тестирования.
Процесс разработки ПО можно оценить с помощью факторов, влияющих на этот процесс. Эти факторы рассматриваются многими авторами. Например, А.В.Коганов и С.Г.Романюк [4] вводят понятие кортежа программы и, говоря о надежности ПО, имеют в виду надежность составляющих этого кортежа. В кортеж входят: сама программа, окружающая среда, режим эксплуатации и документация. В.В.Липаев [5] среди прочих приводит такие факторы, как допустимые финансово-экономические затраты, кадры специалистов, доступные разработчикам ПО вычислительные ресурсы. В.В.Шураков [6] делит все факторы на три группы: общие (процедура управления разработкой, квалификация персонала и др.), связанные с разработкой ПО (конструктивные, технологические, организационные) и эксплуатационные.
Нами выделены следующие, на наш взгляд, наиболее существенные факторы, влияющие на надежность ПО в процессе разработки:
— совершенство процесса управления разработкой (УПР),
— квалификация участников разработки программного продукта (КВАЛ),
— сложность архитектуры системы (АРХ),
— язык программирования (ЯЗ),
— трудоемкость разработки (ТРУД),
— опыт в разработке подобных систем (ОПЫТ),
— взаимодействие в команде (КОМ),
— полнота и качество документации (ДОК).
Совершенство процесса управления разработкой предлагается оценивать в соответствии с моделью зрелости процесса разработки ПО — CMM (Capability Maturity Model), предложенной в 1991 г. институтом системного программирования при университете Карнеги — Меллон [7]. В модели CMM определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически) понижаться.
Для оценки квалификации участников разработки программного продукта введем показатель Q, который рассчитывается по формуле.
где Q — оценка квалификации команды; N — количество человек в команде разработки; N — число сертифицированных специалистов в команде; V — статусная оценка /-го участника команды (от 1 до 5); 2^ — загрузка /-го участника команды в проекте; 0,4 и 0,6 — весовые коэффициенты, установленные эмпирически; 5 — коэффициент приведения к единой шкале.
Сложность архитектуры системы предлагается оценивать в соответствии с существующей их классификацией. Различают следующие основные классы архитектур программных средств: цельная программа, комплекс автономно выполняемых программ, слоистая программная система, коллектив параллельно выполняемых программ [8].
N
/V -1
Q = 0,4 • 5 —^ + 0,6--Е1------
N N
Язык программирования формально можно оценить как количество операторов данного языка на один функциональный указатель. Количество функциональных указателей FP (Function Points) — метрика ПО, введенная А. Альбрехтом в 1979 г. К функциональным указателям относят внешний ввод, внешний вывод, внутренний логический файл, внешний интерфейсный файл, внешние запросы [9].
Трудоемкость разработки оценивается по факту после ее окончания.
Опыт в разработке подобных систем, взаимодействие в команде, полнота и качество документации оцениваются экспертно.
Для оценки надежности ПО с точки зрения процесса разработки необходимо оценить каждый из восьми предложенных факторов по пятибалльной шкале. У авторов статьи разработана методика оценки этих факторов в соответствии с приведенными выше критериями, но рамки журнальной статьи не позволяют привести ее здесь.
Оценка факторов проводится экспертно. Вклад каждого из факторов в надежность разрабатываемого ПО очевидно различен. Необходимо выделить постоянную систему весов для этих факторов, чтобы сравнивать надежность различных программных продуктов.
Обобщенную оценку надежности как результата организации процесса разработки R1 определим как взвешенную сумму оценок факторов, влияющих на надежность:
Z'
у, • Y,
R = -г=
8
где V, — оценка /-го фактора по пятибалльной шкале; у,- — вес /-го фактора по пятибалльной шкале.
Теоретически 0 < Я1 < 25.
Теперь рассмотрим оценку надежности ПО, которая может быть получена как результат испытания (тестирования) готового программного продукта.
Перечислим требования, которым должна удовлетворять корректная модель.
1. Вся совокупность тестов и возможных комбинаций входных данных (все тесты, принадлежащие программе функциональных испытаний) есть одно испытание на надежность.
2. Целесообразно, чтобы модель учитывала процесс доработки ПО по результатам испытаний
3. Оценка надежности ПО должна производится тогда, когда после испытания данной версии ПО не было обнаружено ни одной ошибки.
4. В модели не должны учитываться временные интервалы между обнаруженными ошибками, так как они отражают в основном очередность отдельных проявляющих ошибки условий или очередность смены наборов входных данных.
5. Модель не должна требовать априорных данных или данных предшествующего периода функционирования однотипных программных средств
Для описания процесса проявления и исправления ошибок в ПО можно воспользоваться моделью Пуассона, удовлетворяющей всем пяти условиям.
Пусть Щґ) — число проявившихся ошибок за время ґ тестирования версии г ПО есть неоднородный процесс Пуассона с интенсивностью Х(ґ), ґ > 0.
Обозначим N(ґг, ґг-1) = N(ґг) - N(ґг-1). Тогда для любых моментов 0 < ґ1 < ґ2 <... справедливо
р{(ґг,ґг-і) = £} = [от(ґг) т(ґг-і)] .ехр{-[т(ґг)-т(ґгч)]}, т(ґг) = [Ци^и,
к\ і
0
где к = 0,1,2,. — число ошибок; г = 0,1,2,. — ряд последовательно испытываемых версий ПО; т(ґг) — среднее число проявлений ошибок за время ґ в версии г. Отсюда определяется вероятность того, что на интервале (ґ,4) ошибки не проявятся:
Р^(ґ, ґ,) = 0} = ехр| - ^ 1(и)ёи I.
(*)
Для оценки вероятности Р необходимо по заданной статистике доработки ПО построить функцию, аппроксимирующую т(ґ) или Х(ґ), и на основании этого получить верхнюю оценку т(ґ) или Х(ґ) с заданным уровнем доверия. После подстановки этой оценки в
(*) можно вычислить показатель надежности ПО.
Для выбора аппроксимирующей зависимости предлагается использовать критерий минимума среднеквадратичного отклонения, аппроксимирующей кривой — экспоненту. В качестве параметра ґ берутся дискретные значения номеров соответствующих версий ПО (из натурального ряда чисел 1,2,3,...).
В результате мы получим некоторое положительное число < 100. Полученное значение может трактоваться как вероятность того, что в последней версии в процессе эксплуатации не проявится ошибка. Обозначим эту оценку как Я2.
Таким образом, мы получили две оценки надежности ПО: Я1 как результат оценки процесса разработки и Я2 как результат тестирования готового программного продукта.
На основании этих оценок предлагается новая модель оценки надежности ПО. В рамках этой модели введем два новых понятия: класс надежности и матрица надежности. Под классом надежности будем понимать совокупную оценку надежности программного продукта, которая базируется на оценке процесса разработки и результатов испытания ПО и позволяет сравнивать программные продукты между собой по надежности их функционирования. Таблица иллюстрирует понятие матрицы надежности.
*2 *1 0-50 % 51-75% 76-90% 91-98% 99-100%
0-10 Класс М Класс К Класс Н Класс Б —
11-20 Класс Ь Класс ] Класс в Класс Б Класс В
21-25 — Класс I Класс Е Класс С Класс А
Будем откладывать по горизонтали интервалы оценки надежности Я2, а по вертикали — интервалы оценки надежности Я1. На пересечении этих интервалов получим класс надежности для данного продукта. Два пересечения не определяют класса надежности: когда одна из оценок низшая, а вторая — наивысшая. В таких случаях будем считать, что либо процесс тестирования организован некорректно, либо дана не отражающая реальности оценка процесса разработки. Остальные классы могут быть ранжированы по степени увеличения надежности в соответствии с их положением в матрице надежности. Класс А мы представляем как класс высоконадежного ПО, показавшего максимальную вероятность дальнейшей безотказной работы и процесс разработки которого оценен максимально. Остальные классы представляют ПО меньшей надежности, однако в некоторых случаях этой надежности будет достаточно для нормального функционирования конкретного ПО.
Выводы
1. Предложен новый способ практической оценки надежности ПО, основанный на оценках процесса разработки ПО и результатов тестирования программного продукта. Введены понятия матрицы надежности и класса надежности для количественного расчета надежности ПО.
2. Определены факторы, влияющие на надежность, по которым возможно производить оценку процесса разработки ПО, сформулированы принципы оценки этих факторов по пятибалльной шкале.
3. Формализованы требования к модели оценки надежности по результатам его тестирования. Адаптирована модель оценки надежности, основанная на неоднородных Пуас-соновских процессах, которая максимально ориентирована на оценку надежность программного средства по результатам его тестирования в производстве.
1. ISO 9126:1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению. 186 с.
2. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Tecrminology (ANSI). 1283 с.
3. Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств: Учеб. пособие под ред. О.С.Разумова. М.: Финансы и статистика, 2003. 284 с.
1. Коганов А.В., Романюк С.Г. Экономический подход к понятию надежности программы — http://inf.tu-
chel.ac.ru/~tyrty/nadejnost.html
5. Липаев В.В. Надежность программных средств. Сер.: Информатизация России на пороге XXI века. М.: СИНТЕГ,1998. 232 с.
6. Шураков В.В. Надежность программного обеспечения систем обработки данных: Учебник. 2-е изд., пе-рераб. и доп. М.: Финансы и статистика, 1987. 272 с.
7. Терехов А. А. // BYTE/Россия. 1999. №12. С.12-18.
8. Майерс Г. Надежность программного обеспечения. М.: Мир, 1980. 360 с.
9. Технологии разработки программного обеспечения: Учеб. пособие. 2-е изд. / С.Орлов. СПб.: Питер, 2003. 480 с.
