Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Моделирование надежности программного обеспечения
Автор:
Ханджян А.О.
Имеется программный комплекс (ПК) типа клиент-сервер. Сервер обслуживает запросы от N клиентов. В ПК равномерно по области определения входных данных (ООД) (A, B) расположены Er ошибок. Сервер сложнее клиентов с точки зрения разработки ПК в S раз. S – коэффициент сложности сервера по отношению к клиентам. Каждый k-ый (k = 1, 2, …, N) клиент порождает пуассоновский поток данных к серверу интенсивностью обр. Данные от клиента распределены по области определения данных (ООД) по нормальному закону с характеристиками mk и k, где mk распределено между клиентами равномерно по всей области входных данных, 3k – распределено равномерно на меньшем из участков отсекаемых mk на оси области данных (это нужно для имитации неравномерности использования ООД при малом количестве клиентов).
На запрос клиента сервер отвечает данными, которые распределены равномерно по всей области определения данных (A, B).
На рисунке (см. Рисунок 1 – «Распределение запросов k-го клиента на области данных») изображено распределение запросов одного клиента по области всех возможных запросов к серверу, а также показано равномерное распределение ошибок по ООД. При попадании запроса клиента или ответа сервера в область ООД, содержащую ошибку, считается, что ошибка обнаружена и соответствующий модуль выводится из эксплуатации для ее исправления:
Рисунок 1 – «Распределение запросов k-го клиента на области данных»
Входными данными для розыгрыша являются:
P – количество программистов, обслуживающих систему;
K - количество программ-клиентов (далее просто клиенты);
- ширина одного запроса клиента как доля от ООД (от 0 до 1, где 1 – это вся ООД);
t - шаг итерации (сутки);
s - коэффициент сложности сервера по сравнению с программой-клиентом;
обр - интенсивность потока обращений одного клиента к серверу (1/сутки);
испр - интенсивность потока исправления ошибки одним программистом (1/сутки);
внес - интенсивность внесения ошибки при исправлении одним программистом (1/сутки) или
pвнес – вероятность внести ошибку при исправлении одним программистом;
M - количество итераций;
К – количество розыгрышей для усреднения;
Er - начальное количество ошибок.
В программе также есть возможность оценить первоначальное количество ошибок по следующему алгоритму: Принимаем ООД за единицу. Каждый клиент в запросе генерирует долю от ООД. За время t клиент обратиться к серверу (t * обр) раз. За время t все клиенты обратятся к серверу (t * обр * K) раз. И объем данных, который будет затронут в ООД при этом равен (t * обр * K * ). Так как в нашей модели ошибки распределены равномерно по ООД, то за время t будет обнаружено (t * ош), где ош – первоначальная интенсивность ошибок в системе. Если бы за время t клиенты затронули всю ООД, то было бы обнаружены все Er ошибок. Поэтому можно записать следующую пропорцию: . Отсюда находим Er: . При этом считаем, что каждый из K клиентов обратился к серверу с запросом с данными непересекающимися в ООД. Но на самом деле это не так, т.к. чаще сего клиенты обращаются к серверу с однотипными запросами, поэтому полагаем K = 1. И тогда окончательная формула для оценки первоначального количества ошибок будет: ;
Программа предупреждает, если задается интенсивность такая, что на интервал времени t приходится больше одного события (т.е (t * ) должно быть меньше единицы) – для соблюдения условия ординарности потока событий.
При одном розыгрыше выполняются следующие шаги:
Количество ошибок в сервер рано количеству ошибок в клиентах * коэффициент сложность /10.
Изучим влияние количества программ-клиентов на поведение программной системы клиент-сервер (далее ПС или ПК).
Розыгрыш проводился при следующих начальных условиях (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, то получим:
Начальные условия розыгрыша:
Кол-во программ-клиентов: 10, Кол-во программистов: 12, Доля от общей области данных (ООД) в одном запросе клиента: 1E-5, Начальное кол-во ошибок: 250, Коэффициент сложности сервера: 2, Интенсивность потока обращений клиента к серверу: 500 (1/сутки), Интенсивность потока исправления ошибки: 1 (1/сутки), Интенсивность внесения ошибки при исправлении: 0,1 (1/сутки), Шаг итерации: 0,002, Кол-во итераций: 50000, Общее время розыгрыша: 100 (сутки); Число розыгрышей:50
Рис.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ью розыгрыша подобрать начальное количество ошибок в ПО таким, чтобы результаты розыгрыша совпадали с результатом расчета.
Еще эта модель позволяет решать обратную задачу, то есть, зная количество программистов, интенсивность их работы и интенсивность отказов в начале опытной эксплуатации и в конце опытной эксплуатации можно подобрать количество ошибок в программе такое, чтобы оно совпадало с ними.
Создана программа для прогнозирования поведения надежности ПО со временем на основе метода Монте-Карло. Программа позволяет, задавая различные начальные условия, наблюдать поведение надежности ПО во времени. Это позволяет оценивать затраты и ресурсы для построения и сопровождения высоконадежного ПО.
Сочетание двух подходов – модели надежности ПО и прогнозирования при помощи метода Монте-Карло – позволяет более точно и более всесторонне оценить характеристики надежности ПО. В частности, это позволяет найти начальное количество ошибок в ПО.