Разработка программно–алгоритмических средств для определения надёжности программного обеспечения на основании моделирования работы системы типа "клиент

Рисунок 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] построим марковскую модель поведения программы состоящей из многих (примерно однотипных) модулей или (что сейчас применяется наиболее часто) построим модель программной системы типа "клиент–сервер". Характерной особенностью такой системы является запуск сервером параллельных однотипных потоков, каждый из которых обслуживает запросы одной программы–клиента или работа сервера со многими однотипными клиентскими программами. В этом случае потоки или программы–клиенты полностью идентичны и каждый из них может выходить из строя независимо от остальных. Особенностью этой системы в отличие от систем, рассматриваемых в теории массового обслуживания, (например, обслуживание ремонтной бригадой автомобиля, или однотипных аппаратных комплексов) заключается в том, что при выходе из строя (обнаружении ошибки) в одном модуле (потоке или клиенте) и устранении этой ошибки, эта ошибка автоматически устраняется и во всех других модулях (потоках), так как эти потоки размножаются путем запуска на выполнение одного и того же кода программы. Учтем эту особенность при применении метода динамики средних. При этом временем на замену модуля с ошибкой на исправленный модуль мы пренебрегаем.