/>/>/>ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
Государственноеобразовательное учреждение высшего профессионального образования
«Нижегородскийгосударственный университет им. Н.И. Лобачевского»
Физическийфакультет
Кафедра физикиполупроводников и оптоэлектроники
Дипломная работа
Разработкапрограммно–алгоритмических средствдля определения надёжности программного обеспеченияна основании моделирования работы системы типа «клиент–сервер»
студента 5–го курса
«Допустить к защите»
зав. каф. ФПО,
д.ф.–м.н., проф.
ПАВЛОВ Д.А.
Научный руководитель,
доцент каф. ФПО, к.ф.–м.н.
Рецензент:
доцент каф. ЭТТ, к.ф.–м.н.
Москва 2008 г.
Оглавление
Сокращения… 4
Введение… 5
1. Аналитическийобзор литературы… 7
1.1 Надежностькак характеристика качества ПО… 7
1.2 Текущеесостояние вопроса… 9
1.3 Выводы… 19
2. Теоретическаячасть… 21
2.1 Существующиемодели надежности ПО… 21
2.2 Содержательнаяпостановка задачи… 24
2.3 Разработкамодели надежности ПО типа клиент–сервер… 29
2.3.1Модель надежности клиентских программ… 29
2.3.2Модель с заменой вероятностей состояний на средние численности состояний 34
2.3.3Модель для случая N модулей–клиентов… 37
2.3.4Модель для случая l ¹ const… 42
2.4 Разработкаобобщенной модели надежности ПО типа клиент–сервер 46
3. Экспериментальнаячасть… 52
3.1 Обоснованиевыбранного метода реализации… 52
3.2 Алгоритмфункционирования программы… 52
3.3 Практическиерезультаты моделирования… 55
3.3.1Оценка времени, необходимого для уменьшения количества ошибок до расчетногоуровня… 55
3.3.2Влияние количества клиентов на надежность ПО… 57
3.3.3Влияние количества программистов на надежность ПО… 59
3.3.4Влияние интенсивности обращений клиентов к серверу… 61
3.3.5Определение начального количества ошибок в ПО… 62
3.3.6Поиск начального количества ошибок в программе по начальной и конечнойинтенсивностям отказов… 65
Выводы… 68
Списокиспользованных источников… 70
ПриложениеА. Примеры моделей надежности ПО… 73
/>/>/>/>/>Сокращения
ВС – вычислительное средство
ВТ – вычислительная техника
ЖЦ – жизненный цикл
КИС – корпоративная информационная система
ММП – метод максимального правдоподобия
МНК – метод наименьших квадратов
ООД – область определения данных
ОС – операционная система
ПИ – программное изделие
ПК – программный комплекс
ПО – программное обеспечение
ПТС – программно–техническое средство
СВМО – среднее время между отказами
СМО – система массового обслуживания
СПО – системное программное обеспечение
ТЗ – техническое задание
ТУ – технические условия
ЭП – экстремальное программирование
/>/>/>/>/>/>Введение
Архитектура современных корпоративных информационныхсистем (КИС) является, как правило, функционально распределенной. Онахарактеризуется многопотоковой организацией вычислений, при которой запросыреализуются параллельно и распределяются по нескольким процессорам (серверам).Основным средством реализации функций обработки информации и управления в такихсистемах является программное обеспечение (ПО). Существенной особенностью КИСявляется непрерывность процессов ввода и обработки информации, цикличныйхарактер вычислительных процессов. В связи с этим важнейшей проблемой,возникающей при создании КИС, является обеспечение высокого уровня надежностиих функционирования. В распределенных системах, архитектура которыхобеспечивает возможность полного или частичного резервирования аппаратных средств,основным фактором, определяющим надежность функционирования, являетсяпрограммное обеспечение.
Многочисленные научные публикации [1-4] и накопленныйопыт разработки программных систем в России и за рубежом свидетельствуют о том,что достаточно уверенно прогнозировать уровень надежности функционирования ПО весьматрудно. Проблема заключается в том, что существующие методы и моделипрогнозирования надежности ПО не в полной мере пригодны для практическогоприменения.
В настоящее время в области машинной обработкиинформации существуют две взаимосвязанные проблемы: стоимость обработкиинформации и ненадежность программного обеспечения, организующего ивыполняющего процесс обработки информации. При этом первая проблема находится взависимости от второй, так как высокая стоимость проектирования, тестирования исопровождения программ обработки информации определяется прежде всегоненадежностью ПО [5].
Необходимость повышения надежности программногообеспечения обусловлена еще и тем, что в настоящее время ПО несет значительнобольшую функциональную нагрузку в решении задач управления, чем техническиесредства.
Поэтому целью данной дипломной работы разработкапрограммно–алгоритмических средств для проведения оценки надежностипрограммного обеспечения на основе построения модели надежности ПО, позволяющейпроводить расчет характеристик надежности ПО (таких как, время наработки доотказа, коэффициент готовности, вероятность отказа) и на основе этой моделипрогнозировать изменение этих характеристик во времени.
В качестве теоретической основы использованы: теориямассового обслуживания, теория вероятностей, теория линейного программирования,методы разработки программного обеспечения, международные и отечественныестандарты по программному обеспечению. В качестве метода исследования выбранметод Монте–Карло.
В качестве информационных источников в работеиспользовались научные данные и сведения из книг, журнальных статей, а такжемеждународные и отечественные стандарты по разработке и применению программногообеспечения, результаты собственных расчетов и проведенных экспериментов.
/>/>/>/>
1. Аналитический обзор литературы
/>/>/>
1.1 Надежность как характеристика качества ПО
В работах [6-9] дается определение основныххарактеристик качества ПО, а также приводятся рекомендации по их измерению, даютсяметрики и критерии. В частности, дается номенклатура показателей надежности ПО.В стандарте [10] вводится шесть характеристик качества, в том числе для оценкинадежности: завершенность, устойчивость к ошибкам, восстанавливаемость,согласованность, правильность работы, своевременность. Основные показателикачества ПО отображены в таблице 1.
Таблица 1 – Показателикачества ПОПоказатель Описание Удобство сопровождения ПО должно быть таким, чтобы существовала возможность его усовершенствования в ответ на изменения требований заказчика или пользователя Надежность Определяется рядом характеристик, таких как безотказность, защищенность и безопасность Эффективность ПО должно разумно расходовать ресурсы и обладать достаточными скоростными и временными характеристиками Удобство в использовании ПО должно быть удобным в эксплуатации и быть рассчитанным на технический уровень эксплуатирующего персонала, обладать соответствующим пользовательским интерфейсом и документацией
Данные показатели не вытекают непосредственно из того,какие действия может выполнять программный продукт. Они характеризуют поведениепрограммы при выполнении этих действий.
Надежность — один из важнейших факторов, определяющихобщую производительность и эффективность систем. В связи с этим уже на стадиипроектирования системы вопросам надежности должно уделяться пристальноевнимание. В этот период, когда устанавливается первоначальная взаимозависимостьмежду характеристиками системы, затратами и графиком выполнения работ, должныбыть сформулированы и требования к надежности, так как именно они взначительной мере определяют реализуемость проекта и стоимость будущей системы.
В КИС компьютер, как часть системы, обычно выполняетфункции управления и должен работать в режиме реального времени. Поэтому приразработке ПО необходимо учитывать аппаратные средства, средства взаимодействияс пользователем и среду окружения [8]. Поскольку многие свойства ПО сложнойсистемы проявляют себя только тогда, когда она собрана целиком и запущена врабочий режим, то не учет этих факторов в совокупности может привести кпостроению ненадежного ПО. График соотношения надежности ПО и аппаратурыпоказан на рис. 1.
/>
Рисунок 1 – Соотношениенадежности программы и аппаратуры
Можно выделить три типа системных(программно–аппаратных) компонентов, склонных к отказам:
аппаратные средства системы, отказывающие либо из–заошибок конструирования, либо из–за ошибок изготовления, либо из–за износа(старения), либо из–за эксплуатации в тяжелых недопустимых по ТУ условиях;
ПО системы, которое может отказать из–за ошибок вспецификациях, в архитектуре, в программном коде;
человеческий фактор, который своими действиями нарушаетзапланированную работу системы либо производит незапланированные в ПО действия.
В данной дипломной работе будут рассмотрены вопросынадежности ПО.
В [11] говорится о высокой стоимости ПО как следствиеего низкой надежности. Типичное распределение стоимости ПО приведено на рис. 2.
/>
Рисунок 2 – Типичное распределение стоимости ПО
Отсюда делается вывод, что наилучший путь сокращениястоимости ПО – в уменьшении стоимости его тестирования и, главное,сопровождения, то есть в повышении надежности.
/>/>/>
1.2 Текущее состояние вопроса
Теория надежности как наука получила развитиеприменительно к сложным техническим системам. Необходимость и полезностьконтроля технических компонент систем и систем в целом, с целью проверкисоответствия их текущих характеристик заданным, доказаны практикой. В этомплане выполнено значительное количество работ по надежности применительно ктехническим системам, разработано множество моделей обеспечения разумнымиметодами надежности сложных систем и их технической готовности.
Эти модели в ряде случаев позволяют не только оцениватьпоказатели надежности и готовности технических систем и их компонентов, но идают возможность предсказывать значения этих показателей на основе накопленногоопыта. Кроме того, ряд моделей позволяет на основе накопленных данныхвысказывать предположения в отношении режимов работы, при которых наиболеечасто проявляются отклонения от нормального функционирования, а также оприменяемом подходе к восстановлению (ремонту) системы или ее компонентов послесбоя.
Под системой в теории надежности принято пониматьсовокупность подсистем или элементов, функционально объединенных в соответствиис некоторым алгоритмом взаимодействия при выполнении заданной задачи в процессеприменения по назначению. Под это определение системы полностью подходитпрограммное обеспечение. В работе [12] указывается, что исследования в областипрограммной надежности находятся на начальной стадии своего развития.
К основным проблемам исследований надежности ПОотносятся:
прежде всего – разработка методов оценки ипрогнозирования надежности ПО;
определение основных факторов, влияющих на надежностьПО;
разработка методов, обеспечивающих достижение заданногоуровня надежности ПО;
совершенствование методов повышения надежности ПО впроцессе проектирования и эксплуатации.
Основная причина ошибок в ПО – это его сложность. Дляборьбы со сложностью выделяются две концепции:
независимость;
иерархическая структура.
В работе [11] приводится правило «n ± 1»: Проверкаправильности фазы n проекта должна осуществляться проектировщиками (исполнителями)фаз (n+1) и (n–1). Кроме того, в [11] приводится обоснование необходимости какможно более раннего обнаружения ошибок проектирования ПО. Оно заключается втом, что стоимость исправления ошибки со временем возрастает (рис. 3б), авероятность правильно исправить ошибку – падает (рис. 3б).
/>
Рисунок 3 – Обоснованиенеобходимости раннего обнаружения ошибки
При этом вероятность правильно исправить ошибкунаходится в противоречии с вероятностью обнаружить ошибку. Вероятностьобнаружить ошибку возрастает со временем при уточнении требований заказчика иво время опытной эксплуатации. В этой связи важно решить задачу оптимизациивремени обнаружения ошибки при минимальных затратах на ее исправление (см. рис.4).
/>
Рисунок 4 – Вероятностьобнаружения ошибки и задача оптимизации
На рис.4а изображена зависимость вероятности обнаружить ошибкуот времени, а на рис.4б: линия 1 – зависимость вероятности обнаружить ошибку отвремени; линия 2 – вероятность исправить ошибку; также представлены областиоптимального соотношения и оптимального времени для обнаружения и исправленияошибок в ЖЦ ПО.
Кроме того, дается определение тестирования исопутствующих ему понятий. Тестирование – процесс выполнения программы снамерением найти ошибку. Валидация (испытание) – попытка найти ошибку, выполняяпрограмму в заданной реальной среде.
Процентные частоты появления ошибок в ПО [13-15] потипам ошибок представлены в табл. 2.
Таблица 2 – Процентные частоты появления ошибок в ПОТип ошибки Частота появления, % Не полная или ошибочная спецификация 28 Отклонение от спецификации 12 Пренебрежение правилами программирования 10 Ошибочная выборка данных 10 Ошибочная логика или последовательность операций 12 Ошибочные арифметические операции 9 Нехватка времени для решения 4 Ошибка обработки прерываний 4 Ошибка в исходных данных 3 Неточная запись 8
Как видно из таблицы 2, основное количество ошибокделается из–за неверной спецификации или ТЗ. Эти ошибки, в свою очередь, могутбыть разделены на следующие категории:
Таблица 3 – Категории ошибок в ПОПричина ошибки Частота появления, % Ошибки в числовых значениях 12 Недостаточные требования к точности 4 Ошибочные символы или знаки 2 Ошибки оформления 15 Неправильное описание или требование к аппаратуре 2 Исходные данные для разработки неполные, неточные или ошибочные 52 Двусмысленность требований 13
Из этих таблиц следует, на что нужно обращать особоевнимание при проведении валидации и верификации ПО.
Тестирование программы ведется до тех пор, покаинтенсивность программных ошибок не уменьшится до заранее заданного уровня.Ориентировочно можно исходить из того, что интенсивность программных ошибок наэтапе испытаний должна быть не больше интенсивности аппаратных отказов.
Программные отказы и аппаратные отказы имеют общиепризнаки:
объект не выполняет заданной функции;
времена до отказов и времена устранения отказов носятслучайный характер;
методы обработки статистических данных одинаковы.
И отличия:
аппаратный отказ зависит либо от времени, либо от объемавыполненной работы, а программный отказ – от той функции, которую выполняетизделие под управлением программы (то есть с какой вероятностью программавыйдет на участок, который содержит ошибку);
обнаружение и устранение аппаратного отказа не означает,что такой отказ не повториться, а обнаружение и устранение программной ошибкиозначает, что такой отказ больше не повториться (но могут появиться новыеошибки);
программный отказ может никогда не реализоваться приданных условиях эксплуатации программы;
аппаратные отказы подразделяют на внезапные и постепенные.
Программные отказы возникают, как правило, внезапно и поприроде своей не совпадают с внезапными аппаратными отказами, так каквероятность их возникновения не связана с продолжительностью работы изделия.Она связана с условной вероятностью того, что программа содержит ошибку вданной части программы и вероятности того, что изделие будет работать подуправлением этой части программы.
Если аппаратная часть жестко задана и интенсивностьотказов ее не меняется (только увеличивается в результате старения), то ПОимеет в процессе эксплуатации ряд модификаций с уменьшающейся (в идеале)интенсивностью отказов. Следует иметь в виду, что ПО в ПТС определяетнаибольшее количество ошибок. В настоящее время около половины отказов сложныхвычислительных систем обусловлено ошибками ПО, а с ростом надежноститехнических средств составит 90% отказов от общего числа [16].
Можно выделить 4 группы принципов обеспечениянадежности:
предупреждение ошибок;
обнаружение ошибок;
исправление ошибок;
обеспечение устойчивости к ошибкам.
В работе [17] говорится, что для повышения надежностипрограммных комплексов необходимо применять разнообразие. Этот методпредполагает реализацию одной и той же функции разными алгоритмами и сприменением разных средств разработки. Также предлагается применять глубокоэшелонированную защиту. Этот метод предполагает применение многоуровневойзащиты с перекрытием, т.е. с перекрывающимися назначениями защит разныхуровней. Предлагается применять также смягченную деградацию систем, т.е. когдачасть системы при выходе из строя другой части частично берет на себявыполнение ее функций.
Возможные действия, направленные на минимизацию ошибок исбоев:
предотвращение ошибок за счет структурногопрограммирования;
сокрытие информации или дозированный доступ к данным состороны программных средств и объектов в объектно–ориентированномпрограммировании;
отладка;
устойчивость к сбоям;
обработка исключительных ситуаций (перехват ошибок,например, деление на ноль) и локализация ошибок и сбоев;
восстановление программы после сбоя;
верификация и валидация (верификация отвечает на вопрос,правильно ли и качественно ли создана программа, а валидация (или аттестация) –на вопрос правильно ли работает программа).
В работе [13] говорится о повышении надежности ПО спомощью введения избыточности. Для повышения надежности ПО пользуются методомрезервирования. Для этого разрабатывают две или более различных по алгоритмамверсий программы для решения одной и той же задачи. Для этого хорошо подходитметод, когда одну и ту же программу пишут две независимые группы программистов,даже если при этом они реализуют один и тот же алгоритм (задача не должна бытьпри этом тривиальной). Это очень ресурсоемкий метод и поэтому редкоиспользуется на практике. Такое ПО параллельно выполняется в процессеэксплуатации. Сюда же подходит метод быстрого, но не точного решения и долгогои точного, с последующим сравнением результатов. ПО считается правильноотработавшим, если результат сравнения удовлетворяет какому–либо критериюблизости результатов, например разность результатов не должна превышатьнекоторого значения.
Надежность ПО повышается также с помощью примененияразличных методов тестирования. Полное тестирование ПО объективно невозможно,поэтому обычно применяют следующие виды тестирования:
тестирование ветвей;
математическое доказательство правильности алгоритмарешения задачи (в некоторых работах именно в этом смысле употребляется слововерификация). В [11] показывается, что доказательство правильности программы спомощью исчисления предикатов первого порядка не исключает ошибки в программе,так как относится к доказательству правильности внутренней спецификации наконкретный модуль. Этот метод заключается в том, что с помощью аппаратаформальной математической логики пишут входные условия и выходные утверждения,а затем показывают, что, производя над входными условиями действия согласнотем, что записаны в программе, получается выходное утверждение. Частопользуются обратным методом, т.е. идут от выходного утверждения к входномуутверждению. Этот метод труден и утомителен, а многие конструкции языковпрограммирования не поддаются доказательству с точки зрения формальной логики.Этот метод не работает, если выходное утверждение само не правильно. Тогдаможно доказать, что программа приводит к этому утверждению, но это оказываетсябесполезно с практической точки зрения. Тем не менее, метод имеет право нажизнь, потому что позволяет обнаруживать ошибки во внутренней логике модуля, ноприменим в основном к программам численных вычислений и применим кнезначительному подмножеству языка программирования;
символическое тестирование (или с помощью специальноподобранных тестовых наборов), еще называется статическим тестированием. Удобнопри локализации ошибки, проявление которой выявлено при конкретном узком илистрого заданном диапазоне входных значений;
динамическое тестирование (с помощью динамическигенерируемых входных данных), что удобно при быстром тестировании во всемшироком диапазоне входных параметров;
тестирование путей выполнения программы;
функциональное тестирование;
проверки по времени выполнения программы;
проверка по использованию ресурсов и стрессовоетестирование.
В работе [8] говорится, что существует 4 основныесоставляющие функциональной надежности программных систем:
безотказность – свойство программы выполнять своифункции во время эксплуатации;
работоспособность – свойство программы корректно (таккак ожидает пользователь) работать весь заданный период эксплуатации;
безопасность – свойство программы быть не опасной длялюдей и окружающих систем;
защищенность – свойство программы противостоятьслучайным или умышленным вторжениям в нее.
В этом случае высокий уровень функциональной надежностиможет быть достигнут только за счет уменьшения эффективности работы программы. Вработе [19] говорится, что в соответствии с ГОСТ 19.004–80 различают следующиевиды работ, направленные на устранение ошибок в ПО: проверка, отладка ииспытание программы.
Чем интенсивнее использование ПО, тем быстрее выявляютсяв нем ошибки. На рис.5 приведена зависимость числа обнаруженных ошибок от числаиспользующих ПО пользователей:
/>
Рисунок 5 – Интенсивность обнаружения ошибок отинтенсивности использования, где K – число пользователей, K1 > K2 > K3.
В [19] подчеркивается, что при заключительныхприемо–сдаточных и сертификационных испытаниях для определения надежности ПОорганизуются многочасовые и многосуточные прогоны функционирования комплексапрограмм в реальной или имитационной внешней среде в условиях широкоговарьирования исходных данных с акцентом на стрессовые ситуации.
Если интенсивное тестирование программ в течениидостаточно длительного времени не приводит к обнаружению дефектов или ошибок,то создается ощущение бесполезности дальнейшего тестирования, и программапередается на эксплуатацию. Экспериментальные исследования характеристикобнаружения ошибок в сложных программах позволило оценить темп обнаружения ошибок,при котором сложные комплексы программ передаются на регулярную эксплуатацию:0,02 – 0,05 ошибок в день на человека, т.е. специалисты выявляют только околоодной ошибки каждые два месяца.
Интенсивность обнаружения ошибок ниже 0,001 ошибок вдень на человека, т.е. меньше одной ошибки в год на 3–4 специалистов, повидимому, может служить эталоном высокого качества отладки и надежности для ПОобработки информации и соответствует очень высокому уровню наработки на отказ » 5 – 10 тысяч часов.
В [20] к числу основных факторов, влияющих на надежностьПО отнесены:
взаимодействие ПО с внешней средой(программно–аппаратная средства, трансляторы, ОС). Этот фактор вноситнаименьший вклад в надежность ПО при современном уровне надежности аппаратуры,ОС и компиляторов;
взаимодействие с человеком (разработчиком ипользователем) (см. например метрику Холстеда);
организация ПО (проектирование, постановка задачи испособы их достижения и реализации) и качество его разработки. Этот факторвносит наибольший вклад в надежность;
тестирование.
В соответствии с этим способы обеспечения и повышениянадежности ПО могут быть следующими:
усовершенствование технологии программирования(например, формальное описание этапов программирования при помощи языка UML);
выбор алгоритмов, не чувствительных к различного роданарушениям вычислительного процесса (использование алгоритмическойизбыточности);
резервирование программ – N–версионное программирование;
верификация и валидация программ с последующей коррекцией.
/>/>/>
1.3 Выводы
На основе сделанного обзора можно констатировать: насегодняшний день отсутствует общее решение проблемы надежности ПО и есть многочастных решений, не учитывающие такие существенные факторы как интенсивностьвнесения и устранения ошибок в программе, время разработки ПО. Ни одна измоделей не может считаться достаточной для оценки надежности. Таким образом,сегодняшний уровень понимания проблемы надежности, в основном качественный,позволяет нам рассматривать программу как черный ящик с поступающими ему навход данными и внешними воздействиями, а на выходе выдающий нам поток ошибок,устраняемый с большим или меньшим успехом. Стоит актуальная задача построенияболее совершенных моделей. В данной дипломной работе предлагается модель,основанная на марковской теории систем массового обслуживания (СМО), с решениемзадачи появления и устранения ошибок в программе как марковского процессагибели и размножения с непрерывным временем и нахождением его характеристики.
/>/>/>/>
2. Теоретическая часть
/>/>/>
2.1 Существующие модели надежности ПО
Прогнозирование надежности ПО в процессе егоэксплуатации осуществляется на основе математических моделей надежностипрограмм.
В работе [11] приведены вероятностные модели надежности.Теория надежности для аппаратного обеспечения развита довольно хорошо, и, какпоказано выше, есть применить ее и к надежности ПО. В этих моделях ищется числоошибок, оставшихся в программе. Это необходимо знать для завершения процессатестирования, и оценки стоимости сопровождения, которая пропорциональнаколичеству оставшихся в программе ошибок. Также эти модели позволяют находитьнадежность программы, которая понимается как вероятность, что программа будетфункционировать без ошибок в течение заданного интервала времени, а также –среднее время между отказами программы.
В [20] дается классификация моделей надежности ПО.Наиболее известных моделей надежности ПО в настоящее время существует околодесятка, поэтому в данной работе они сгруппированы по признакам. В качествеклассификационных признаков выбраны следующие (рис.6):
временная структура процессов проявления ошибок в ПО(время появления ошибки, количество ошибок за заданный интервал времени);
сложность программы (мера сложности ПО – длина,количество функций или модулей, данных и т.п.);
разметка ошибок (искусственное внесение в ПО известныхошибок);
структура пространства входных данных;
структура текста программы (распределение ошибок потексту программы).
/>
Рисунок 6 – Классификация моделей надежности ПО
Как показано в [19] на практике простейшие, элементарныеошибки программ и данных могут приводить к катастрофическим последствиям прифункционировании ПО. В то же время, крупные системные дефекты могут тольконесколько ухудшать эксплуатационные характеристики ПО. Поэтому невозможноранжировать типы первичных ошибок по степени влияния на надежность и следуетодинаково тщательно относиться к их обнаружению и устранению.
Статистика ошибок в комплексных программах и иххарактеристики могут служить ориентиром для разработчиков при распределенииусилий на отладку и предохранять их от излишнего оптимизма при оценкедостигнутого качества и надежности ПО. Они помогают:
оценивать реальное состояние проекта и планироватьнеобходимые трудоемкость и длительность до его завершения;
выбирать методы и средства проектирования,программирования и тестирования.
Регистрация, сбор и анализ характеристик ошибок впрограммах является сложным и трудоемким процессом. Поэтому имеетсяотносительно небольшое число работ, в которых опубликованы реальныехарактеристики ошибок.
При автономной, и в начале комплексной отладки долясистемных ошибок невелика (~ 10%), но она существенно возрастает (до 35–40%) назавершающих этапах комплексной отладки. В процессе сопровождения системныеошибки являются преобладающими (~ 80% от всех ошибок).
Различными авторами были сделаны ряд уточненийвышеизложенной модели (к настоящему времени предложено около 15 математическихмоделей для описания количества ошибок в ПО различной степени сложности).Однако ни одна из этих моделей не имеет явных преимуществ по точности аппроксимациираспределений и прогнозирования числа ошибок в программах по сравнению спростейшей экспоненциальной моделью. Обзор наиболее характерных моделейнадежности ПО дается в Приложении А.
В работе [20] дается сравнениемоделей. Модели Джелинского–Моранды и Шика–Уолвертона целесообразны примоделировании надежности ПО небольшого объема, а модифицированная модельШика–Уолвертона – для ПО больших проектов. Если при моделировании необходимополучить значения надежности (например, среднюю наработку до отказа), то лучшеиспользовать геометрические модели. Некоторые модели не имеют решений (то естьрасходятся при определенных входных условиях). Если имеются данные обинтервалах времени между ошибками, то лучше воспользоваться геометрической моделью,а если имеются данные о числе ошибок, приходящихся на единицу времени, то лучшеприменять модель Шнейдевинда. Экспоненциальная и дискретная модели былипроверены при тестировании реальных программ и хорошо соответствуютдействительности [21].
В заключение в [20] делается вывод, что на сегодняшнийдень невозможно выбрать наилучшую модель среди десятка предложенных.
Из–за значительных неопределенностей во всехвышеописанных моделях в [11] рекомендуется использовать несколько моделейодновременно и объединять их результаты.
В [19] говорится, что модели дают удовлетворительныйрезультат при относительно высоких уровнях интенсивности проявления ошибок, тоесть при невысокой надежности ПО. В этих условиях математические моделипредназначены для приближенной оценки:
потенциально возможной надежности функционированияпрограмм в процессе испытаний и эксплуатации;
числа пропущенных ошибок;
время тестирования, требуемое для обнаружения следующейошибки;
время, необходимое для обнаружения с заданнойвероятностью большинства имеющихся ошибок.
Можно предположить, что оценки, приведенные длянескольких конкретных систем, позволят прогнозировать эти характеристики длядругих проектов. Вероятностный подход к надежности ПО должен дать ответ на одиниз самых сложных вопросов при тестировании ПО – когда нужно остановиться изавершить тестирование, то есть, в течении какого времени времени нужнотестировать программу, чтобы она удовлетворяла требованиям по надежности? Спомощью предложенной в данной работе модели надежности можно получить ответ наэтот вопрос.
/>/>/>
2.2 Содержательная постановка задачи
Имеется ПО типа «клиент–сервер». Серверобслуживает запросы от N программ–клиентов (далее просто клиенты, рис.7). В ПОравномерно по области определения входных данных (ООД) (A, B) расположены Erошибок.
Ошибками (отказами) ПО являются:
Отказы в программе. Если ПО не модифицируется, тоинтенсивность его отказов остаётся постоянной.
Внутренние отказы в программе. Такие отказы обусловленыфундаментальными ограничениями алгоритма, используемого в ПО (например,использование эвристических алгоритмов может привести к случайным отказам).
Отказы, обусловленные ограничением на функционирование вреальном времени. В рассматриваемых системах среда может изменятьсядинамически. Поэтому если планирования или расчёта отклика слишком велико, то кмоменту выполнения отклика среда может быть уже изменена настолько, чтовычисленный или спланированный отклик не будет иметь требуемого эффекта.
/>
Рисунок 7 – Типовая клиент-серверная структура
Сервер сложнее программ–клиентов с точки зренияразработки ПО в S раз. S – коэффициент сложности сервера по отношению кклиентам. Каждый k–ый (k = 1, 2, …, N) клиент порождает пуассоновский потокданных к серверу интенсивностью lобр.Данные от клиента распределены по ООД по нормальному закону с характеристикамиmk и sk, где mkраспределено между клиентами равномерно по всей области входных данных, 3sk – распределено равномернона меньшем из участков отсекаемых mk на оси области данных. Это нужно дляимитации неравномерности использования ООД при малом количестве клиентов.
На запрос клиента сервер отвечает данными, которыераспределены равномерно по всей области определения данных (A, B).
На рис. 8 изображено распределение запросов одногоклиента по области всех возможных запросов к серверу, а также показаноравномерное распределение ошибок по ООД. При попадании запроса клиента илиответа сервера в область ООД, содержащую ошибку, считается, что ошибкаобнаружена и соответствующий модуль выводится из эксплуатации для ееисправления:
/>
Рисунок 8 – Распределениезапросов k–го клиента на области данных
Входными данными для модели являются:
P – количество программистов, обслуживающих систему;
K – количество программ–клиентов;
a– ширина одного запроса клиента как доля от ООД (от 0 до 1, где 1 – это всяООД);
Dt– шаг итерации (сутки);
s – коэффициент сложности сервера по сравнению спрограммой–клиентом;
lобр– интенсивность потока обращений одного клиента к серверу (1/сутки);
lиспр– интенсивность потока исправления ошибки одним программистом (1/сутки);
lвнес– интенсивность внесения ошибки при исправлении одним программистом (1/сутки)или
pвнес – вероятность внести ошибку при исправлении однимпрограммистом;
M – количество итераций (количество попыток обращенийпрограмм–клиентов к серверу в одном розыгрыше);
R – количество розыгрышей для усреднения;
Er – начальное количество ошибок.
Для моделирования потоков запросов в ПО применяетсяметод Монте–Карло.
Также есть возможность оценить первоначальное количествоошибок по следующему алгоритму: Принимаем ООД за единицу. Каждый клиент взапросе генерирует долю aот ООД. За время Dtклиент обратиться к серверу (Dt*lобр) раз. За время Dt все клиенты обратятся ксерверу (Dt*lобр*K) раз. И объем данных,который будет затронут в ООД при этом равен (Dt*lобр*K*a). Так как в нашей моделиошибки распределены равномерно по ООД, то за время Dt будет обнаружено (Dt*lош), где lош– первоначальная интенсивность ошибок в системе. Если бы за время Dt клиенты затронули всюООД, то было бы обнаружены все Er ошибок. Поэтому можно записать следующуюпропорцию:
/>.
Отсюда находим Er:
/>.
При этом считается, что каждый из K клиентов обратился ксерверу с запросом с данными непересекающимися в ООД. Однако в реальностиклиенты чаще всего обращаются к серверу с однотипными запросами, поэтомуполагаем К=1. Тогда первоначальное количество ошибок можно оценить как:
/>
Поставленная задача позволяет определить такие важныехарактеристики функционирования программного комплекса, как:
расчет текущего времени наработки до отказа;
расчет среднего времени наработки до отказа за все времямоделирования работы системы;
расчет вероятности отказа ПО в единицу
расчёт коэффициента готовности
Таким образом, наша задача может использоваться дляпредсказания характеристик ПО и оценки времени, необходимого затратить длядостижения заданного уровня надежности ПО при имеющихся ресурсах, выработкирекомендаций по повышению надежности ПО.
Данная задача имеет смысл для систем типа «клиент-сервер»с целью определения надёжности системы на этапе тестирования.
2.3 Разработка модели надежности ПО типа клиент–сервер
2.3.1 Модель надежности клиентских программ
С помощью метода динамики средних [22] построиммарковскую модель поведения программы состоящей из многих (примерно однотипных)модулей или (что сейчас применяется наиболее часто) построим модель программнойсистемы типа «клиент–сервер». Характерной особенностью такой системыявляется запуск сервером параллельных однотипных потоков, каждый из которыхобслуживает запросы одной программы–клиента или работа сервера со многимиоднотипными клиентскими программами. В этом случае потоки или программы–клиентыполностью идентичны и каждый из них может выходить из строя независимо отостальных. Особенностью этой системы в отличие от систем, рассматриваемых втеории массового обслуживания, (например, обслуживание ремонтной бригадойавтомобиля, или однотипных аппаратных комплексов) заключается в том, что привыходе из строя (обнаружении ошибки) в одном модуле (потоке или клиенте) иустранении этой ошибки, эта ошибка автоматически устраняется и во всех другихмодулях (потоках), так как эти потоки размножаются путем запуска на выполнениеодного и того же кода программы. Учтем эту особенность при применении методадинамики средних. При этом временем на замену модуля с ошибкой на исправленныймодуль мы пренебрегаем.
Метод динамики средних представляет собой удобныйматематический аппарат только в том случае, когда число возможных состоянийсистемы S сравнительно велико (от нескольких десятков и более). В этом случаеобычный математический аппарат теории непрерывных марковских цепей перестаетбыть удобным. Метод динамики средних позволяет составить и решить уравнениянепосредственно для интересующих нас средних характеристик, минуя использованиевероятности состояний.
Итак, пусть имеется сложная (типа клиент – сервер)программная система S, состоящая из большого числа однородных модулей (потоковили клиентов) N, каждый из которых может случайным образом переходить изсостояния в состояние. Пусть (для простоты) все потоки событий (в случаепрограммы – это потоки внешних данных или запросов от клиентских программ ксерверу), переводящие систему S и каждый ее модуль из состояния в состояние –пуассоновские (может быть даже с интенсивностями, зависящими от времени). Тогдапроцесс, протекающий в системе, будет марковским.
Допустим, что каждый модуль может быть в любом из nвозможных состояний: x1,x2, …, xn, а состояние системы S вкаждый момент времени характеризуется числом элементов (модулей), находящихся вкаждом из этих состояний. Исследуем процесс, протекающий в системе S.Отвлечемся от возможных состояний системы в целом (а именно, SN, 0, …, 0 – всемодули находятся в состоянии x1,а в других состояниях нет ни одного элемента; SN–1, 1, …, 0 – один элементнаходится в состоянии x2,все остальные – в состоянии x1и так далее. Очевидно, таких состояний будет очень много – N!), поэтомурассмотрим отдельный модуль x(так как все модули одинаковы) и рассмотрим для него граф состояний (рис.9).
Введем в рассмотрение случайную величину Xk(t) – числомодулей, находящихся в момент времени t в состоянии xk. Будем ее называть для краткостичисленностью состояния xkв момент t. Очевидно, что для любого момента времени t сумма численностей всехсостояний равна общей численности модулей:
/>.
Xk(t) для любого фиксированного момента времени tпредставляет собой случайную величину, а в общем случае – случайную функциювремени. Найдем для любого t основные характеристики случайной величины – еематематическое ожидание mk(t) = M[Xk(t)] и дисперсию Dk(t) = D[Xk(t)].
/>
Рисунок 9 – Граф состояний одногомодуля
Для того, чтобы найти эти характеристики, нам надо знатьинтенсивности всех потоков событий, переводящих модуль (элемент) (не всегокомплекса программ, а именно модуль) из состояния в состояние (см. рис.9).Тогда численность каждого состояния Xk(t) можно представить как сумму случайныхвеличин, каждая из которых связана с отдельным (i–тым) модулем, а именно: равнаединицы, если этот модуль в момент времени t находится в состоянии xk, и равна нулю, если ненаходится в этом состоянии:
/>(1)
Очевидно, для любого момента времени t общая численностьсостояния xk равнасумме случайных величин (1):
/>.
По теореме сложения математических ожиданий и теоремесложения дисперсий получаем:
/>(2)
Найдем основные характеристики – математическое ожиданиеи дисперсию – случайной величины />, заданной выражением (1). Этавеличина имеет два возможных значения: 0 и 1. Вероятность первого из них равнаpk(t) – вероятности того, что модуль находится в состоянии xk (так как программныемодули одинаковы, то для всех эта вероятность одинакова). Ряд распределениякаждого из случайных величин /> один и тот же и имеет вид:возможное значение (xj): 1 вероятность (pj): 1–pk(t) pk(t)
Математическое ожидание случайной величины, заданноетаким рядом, равно:
/>