Производственный менеджмент на предприятиях по производству металлоизделий

Моделирование надежности программного обеспечения

Автор:

Ханджян А.О.

1. Постановка задачи

Имеется программный комплекс (ПК) типа клиент-сервер. Сервер обслуживает запросы от N клиентов. В ПК равномерно по области определения входных данных (ООД) (A, B) расположены Er ошибок. Сервер сложнее клиентов с точки зрения разработки ПК в S раз. S – коэффициент сложности сервера по отношению к клиентам. Каждый k-ый (k = 1, 2, …, N) клиент порождает пуассоновский поток данных к серверу интенсивностью l_обр. Данные от клиента распределены по области определения данных (ООД) по нормальному закону с характеристиками m_k и s_k, где m_k распределено между клиентами равномерно по всей области входных данных, 3s_k – распределено равномерно на меньшем из участков отсекаемых m_k на оси области данных (это нужно для имитации неравномерности использования ООД при малом количестве клиентов).

На запрос клиента сервер отвечает данными, которые распределены равномерно по всей области определения данных (A, B).

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

Рисунок 1 – «Распределение запросов k-го клиента на области данных»

Входными данными для розыгрыша являются:

P – количество программистов, обслуживающих систему;

K - количество программ-клиентов (далее просто клиенты);

a - ширина одного запроса клиента как доля от ООД (от 0 до 1, где 1 – это вся ООД);

Dt - шаг итерации (сутки);

s - коэффициент сложности сервера по сравнению с программой-клиентом;

l_обр - интенсивность потока обращений одного клиента к серверу (1/сутки);

l_испр - интенсивность потока исправления ошибки одним программистом (1/сутки);

l_внес - интенсивность внесения ошибки при исправлении одним программистом (1/сутки) или

p_внес – вероятность внести ошибку при исправлении одним программистом;

M - количество итераций;

Er - начальное количество ошибок.

В программе также есть возможность оценить первоначальное количество ошибок по следующему алгоритму: Принимаем ООД за единицу. Каждый клиент в запросе генерирует долю a от ООД. За время Dt клиент обратиться к серверу (Dt * l_обр) раз. За время Dt все клиенты обратятся к серверу (Dt * l_обр * K) раз. И объем данных, который будет затронут в ООД при этом равен (Dt * l_обр * K * a). Так как в нашей модели ошибки распределены равномерно по ООД, то за время Dt будет обнаружено (Dt * l_ош), где l_ош – первоначальная интенсивность ошибок в системе. Если бы за время Dt клиенты затронули всю ООД, то было бы обнаружены все Er ошибок. Поэтому можно записать следующую пропорцию: . Отсюда находим Er: . При этом считаем, что каждый из K клиентов обратился к серверу с запросом с данными непересекающимися в ООД. Но на самом деле это не так, т.к. чаще сего клиенты обращаются к серверу с однотипными запросами, поэтому полагаем K = 1. И тогда окончательная формула для оценки первоначального количества ошибок будет: ;

Программа предупреждает, если задается интенсивность такая, что на интервал времени Dt приходится больше одного события (т.е (Dt * l) должно быть меньше единицы) – для соблюдения условия ординарности потока событий.

2. Алгоритм одного розыгрыша

При одном розыгрыше выполняются следующие шаги:

1.Разыгрывается размещение Er ошибок в клиентах на ООД, распределенных на ней равномерно;

2.Разыгрывается размещение (s*Er_к)/10 ошибок в сервере на ООД, распределенных на ней равномерно;

3.Для каждого из K клиентов разыгрывается в начале и только один раз m_ki и s_ki.

4.Далее итеративно с шагом Dt для каждого клиента:

a.   Если клиент исправен, то он может обращается с запросами к серверу с интенсивностью l_обр. Вероятность обращения клиента к серверу равна . В случае обращения клиента к серверу разыгрывается случайная величина x_i, распределенное по нормальному закону с параметрами m_ki и s_ki – входное данное для запроса к серверу. Область, занимаемая входными данными запроса от одного клиента к серверу на ООД, есть случайная величина, распределенная равномерно на отрезке от 0 до a/2 (обозначим ее как Rand(a/2))

b. Если в интервал (x_i ± Rand(a/2)) попадает хотя бы одна ошибка на ООД, то считается, что в клиенте обнаружена ошибка, и он выводится из эксплуатации для ее исправления одним из свободных программистов. Если свободных программистов нет, то неисправный клиент становится в очередь и ожидает, когда один из программистов освободится.

c.   Если в запросе клиента к серверу ошибки нет, то этот запрос направляется серверу на обработку и ответа. При этом разыгрывается ответ от сервера клиенту аналогично a), только объем данных есть случайная величина, распределенная равномерно на отрезке от 0 до a*10/2 (обозначим ее как Rand(a*10/2)). Если в область (x_i ± Rand(a*10/2)) попадает хотя бы одна ошибка из списка ошибок сервера, то считается, что в сервере произошла ошибка. В этом случае работа системы останавливается и все программисты пытаются исправить эту ошибку в сервере со скоростью l_испр каждый. Вероятность исправления ошибки одним программистом равна .

d. Если в клиенте есть ошибка и есть свободный программист, то свободный программист пытается исправить ошибку в клиенте с вероятностью .

e.   Если ошибка исправляется, то она удаляется из списка ошибок клиента или сервера соответственно. Таким образом, эта ошибка уже не может возникнуть в других клиентах. При этом если есть клиенты, в которых была обнаружена такая же ошибка, то эти клиенты считаются тоже исправленными. При исправлении ошибки каждый программист может внести новую ошибку с вероятностью  или p_внес. Причем, если программист внес ошибку в программу, то он может внести туда еще одну ошибку с вероятностью равной квадрату вероятности внесения предыдущей ошибки. Вновь внесенные ошибки вносятся в список ошибок клиентов или сервера соответственно. При этом эти новые ошибки не считаются обнаруженными в клиенте или сервере, то есть если обнаруженная ошибка исправляется, то клиент или сервер считается исправленными даже, если при этом были сделаны новые ошибки.

f. За один временной такт Dt разыгрывается сценарий обмена данными для всех работающих на этот момент времени клиентов. Для неисправных клиентов или неисправного сервера разыгрывается вероятностный процесс исправления ошибки в них.

5.В результате разыгрывается M итераций согласно п. 4, и получаем одну реализацию случайных функций ,  и  (средние численности работающих, неработающих, клиентов и вероятность работы сервера) на временном интервале M*Dt.

6.Испытания проводим еще K раз и таким образом получаем K реализаций случайных функций , ,  и . Для каждого момента времени t_j (для j = 1, … M) с шагом Dt находим статистическое среднее для этих функций и получаем средние функции , ,  и .

7.Также в процессе розыгрыша производится:

- расчет текущего времени наработки до отказа;

- расчет среднего времени наработки до отказа за все время розыгрыша;

- расчет вероятности отказа ПО в единицу времени как P = (<объем запроса> * <количество ошибок в клиентах и сервере> * (<количество работающих клиентов> + 1) * <интенсивность обращение> * <шаг итерации по времени>;

Количество ошибок в сервер рано количеству ошибок в клиентах * коэффициент сложность /10.

3. Практические результаты моделирования

Изучим влияние количества программ-клиентов на поведение программной системы клиент-сервер (далее ПС или ПК).

Розыгрыш проводился при следующих начальных условиях (10 клиентов):

Кол-во программ-клиентов: 10, Кол-во программистов: 3, Доля от общей области данных (ООД) в одном запросе клиента: 1E-5, Начальное кол-во ошибок: 250, Коэффициент сложности сервера: 2, Интенсивность потока обращений клиента к серверу: 500 (1/сутки), Интенсивность потока исправления ошибки: 1 (1/сутки), Интенсивность внесения ошибки при исправлении: 0,1 (1/сутки), Шаг итерации: 0,002, Кол-во итераций: 50000, Общее время розыгрыша: 100 (сутки); Число розыгрышей:40

Получены следующие результаты:

Средние значения за все 40 розыгрышей:

Рис.2 – Значения за все 40 розыгрышей

Из рисунка видно, что ПК начнет устойчиво работать (т.е. количество работающих клиентов сравняется с количеством неработающих клиентов на 15 сутки).

Теперь увеличим количество клиентов с 10 до 100:

Кол-во программ-клиентов: 100, Кол-во программистов: 3, Доля от общей области данных (ООД) в одном запросе клиента: 0,00001, Начальное кол-во ошибок: 250, Коэффициент сложности сервера: 2, Интенсивность потока обращений клиента к серверу: 500 (1/сутки), Интенсивность потока исправления ошибки: 1 (1/сутки), Интенсивность внесения ошибки при исправлении: 0,1 (1/сутки), Шаг итерации: 0,002, Кол-во итераций: 75000, Общее время розыгрыша: 150 (сутки); Число розыгрышей:50

Получены следующие результаты:

Средние значения за все 50 розыгрышей:

Рис.3 – Значения за все 50 розыгрышей

Видно, что на 150 сутки почти все ошибки исправлены. Это происходит из-за того, что клиентов больше и их запросы охватывают большую область данных и, следовательно, обнаруживается большее количество ошибок и большее количество ошибок исправляется.

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

Например, если увеличить количество программистов с 3 до 12, то получим:

Начальные условия розыгрыша:

Рис.5 – Значения за 50 розыгрышей

Видно, что программа начнет устойчиво работать как и раньше только на 15 сутки, то есть увеличение количества программистов дает не большой эффект и скорее всего, часть программистов будет простаивать.

Гораздо эффективнее в этой ситуации увеличивать нагрузку при тестировании. Например, как это уже было показано выше, увеличивая количество клиентов.

Увеличивая интенсивность обращения каждого клиента к серверу не дает такого эффекта, т.к. каждый клиент обычно работает в своей узкой части ОД и выбивает ошибки из этой части и остается значительная ОД не проверенная, а значит с ошибками. Вот пример розыгрыша при увеличения интенсивности обращений на порядок с 500 до 2500 в сутки.

Пример:

Начальные условия розыгрыша:

Кол-во программ-клиентов: 10, Кол-во программистов: 3, Доля от общей области данных (ООД) в одном запросе клиента: 1E-5, Начальное кол-во ошибок: 250, Коэффициент сложности сервера: 2, Интенсивность потока обращений клиента к серверу: 2500 (1/сутки), Интенсивность потока исправления ошибки: 1 (1/сутки), Интенсивность внесения ошибки при исправлении: 0,1 (1/сутки), Шаг итерации: 0,0004, Кол-во итераций: 250000, Общее время розыгрыша: 100 (сутки); Число розыгрышей:10

Рис.6 – Число розыгрышей:10

Вот еще пример, когда увеличение количества непрофессиональных программистов может привести к отрицательному результату. В примере показан результат увеличения количества программистов с 3 до 10, у которых поток ошибок при исправлении равен не 0,3, а 0,7. Из рисунка видно, что поток ошибок даже увеличивается, а за 100 дней работы системы количество ошибок практически не уменьшилось.

Начальные условия розыгрыша:

Кол-во программ-клиентов: 10, Кол-во программистов: 10, Доля от общей области данных (ООД) в одном запросе клиента: 1E-5, Начальное кол-во ошибок: 250, Коэффициент сложности сервера: 2, Интенсивность потока обращений клиента к серверу: 250 (1/сутки), Интенсивность потока исправления ошибки: 1 (1/сутки), Интенсивность внесения ошибки при исправлении: 0,7 (1/сутки), Шаг итерации: 0,002, Кол-во итераций: 50000, Общее время розыгрыша: 100 (сутки); Число розыгрышей:30

Рис.7. – Число розыгрышей:30

Данная модель в сочетание с моделью надежности ПО позволяет оценить количество ошибок в программе следующим образом – получить из модели расчетный результат, а затем с помо0ью розыгрыша подобрать начальное количество ошибок в ПО таким, чтобы результаты розыгрыша совпадали с результатом расчета.

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

Заключение

Создана программа для прогнозирования поведения надежности ПО со временем на основе метода Монте-Карло. Программа позволяет, задавая различные начальные условия, наблюдать поведение надежности ПО во времени. Это позволяет оценивать затраты и ресурсы для построения и сопровождения высоконадежного ПО.

Сочетание двух подходов – модели надежности ПО и прогнозирования при помощи метода Монте-Карло – позволяет более точно и более всесторонне оценить характеристики надежности ПО. В частности, это позволяет найти начальное количество ошибок в ПО.