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ью розыгрыша подобрать начальное количество ошибок в ПО таким, чтобы результаты розыгрыша совпадали с результатом расчета.

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


Заключение

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

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


Информация о работе «Моделирование надежности программного обеспечения»
Раздел: Информатика, программирование
Количество знаков с пробелами: 13653
Количество таблиц: 0
Количество изображений: 6

Похожие работы

Скачать
104437
5
35

... первоначальное количество ошибок можно оценить как: Поставленная задача позволяет определить такие важные характеристики функционирования программного комплекса, как: расчет текущего времени наработки до отказа; расчет среднего времени наработки до отказа за все время моделирования работы системы; расчет вероятности отказа ПО в единицу расчёт коэффициента готовности Таким образом, наша ...

Скачать
149178
9
8

... реализации заложена в основу написания данной программы. В ходе выполнения данного дипломного проекта была разработана программа управления автоматизированным комплексом многоканальной связи. Предъявленные в техническом задании к проекту требования выполнены полностью: программное обеспечение для процессора АТ89С51 разработано в соответствии с общим алгоритмом ПО изделия ТС16Е1, ОЗУ данных ...

Скачать
33151
0
1

... программирования, и в целом изменилось отношение к требованиям, гарантирующим более высокое качество.   1990-1999 гг. Следующее "решение" проблемы качества программного обеспечения появилось в 90-х годах под названием "совершенствование процесса разработки программ". Основой этого движения была теперь популярная и часто критикуемая модель Capability Maturity Model. Для краткости упростим ...

Скачать
110938
1
10

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

0 комментариев


Наверх