Количество ошибок в сервер рано количеству ошибок в клиентах * коэффициент сложность /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, то получим:
Начальные условия розыгрыша:
Кол-во программ-клиентов: 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ью розыгрыша подобрать начальное количество ошибок в ПО таким, чтобы результаты розыгрыша совпадали с результатом расчета.
Еще эта модель позволяет решать обратную задачу, то есть, зная количество программистов, интенсивность их работы и интенсивность отказов в начале опытной эксплуатации и в конце опытной эксплуатации можно подобрать количество ошибок в программе такое, чтобы оно совпадало с ними.
Создана программа для прогнозирования поведения надежности ПО со временем на основе метода Монте-Карло. Программа позволяет, задавая различные начальные условия, наблюдать поведение надежности ПО во времени. Это позволяет оценивать затраты и ресурсы для построения и сопровождения высоконадежного ПО.
Сочетание двух подходов – модели надежности ПО и прогнозирования при помощи метода Монте-Карло – позволяет более точно и более всесторонне оценить характеристики надежности ПО. В частности, это позволяет найти начальное количество ошибок в ПО.