CC BY
88
ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА
И УПРАВЛЕНИЕ
УДК 004.412
B.C. Карпов, д-р. техн. наук, проф., (4872) 33-24-45 (Росси, Тула, ТулГУ), А.Н. Ивутин, канд. техн. наук, доц., alexey.ivutin@gmail.com,
(Росси, Тула, ТулГУ),
А.А. Суслин, аспирант, (960) 599-99-91, suslin@brvs.net (Росси, Тула, ТулГУ)
ПОДХОД К РЕАЛИЗАЦИИ МЕТОДИКИ ОЦЕНКИ НАДЕЖНОСТИ ПО НА ОСНОВЕ КОМПЛЕКСНЫХ МЕТРИК
Дан обзор существующих методов оценки надежности программного обеспечения с использованием измеримых характеристик объекта - метрик, описаны их недостатки, а также указана необходимость избежання их изолированного использования. Приведены базовые понятия и подходы для создания комплексной метрики на основе вероятностной модели - байесовской сети доверия.
Ключевые слова: надежность прораммноо обеспечения, метрики, оценка надежности, проектирование программного обеспечения, информационная безопасность.
Необходимость получени адекватной и максимально объекгиной методии оценки надежности и качества (в частности, как одного из основных определяющих надежность показателей) программного обеспече-ни определилась сравниельно недавно, и её акгульность возрастает день ото дня. Программные компоненты всё чаще используются в криичных к уровню надежности и отклоустойчиости системах: от комплексов диспетчеризации потоков воздушного транспорта и банковских систем до атомных электростанций и автоматизиованных медицинских аппаратов для мониоринга за состоянием пациентов. При этом тенденции по переход от однопроцессорных систем к многопроцессорным, от изолированных самодостаточных систем к сетевым распределенным проектам, от ло-кльных вычислительных сетей к глобльным являются отражением всеобщего увеличени р л мера и сложности вычислительных систем.
В вычислительных системах объединены программная и аппаратная составляющие, от сбоев в которых в равной мере зависит надежность всей вычислительной системы. Уместнее в таких случаях звучит широко известна аксиома о том, что обща надежность системы определяется надежностью её самого ненадежного звена. И если надежность аппаратного обеспечения является темой, глубоко исследованной и получившей самое широкое освещение в специализированной литературе, то проблема моделирования надежности программного обеспечения до сих пор однозначно не решена. Именно поэтому зачастую оно становится таким, - определяющим суммарный уровень надежности автоматизированной системы, - звеном. Кроме того, обнаруживаемые недостатки и уязвимости в аппаратной части, напрямую влияющие на общий уровень надежности системы, в большинстве случаев устраняются именно внесением корректив в программную составляющую, как требующих минимальных усилий и затрат от раработчиков и внедряющего персон аа.
Согласно общепринятой терминологии под надежностью программного обеспечения понимается вероятность его корректной работы на определенном промежутке времени [1]. Корректна работа прерывается сбоями
— состояниями системы, в которых дальнейшее функционирование её невозможно либо ведёт к неверным результатам работы. Среди сбоев в отдельную группу можно выделить отказы — состояние системы, в которых результаты работы недоступны пользователю системы либо не могут быть сгенерированы в принципе. Зачастую сбои проявляются только на небольшой области входных данных, либо при определенных условиях. Программное обеспечение, используемое в вычислительных системах, создано для выполнения строго определенного, в большинстве случаев довольно узкоспециализированного, круга задач. Таким обраом, более точное определение будет звучать следующим обраом: надежность программного обеспечения — это вероятность того, что оно будет функционировать без сбоев в заданном окружении определенный промежуток времени [2]. В таком определении под сбоем подраумевается именно невозможность выполнения программным обеспечением возложенных на него и в частности на вычислительную систему в целом задач.
Надежность программного обеспечения — очень трудноформаи-зуема область исследований. Несмотря на то, что предложено большое количество моделей надежности, ни для одной из них не была доказана унтере а ьность, то есть не существует модели, удовлетворяющей всем возможным случаям и областям применения. Более того, как правило, даже незначительное отклонение от типовых параметров для таких моделей способно рабаан сиров ать ее покзания. Проблема состоит в том, что для каждой из модели существует ряд корректных допущенй, отступление от которых срау делает модель несостоятельной.
Необходимо заметить, что в отличие от аппаратуры программное обеспечение не стареет и не изнашивается, а также очень легко воспроизводится. Подавляющее большинство ошибок в программном обеспечении возникает на стадии проектирования и разработки, а не на стадии производства, и обнаруживается и отлаживается на стадии тестирования.
Многие модели надежности подразумевают только два возможных состояния системы: нормальную работу и сбой. На практике многие системы могут находиться во множестве других состояний, особенно системы реального времени [3]. Например, если в системе реального времени произойдет сбой в части компонентов, она может продолжить своё функционирование, при этом производительность снизится. С целью изучения таких состояний многие исследователи заняты изучением надежности систем с множеством состояний. Безусловно, модели, созданные для анализа таких систем, могут не стыковаться с классическим подходом, что порождает соответствующие трудности при исследовании сложных или комплексных систем, когда, например, надежность компонента или некоторого подмножества компонентов выражается бинарным способом («норма» -«сбой»), а надежность другой части компонентов — множеством переходных состояний. Следует заметить, что под такое определение подходит большинство современных программных и программно-аппаратных систем.
Одной из немаловажных составных частей современной теории управления является набор количественных методов исследования сложных процессов и явлений. В условия совершенствования систем управления промышленностью и экономикой количественные методы придают процессу управления необходимую научную обоснованность, сводят до минимума элемент субъективности при выборе управленческих решений и позволяют в определенной мере оптимизировать как сам процесс управления, так и комплекс технически средств, обеспечивающих его осуществление [4]. В основе количественных методов лежат метрики — измеримые параметры объекта, характеризующие некоторые узкие стороны его функционирования. На основе наборов однотипных метрик из общей функциональной группы (например, метрики результатов тестирования) и строится большинство моделей надежности программного обеспечения.
Современна теория надежности программного обеспечения предлагает на выбор исследователя целый ряд самых разнообразных метрик и моделей надежности программного обеспечения.
На разных уровнях детализации используемых данных существуют разные классификации групп метрик [5]. Одна из классификаций подразумевает ввод трех основных категорий метрик: метрики продукта, метрики процесса (разработки), а также метрики проекта. К первой группе относятся такие характеристики, как размер, сложность, особенности дизайна, производительность, а также метрики, прямо или косвенно характеризую-
щие уровень качества программного обеспечени. Метрики процесса могут использоваться для улучшения процесса рлработкр программного обеспечения и его сопровождения. Среди таких метрик — уровень эффективности устранени обнаруживаемых дефектов в программном проекте на этапе разработки, уровень моделировани сбойных ситуаций во время тестировани или время отклик на новые ошибки в процессе эксплуатационных испытаний. Метрики проекта описывают характеристики подхода к проектированию и разработке программного продукта. Среди подобных метрик — количество задействованных в проекте рлработчиков, комплексность подхода к рлработке на протяжении всего жизненного цикла программного продукта. Некоторые метрики относятся срлу к нескольким характеристикам.
Одна из основополагающих метрик (из категории метрик продукта) относится к группе метрик рлмера. В зарубежной литературе она носит нлвание Lines of Code — LOC, число строк кода. Основная проблема, с которой стакивается исследователь при введении данной метрики, — это выбор способа её подсчета. Во времена низкоуровневого программирова-ни, когда одна строка кода была эквиваентна одной процессорной инструкции, така проблема отсутствовал. Однако подобное соответствие ока-заось нарушено с появлением высокоуровневых языков программирована Различи между реальными («физическими») строками кода и конечными инструкцими («логическими» строками), а также различи между языками порождают множество вариантов способов подсчета LOC. Основными из них являются: [6]
- подсчет только исполняемых строк;
- подсчет исполняемых строк и строк с определениями данных;
- подсчет исполняемых строк, строк с определениями данных и комментариями;
- подсчет исполняемых строк, строк с определеними данных, комментариями, а также служебных (управляющих) строк языка программирования (например, директив препроцессора);
- подсчет конечных строк на дисплее консоли;
- подсчет строк, отделенных логическими разделителями.
Наиболее широко распространено следующее определение строки
кода: это люба строка исходного текста программы, не являющаяся комментарием или пустой строкой, независимо от числа выражений или фрагментов выражений на ней [7]. К строкам кода относятся все строки, содержащие программные заголовки, объявления и исполняемые и нeиcпoлуяe-мые выражени.
Эффективный подход к проектированию программного продукта позволяет осуществлять релизацию функционала с меньшими усилими и соответственно наименьшим показателем LOC. В дополнение к этому вполне очевидным является тот факт, что при среднем стабильном покла-
теле числа ошибок на количество строк кода количество дефектов в программном обеспечении становится прямо пропорциональным метрике LOC при прочих равных условиях. В реальности этот показатель в отрыве от остальных метрик абсолютно несостоятелен и не может быть использован в качестве полноценного оценочного критерия уровня качества или надежности.
Использование данной метрики в связке с показателями результатов тестирования, а также опытной и конечной эксплуатации позволяет получить адекватную картину, всё более объективную со временем, при растущем массиве обрабатываемых данных. Для получения такого комплексного показателя достаточно иметь информацию о текущем LOC (исходное значение показателя, а также изменения в ходе внесения правок в проект) и динамику проявления дефектов. Таким образом, на любом этапе жизненного цикла продукта можно будет подводить заключения следующего рода: «Показатель проекта 50000 LOC (или 50 KLOC). Устойчивая средневзвешенная частота сбоев на ближайшие два года составляет 2,7 ошибок на KLOC». Сравнивая полученные показатели в динамике, имеем объективную картину изменений в уровне надежности и качества программного проекта.
В данном случае для получения участка вероятностной модели надежности программного обеспечения на основе метрики LOC очевидна необходимость установления связи с сопутствующими метриками. Среди них можно выделить основные: время эксплуатации продукта (life of product, LOP) и метрики, отражающие частоту сбоев на этапе тестирования и опытной эксплуатации, — среднее время до сбоя и плотность ошибок. Например, очевидно, что для большого многолетнего программного проекта, в котором сбои происходя крайне редко, показатель LOC внесет значительно метшую поправку в комплексный показатель надежности, чем для свежего продукта такого же размера. В данном случае также немаловажную роль играют метрики статистики сбоев, получаемые в результате тестирования и опытной эксплуатации.
Среднее время до сбоя — mean time to failure (MTTF) — это метрика, получившая очень широкое распространение в анализе надежности критически важных систем, таких как, авиационные или оружейные комплексы. Например, правительство США устанавливает правило, что его система управления воздушным трафиком не может быть недоступна более трёх секунд в году [5]. Для гражданских авиалиний вероятность катастрофических сбоев должна быть не более чем 10-9 в час [8]. В промышленных программных системах чаще используется родственна MTTF метрика — плотность ошибок (defect density metric).
Две данные метрики взаимно коррелированы, хоть и имеют несколько разную природу: MTTF измеряет время между сбоями, плотность оттти-
бок определяет соотношение дефектов к различным показателям размера (функциональным блокам, LOC, времени эксплуатации и т.д.).
С изолированным использованием таких метрик связан целый ряд проблем. Основные ошибки в коде программ, которые теоретически резко снижают MTTF, зачастую устраняются на ранних этапах тестирования и опытной эксплуатации. Таким образом, этот параметр оказывается тесно скоррелирован с метриками результатов тестирования и LOP.
Важной метрикой процесса является показатель эффективности устранения ошибок (defect removal effectiveness, DRE) [5]. Он описывается следующей формулой:
г**у>сугогг/у о /у л г /у л г у /*и у у .. у у X > >с у г /у у /у у
onooaianu а юеаее ia поааее оасоааюее DRE =--------------------------------------1---------100%.
/V Л X Л \ /4 0 /У У Г /У У /У нХЛн ^ л \ о
neououa юеаее a loiaoeoa
Так как конечное число скрытых ошибок неизвестно на текущей стадии разработки, делитель в данной метрике определяется приближенно как ошибки, устраненные на стадии разработки, плюс ошибки, обнаруженные на следующих стадиях
Динамика данной метрики оценивается как для всего процесса разработки, так и апостериорно — для каждой из фа или ранних этапов. Соответственно метрика носит название «фазовой эффективности» и «ранней эффективности устранения ошибок». Чем выше данный показатель, тем эффективнее организован процесс разработки и тем меньше ошибок перейдет на следующий этап разработки.
Качество сопровождения программного обеспечения также оценивается рядом специализированных метрик. Одна из основных — качество исправлений (fix quality, FQ). Исправление считается ошибочным, если оно не исправило заявленную ошибку, либо исправило её, но добавило в программу новые. Метрика качества исправлений подсчитывается как отношение неошибочных исправлений к их общему числу за определенный интервал времени опытной эксплуатации. Существуют два варианта ведения статистики FQ — фиксирование ошибочного исправления при его обнаружении либо при его доставке конечному пользователю.
Как было показано выше на примере основных метрик из различных групп, изолированное их использование не имеет практической ценности в связи с их потной взаимной коррелированностью. В связи с этим при моделировании надежности программного проекта выделяют максимальное число самых важных и подходящих для него метрик и, учитывая всю совокупность показателей, делают выводы о значении интегральной метрики надежности.
Например, специалисты компании «Хьюлетт-Паккард» (США) выделяют в своей оценочной модели как основные (простые) метрики, которые можно подсчитать напрямую: число сбоев, количество операндов,
LOC, управляющие признаки и т.д., так и комплексные метрики, являющиеся их комбинацией.
Компания «Ай-Би-Эм» (США) использует для получения комплексного значения другой набор метрик, среди которых обща удовлетворенность пользователя и удовлетворенность различными атрибутами, после-релизова частота сбоев, число звонков о проблемах пользователей в месяц, время устранения ошибки и многие другие комплексные метрики, многие из которых направлены на обработку данных откликов от конечных пользователей.
Как видно из приеденных примеров, наборы метрик, входящих в комплексную модель, выбранные разработчиками разных компаний, достаточно существенно отличаются. Как было сказано выше, существующие на данный момент модели оценки надежности программного обеспечения предусматривают ряд допущений, а потому ориентированы на определенный тип программного обеспечени. Компания «Хьюлетт-Паккард» в области программного обеспечения в первую очередь занимается разработками системных решений и драйверов устройств, «Ай-Би-Эм» — прикладных приложений и систем, более ориентированных на интерфейс с конечным пользователем. Из набора метрик очевидно, что в первом случае основной вклад в формирование комплексной оценки производится на ранних стадиях разработки, а во втором — на стадии опытной и послерелизо-вой эксплуатации.
Более универсальна комплексна метрика, подходяща для различных типов программного обеспечени, может быть получена совмещением различных уникальных наборов покаателей, и введением поправочных коэффициентов (весов), формируемых на основе простых метрик и в зависимости от типа оцениваемого ПО и регулирующих степень значимости конкретных групп в общем комплексном покаателе надежности. Одна из основных проблем получени такой метрики - отбор простых метрик, которые будут участвовать в вычислении такого покаателя. Как было скаа-но выше, большинство из метрик - взаимно коррелированны, при этом в зависимости от коэффициента корреляции принимается решение о включении или не включении зависимых метрик в комплексный показатель. Коэффициент корреляции для двух покаателей (являющихся в известной мере случайными):
соу( X, У)
с>Х, У = ,----- ,= (1)
■Щх)-ТдТ) ’ ^ ’
где В(Х) и В(У) - дисперсии парных величин; cov(X,У) - ж ковариаци
соу(X,У) = М([X - М(X)][У - М(У)]),
где М(Х) - математическое ожидание соответствующей величины.
При подсчете значени о - парного коэффициента корреляции - будет получено значение от -1 до +1. При этом чем ближе модуль этого чис-
ла к 1, тем сильнее выражена корреляционная зависимость между метриками. Для тех пар метрик, в которых она равна единице или близка к ней, достаточно включать в комплексный покаатель одну из них. Для пар метрик с высокой и средней корреляцией необходимо вводить поправочные коэффициенты. Величины таких коэффициентов для раных типов программного обеспечения устанавливаются на основе усредненных покаа-телей, но могут быть уточнены в результате экспериментальных исследований. Для этого по каждой метрике необходимо учесть в среднем до 100 результатов наблюдений. Подобный алгоретм подсчета комплексной метрики удобно смоделировать с использованием сетей довери Байеса, закладывая в узлы полученные значения метрик и устанавливая связи между узлами с помощью полученных коэффициентов корреляции.
Положим, что п - это номер категории (типа) программного обеспечения, для которого производется исследование, т - номер метрики, входящей в комшексную оценку.
Если метрика является числовой (например, LOC), то для оцени коэффициента динамики изменени количественных покаателей проекта в процессе его раработки в рарезе т-й метрики для п-й категории воспользуемся следующей формулой:
К = —
п, т
Е - Е
п, ті п, ті-1
Я -я ,
п, ті п ,ті -1
1п, т 1
/ Е
' п, тм
/ Я
п ,ті-1 , (2)
где - числовое значение п-й метрики в і-м опыте проведенном на экс-
периментальном экземтшре программного обеспечения из т-й категории; Епті - количество обнаруженных ошибок в программном коде, обнаруженных после изменения п-й метрики на экспериментальном экземпляе программного обеспечени из т-й категории на і-м опыте; 1пт - количество опытов, проведенных для п-й метрики на экспериментальном экземпляре программного обеспечени из т-й категории. При этом предполагается, что в ходе измерений количество ошибок оценивается набегающим результатом, то есть обнаруженные на предыдущих опытах ошибки включаются в результат текущего измерения независимо от состоял их исправления.
Однако такая характеристика может использоваться только для примерной оценки связи значения числовой метрики с надежностью кода, так как на раных промежутках значений зависимость может сильно колебаться. Так, для программных продуктов небольшого рамера незначительные изменения в рамере кода могут вызывать появления значительного количества ошибок и наоборот. Несмотря на то, что в выражении (2) используется относительное изменение, отмасштабированное по предыдущему значению как для самой метрики, так и д л количества полученных ошибок, така поправка зачастую окаывается недостаточной. Существуют два решения.
Во-первых, для подобных случаев можно выделить отдельные категории программного обеспечения. Возвращаясь снова к оценке LOC, в качестве примера введём для любой категории «программный продукт п-го типа» подкатегории «программный продукт с объёмом LOC от Яшш до Яшах», где Rmin и Rmax -границы интервала значений метрики, для которого перепады значения оценки незначительны. После введения подобных категорий необходимо уточнить подсчитанные коэффициенты Кпш Достоинством такого метода является простота реализации в случае, когда в комплексную метрику включается небольшое количество показателей (до 8-10 метрик). Для случаев, когда значение т начинает превышать эту величину, при этом большинство из метрик порогообрано влияют на надежность, количество таких подкатегорий увеличивается геометрически. Сложность проведения эксперимента растёт лавинообрано, так как существует объективна необходимость предварительной классификации программного экземпляра по введённым подкатегориям для текущих значений используемых метрик на данном шаге.
Второй метод - введение табличного представления коэффициента Кпдш для каждой метрики, где есть порогообрана зависимость. Сложность проведения эксперимента при этом растёт алгебраически, классификацию экземпляра не требуется проводить перед каждым экспериментом. В общем случае необходимо лишь по мере получения результатов вводить ин-терваьные пороги для каждого коэффициента и сводить их в индивидуальные таблицы для последующего применения в результирующей байесовской сети доверия (таблица).
Коэффициент Кп,т
Номер интервала К-тіп Ктах Интерваьше значение Кп,т
1 0 1000 0.0278
] Ктіп і Ктах і Кп,т і
I К ^тіп I к ^тах I Кп.т I
При таком подходе строки таблицы в результате становятся узлами сети, влияющими на выходное значение обработки статистических данных.
Для метрик, выраженных в виде логических заключений («свидетельств» в терминологии байесовских сетей), при необходимости таблицы составляются аналогичным обраом, но вместо Rmin и Ятах используются сами значения заключений. При этом следует иметь в виду, что выделение отдельных строк данной таблицы необходимо лишь в случае значительных отклонений Кпт для различных значений метрики. В случае, если данный коэффициент для раличных значений метрики отклоняется незначительно, используется одно усредненное значение.
Полученная величина позволяет судить не только о степени влияния конкретной метрики на надежность конкретных категорий программного обеспечения, но и сделать выводы о совместном влиянии нескольких метрик с помощью зависимости (1). Полученные данные после обработки используются в выходной байесовской сети доверия и позволяют в динамике развития программного продукта оценивать его комплексный показатель надежности. При этом при достаточном количестве экспериментальных данных методика становится достаточно объективной независимо от категорий программного продукта.
Библиографический список
1. Pan J. Software Reliability. 18-849b Dependable Embedded Systems,
1999.
2. Min Xie, Yuan-Shum Dai, Kim-Leng Poh. Computing systems reliability: models and analysis. Springer, 2004.
3. Linger R. C. and Hausler P. A., The Journey to Zero Defects with Cleanroom Software Engineering, Creativity!, IBM Corporation, September 1992.
4. Трухаев Р.И. Модели принятия решений в условиях неопределенности. М.: Наука, 1981.
5. Kan Stephen H. Metrics and models in software quality engineering / Addison-Wesley. 2-nd ed., 2002.
6. Jones C., Programming Productivity. New York: McGraw-Hill, 1986.
7. Conte S. D., Dunsmore H. E., Shen V. Y. Software Engineering Metrics and Models, Menlo Park, Calif.: Benjamin/Cummings, 1986.
8. Littlewood B., Strigini L., The Risks of Software// Scientific American,
1992.
9. Grady R. B., Caswell D. L., Software Metrics: Establishing A Company-Wide Program. Englewood Cliffs, N.J.: Prentice-Hall, 1986.
V. Karpov, A. Ivutin, A. Suslin
The approach of method for evaluation of software reliability based on complex
metrics
The article reviews existing methods of evaluation of software reliability regarding to measurable object characteristics - the metrics. Their lacks are viewed, the shortage of standalone usage is described. The basis approaches of building complex measure based on probability model - Bayesian belief network- is brought.
Получено 12.11.2009
