Повышение надежности программного обеспечения информационно-измерительных и управляющих систем безопасности ядерных радиационно-опасных объектов

Ханджян, Аркадий Олегович

автореферат диссертации по приборостроению, метрологии и информационно-измерительным приборам и системам, 05.11.16, диссертация на тему:Повышение надежности программного обеспечения информационно-измерительных и управляющих систем безопасности ядерных радиационно-опасных объектов

кандидата технических наук: Ханджян, Аркадий Олегович
город: Москва
год: 2006
специальность ВАК РФ: 05.11.16

Диссертация по приборостроению, метрологии и информационно-измерительным приборам и системам на тему «Повышение надежности программного обеспечения информационно-измерительных и управляющих систем безопасности ядерных радиационно-опасных объектов»

Автореферат диссертации по теме "Повышение надежности программного обеспечения информационно-измерительных и управляющих систем безопасности ядерных радиационно-опасных объектов"

На правах рукописи

Ханджян Аркадий Олегович

ПОВЫШЕНИЕ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННО-ИЗМЕРИТЕЛЬНЫХ И УПРАВЛЯЮЩИХ СИСТЕМ БЕЗОПАСНОСТИ ЯДЕРНЫХ РАДИАЦИОННО-ОПАСНЫХ ОБЪЕКТОВ

Специальность 05.11.16 - «Информационно-измерительные и управляющие системы»

(промышленность)

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Москва - 2006

Работа выполнена в НИЦ «СНИИП».

Научный руководитель - доктор технических наук Сергей Борисович Чебышов.

Официальные оппоненты:

доктор технических наук, профессор Там аз Георгиевич Самхарадзе кандидат технических наук Павел Александрович Бусаров

Ведущая организация - РНЦ «Курчатовский институт»

Защита состоится «19» октября 2006 г. в 11 час. 30 мин. на заседании диссертационного совета Д.201.005.01 при ФГУП Научно-Инженерном Ишконорныи Центре «СНИИП» в зале НТС по адресу: 123060 г. Москва, ул. Расплетина, 5.

С диссертацией можно ознакомиться в научно-технической библиотеке ФГУП НИЦ «СНИИП» (тел 198-41-35)

Автореферат разослан « 200 г

Ученый секретарь диссертационного совета

кандидат технических наук Хазанов Д.Б.

1. ОСНОВНЫЕ ПОЛОЖЕНИЯ Актуальность исследования

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

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

В связи с этим можно выделить несколько основных показателей, оказывающих существенное влияние на надежность ПО:

- сложность радиационно-опасных объектов с точки зрения формализации описания алгоритмов их функционирования;

- неповторимость и уникальность ПО для конкретных РОО;

- нечеткая формализация заказчиком требований к программной автоматизации технологических процессов конкретного РОО;

- неточное понимание разработчиком ПО требований заказчика;

- выявление проектных ошибок на поздних этапах создания объекта и как следствие необходимость корректировки ПО;

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

- появление новых непроверенных технологий программирования, стандартов и инструментов разработки программ, быстрое устаревание существующих ОС, технологий, библиотек программ и инструментов программирования;

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

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

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

Цели и задачи диссертации

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

- изучены существующие модели надежности ПО и методы разработки надежного ПО;

- построена новая математическая модель надежности ПО, адаптированная для адекватной оценки влияния характеристик ПО на надежность (таких как одна программ, много программ, система типа клиент-сервер);

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

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

- результаты моделирования сравнены с надежностными характеристиками реального ПО при его тестировании и эксплуатации.

Объект исследования. Программное обеспечение систем важных для безопасности РОО и ЯУ.

Предмет исследования. Характеристики надежности программного обеспечения радиационно-опасных объектов.

Методологические и теоретические основы исследования. Метод исследования. Изучение существующих моделей надежности программного обеспечения, методов разработки надежных программ. Построение модели надежности, основанной на теории массового обслуживания. Моделирование поведения программного продукта в процессе тестирования и эксплуатации. Проверка достоверности модели на практике при разработке и эксплуатации реальных программных систем. Теоретической основой для построения модели является теория массового обслуживания, теория вероятностей и методы разработки программного обеспечения, международные и отечественные стандарты по программному обеспечению. Основополагающими трудами в этих областях являются труды Майерса Г., Шеннона К., Маркова A.A., Колмогорова А.Н., Котельникова В.А., Вентцель Е.С., Овчарова Л.А., Липаева В.В. В качестве метода исследования выбран метод Монте-Карло. Базой для исследования является разрабатываемые в НИЦ «СНИИП» под руководством Чебышова С.Б., Зорина A.B., Бурьяна В.И., Книжника A.C., Черкашина И.И., Рыжова Н.В. и в Российском Научном Центре «Курчатовский институт» под руководством Митина В.И. системы автоматизации радиационного контроля ядерных объектов, системы внутриреакторного контроля и системы контроля, управления и диагностики ядерных объектов.

Информационная база исследования

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

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

- поставлены и решены задачи линейного программирования оценки оптимальных ресурсов для создания и сопровождения надежных программных систем;

- разработана методология анализа надежности ПО как процесс возникновения и устранения ошибок в ПО на всех этапах жизненного цикла ПО;

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

Личный вклад

При выполнении диссертационной работы автором были сформулированы задачи исследований, проведен обзор, разработана модель надежности, разработана алгоритм и программа прогнозирования надежности. Результаты исследований были апробированы автором при создании и сопровождении ПО для АСКРО, программы диагностики ПТС, СПО ПТС, испытаниях ПТС.

Практическая значимость работы

Результаты выполненных исследований могут быть использованы при построении ответственных программных систем применяемых на ядерных радиационно-опасных объектах, для прогнозирования и оценки надежности ПО и при расчете надежности систем в целом, а именно СВРК, СКУД, АСКРО, АСРК для разработки и эксплуатации малых и средних программных комплексов.

Апробация результатов исследования

Основные положения и результаты диссертационной работы были опробованы и применены:

- при разработке и эксплуатации автоматизированной системы радиационного контроля Волгодонской АЭС;

- при разработке автоматизированной системы радиационного контроля НИЦ «СНИ-

ИП»;

- при разработке, испытаниях и эксплуатации системного программного обеспечения

щюграммно-технических средств СВРК и СКУД АЭС Козлодуй (Болгария), Моховце (Словакия), Тяньвань (Китай), Бушер (Иран), Балаково, Калинин, Волгодонск (Россия).

- при разработке и эксплуатации диагностической программы ПТС серии ПАМИР;

- при руководстве лабораторией разработки программных средств для определения оптимальных ресурсов, необходимых для разработки и сопровождения ПО;

- при участии в разработке новой редакции стандарта «IEC 62138 Ed.l: Nuclear power plants - Instrumentation and control for systems important to safety - Software for computer-based I&C systems supporting category В or С functions» в качестве эксперта комиссии 45А МЭК.

Где и когда докладывались и публиковались основные результаты работы- см. список публикаций.

Перечень базисных положений, выносимых на защиту:

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

- Рассмотрены существующие на сегодняшний день модели надежности ПО. Необходимо разработать новую более простую и комплексную модель надежности для малых и средних программ (до 100 тысяч строк, участие 2-10 программистов), так как существующие модели либо слишком сложны, либо учитывают только одну из сторон разработки ПО, часто основанной на объеме текста программ и начальном количестве ошибок.

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

- Изучено распределение ошибок по этапам ЖЦ и делается вывод по оптимальному распределению времени для разработки высоконадежного ПО. Рассчитаны оптимальные ресурсы для разработки и сопровождения надежного ПО.

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

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

Структура и объем диссертаиионной работы

Диссертация состоит из введения, четырех глав, библиографического списка, включающего 56 наименования, трех приложений. Работа изложена на 157 страницах с 70 рисунками и 106 пронумерованными формулами.

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

В главе 2 описывается построение новой модели надежности ПО, созданной на основе

марковской теории массового обслуживания.

В главе 3 проводится исследование путей повышения надежности ПО на основе предложенной модели надежности ПО, предлагается алгоритм моделирования поведения надежности ПО от времени, приводятся результаты моделирования.

В главе 4 делаются основные выводы и заключение по итогам работы.

В приложениях приводятся листинги программ и обзор существующих модели надежности ПО.

2. СОДЕРЖАНИЕ РАБОТЫ

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

В первой главе «Анализ современных методов повышения надежности

ПО» проведен подробный обзор литературы по теме диссертации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О)

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

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

mJt) = — -(l-«Г"'(2)

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

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

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

fh

ад м<<) ад

Х.аввп!

ООП*

«МП-со*»

1 ц «

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

ад, СО) к,-ей« ад и» ц^ • Г тт для упрощч—1 решай им V 1КЯМ0 «зять »«(1) -|-

1 « Рис. 3 Ш-й этап: этап тестированиа « Рис. 41У-й этап: этап эксплуатации

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

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

ошибок: т2 (г) =&. (1 _ )+А. )

М2 Мх

3. Тестирование. На этом этапе ошибки практически не вносятся, но интенсивно исправляются. Считаем, что начальное условие есть тгО?) при достаточно большом / (г ос), то есть на начальный момент времени третьего этапа было ошибок т3(^2) равное А//^. Тогда из (1)

имеем: от3(0 = е"Л<'~'2)-

-. _ 1)+ Л. -1)+ ¿2.

.Ръ-й Мз Иг.

4. Эксплуатация. На этом этапе ошибки появляются очень редко, а исправлять их становится все труднее из-за забывания. Считаем, что начальное условие есть тзрз) при достаточно большом Г (/ ос), то есть на начальный момент времени четвертого этапа было ошибок т^^з) равное Е/цз. Тогда из (1) можно найти т4(Г).

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

_ 1 , ((м л}/(„ Л^

для уменьшения количества ошибок в два раза равно: Г. ----1п---1/17/--

2 М 2 »)/ \ ц

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

Рис. 5 Распределение числя ошибок ПО при сопровождении На рисунке: [0, //[ - интервал установки, наладки, "привыкания" к условиям эксплуатации, обучение пользователей и передача в эксплуатацию;

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

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

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

т,(()« 0,(1)

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

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

Далее рассмотрен случай, когда в эксплуатации находится п однотипных (то есть у всех программ одинаковые Л,/¡г) и /л(0) программ. Рассмотрен процесс выхода из строя этих программ, когда в них обнаружена ошибка. И рассмотрен обратный процесс - процесс исправления ошибки в программе и ввода программы в эксплуатацию. Математическое ожидание случайного процесса Х(г) — общее число программ, находящихся в работоспособном состоянии будет:

М[Х(Щ = «•«,(/)

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

а,(0 = ехр[ - |(и(х) + А(х))Л •

V о ,

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

Эту модель можно применить для планирования нагрузки систем, работающих с боль-

|Л(/).ехЛ |Си(г) + А(г)>/г

о V«

<£с + а,(0)

(4)

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

тх (0 = п • Я • (l - е_0,+Д)' )l(ji + Я) , где / > О

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

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

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

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

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

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

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

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

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

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

_ тд. __(т-и-им_(т-*м __(т-лД___

Г I у I [ I_у" I у I I ' I у -1_и ■ I

— К-И N □ — кгьпч —

I-г I-1 I-г I__1> I_I I_г-1___г-1_I

и" п>/' пц'

Рис. 7 Граф замкнутой СМО На рисунке введены следующие обозначения:

хк - отказало ровно к программ (к - 0, 1, ..., и) и все они находятся на обслуживании; х„+г — отказало п + г программ, из них п обслуживается и г программ ожидает в очереди (г = 1, 2, ..., т-п).

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

производных. Решением этой системы будет:

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

т! (лУ к В(т,к,р) , ' , Л

Рк =—-77Г — 'Ро=с»'а ■Ро^-^—^-Ро.глек^О, 1.....п; сс= —

к\(т-к)\ ) ц ц

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

Р»+г =-р/п ч р/-г--Ро»гдег-0, 1, 2, ..., т — п, Р(т,а)=—е

Р(Ъ,п)-Р(т,х) т\

П' и* п X = -Я а

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

_1_

Ро Л(т,п,р) | f(^J>n).^г(WI-я-l>^), д" Р(0,п)'Р(т,х)

к

*=0 *=0 *-0 *-0 В(т,к,р) = Скт.рк-ч-к-,д = \-р;р = -^;Скт=- т!

1 + а к\(т — к)\

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

Я" & Р{0,п)-Р{т,Х)

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

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

7 = к+г.

Коэффициент использования (готовности) программ 4 " вероятность того, что определенная (любая) программа в любой момент времени г будет работать: ^ = 1 ——.

т

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

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

т

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

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

4 Л т-1

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

- - - 1 1

Среднее время ожидания в очереди: /0„ = /„ - /= — ----.

Л £ м'

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

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

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

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

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

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

ЮШШБ

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

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

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

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

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

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

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

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

¡ь

Рис 10 Граф состояния модуля Здесь Л* - интенсивность потока ошибок в зависимости от предыдущих исправлений. Найдем Л * от числа предыдущих исправлений этого модуля. Выскажем предположение, что Я' падает с количеством исправленных ошибок до некоторого постоянного значения нечув-

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

Рис. 11 Интенсивность потока ошибок Для упрощения предположим, что Л' обратно пропорционально т числу модернизаций

3

модуля, то есть убывает по гиперболическому закону: Я'= . (5)

т + \

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

• Л (6) = О + ЛЧС)

ш

где от; (У, т»2(0 - средние численности состояний и <£?.

Из этих двух уравнений можно выбрать одно — например, второе, а первое отбросить. Во второе уравнение подставим выражение для гп](1) из условия: т](0 + г»2(0 = N.

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

= + Х'-Ы - Л'-/л2(0 = + Л') • /и2(0 + А'-ЛГ

Ш

Из предположения (5) имеем: = -{/и-И + ) • т2(/) + ^ • N

ш V т + \) т + 1

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

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

Л V + 2 ц-Р'1 +1

Решать это уравнение нужно при начальном условии гп2&=0) = 0 численными методами. Это уравнение было решено с помощью пакета математических программ МаЛаЬ 6.5 методом Рунге-Кутга (функция ос!е45) и получен следующий результат для условий задачи: ц — 0,2 раза в сутки исправляется одна ошибка одним программистом;

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

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

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

Пояснения к рисунку: Непрерывная линия — — число неработающих модулей; Прерывистая линия - ггц(0 - число работающих модулей.

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

Для экспоненциальной зависимости: Я'= ^ -е'"4 + Я, (7)

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

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

Пояснения к рисунку: Непрерывная линия - т2(0 - число неработающих модулей; Прерывистая линия (точка тире) - т^) - число работающих модулей; Прерывистые линии (редкие точки) — представление поведения кривой при отсутствии зависимости ¡¿— N • ¡л - особенности присущей ПО. Видно, что в этом случае изменения со временем происходят гораздо медленнее.

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

В технике, где // не пропорционально при заданных начальных условиях вся техника

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

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

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

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

"У

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

С(0 - работает; С '(0 — не работает (ошибка обнаружена и исправляется).

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

Состояние сервера характеризуется в момент времени г одним из событий СО) и С'(О-Вероятности этих событий обозначим через р(0 и р '(г) - 1 - р(0, а численности состояний П1С(0, П2С(0 и П2С'(0 соответственно: Х,с(0, Х2С(0 и Х2С'(0.

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

т1 (о = л/[*,се)]

- тс2(!) = м[хс2({)}

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

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

Рис. 15 р и р'

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

Рис. 16 т1С, ш2С, т2С' Из рисунка видно, что клиенты начнут устойчиво работать на 4 сутки. Если количество программ-клиентов увеличить с 10 до 100, то результаты практически не изменятся или выход на устойчивую работу произойдет даже быстрее. Если же число программистов уменьшить с 3-х человек до одного, то сервер начнет устойчиво работать на 14 сутки, а клиенты — на 10 сутки.

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

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

Описание программы: Имеется ПО типа клиент-сервер. Сервер обслуживает запросы от N программ-клиентов (далее просто клиенты). В ПО равномерно по области определения входных данных (ООД) (А, В) расположены Ег ошибок. Сервер сложнее программ-клиентов с точки зрения разработки ПО в 5 раз. 5 - коэффициент сложности сервера по отношению к клиентам. Каждый £-ый (к = 1, 2, ..., ЛГ) клиент порождает пуассоновский поток данных к серверу интенсивностью ЯобР. Данные от клиента распределены по ООД по нормальному закону с характеристиками от* и о>, где т/с распределено между клиентами равномерно по всей области входных данных, Зет* - распределено равномерно на меньшем из участков отсекаемых т* на оси области данных. Это нужно для имитации неравномерности использования ООД при малом количестве клиентов.

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

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

1

Л I

VI,

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

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

Входными данными для розыгрыша являются: Р — количество программистов, обслуживающих систему; К - количество программ-клиентов; а - ширина одного запроса клиента как доля от ООД (от 0 до 7, где 1 — это вся ООД); Л1 - шаг итерации (сутки); 5 - коэффициент сложности сервера по сравнению с программой-клиентом; ХобР - интенсивность потока обращений одного клиента к серверу (7/сутки); ЯИСПр - интенсивность потока исправления ошибки одним программистом (7/сутки); Яянсс - интенсивность внесения ошибки при исправлении одним программистом (7/сутки) или Ранее — вероятность внести ошибку при исправлении одним программистом; М - количество итераций; К - количество розыгрышей для усреднения; Ег - начальное количество ошибок.

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

Г"Г!'"И...... \...и...... "ч"1 А'"1"

мшш, ; ; ; : • .....:...;..:...;..

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

Из рисунка видно, что ПО начнет устойчиво работать (т.е. количество работающих кли>

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

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

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

У 41

М51 |е*| 1.JÍ» М

0.t1448 «.tt*2

• 1.Ш

—(e»~et.7»í

rCvp*

|«аШ|П0>«<

ilililiiiii.il'iii. i.....ihfoUitiuLi., iin j.iiiiLiiji lililí lli,

• »иххихнтохякпчшя

M 0.«

0Л-

o.n 0.1

ш «о «о м » ao ao ico no i» 130 140 150 100 m

.¡—i—i-—i.

-->--■f-i—i-..i....;...¡...;.

o w 30 30 «o 90 ló то « óó 1« 110 iao 1» 14Ó iso 1B0 t>9

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

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

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

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

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

3. ЗАКЛЮЧЕНИЕ

1. На основании изучения современных методов разработки качественного (прежде всего надежного, Кг > 0,999) ПО, делается вывод о необходимости использования принципов экстремального программирования для разработки высоконадежного ПО в условиях ограниченных ресурсов.

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

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

Дана интерпретация работы п однотипных программ как ^-канальная система обслуживания заявок, которая имеет большое практическое значение, так как позволяет решать задачи достаточности ресурсов (надежности) программ обработки поступающих данных. Такие классы программ очень распространены в системах важных для безопасности РОО. Приведены конкретные примеры расчетов.

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

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

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

Обобщены ранее полученные результаты для одной программы (прототипа сервера) и многих однотипных программ (прототип программ-клиентов) для описания ПО типа клиент-

сервер. Для подобного ПО смешанного типа написана и численными методами решена система уравнений.

Показана работа модели на конкретных примерах. Полученные результаты хорошо согласуются с результатами полученными на практике.

4. Рассмотрены характеристики процесса размножения и гибели ошибок в ПО на различных этапах ЖЦ. Получены основные зависимости распределения ошибок по этапам ЖЦ для наиболее характерного случая.

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

Количество ошибок при увеличении времени кодирования постепенно уменьшается. Следовательно, если временные ресурсы позволяют (а объем работ велик), то можно сократить время тестирования за счет увеличения времени кодирования. На практике обычно именно так и поступают.

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

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

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

не оценить характеристики надежности ПО. В частности, это позволяет найти начальное количество ошибок в ПО.

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

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

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

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

7. Предложенный метод исследования (сочетания новой модели надежности ПО и программы моделирования надежности ПО) был опробован при разработке и эксплуатации ПО радиационно-опасных объектов (автоматизированной системы контроля радиационной обстановки (АСКРО) Волгодонской АЭС, при разработке АСКРО НИЦ «СНИИП», при разработке и эксплуатации системного программного обеспечения программно-технических средств верхнего уровня систем внутриреакторного контроля и систем контроля и управления АЭС Козлодуй (Болгария), Моховце (Словакия), Тяньвань (Китай), Волгодонской, Калининской, Балаковской (Россия), при разработке системы диагностики программно-технических средств «ПАМИР»), Результаты моделирования и модели были сравнены с результатами накопленного опыта при разработке и эксплуатации вышеперечисленного ПО. Полученные результаты хорошо согласуются с опытом и практикой.

Например, предложенный метод позволил оценить необходимое время опытной эксплуатации ПО АСКРО для достижения нужного уровня надежности ПО и передачи его в промышленную эксплуатацию. Задавая требуемую по техническим условиям надежность ПО равной 0,999, было получено время тестирования (около одного года), необходимое для достижения такой надежности. И действительно, на практике за найденное время удалось достичь нужного уровня устойчивой работы ПО. Без применения этого подхода обосновать такое время опытной эксплуатации при заданных ресурсах было бы затруднительно.

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

ных в тестировании.

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

ОПУБЛИКОВАННЫЕ РАБОТЫ ПО ОСНОВНЫМ ПОЛОЖЕНИЯМ ДИССЕРТАЦИИ

1. Зорин A.B., Федотов А А., Mumm В.И., Калинушки» А.Е., Мусихин A.M., Ханджян А. О. Программно-технические средства и комплексы "ПАМИР". // Ядерные измерительно-информационные технологии. - 2000. - №2 - С. 25-35.

2. Рыжов Н.В., Зорин A.B., Книжник АС., Тихонов АА., Ханджян А.О., Чебышов С.Б. АСКРО в защитной зоне и зоне наблюдения Ростовской АЭС // Материалы Всероссийской научно-практическая конференция "Состояние и развитие Единой государственной автоматизированной системы контроля радиационной обстановки на территории Российской Федерации". - 23-25 мая 2001. - г. Обнинск.

3. Елохин А.П., Ханджян АО. О погрешности расчетных оценок радиационных характеристик окружающей среды при аварии на АЭС и адаптации к работе на РоАЭС. // Материалы Всероссийской научно-практическая конференция "Состояние и развитие Единой государственной автоматизированной системы контроля радиационной обстановки на территории Российской Федерации". - 23-25 мая 2001. -г. Обнинск.

4. Зорин A.B., Попов В.В., Федотов ПА., Ханджян А. О. СОВРЕМЕННЫЕ ПРОГРАММНО-ТЕХНИЧЕСКИЕ СРЕДСТВА ВЕРХНЕГО УРОВНЯ ИНФОРМАЦИОННО-ИЗМЕРИТЕЛЬНЫХ СИСТЕМ ДЛЯ АЭС В ПРОЕКТЕ АСКРО ВОЛГОДОНСКОЙ АЭС // Материалы молодежной научно-технической конференции "Методы и средства ядерных измерительно-информационных систем " к 50-летию НИЦ "СНИИП". - 11-12 апреля 2002 г.

5. Тихонов АА., Зорин A.B., Попов В.В., Федотов ПА., Ханджян А.О. Методы построения программно-технические средства верхнего уровня АСКРО // Тезисы третьей МНТК "Безопасность, экономика и эффективность атомной энергетики" - М. - 18-19 апреля 2002.

6. Друзягин A.B., Зорин A.B., Книжник АС., Петров В.И., Рыжов Н.В., Тихонов АА., Ханджян А.О., Чебышов С.Б. Автоматизированная система радиационного контроля Волгодонской АЭС // Ядерные измерительно-информационные технологии. - 2002. - №1. - С.37-48.

7. Зорин A.B., Федотов АА., Федотов ПА., Ханджян А.О. Программно-технические средства верхнего уровня для АЭС // Ядерные измерительно-информационные технологии. - 2002. - №1. - С.65-70.

8. Зорин A.B., Попов В.В., Федотов ПА., Ханджян А. О. Современные программно-технические средства верхнего уровня информационно-измерительных систем для АЭС в проекте АСКРО Волгодонской АЭС //Ядерные измерительно-информационные технологии. - 2002. - №3 - С.25-35.

9. Ханджян АО. Модель и моделирование надежности программного обеспечения как системы массового обслуживания //Техника и технология. - 2005. - №2(8). - С. 76 - 85.

10. Ханджян А.О. Анализ современного состояния разработки надежного программного обеспечения // Естественные и технические науки. - 2005. - №2. - С, 220 - 227.

11. Ханджян А. О. Модель надежности программного обеспечения как системы массового обслуживания //Объединенный научный журнал. - 2005. - №7( 135) март. - С. 63 - 71.

12. Бодров А А., Бодров Д. А, Ретюнский КВ., Ханджян А. О. Специальное программное обеспечение «Мигрант-1» Центрального Банка Данных учета иностранных граждан ФМС России - проблемы информатизации // Сборник трудов XV Международной научной конференции «Информатизация и информационная безопасность правоохранительных органов». - Академия Управления МВД России. - 2324 мая 2006 г. - С. 245 - 248.

13. Ханджян А. О. Повышение надежности программного обеспечения ядерных радиационно-опасных объектов // Ядерные измерительно-информационные технологии. - М., 2006. - №3. — 10 стр. (принято в печать).

14. Бодров А А., Ханджян АО. Обзор современного состояния разработки надежного программного обеспечения и модель надежности ПО // Новые промышленные технологии. - М.: ЦНИЛОТ, 2006. -№6. — 10 стр. (принято в печать).

Отпечатано в ООО «Компания Спутник+» ПД № 1-00007 от 25.09.2000 г. Подписано в печать 11.07.06. Тираж 75 экз. Усл. п.л. 1,63 Печать авторефератов (095) 730-47-74,778-45-60

Оглавление автор диссертации — кандидата технических наук Ханджян, Аркадий Олегович

ВВЕДЕНИЕ.

1. АНАЛИЗ СОВРЕМЕННЫХ МЕТОДОВ ПОВЫШЕНИЯ НАДЕЖНОСТИ ПО.

1.1. Процесс разработки ПО.

1.1.1. Классическая (водопадная или каскадная) модель.

1.1.2. Итерационная или эволюционная модель.

1.1.3. Экстремальное программирование.

1.1.4. Характеристики разработки ПО.

1.2. Качество ПО.

1.3. Надежность ПО.

1.3.1. Надежность ПО и аппаратуры.

1.3.2. Частоты появления ошибок.

1.4. Программный контроль для повышения надежности вычислительной техники. Оперативный контроль и диагностика.

1.5. Поиск ошибок в тексте программы и тестирование.

1.6. Модели надежности ПО.

1.6.1. Обзор моделей.

1.6.2. Сравнение моделей.

1.7. Выводы.

2. РАЗРАБОТКА МОДЕЛИ НАДЕЖНОСТИ ПО НА ОСНОВЕ МАРКОВСКИХ СИСТЕМ МАССОВОГО ОБСЛУЖИВАНИЯ.

2.1. Модель появления и устранения ошибок.

2.1.1. Постановка задачи.

2.1.2. Вывод основных математических выражений модели.

2.1.3. Дополнительные возможности модели.

2.1.4. Выводы.

2.2. Распределение ошибок по этапам ЖЦ.

2.2.1. Исследование зависимостей.

2.2.2. Пример работы модели.

2.2.3. Расчет типичного случая (на примере АСКРО).

2.2.4. Выводы.

2.3. Уточнение модели для описания работы п однотипных программ.

2.3.1. Постановка задачи и выводы основных формул.

2.3.2. Примеры использования и n-канальная интерпретация.

2.3.3. Определение рентабельности сопровождения.

2.3.4. Выводы.

2.4. Уточнение модели надежности ПО как СМО с отказами, недостоверным обслуживанием, ожиданием и взаимопомощью.

2.4.1. Учет в модели надежности отказов в обслуживании и недостоверности обслуживания.

2.4.2. Учет в модели времени ожидания заявкой выполнения.

2.4.3. Учет в модели взаимопомощи между программистами при устранении ошибок.

2.4.4. Об учете в модели ограничения на время пребывания заявки в очереди.

2.4.5. Выводы.

2.5. Разработка модели надежности ПО как замкнутой СМО - учет работы программистов.

2.5.1. Постановка задачи и вывод основных уравнений.

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

2.5.3. Случай с одним программистом.

2.5.4. Примеры использования модели.

2.5.5. Выводы.

2.6. Разработка модели надежности клиентских программ в ПО типа клиент-сервер.

2.6.1. Постановка задачи и вывод основных формул.

2.6.2. Пример работы модели с заменой вероятностей состояний на средние численности состояний.

2.6.3. Применение модели для случая N модулей-клиентов, каждый из которых может находится либо в рабочем либо в нерабочем состоянии.

2.6.4. Уточнение модели для случая X Ф const.

2.6.5. Учет фактора внесения новых ошибок.

2.6.6. Выводы.

2.7. Разработка общей модели надежности ПО типа клиент-сервер как марковской модели смешанного типа

2.7.1. Постановка задачи и выводы основных формул.

2.7.2. Пример использования модели.

2.7.3. Выводы.

2.8. Выводы.

3. ИССЛЕДОВАНИЕ ПУТЕЙ ПОВЫШЕНИЯ НАДЕЖНОСТИ ПО НА ОСНОВЕ ПРЕДЛОЖЕННОЙ МОДЕЛИ П

3.1. Постановка задачи.

3.2. Описание функционирования программы моделирования.

3.3. Алгоритм одного розыгрыша.

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

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

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

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

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

3.4.5. Поиск начального количества ошибок в программе по начальной и конечной интенсивностям отказов

3.5. Выводы.

Введение 2006 год, диссертация по приборостроению, метрологии и информационно-измерительным приборам и системам, Ханджян, Аркадий Олегович

Актуальность исследования.

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

В работе [32] в статье «Вклад фон Неймана в теорию автоматов» есть замечательный параграф: "Мозг человека и животных дает нам пример очень большой и относительно надежной системы, построенной из индивидуальных компонент, нейронов, которые ненадежны не только в выполнении операций, но и в тонких деталях взаимосвязи. Более того, хорошо известно, что при повреждении, несчастном случае, болезни и так далее мозг продолжает функционировать удивительно правильно, даже если поражены его большие области.

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

На сегодняшний день [17] программное обеспечение (ПО) является неотъемлемой частью современного мира. ПО - эта та движущая сила, которая в современном мире обеспечивает функционирование торговли, промышленности, обороны и связывает воедино страны и людей. ПО помогает создавать и обмениваться информацией, визуализировать ее. Развитие мировой экономики напрямую связано с процессом развития в области ПО и вычислительных средств. Мировая экономика и жизнедеятельность всего человечества становится все более зависимой от ПО. Благодаря развитию вычислительной техники стало возможным создание программных систем, которые постоянно растут, усложняются, распространяются и становятся все более важными и от их работоспособности зависит все больше количество людей. Кроме того, растет и потребность общества на эти системы.

Относительная стоимость ПО в настоящее время все растет [27] и в отдельных отраслях намного превышает стоимость аппаратных средств.

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

Интенсивное и масштабное использование [38] вычислительной техники в задачах автоматизации радиационно-опасных объектов (РОО), её корректная работа часто является критичной для надежного обеспечения управления и контроля за работой объектов и обеспечения их безопасности. В этой связи создание надежного ПО и программно-технических средств (ПТС) имеют сегодня первостепенную важность, т.е. надежность ПО является важнейшей характеристикой ПО информационно-измерительных и управляющих систем безопасности ЯУ.

В связи с этим можно выделить несколько основных показателей, оказывающих существенное влияние на надежность ПО:

- сложность радиационно-опасных объектов с точки зрения формализации описания алгоритмов их функционирования;

- неповторимость и уникальность ПО для конкретных РОО;

- нечеткая формализация заказчиком требований к программной автоматизации технологических процессов конкретного РОО;

- неточное понимание разработчиком ПО требований заказчика;

- выявление проектных ошибок на поздних этапах создания объекта и как следствие необходимость корректировки ПО;

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

- появление новых непроверенных технологий программирования, стандартов и инструментов разработки программ, быстрое устаревание существующих ОС, технологий, библиотек программ и инструментов программирования;

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

Указанные факторы в своей совокупности существенно снижают надежность ПО РОО. Учитывая, что данная характеристика является одной из важнейших при создании информационно-измерительных и управляющих систем безопасности РОО и ЯУ [27], существенное повышение надежности ПО для указанного класса систем представляет собой актуальную проблему. Для создания надежного ПО целесообразно разработать механизм его создания, критерии его оценки и прогнозирования результирующих значений его надежностных характеристик.

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

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

Цели и задачи исследования.