litceysel.ru   1 2 3

2.Содержание работы

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

В первой главе «Анализ современных методов повышения надежности ПО» проведен подробный обзор литературы по теме диссертации.

Рассмотрен процесс разработки ПО. Процесс разработки ПО очень важен и сильно влияет на характеристики качества ПО и в первую очередь на его надежность.

Рассмотрены различные подходы к разработке ПО: классическая (водопадная или каскадная), итерационная (эволюционная), экстремальное программирование (ЭП), смешанная. Основное внимание уделяется рассмотрению экстремального программирования как наиболее приемлемого, на мой взгляд, подхода для разработки высоконадежного ПО малого и среднего объема.

В главе дается обзор основных характеристик разработки ПО. Модель разработки ПО представляет собой нахождение оптимального соотношения между следующими 4-мя характеристиками: затраты; время; качество (в том числе и надежность); объем работ.

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

В главе отдельно дается обзор надежности ПО как основной характеристики качества ПО. К основным проблемам исследований надежности ПО относятся:


  • прежде всего - разработка методов оценки и прогнозирования надежности ПО;

  • определение основных факторов, влияющих на надежность ПО;

  • разработка методов, обеспечивающих достижение заданного уровня надежности ПО;

  • совершенствование методов повышения надежности ПО в процессе тестирования и эксплуатации.

В обзоре сравнивается надежность ПО и аппаратуры. Теория надежности аппаратуры частично применима к проблеме надежности ПО.


В обзоре и приложении рассматриваются основные на сегодняшний день модели надежности ПО. В заключение делается вывод, что на сегодняшний день невозможно выбрать наилучшую модель среди десятка предложенных. Большинство вышеприведенных моделей сложны в применении, так как требуют знаний таких характеристик ПО, которые можно вычислить только после длительной его эксплуатации. А в этом случае надежностные характеристики ПО известны и так!

Из-за значительных неопределенностей во всех вышеописанных моделях рекомендуется использовать несколько моделей одновременно и объединить их результаты.

На сегодняшний день можно констатировать: отсутствует общее решение проблемы надежности ПО и есть много частных решений не учитывающие такие существенные факторы как квалификация и число разработчиков ПО. Ни одна из моделей не может считаться достаточной для оценки надежности. Стоит актуальная задача построения более совершенных моделей. Эта задача может быть решена путем рассмотрения комплекса вопросов, в том числе и зависимости надежности ПО по этапам ЖЦ ПО.

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

Во второй главе «Разработка модели надежности ПО на основе Марковских систем массового обслуживания» предлагается модель надежности ПО, основанная на марковской теории систем массового обслуживания (СМО). Постановка задачи: рассмотрим появление и устранение ошибок в программе как марковский процесс гибели и размножения с непрерывным временем и найдем его характеристики. Рассматривается программа с большим количеством ошибок. Интенсивность внесения ошибок в программу в результате доработок, усовершенствований и исправления ошибок равна (t). Каждая внесенная в программу ошибка обнаруживается и исправляется через случайное время T, распределенное по показательному закону с параметром . Рассматривается случайный процесс X(t) – число ошибок в программе в момент времени t.


Далее вычисляются характеристики случайного процесса X(t) для более общего случая, когда и зависят от времени.

Общее решение при начальном условии mx(0) будет:

(1)

В соответствии с условием задачи решать это уравнение нужно при начальном условии mx(0) = X(0) = N – начальное число ошибок в программе.

При постоянных интенсивностях = const и = const уравнение (1) примет вид:

(2)

Далее в главе рассматривается распределение ошибок по этапам жизненного цикла ПО (модель разработки ПО):


  1. Этап проектирования, когда вносится наибольшее число ошибок в ПО и эти ошибки практически не исправляются.

В конце этапа (t - то есть при достаточно большом t) в ПО будет согласно (2) следующее количество ошибок: (3)



Рис. 1 I-й этап: этап проектирования



Рис. 2 II-й этап: этап разработки и кодирования


Рис. 3 III-й этап: этап тестирования




Рис. 4 IV-й этап: этап эксплуатации

  1. Разработка и кодирование. На этом этапе ошибки вносятся, но мало, и они в большинстве своем исправляются.

В конце этапа в ПО будет согласно (2) и начальному условию (3) следующее количество ошибок:

  1. Тестирование. На этом этапе ошибки практически не вносятся, но интенсивно исправляются. Считаем, что начальное условие есть m2(t2) при достаточно большом t (t ), то есть на начальный момент времени третьего этапа было ошибок m3(t=t2) равное 2/2. Тогда из (1) имеем:

  2. Эксплуатация. На этом этапе ошибки появляются очень редко, а исправлять их становится все труднее из-за забывания. Считаем, что начальное условие есть m3(t3) при достаточно большом t (t ), то есть на начальный момент времени четвертого этапа было ошибок m4(t=t3) равное E/3. Тогда из (1) можно найти .

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


Далее делается предположение о распределение ошибок при сопровождении ПО. На основе наших исследований достаточно типичный случай распределения частоты ошибок по этапам сопровождения ПО может быть следующим:



Рис. 5 Распределение числа ошибок ПО при сопровождении

На рисунке: [0, t1[ - интервал установки, наладки, "привыкания" к условиям эксплуатации, обучение пользователей и передача в эксплуатацию;

[t1, t2[ - опытная эксплуатация и обнаружение ошибок в проектировании (т.е. требование не верно реализовано, требование не сформулировано, требование не верно сформулировано);

[t2, t3[ - промышленная эксплуатация без модернизации ПО и вычислительной техники;

t3 - ПО проработало во всех режимах и дальнейшее исправление ошибок не возможно из-за смены поколений.

Решение уравнения (1) дает следующий результат:



Рис. 6 Количество ошибок в ПО в течении ЖЦ

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

Далее рассмотрен случай, когда в эксплуатации находится n однотипных (то есть у всех программ одинаковые i(t) и i(t)) программ. Рассмотрен процесс выхода из строя этих программ, когда в них обнаружена ошибка. И рассмотрен обратный процесс – процесс исправления ошибки в программе и ввода программы в эксплуатацию. Математическое ожидание случайного процесса X(t) – общее число программ, находящихся в работоспособном состоянии будет:




Вероятность 1(t) того, что в момент времени t программа находится в рабочем состоянии, определятся следующим образом:

(4)

где 1(0) – вероятность того, что программа находится в рабочем состоянии в начальный момент времени.

Эту модель можно применить для планирования нагрузки систем, работающих с большими источниками данных. Рассмотрим работу вычислительной системы, в которой работает n программ, функционирующих в режиме «on-line» круглосуточно. Каждая программа в среднем раз в сутки получает данные (независимо от работы остальных программ). Поступающие данные принимаются и обрабатываются свободной программой. Прием данных каждой программой длится случайное время, распределенное по показательному закону с параметром . Считая поток данных для каждой программы простейшим с параметром , определим характеристики случайного процесса X(t) – числа программ, принимающие данные в момент времени t, если в момент времени t = 0 ни одна из программ не принимала данные. Решение:

, где t > 0

Далее в главе рассматривается надежность ПО как СМО с ожиданием. Эта модель более приближенна к реальному положению дел для описания работы группы программистов и представляет собой систему массового обслуживания с ожиданием, в которых заявка, заставшая все каналы занятыми, не получает немедленного отказа, а может стать в очередь и ожидать освобождения канала (в нашем случае программиста), который сможет ее обслужить.

Итак, рассмотрим СМО смешанного типа с ограниченным числом мест в очереди m. Очевидно, что при m = 0 мы получим как частный случай систему с отказами, а при m получим чистую систему с ожиданием. Постановка задачи: в группу из n программистов поступает простейший поток заявок на сопровождение ПО (внесение изменений, дополнений и исправление ошибок) с плотностью (интенсивностью) . Интенсивность простейшего потока выполнения одним программистом заявки равна . Если новая заявка поступает, когда свободен хотя бы один программист, то она принимается на обслуживание и обслуживается до конца (заявки или Заказчик терпеливые). Если заявка застает всех программистов занятыми, она становится в очередь и «терпеливо» ждет своего обслуживания. При этом дисциплина очереди естественная: кто раньше пришел, тот раньше и обслуживается. Максимальное число мест в очереди равно m. Если заявка застает все m мест в очереди занятыми, то она получает отказ и исключается из обслуживания. Причем в данной ситуации нас будет особо интересовать вероятность переполнения очереди, что фактически означает, что группа программистов не справляется с работой. Для простоты будем считать, что каждая заявка может обслуживаться только одним программистом, то есть взаимопомощи между ними нет. Для такой СМО с ожиданием с параметрами n, , , m вычисляются ее характеристики, а также ставятся и решаются задачи линейного программирования для нахождения оптимальных характеристики (количество программистов и ), чтобы получить надежную разработку или сопровождение ПО.


Далее в главе рассматривается надежность ПО как замкнутая СМО для учета того факта, что n программистов обычно обслуживают не одну программу, а m программ. До сих пор мы рассматривали СМО, на которые поступал поток заявок с интенсивностью , причем эта интенсивность не зависела от состояния СМО, а сами источники заявок находились вне системы и нами не рассматривались. Теперь рассмотрим СМО, где интенсивность потока заявок зависит от состояния СМО, а сами источники заявок являются не внешними, а внутренними элементами СМО. К такому типу СМО относится обслуживание m однотипных программ группой из n программистов. Когда в одной из программ обнаруживается ошибка или она нуждается в модернизации вследствие ремонта или модификации ПТС, то эта программа выводится из эксплуатации и отправляется на обслуживание (модернизацию) одному из n программистов (или одной из n групп программистов). Находясь на обслуживании, данная программа перестает быть источником новых ошибок при эксплуатации (то есть перестает подавать заявки на обслуживание). После завершения обслуживания (после исправления ошибки или модернизации и ввода в эксплуатацию) она снова становится источников ошибок (заявок на обслуживание), так как только в процессе эксплуатации ПО или в процессе его тестирования можно обнаружить ошибку. Если ошибка в одной из программ обнаруживается (поступает заявка) в тот момент, когда все n программистов заняты, то такая программа выводится из эксплуатации и становится в очередь.

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

Обозначим через:

  • m – число программ, каждая из которых может в некоторые случайные моменты времени нуждаться в обслуживании;


  •  - интенсивность потока ошибок или модернизаций каждой программы;

  • n – число программистов или групп программистов, которые могут обслуживать программы. Причем, одна программа может обслуживаться одним из n программистов (каналов);

  •  - интенсивность пуассоновского потока обслуживаний программы каждым программистом (каналом). Отметим, что в случае, когда программистами обслуживается m однотипных программ, то во всех формулах нужно заменить на ’ = *m, так как в этом случае исправление ошибки в одной программе она автоматически исправляется и во всех остальных программах. И это является характерной особенностью работы с программами, отличающей их от техники и делающей возможным быстрое исправление ошибок в ПО, несмотря на изначально большое их количество в нем.

Граф состояний системы показан на рисунке:



Рис. 7 Граф замкнутой СМО

На рисунке введены следующие обозначения:

xk – отказало ровно k программ (k = 0, 1, …, n) и все они находятся на обслуживании;

xn+r – отказало n + r программ, из них n обслуживается и r программ ожидает в очереди (r = 1, 2, …, m-n).

Рассматриваем (для простоты) стационарный режим работы системы и = const, = const, t . Для этого графа составляется система уравнений Колмогорова с нулями вместо производных. Решением этой системы будет:

Вероятность того, что в системе будет k (k = 0, 1, …, n) отказавших программ, и все они исправляются:


, где k = 0, 1, …, n;

Вероятность того, что отказало n+r программ, из них n программ исправляется и r (r = 1, 2, …, m-n) программ ожидает в очереди:

, где r = 0, 1, 2, …, mn;



Вероятность того, что все программы работают:

,

где ; ; ; ; ; .

Среднее число программ находящихся на обслуживании (то есть в которых исправляется ошибка или добавляется новая функция):



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


Среднее число программ выведенных из эксплуатации (простаивающих) будет: .


Коэффициент использования (готовности) программ - вероятность того, что определенная (любая) программа в любой момент времени t будет работать: .

Чем больше тем более интенсивнее используются программы и тем менее они простаивают.

 - коэффициент простоя программы (вероятность того, что программа будет простаивать): .

Среднее время безотказной работы программы (наработка до отказа): .

Среднее время простоя программы:

Среднее время обслуживания программы: .

Среднее время ожидания в очереди: .

Поставим и решим задачу линейного программирования: найти оптимальное количество программистов n, при котором среднее количество работающих программ будет больше половины всех программ в системе, т.е. m (двойной запас по надежности).

Приводится пример расчета для практического случая (проект АСКРО):

В начале опытной эксплуатации (m=10, =1 ошибки в день; =1/5 ошибки в день) получаем следующую зависимость (построена с помощью MatLab5):


Рис. 8 График зависимости количества работающих программ от количества программистов в начале опытной эксплуатации (по горизонтальной оси отложено количество программистов, обслуживающих программы, а по вертикальной оси – количество работающих программ)


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

В начале промышленной эксплуатации (m=10, =1/30 ошибки в день; =1/5 ошибки в день) получаем:



Рис. 9 График зависимости количества работающих программ от количества программистов в начале промышленной эксплуатации

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

Далее в главе рассмотрен метод динамики средних в применении к надежности ПО для уточнения модели для программ-клиентов к программных системах типа клиент-сервер. С помощью метода динамики средних построена марковская модель поведения программы состоящей из многих (примерно однотипных) модулей. Характерной особенностью такой системы является запуск сервером параллельных однотипных потоков, каждый из которых обслуживает запросы одной программы-клиента или работа сервера со многими однотипными клиентскими программами. В этом случае потоки или программы-клиенты полностью идентичны и каждый из них может выходить из строя независимо от остальных. Особенностью этой системы в отличие от систем рассматриваемых в теории массового обслуживания (например, обслуживание ремонтной бригадой автомобиля, или однотипных вычислительных комплексов) заключается в том, что при выходе из строя (обнаружении ошибки) в одном модуле (потоке или клиенте) и устранении этой ошибки, эта ошибка автоматически устраняется и во всех других модулях (потоках), так как эти потоки размножаются путем запуска на выполнение одного и того же кода программы. Учтем эту особенность при применении метода динамики средних. При этом временем на замену модуля с ошибкой на исправленный модуль мы пренебрегаем.


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

Итак, процесс работы клиент-серверного ПО зависит от количества исправленных в ней до этого ошибок. То есть от интенсивности потоков событий, переводящих элемент из состояния в состояние, зависят от того сколько элементов было в системе в данном состоянии. Чем большее количество раз ПО было на доработке (исправление ошибок в нем), тем меньше поток ошибок в будущем. Считаем, что ошибки исправляются корректно, то есть при исправлении не вносятся новые ошибки или вносятся, но гораздо реже, чем исправляются. При этом уменьшается интенсивность потока событий, переводящий каждый элемент (модуль или поток или процесс) ПО из состояния «исправен» (работоспособен) в состояние «неисправен».

Каждый из элементов (модуль или поток одного модуля)может быть в одном из двух состояний: 1 – работоспособен (работает); 2 – не рабочий (обнаружена ошибка и исправляется).

На каждый модуль действует поток ошибок с интенсивностью , которая зависит от количества исправленных ранее в модуле ошибок. Каждый неисправный элемент исправляется в среднем со скоростью в единицу времени. В начальный момент (t = 0) все элементы (модули) исправны. Все потоки событий – пуассоновские (может быть с переменной интенсивностью). Напишем уравнения динамики средних для средних численностей состояний. Граф состояний одного модуля имеет вид, представленный на рисунке:




Рис 10 Граф состояния модуля

Здесь ` - интенсивность потока ошибок в зависимости от предыдущих исправлений.

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



Рис. 11 Интенсивность потока ошибок

Для упрощения предположим, что ` обратно пропорционально m числу модернизаций модуля, то есть убывает по гиперболическому закону: . (5)

На основе графа (см. рис. 10) дифференциальные состояния динамики средних запишутся в виде:

(6)

где m1(t), m2(t) – средние численности состояний 1 и 2.

Из этих двух уравнений можно выбрать одно – например, второе, а первое отбросить. Во второе уравнение подставим выражение для m1(t) из условия: m1(t) + m2(t) = N.


Тогда получим вместо системы уравнений (6) одно дифференциальное уравнение:



Из предположения (5) имеем:

При этом количество модернизаций m зависит от интенсивности исправления модуля и количества программистов (или групп программистов) P работающих над исправлением модулей. Предположим, что: m = Pt

Окончательно получим уравнение для m2(t):



Решать это уравнение нужно при начальном условии m2(t=0) = 0 численными методами.

Это уравнение было решено с помощью пакета математических программ MatLab 6.5 методом Рунге-Кутта (функция ode45) и получен следующий результат для условий задачи:

= 0,2 раза в сутки исправляется одна ошибка одним программистом;

0 = 10 раз в сутки в программе обнаруживаются ошибки в начальный момент времени;

P = 3 – количество программистов (или групп программистов), исправляющих ошибки с интенсивностью каждый;

N = 10 – количество модулей (потоков или клиентов) в ПО:



Рис. 12 Решение для гиперболической зависимости

Пояснения к рисунку: Непрерывная линия – m2(t) – число неработающих модулей; Прерывистая линия – m1(t) – число работающих модулей.

Из рисунка видно, что количество работающих модулей превысит количество неработающих модулей на 7 сутки. С этого момента можно считать, что ПО работает устойчиво. Если бы изначально 0 = 100, то при тех же остальных начальных условиях программа начала устойчиво работать только на 85 сутки.

Для экспоненциальной зависимости: (7)

(см. рис. 11) получаем решение, которое быстрее приводит к устойчивой работе ПО. Для 1 = 0,1 получаем решение, показанное на рисунке:



Рис. 13 Решение для экспоненциальной зависимости

Пояснения к рисунку: Непрерывная линия – m2(t) – число неработающих модулей; Прерывистая линия (точка тире) – m1(t) – число работающих модулей; Прерывистые линии (редкие точки) – представление поведения кривой при отсутствии зависимости - особенности присущей ПО. Видно, что в этом случае изменения со временем происходят гораздо медленнее.

Из рисунка видно, что количество работающих модулей превысит количество неработающих модулей на 3 сутки. С этого момента можно считать, что ПО работает устойчиво. Если бы изначально 0 = 100, то при тех же остальных начальных условиях программа начала устойчиво работать только на 7 сутки, что гораздо быстрее, чем при гиперболической зависимости (5). Из практики можно сделать вывод, что зависимость (7) более отвечает действительности, чем зависимость (5).

В технике, где не пропорционально N, при заданных начальных условиях вся техника была бы неисправна уже на первые сутки и никогда бы не была приведена в исправное состояние. Поэтому, не смотря на то, что ПО в начале эксплуатации (или тестирования) содержит большое количество (гораздо больше, чем в технике) ошибок с большой интенсивностью их проявления, ошибки в ПО быстро исправляются и очень быстро ПО становится устойчивым. Это происходит из-за очень быстрого исправления ошибок по сравнению с техникой.


Именно такая картина, на мой взгляд (см. рис. 13) наиболее верно отражает реальное поведение надежности ПО от времени.

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

Рассмотрим ПО S, состоящее из большого количества N одинаковых клиентских программ и одного сервера, который координирует работу всех клиентских программ. Как сервер, так и отдельные клиенты могут отказывать (зависать). Опишем процесс, протекающий в ПО с помощью уравнений смешанного типа, в которых неизвестными функциями будут: вероятности состояний сервера; средние численности состояний клиентов. Опишем нашу систему при помощи графа, показанного на рисунке:




Рис. 14 Граф смешанной системы

Этот граф распадается на два подграфа. Первый (верхний) – это подграф состояний сервера, который может быть в одном из двух состояний:

C(t) – работает; С’(t) – не работает (ошибка обнаружена и исправляется).

Что же касается программы-клиента, то для нее мы учитываем возможность находиться в одном из трех состояний: П1С(t) – клиент работает при работающем сервере; П2С(t) – клиент не работает при работающем сервере; П2С’(t) – клиент не работает при не работающем сервере;

Состояние сервера характеризуется в момент времени t одним из событий C(t) и C’(t). Вероятности этих событий обозначим через p(t) и p’(t) = 1 – p(t), а численности состояний П1С(t), П2С(t) и П2С’(t) соответственно: X1С(t), X 2С(t) и X 2С’(t).

Соответствующие математические ожидания обозначим как:


Для графа (см. рис. 14) написаны и численными методами решены уравнения Колмогорова. Решение вышеизложенной модели было проведено с помощью пакета MatLab6.5 (функция ode15s) методом Рунге-Кута.


Получены следующие результаты(для следующих начальных условий S = 3 – коэффициент сложности сервера; N = 10 – число программ-клиентов; 0 = 10 ошибок/день; P = 3 – количество программистов; 0 = 0,5 ошибок/день):




Рис. 15 p и p'

Из рисунка видно, что сервер начнет устойчиво работать на 8 сутки.




Рис. 16 m1C, m2C, m2C'

Из рисунка видно, что клиенты начнут устойчиво работать на 4 сутки.

Если количество программ-клиентов увеличить с 10 до 100, то результаты практически не изменятся или выход на устойчивую работу произойдет даже быстрее. Если же число программистов уменьшить с 3-х человек до одного, то сервер начнет устойчиво работать на 14 сутки, а клиенты – на 10 сутки.

В третьей главе «Исследование путей повышения надежности ПО на основе предложенной модели ПО» предложен и экспериментально исследован алгоритм моделирования надежности ПО. Постановка задачи: Основной проблемой нахождения надежности ПО при помощи многих моделей надежности является необходимость знать начальное количество ошибок в ПО. К сожалению, предложенная модель надежности не позволяет найти эту величину. Она вообще не использует ее, что является ее преимуществом перед другими моделями. Тем не менее, получаемые при использовании этой модели результаты хорошо согласуются с практикой. Поэтому можно попытаться воспользоваться этими результатами для нахождения N0 – начального количества ошибок в программе методом обратного расчета. Это позволит воспользоваться и другими моделями надежности. Также такая программа моделирования позволит найти такие характеристики надежности ПО, как время до следующего отказа, его вероятность и время достижения нужной надежности при заданных начальных условиях. Также такая программа моделирования позволит исследовать пути повышения надежности ПО, варьируя один из имеющихся в распоряжении разработчиков ресурс, такой как количество программистов, скорость устранения ошибок, скорость внесения ошибок, время тестирования и интенсивность тестирования.


Предлагается следующий вариант решения этой задачи: с учетом ранее полученных результатов о характере поведения надежности ПО от времени (распределение Пуассона; смешанная модель типа клиент-сервер, когда сервер неисправен, то клиенты простаивают: одновременное исправление ошибки во всех клиентах при исправлении ошибки в каком-либо одном клиенте) написать программу моделирования поведения надежности ПО (моделирующую процесс обнаружения ошибок в ПО и устранения ошибок) и с ее помощью подбирать N0 таким образом, чтобы конечные надежностные характеристики ПО совпадали с результатами, получаемыми при помощи ранее предложенной модели надежности.

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

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

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




Рис. 17 Распределение запросов k-го клиента на области данных

Для моделирования потоков гибели и размножения ошибок в ПО применяется метод Монте-Карло.

Входными данными для розыгрыша являются: P – количество программистов, обслуживающих систему; K - количество программ-клиентов; - ширина одного запроса клиента как доля от ООД (от 0 до 1, где 1 – это вся ООД); t - шаг итерации (сутки); s - коэффициент сложности сервера по сравнению с программой-клиентом; обр - интенсивность потока обращений одного клиента к серверу (1/сутки); испр - интенсивность потока исправления ошибки одним программистом (1/сутки); внес - интенсивность внесения ошибки при исправлении одним программистом (1/сутки) или pвнес – вероятность внести ошибку при исправлении одним программистом; M - количество итераций; К – количество розыгрышей для усреднения; Er - начальное количество ошибок.

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




Рис. 18 Влияние количества программистов на надежность - вариант 1

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

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


Получены следующие результаты (средние значения за все 50 розыгрышей):



Рис. 19 Влияние количества программистов на надежность - вариант 2

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

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


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

При помощи программы моделирования и модели определяется начальное количество ошибок в программе.



<< предыдущая страница   следующая страница >>