Geum.ru

С. О. Никольский исследование характеристик надежности крупной тиражной программной системы с использованием программного комплекса «reliability calculator»

Вид материалаИсследование

Содержание


Список литературы
Подобный материал:

Вестник Брянского государственного технического университета. 2006. № 4 (12)


УДК 004.4 + 004.415.5


С.О. Никольский


ИССЛЕДОВАНИЕ ХАРАКТЕРИСТИК НАДЕЖНОСТИ КРУПНОЙ ТИРАЖНОЙ ПРОГРАММНОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ ПРОГРАММНОГО

КОМПЛЕКСА «RELIABILITY CALCULATOR»


Рассматриваются результаты применения разработанного программного комплекса «Reliability Calculator» для прогнозирования числа отказов в очередной сборке исследуемого тиражного продукта. Кратко описываются возможности самого комплекса и основные постулаты модели надежности, положенной в его основу.


Необходимость определения характеристик надежности разрабатываемого программного продукта на ранних стадиях жизненного цикла – проблема, которая рано или поздно встает перед любой компанией, занимающейся разработкой ПО. Особенно это важно в условиях разработки так называемого тиражного программного обеспечения, когда клиенты одновременно пользуются несколькими версиями (тиражными сборками) программного обеспечения. Соответственно приходится одновременно поддерживать (вносить изменения в код) каждую из этих версий. Затраты на тестирование, естественно, возрастают в несколько раз.

Для того чтобы спрогнозировать число отказов еще до начала тестирования системы, а также узнать распределение этих отказов по различным частям системы, была разработана модель надежности тиражного программного обеспечения на основе нейросетевых алгоритмов [1,2]. Однако применять модели такого уровня без специального программного обеспечения практически невозможно. Для исследования возможностей и перспектив модели был разработан программный комплекс «Reliability Calculator», результаты применения которого для прогнозирования числа отказов в очередной сборке крупного тиражного программного продукта и приводятся в данной статье.

Объектом исследования стала часть автоматизированной банковской системы (АБС), автоматизирующая розничную деятельность банка. Основными особенностями разработки данной системы является большой объем исходного кода – около 3 000 исходных файлов и 19 000 функций – и достаточно небольшое число программистов, занимающихся доработкой системы, – от 3 до 7 в разные периоды времени. Подобные характеристики, а также описываемые ниже особенности разработки системы позволяют назвать ее хорошим «кандидатом» для апробации разработанной модели и ПК «Reliability Calculator».

При апробации был допущен ряд упрощений.
  • Несмотря на то, что система состоит из множества функциональных блоков, разработанных с использованием различных языков программирования, рассматривалось только «ядро» системы, написанное на C/C++. Отказы, возникающие в других частях системы, игнорировались.
  • В ходе тестирования были выявлены отказы, причиной которых служили не изменения, внесенные именно в исследуемую сборку системы, а более ранние, оставшиеся вследствие недостаточного тщательного тестирования предыдущих сборок. Подобные отказы в рассмотрении не участвовали и игнорировались.
  • Иерархия системы строилась исключительно для исследования возможностей модели и не претендует на полноту отражения функций системы.

Стоит отметить, что модель применялась не в реальном времени, а уже по следам выпущенных сборок. Обусловлено это, прежде всего, отсутствием в используемых для разработки средствах необходимых функций, а именно связывания запроса со списком измененных файлов по нему. Как результат – практическая невозможность отслеживания изменений в реальном времени. Однако исследование модели на основе уже выпущенных сборок обладает одним существенным плюсом: можно почти со стопроцентной гарантией сказать, что в модели были учтены все отказы, возникшие в результате внесения изменений. Таким образом, эффект недостаточного тестирования практически исключен.

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

Обучающая выборка включила 154 выполненных запроса на доработку системы. Сведения о каждом запросе, а также необходимые для обучения характеристики элементарных изменений по запросам, были загружены в БД системы. Каждое изменение характеризовалось по следующим параметрам (параметры модели):
  • Общая квалификация программиста, выполнившего изменение, – характеризует знание программистом приемов программирования, используемого языка программирования и т.п. Влияние данного параметра на вероятность внесения дефекта (и как следствие возможности проявления его в виде отказа) при внесении изменения в исходный код очевидно: чем выше квалификация программиста, тем больше вероятность того, что его код не будет содержать дефектов. Значение данной характеристики, представляющее собой число в пределах [0; 1], было получено от руководителя группы разработчиков. Следует отметить, что подобный метод получения экспертной оценки никоим образом не может ухудшить прогнозирующие качества модели – для модели важна не абсолютная, а относительная оценка квалификации каждого из программистов.
  • Квалификация программиста в данной части системы – характеризует знание программистом той части системы, в которую он вносит изменение. Понятно, что чем более знаком программисту код (чем выше его квалификация в данной части системы), тем выше вероятность того, что его код не будет содержать дефектов.
  • Сложность функции до ее изменения в терминах метрики цикломатической сложности Мак Кейба (McCabe's cyclomatic complexity metric). Влияние сложности функции на вероятность того, что в ее код при внесении изменения будет также внесен и дефект, очевидно. Причем, как правило, на эту вероятность влияют не такие характеристики сложности, как число строк исходного кода или число строк исходного кода за исключением комментариев, а именно те метрики, которые характеризуют разветвленность кода.
  • Сложность изменения функции – определяется как абсолютная величина разности сложности функции до изменения и сложности функции после изменения.

Всего в БД системы были внесены сведения о 595 изменениях функций исходного кода. Однако поскольку перед обучением нейросети проводится объединение изменений, имеющих одинаковые параметры, в итоге число обучающих примеров сократилось до 512.

Одним из достоинств модели является достаточно легкая для осуществления возможность замены «ядра модели» - нейросети изменения. При этом с помощью одной нейросети можно прогнозировать общее число отказов, с помощью другой – число критических отказов, третьей – число отказов за определенный промежуток времени. Однако при тестировании модели это ее свойство было применено для того, чтобы изучить, как влияет архитектура нейросети изменения на прогнозирующие способности модели. Для этого были обучены (методом обратного распространения ошибки) 15 нейросетей, которые можно разделить на 3 класса:
  1. 5 трехслойных нейросетей с 4 стандартными входами. Первый и второй слои имели по 4 нейрона, выходной слой – 1 нейрон.
  2. 5 двухслойных нейросетей с 4 стандартными входами. Первый слой – 4 нейрона, выходной слой – 1 нейрон.
  3. 5 двухслойных нейросетей с 4 стандартными входами, одним дополнительным входом и одним выходом. В качестве дополнительного входа был добавлен нейрон, на который подавались 1, 2 или 3, в зависимости от важности, запроса на доработку (низкая – 1, средняя – 2, высокая – 3).

Для построения тестирующей выборки, были выбраны все запросы, реализованные в одну из сборок исследуемого программного продукта. При этом учитывались также отказы, не обнаруженные при тестировании этой сборки, но обнаруженные в трех последующих патчах к ней. Особо следует отметить то, что время выхода сборок, на основе которых строились обучающая и тестирующая выборки, примерно совпадает (они выпускались в течение 1-2 месяцев). Таким образом, можно считать, что общая квалификация каждого из программистов в это время была примерно одинаковой.

В тестирующую выборку вошло 75 реализованных запросов на доработку системы. В результате их реализации возникло и было обнаружено при тестировании 11 отказов.

Каждый из реализованных запросов был разбит на элементарные изменения и подан на вход каждой из 15 нейросетей. Выход нейросети, обозначающий ожидаемое число отказов в системе, в результате изменения данной функции был распространен по функциональному графу системы. Последний был построен путем инструментирования [3] исходного кода исследуемой системы и загрузки в БД результатов выполнения этого кода (трассировочных файлов). Распространение отказа по графу отражает тот факт, что ошибка, которая возникает в данной функции, может привести к отказам во всех частях системы, использующих данную функцию.

После распространения отказов по функциональному графу для каждого из классов нейросетей простым суммированием числа отказов, накопившихся в каждом узле графа, были получены результаты (прогнозируемое число отказов в сборке), приведенные на рис. 1, 2 и 3 соответственно.






Рис. 1. Результаты применения нейросетей первого класса




Рис. 2. Результаты применения нейросетей второго класса



Рис. 3. Результаты применения нейросетей третьего класса


Как видно, нейросети первого класса показали самый неудовлетворительный результат: слишком большой разброс итоговых спрогнозированных чисел (от 2,37 отказов до 16,84). К тому же лишь две нейросети из пяти приблизились к реальному результату – 11 обнаруженным отказам. Такой результат можно объяснить недостаточным числом обучающих примеров для данного числа нейронов (недообучение нейросети). Для выбора подходящей архитектуры нейросети предлагается воспользоваться стандартным в таких случаях подходом – создать несколько вариантов нейросетей и апробировать каждый из них.

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

Нейросети третьего класса – двухслойные, с 4 стандартными и одним дополнительным входами – были созданы для демонстрации возможности безболезненного добавления новых параметров в модель. В данной работе их применение не принесло большой пользы, однако полученные результаты показали правильность выбранного подхода. Как видно из приведенных на рис. 3 данных, завышение результатов здесь немного больше, чем в моделях второго класса, – это минус. Однако разброс значений практически отсутствует (по сравнению с другими классами нейросетей). В данном случае – в условиях не практического применения, а исследования - можно сказать, что добавление к модели новых параметров повлияло на прогнозирующие способности модели положительно. А завышение числа отказов можно объяснить, прежде всего, недостаточно большой обучающей выборкой и сложностью ее составления в условиях разработки исследуемой системы.

После подсчета прогнозируемого числа отказов в системе в целом было проведено распространение отказов вверх по иерархии системы. Результаты этого процесса показаны на рис. 4.

В таблице, внизу рисунка, три строки соответствуют трем классам нейросетей, описанным ранее. Числа в таблице – это среднее число отказов, которое было спрогнозировано при использовании соответствующего класса нейросетей в данной функциональности. Числа около названий функциональностей – это число отказов, обнаруженное в реальности.

Следует обратить внимание на тот факт, что общее число отказов по функциональностям не соответствует общему числу отказов в системе (показаны только 8 реальных отказов из 11). Обусловлено это, во-первых, тем, что, как уже говорилось ранее, иерархия строилась только для демонстрации возможностей системы и не отражает всех функциональностей, существующих в системе. Во-вторых, даже при абсолютно полной иерархии сумма отказов в функциональностях не обязана совпадать со спрогнозированным числом отказов в системе в целом – ведь одна и та же функция может принадлежать нескольким функциональностям или не принадлежать ни одной. Практически же это отражает тот факт, что отказ, найденный при тестировании одного функционала системы, мог бы также быть обнаружен и в других функционалах.







Рис. 4. Распределение отказов по иерархии системы


В заключение хочется сказать, что тестирование разработанной модели и программного комплекса «Reliability Calculator» показало достаточно хороший результат. Несмотря на ощутимый недостаток времени, отведенного на данную часть работы, удалось собрать достаточно большой объем сведений о разработке реальной крупной тиражной системы и применить разработанную программу, достаточно точно спрогнозировав число отказов.


СПИСОК ЛИТЕРАТУРЫ

  1. Никольский, С.О. Модель надежности программного обеспечения на основе интеллектуальных технологий / С.О. Никольский, В.К. Гулаков // Вестник компьютерных и информационных технологий. Машиностроение. – 2005. – № 7. – С. 43-48.
  2. Никольский, С.О. Модель надежности тиражного программного обеспечения / С.О. Никольский, В.К. Гулаков // Вестник БГТУ. – 2004. – № 4. – С. 90-95.
  3. Никольский, С.О. Проблемы организации трассировки в сложных программных системах / С.О. Никольский, В.К. Гулаков // Качество инженерного образования: материалы 2-й междунар. науч.-метод. конф. – 2005. – С. 125-129.



Материал поступил в редколлегию17.05.06.