Смекни!
smekni.com

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

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

В результате разыгрывается M итераций согласно п. 3, и получаем одну реализацию случайных функций

,
,
и
(согласно 3а) на временном интервале M*Dt.

Испытания проводим еще R раз и таким образом получаем R реализаций случайных функций

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

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

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

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

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

Расчет коэффициента готовности: Кг = 1 – < время простоя всей программы > / < время работы >

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

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

3.3.1 Оценка времени, необходимого для уменьшения количества ошибок до расчетного уровня.

Найдем время необходимое для уменьшения количества ошибок в 2 раза. Пусть (рис.17):

K (кол-во программ-клиентов) = 10;

P (кол-во программистов) = 3;

a (ширина запроса клиента) = 0,0001;

N0 (начальное количество ошибок) = 100;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,001 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 100/сутки;

lиспр (интенсивность потока исправления ошибки) = 0,2/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,005

M (количество итераций) = 200000;

Общее время розыгрыша: 200 (сутки);

К (число розыгрышей) =5.

По формуле (27) получаем:

дня, что является очень оптимистичной оценкой. Для этой модели надежности Джелински, Моранда, Шумана получаем
лет, что явно сильно завышено. Программное моделирование дает результат T1/2 = 135 суток (рис.18).

Рисунок 17 – Форма для ввода начальных параметров розыгрыша

Рисунок 18 – Форма с результатами моделирования

3.3.2 Влияние количества клиентов на надежность ПО

Изучим влияние количества программ–клиентов на поведение ПО.

Сначала проведем моделирование при следующих условиях:

K (кол-во программ-клиентов) = 10;

P (кол-во программистов) = 3;

a (ширина запроса клиента) = 0,00001;

N0 (начальное количество ошибок) = 250;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,002 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 500/сутки;

lиспр (интенсивность потока исправления ошибки) = 1/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,1/сутки

M (количество итераций) = 50000;

Общее время розыгрыша: 100 (сутки);

К (число розыгрышей) =50

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

Рисунок 19 – Влияние количества клиентов на надежность ПО (10 клиентов)

Из рисунка видно, что ПО начнет устойчиво работать (т.е. количество работающих клиентов сравняется с количеством неработающих клиентов) на 15 сутки, что хорошо согласуется с расчетной моделью. Теперь увеличим количество клиентов с 10 до 100:

K (кол-во программ-клиентов) = 100;

P (кол-во программистов) = 3;

a (ширина запроса клиента) = 0,00001;

N0 (начальное количество ошибок) = 250;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,002 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 500/сутки;

lиспр (интенсивность потока исправления ошибки) = 1/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,1/сутки

M (количество итераций) = 85000;

Общее время розыгрыша: 170 (сутки);

К (число розыгрышей) =50

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

При десяти клиентах (рис.19) в ПО на 170 сутки еще будет оставаться около 50 ошибок.

Рисунок 20 – Влияние количества клиентов на надежность ПО (100 клиентов)


3.3.3 Влияние количества программистов на надежность ПО

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

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

K (кол-во программ-клиентов) = 10;

P (кол-во программистов) = 12;

a (ширина запроса клиента) = 0,00001;

N0 (начальное количество ошибок) = 250;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,002 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 500/сутки;

lиспр (интенсивность потока исправления ошибки) = 1/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,1/сутки

M (количество итераций) = 50000;

Общее время розыгрыша: 100 (сутки);

К (число розыгрышей) =50

Рисунок 21 – Влияние количества программистов на надежность ПО

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

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

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

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

K (кол-во программ-клиентов) = 10;

P (кол-во программистов) = 12;

a (ширина запроса клиента) = 0,00001;

N0 (начальное количество ошибок) = 250;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,002 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 500/сутки;

lиспр (интенсивность потока исправления ошибки) = 1/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,6/сутки

M (количество итераций) = 50000;

Общее время розыгрыша: 100 (сутки);

К (число розыгрышей) =50

Рисунок 22 – Влияние количества программистов на надежность ПО

Из рис.22 видно, что за 100 дней работы системы количество ошибок практически не уменьшилось.

3.3.4 Влияние интенсивности обращений клиентов к серверу

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

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

K (кол-во программ-клиентов) = 10;

P (кол-во программистов) = 3;

a (ширина запроса клиента) = 0,00001;

N0 (начальное количество ошибок) = 250;

s (сложность сервера) = 2;

Dt (шаг итерации) = 0,0004 (сутки);

lобр (интенсивность потока обращений клиента к серверу) = 2500/сутки;

lиспр (интенсивность потока исправления ошибки) = 1/сутки;

pвнес (вероятность внесения ошибки при исправлении) = 0,1/сутки

M (количество итераций) = 250000;

Общее время розыгрыша: 100 (сутки);

К (число розыгрышей) =10

3.3.5 Определение начального количества ошибок в ПО