CC BY
33
№ 2(32) 2011
Д. Ю. Волканов, ассистент факультета Вычислительной математики и кибернетики МГУим. М. В. Ломоносова
Д.А. Зорин, студентМГУим. М. В. Ломоносова
Исследование применимости моделей оценки надежности для разработки программного обеспечения с открытым исходным кодом
В статье рассматриваются различные модели оценки надежности программного обеспечения с целью определения их применимости к проектам с открытым исходным кодом и уточнения механизма использования. Описываются эксперименты с некоторыми крупными проектами с открытым исходным кодом, в результате которых получены различные характеристики надежности таких проектов и сформулированы гипотезы об их общих свойствах.
Введение
В настоящее время в мире разрабатывается большое количество программных продуктов с открытым исходным кодом (Open Source). В этих проектах участвует много разработчиков, добавляющих свои фрагменты кода в общий репозиторий (хранилище, где находятся различные версии файлов, из которых состоит программа).
Проектом будем считать одну или несколько программ, чьим созданием управляет одна команда разработчиков. Большой проект может состоять из подпроектов, реализующих отдельные части, работающие независимо друг от друга; подпроекты — из компонентов, которые выполняют определенный набор функций и не используются отдельно. В проекте участвуют программисты, задействованные на одном или нескольких подпро-ектах, тестировщики и руководители. Одна из основных задач руководителя проекта — определить, когда программу можно предоставлять конечным пользователям.
Перед руководителями стоят задачи оценить:
• количество ошибок, оставшихся в проекте, и их критичность;
• количество ошибок, оставшихся в выбранном компоненте, и их критичность;
• время, за которое текущая версия станет стабильной, т.е. количество ошибок и их критичность будут меньше заданного порога.
Для решения перечисленных задач можно использовать два подхода: первый основан на изучении исходного кода программы, второй — на применении моделей оценки надежности (МОИ) ПО (англ. Software reliability growth model — SRGM), т. е. данных, полученных при тестировании [1]. Далее в статье подробно рассматривается второй подход.
Основным результатом расчетов в этом случае является функция количества ошибок, или функция количества (англ. mean function) — неубывающая функция времени, показывающая количество ошибок, найденных к заданному моменту времени. Применение МОИ к проприетарному программному обеспечению достаточно хорошо исследовано (например, в работах [2], [3], [4]). Проприетарное программное обеспечение в большей степени, чем открытое, удовлетворяет заданным ограничениям, так как команда разработчиков и тестировщи-ков централизованная, и поэтому процесс
№ 2(32) 2011
разработки и тестирования является более равномерным. Кроме того, МОН изначально создавались без учета возможности применения к проектам с открытым исходным кодом, поскольку в то время (1970-е годы) современного способа разработки проектов с открытым кодом еще не существовало. Поэтому применимость МОН к открытому программному обеспечению требует дополнительного исследования.
Основные особенности проектов с открытым кодом:
• в качестве тестировщиков зачастую выступают пользователи программы, которые работают с ней не в установленные часы, а по мере своих возможностей. Отчеты об ошибках поступают в любое время суток (из-за того, что отправители могут находиться в разных городах мира);
• тестирование ПО проходит неравномерно;
• основные усилия по тестированию предпринимаются после выпуска версии программы.
В следующем разделе описаны задачи, возникающие при получении функции количества ошибок.
Постановка задачи
Введем обозначения:
• f{Г) — количество ошибок, найденных к заданному моменту: данные из статистики тестирования;
• т(Г) — функция количества ошибок, полученная при применении какой-либо модели;
• т(Г)х — функция количества ошибок, полученная в момент времени х (на основании статистики до моментах).
Изначально задана статистика тестирования: множество ошибок, для каждой из которых обязательно определены время обнаружения и компонент, где она была обнаружена.
Для получения функции из исходных данных результатов тестирования требуется решить следующие задачи:
1. Определить период времени, через который необходимо строить новую функцию т(0 для получения более точных оценок, учитывающих вновь поступившие данные.
2. Выбрать наиболее подходящую к этому проекту МОН из нескольких возможных.
3. Оценить, какой объем исходных данных нужен для того, чтобы модели давали результаты с точностью не ниже заданной.
Критерии качества моделей:
• сходимость — возможность построения т(Г) по исходным данным результатов тестирования и выбранной МОН;
• точность — среднеквадратичное отклонение полученной функции количества оши-
V т(Г/)
бок от реальной: ас{Г) = ■
1 а)
г
• 100%; (1)
• устойчивость — оценка в текущии период мало отличается от оценки за предыдущий
т( о
период: вГ(Г)=
т( о
-•100%-100
<к, к=10. (2)
Настоящая работа посвящена решению задач 1-3 для некоторых конкретных проектов с открытым исходным кодом.
Классификация моделей оценки надежности
Суть МОН заключается в том, чтобы построить математическую модель, описывающую процесс обнаружения ошибок. Для этого применяются различные вероятностные модели случайных процессов. Основной случайной величиной, распределение вероятностей которой необходимо найти, является либо количество ошибок в некоторый момент или за определенный период, либо время между двумя ошибками. Выбрав общий вид используемой модели (например, неоднородный пуассоновский процесс или цепь Маркова), можно различными статистическими методами оценить его параметры и в результате получить функцию, показывающую наиболее вероятное количество
27
№ 2(32) 2011
ошибок в некоторый момент, либо оценку для времени до обнаружения следующей ошибки. После этого можно сравнивать функции, полученные в ходе применения различных моделей, между собой и выбирать наилучшую. На основании выбранной модели строят оценки различных величин, например, ожидаемое количество ошибок в ближайший месяц или общее количество оставшихся ошибок, исходя из которых принимают решение о готовности программы к выпуску.
Условно все модели можно разделить на три типа:
1. Марковские. В таких моделях используется предположение, что количество оставшихся ошибок зависит от текущего состояния системы и не зависит от прошлых состояний [1].
2. Пуассоновские. Предполагается, что обнаружение ошибок можно описать моделью «поток редких событий» [5], если сделать допущение, что ошибки независимы, обнаруживаются по одной и известен характер изменения частоты их обнаружения.
3. Байесовские. Время между ошибками считается случайной величиной с показательным распределением, но его параметры зависят от времени появления предыдущих ошибок, при этом оценивается только время до ближайшей ошибки, но не их общее количество [6].
Возможны также комбинации рассмотренных типов, например, в марковскую модель добавляется байесовская модификация.
В данной статье были проанализированы наиболее подробно описанные в литературе и часто используемые модели оценки надежности:
• Goel-Okumoto (GO) [1];
• S-Shaped (SS) [1];
• Logarithmic {Log) [3];
• Jelinski-Moranda (JM) [2];
• Littlewood-Verrall (LV) [7].
Главный вопрос, возникающий при применении SRGM, заключается в выборе модели, наиболее адекватной для конкретного
проекта. Однозначный выбор в общем случае сделать достаточно трудно, более того, нельзя гарантировать, что для одного и того же проекта в течение всего времени разработки будет адекватна одна модель. Перечислим основные факторы, из-за которых МОИ могут работать неточно:
• малое количество данных. Причиной может быть, например, то, что данные тестирования группируются по неделям или месяцам. Из-за их малого количества точность оценки параметров снижается;
• неравномерность тестирования, особенно в сочетании с малым количеством данных;
• стандартные ограничения моделей, т. е. наиболее часто встречающиеся допущения о следующих свойствах проекта [7]:
1. Равномерность — тестирование равномерно, т.е. ПО тестируется одинаково до и после построения оценок МОИ.
2. Однородность — все ошибки (по крайней мере, в рамках анализируемой группы) равноценны, и вероятность их обнаружения одинакова.
3. Независимость — ошибки не зависят друг от друга.
4. Идеальность — после обнаружения ошибка немедленно исправляется и при этом новых ошибок не появляется.
5. Бесконечность — общее число ошибок считается бесконечным, нет возможности получить его оценку напрямую.
Чтобы можно было решить, какую из моделей выбрать, необходимы критерии выбора.
Алгоритм выбора модели оценки надежности
В этом разделе предложен алгоритм, позволяющий сравнивать несколько заданных МОН [8] и состоящий из следующих шагов:
1. На первом шаге рассчитываются параметры для нескольких моделей (методом максимального правдоподобия). После первого шага остаются только те модели,
№ 2(32) 2011
для которых метод сходится. Сходимость может отсутствовать из-за того, что модель в принципе не подходит (например, взята в-изогнутая кривая, а в реальности она строго выпуклая).
2. Исследуется точность моделей. Для этого применяется любой из существующих методов (минимизация среднеквадратичного отклонения, критерий хи-квадрат и др.). В программе, использовавшейся для исследований, рассчитывается среднеквадратичное отклонение, так как данный способ прост и универсален.
3. Проверка на устойчивость (по формулам из раздела «Постановка задачи»),
4. Если на предыдущем шаге не оказалось ни одной устойчивой модели, то необходимо продолжить тестирование и сбор данных еще на один отчетный период. Если же есть устойчивые модели, то на их основе можно решать, является ли текущая версия стабильной.
Описанный алгоритм носит эмпирический характер: модель выбирается после некоторого периода, в течение которого производятся различные промежуточные расчеты, тогда как изначально по свойствам проекта никаких предположений не делается. Для того чтобы проверить работоспособность алгоритма и адекватность выбранных характеристик точности, необходимо испытать модели и алгоритм на реальных данных. Для этих целей было создано программное средство, позволяющее делать расчеты. В следующем разделе показаны результаты проведенных с его помощью экспериментов.
Экспериментальное исследование
Задача исследования — на данных тестирования реальных проектов изучить различные описанные в литературе модели и получить решение для ранее рассмотренных задач 1-3:
1. Определить период времени, через который необходимо строить новую функцию т(1) для более точных оценок, учитывающих вновь поступившие данные.
5
2. Выбрать наиболее подходящую к ис- ¡1 следуемому проекту МОН из нескольких ^ возможных. ^
3. Оценить, какой объем исходных дан- §" ных нужен для того, чтобы модели давали | результаты с точностью не ниже заданной. §
Проекты для исследования выбирались, sj исходя из следующих требований:
• большой объем программы (сотни тысяч строк);
• длительное время тестирования, обширная база данных о тестировании (несколько лет);
• большой коллектив разработчиков (несколько сотен человек);
• проект должен состоять из отдельных компонент.
В практическое исследование были включены несколько проектов с открытым исходным кодом. В качестве основного взят проект Eclipse, а дополнительных — Mozilla и Linux Kernel.
Методика экспериментального исследования заключалась в следующем:
1. По выбранным проектам из системы отслеживания ошибок загружается статистика тестирования.
2. Для этих проектов и выборочно их компонент и подмножеств ошибок одинаковой критичности получены такие данные, как:
• оценка количества ошибок на ближайший период и ее сравнение с реальными данными (по периодам за некоторое время);
• точность и устойчивость рассматриваемых сходящихся моделей в соответствии с ранее описанным алгоритмом.
3. Используя эти данные, с помощью алгоритма получаем ответ к задачам 2 и 3. Оценивая точность результатов на разных промежутках времени между применениями алгоритма выбора модели, можно решить задачу 1.
Полученные в ходе исследования данные показывают, что точность и устойчивость, начиная приблизительно с 10-15 мес., стабильно отклоняются от 100 не более чем на 10% (рис. 1-2), что считает-
№ 2(32) 2011
140 120 100 80 60 40 20 О
Сое1-ОкитоЬ (1) 1_одап№тю (2) иеПп8к1-Могапс1а (3)
-
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 t
Рис. 1. Подпроект — функция ас
ся приемлемым. Из этого можно сделать вывод о том, что в целом МОН применимы к проектам с открытым исходным кодом, несмотря на децентрализованность тестирования и его совмещение с разработкой.
На основе экспериментов также сделан вывод, что наиболее приемлемым периодом для перерасчета является один месяц. %
160
Сравнение данных, полученных при разной частоте пересчета, позволяет обнаруживать, что близость оценки к реальным данным при разбиении по месяцам значительно выше, чем при разбиении по неделям (в среднем 10-15% против 30-40%). При разбиении по неделям расхождения оценок и результатов более явные. При разбиении же по годам данных слишком ма-
Рис. 2. Подпроект —функция ^
140 120 100 80 60 40 20 0
№ 2(32) 2011
ло, и уменьшения количества ошибок не прослеживается. Это можно объяснить тем, что для расчета по годам/полугодиям нужно много данных, а при расчете каждую неделю слишком большое влияние оказывают факторы, непосредственно не связанные с тестированием: нерабочие дни, релизы новых версий и т.д. Кроме того, так как при перерасчете по годам виден почти линейный рост, то за большой период набирается достаточно нового кода, содержащего новые ошибки (по этой же причине предположение о бесконечном количестве ошибок в коде не является существенным ограничением в данном случае). При расчете же по неделям точность сильно понижается. Тем не менее вопрос о более точном определении расчетного периода остается открытым, возможно, стоит вывести формулу или алгоритм для нахождения оптимальной величины расчетного периода, если имеется довольно большой объем статистики.
При этом также можно отметить, что полученные оценки достаточно точны в течение более продолжительного времени, чем 1 мес., вплоть до 3-4 мес.
На рисунке 3 видно, что приемлемая точность аппроксимаций и оценок достигается примерно к 10-15 мес. после начала тестирования, изначально же она очень низкая. Это связано в первую очередь с особенностями самих моделей — до тех пор, пока тестирование не дойдет до того момента, на котором кривая начинает приближаться к асимптоте, очевидно, что стремление к точности аппроксимации будет снижать точность оценок. Кроме того, в случае с Eclipse у данного проекта есть особенность — в начале в Bugzilla, по всей видимости, загрузили статистику за некоторый период, поставив близкие даты.
Что касается сравнения моделей между собой, то показатели Goel-Okumoto {GO), Jelinski-Moranda (JM) и Logarithmic в целом довольно близкие. Проведенные расчеты свидетельствуют, что спустя некоторое время (те же 10-15 мес.) разница между оценками по этим моделям оказывается не выше 5%. Минусом GO является то, что она иногда не сходится — постоянно применять только ее не всегда возмож-
Число ошибок
1_/(f);2-m(f)300;3-m(f):
Рис. 3. Сравнение оценок с реальными данными
Ч..... 31
№ 2(32) 2011
но. Модель JM можно считать особенно устойчивой, но не самой точной, кроме того, у нее скорее заниженные оценки, тогда как из практических соображений более приемлемыми следует считать несколько завышенные.
Наиболее подходящей кривой для проектов с открытым исходным кодом, как можно было предположить, является S-изогнутая кривая, что хорошо видно на примерах статистики по отдельным модулям. Причина этого в том, что у каждого небольшого модуля относительно небольшая команда разработчиков, которые другими модулями почти не занимаются. Как следствие, после обнаружения большого количества ошибок в начале качество тестирования начинает повышаться. В более глобальном масштабе, в рамках целого проекта уровня JDT или Platform (количество ошибок за весь период имеет порядок нескольких десятков тысяч), S-изогнутая модель работает плохо, что можно объяснить неравномерностью разработки по разным модулям.
В результате проведенного исследования были сделаны следующие выводы:
• лучше всего строить новые оценки каждый месяц;
• наиболее подходящая МОН для проектов с открытым исходным кодом — S-Shaped, при этом ее следует применять не к целым проектам, а к подпроектам.
Заключение
В рамках данной статьи получены следующие результаты:
• предложен алгоритм сравнения МОН;
• реализовано программное средство для сравнения моделей и выбора наиболее подходящей;
• показана общая эффективность МОН применительно к выбранным проектам с открытым кодом;
• выбран наиболее подходящий промежуток времени для разбиения данных — один месяц.
Сформулированы следующие гипотезы о применении МОН к проектам с открытым исходным кодом:
• приемлемая точность и устойчивость достигаются через 10-15 мес. после начала тестирования;
• наиболее подходящей для проектов с открытым исходным кодом является S-изо-гнутая пуассоновская модель.
В качестве дальнейшего развития предложенного подхода можно выделить такие направления, как:
• автоматизация выбора наилучшего периода для группировки данных (с возможностью выбора произвольного периода, а не только «круглого»);
• проверка указанных выше гипотез статистически, например, с помощью критерия Пирсона;
• определение периода, на котором оценки верны с точностью не ниже заданной.
Описок литературы
1. Lyu М. Software Reliability Engineering: A Road-map // 2007 Future of Software Engineering. Washington, DC, USA, 2007. P. 153-170.
2. Alam S. Software Reliability Using Markov Chain Usage Model. Dhaka, Bangladesh: Department of Computer Science and engineering Bangladesh University of Engineering and Technology, 2005.
3. WoodA. Software Reliability Growth Models. Technical Report, 1996.
4. Umeda H. The development of a program drawing reliability growth curves and implementing reliability growth models. Tottori University of Natural Sciences, Department of Infromation Systems, 2008.
5. ШиряевА. H. Вероятность. M.: МЦНМО, 2004.
6. Al-Ekram R. Software Reliability Growth Modeling and Prediction. Waterloo: Dept. of Electrical and Computer Engineering, University of Waterloo, 2002.
7. Limnios M., Nikulin N. Recent Advances in Reliability Theory. Birkhauser, 2000.
8. Stringfellow C. An Empirical Method for Selecting Software Reliability Growth Models // Empirical Software Engineering 2002. 7. №4. P. 319-343.
