close

Вход

Забыли?

вход по аккаунту

?

Многокритериальная оптимизация отказоустойчивой программной архитектуры специализированными эволюционными алгоритмами.

код для вставкиСкачать
На правах рукописи
Шеенок Дмитрий Александрович
МНОГОКРИТЕРИАЛЬНАЯ ОПТИМИЗАЦИЯ
ОТКАЗОУСТОЙЧИВОЙ ПРОГРАММНОЙ АРХИТЕКТУРЫ
СПЕЦИАЛИЗИРОВАННЫМИ ЭВОЛЮЦИОННЫМИ
АЛГОРИТМАМИ
05.13.01 – Системный анализ, управление и обработка информации
(космические и информационные технологии)
АВТОРЕФЕРАТ
диссертации на соискание ученой степени
кандидата технических наук
Красноярск – 2013
Работа выполнена в ФГОУ ВПО «Красноярский институт железнодорожного
транспорта» – филиале ФГБОУ ВПО «Иркутский государственный университет
путей сообщения» и ФГБОУ ВПО «Сибирский государственный аэрокосмический
университет имени академика М.Ф. Решетнева».
Научный руководитель:
доктор технических наук, профессор
Терсков Виталий Анатольевич
Официальные оппоненты:
Комарцова Людмила Георгиевна
доктор технических наук, профессор,
Калужский филиал Московского
государственного технического
университета им. Н.Э. Баумана,
профессор кафедры «Компьютерные
системы и сети»
Семѐнкин Евгений Станиславович
доктор технических наук, профессор,
Сибирский государственный аэрокосмический
университет им. академика М.Ф. Решетнева,
профессор кафедры «Системный анализ и
исследование операций»
Ведущая организация:
ФГБОУ ВПО «Национальный исследовательский
Томский политехнический университет».
Защита состоится 10 декабря 2013 г. в 14 часов на заседании диссертационного
совета Д 212.249.02, созданного на базе ФГБОУ ВПО «Сибирский
государственный аэрокосмический университет имени академика М.Ф. Решетнева»
по адресу 660014 г. Красноярск, проспект имени газеты «Красноярский рабочий»,
31.
С диссертацией можно ознакомиться в библиотеке Сибирского государственного
аэрокосмического университета имени академика М.Ф. Решетнева».
Автореферат разослан «
Ученый секретарь
диссертационного совета
» ноября 2013 г.
Александр Алексеевич Кузнецов
Общая характеристика работы
Актуальность. Проблема обеспечения качества программного обеспечения
(ПО) сложных информационно-управляющих систем исследовалась рядом
российских и зарубежных ученых.
Качество конечного программного продукта, поставляемого на открытый
рынок или заказчику, является определяющим фактором для успеха и
конкурентоспособности предприятий, занятых в данной сфере. Одним из
основополагающих показателей качества системы является надѐжность еѐ
функционирования. Недостаточная надѐжность сложных программных средств
может нанести ущерб, значительно превышающий положительный эффект от их
применения в таких критических областях как управление движением,
технологические процессы, оборона, медицина, финансовые операции,
космические технологии. При функционировании таких систем недопустимы
программные сбои. Это повлияло на развитие и применение стандартов, методов и
инструментов автоматизации процессов программной инженерии, которые могут
обеспечить проектирование программных архитектур с заданными высокими
показателями надѐжности. Одним из эффективных и дорогостоящих подходов
обеспечения
надѐжности
программных
систем
является
методология
избыточности.
Однако чрезмерно высокие требования к надѐжности программного
обеспечения для подобных систем принципиально не могут быть выполнены
вследствие реальных ограничений на все виды ресурсов: бюджет, время
разработки, производительность вычислительных систем.
Поэтому при проектировании надѐжного программного обеспечения
возникает
проблема
поиска
оптимального
варианта
архитектуры,
соответствующего наибольшей надѐжности будущей системы при допустимых
затратах на еѐ разработку. Учитывая сложность и размеры современных
программных систем, для решения данной задачи требуется развитие модельноалгоритмического аппарата, позволяющего автоматизировать этап архитектурного
проектирования.
Работы в данной области требуют больших затрат, однако современные
масштабы программных разработок и внедрения информационно-управляющих
систем не оставляют сомнений в экономической целесообразности,
своевременности и актуальности поставленных в диссертации задач.
В связи этим, возникает техническая проблема, заключающаяся в
разработке системы поддержки принятия решения о выборе эффективных
характеристик отказоустойчивой архитектуры проектируемой программной
системы. Это требует развития модельно-алгоритмического обеспечения, методов
и средств анализа надѐжности и трудоемкости сложных программных средств, что
является научной проблемой.
Предметом исследования является генетический алгоритм оптимизации
отказоустойчивой программной архитектуры.
Объектом исследования является отказоустойчивая архитектура сложных
программных систем.
Целью диссертационной работы является повышение эффективности
проектирования
отказоустойчивых
программных
систем
за
счет
3
многокритериальной оптимизации характеристик архитектуры, при ограничениях
на надѐжность функционирования системы и трудозатраты на еѐ разработку.
Для достижения поставленной цели решались следующие задачи:
- проанализировать проблему оценки надѐжности программного
обеспечения и затрат трудовых ресурсов на еѐ обеспечение;
- модифицировать модель надежности архитектуры ПО сложных
информационно-управляющих систем для учета введения программной
избыточности и трудозатрат на еѐ реализацию;
- разработать генетический алгоритм многокритериальной условной
оптимизации, позволяющий найти оптимальные характеристики архитектуры ПО с
заданными ограничениями по надѐжности, трудозатратам на реализацию и среднее
время выполнения отдельных архитектурных компонентов;
- реализовать систему поддержки принятия решений о выборе
оптимальной архитектуры программного обеспечения;
- применить реализованную программную систему при решении тестовых
и реальных практических задач проектирования архитектуры ПО;
- разработать и апробировать методику оценки затрат на реализацию
системы с учетом введения программной избыточности и затрат на отдельные
этапы жизненного цикла ПО.
Методы исследования. При выполнении работы использовались методы
прикладного системного анализа, методы оценки стоимости разработки
программного обеспечения, элементы теории вероятностей, теория надѐжности
программного обеспечения, методология мультиверсионного проектирования
отказоустойчивого
программного
обеспечения,
методы
эволюционных
вычислений, методология разработки программного обеспечения.
Научная новизна работы заключается в следующем:
1. Модифицирована модель надѐжности архитектуры программного
обеспечения сложных информационно-управляющих систем, отличающаяся
учетом введения программной избыточности различными методами, позволяющая
рассчитать трудозатраты на реализацию компонентов и среднее время выполнения
программных модулей.
2. Предложен новый оператор кроссинговера в генетическом алгоритме,
отличающийся от известных учетом связи между генами, и позволяющий задавать
вероятность разрыва хромосомы между ними.
3. Впервые разработан генетический алгоритм многокритериальной
условной оптимизации, позволяющий осуществлять поиск эффективных
характеристик отказоустойчивой программной архитектуры с учетом ограничений
на коэффициент готовности системы, трудозатраты на реализацию и среднее время
выполнения отдельных модулей.
Теоретическая значимость результатов диссертационного исследования
состоит в разработке нового эволюционного алгоритма для многокритериальной
условной оптимизации отказоустойчивой программной архитектуры и
модифицированного оператора кроссинговера с заданной вероятностью выбора
точки разрыва связанных генов.
Результаты, полученные при выполнении диссертационной работы, создают
теоретическую основу для разработки моделей, методов и алгоритмов,
4
направленных на повышение эффективности процессов разработки и
модернизации программных систем.
Практическая ценность. Разработанная в результате работы над
диссертацией программная система позволяет экономить время и вычислительные
ресурсы при выборе оптимального варианта проектируемой программной
архитектуры по критериям надѐжности и трудоемкости, а также осуществлять
поиск оптимальных решений по модернизации архитектур уже существующих
программных систем.
Предложен подход к прогнозированию затрат и надѐжности проектируемых
программных компонентов, с использованием зависимости надѐжности
функциональных точек и трудозатрат на еѐ достижение.
Разработана методика оценки затрат на все этапы жизненного цикла
реализации или модернизации отказоустойчивых программных систем.
Достоверность полученных результатов подтверждается тестированием и
оценкой результатов применения разработанной системы в реальных проектах,
согласованностью расчетных и экспериментальных данных, корректностью
выполненных математических выкладок.
Реализация
результатов
работы.
Разработанные
на
основе
модифицированной модели надѐжности архитектуры и нового генетического
алгоритма программные системы зарегистрированы в Роспатенте, что делает их
доступными широкому кругу специалистов по системному анализу,
архитектурному проектированию и планированию разработки сложных
информационных систем.
Разработанная программная система внедрена в компании ООО «Сибирские
интеграционные системы» и используется при модернизации программного
обеспечения информационной системы Пенсионного Фонда Российской
Федерации.
Результаты диссертационного исследования, разработанные алгоритмы и
программная система используются при проведении занятий по дисциплинам
«Алгоритмы и структуры данных», «Управление данными», «Технология
автоматизированного проектирования информационных систем» в Красноярском
институте железнодорожного транспорта.
Основные положения, выносимые на защиту:
1. Модифицированная модель надѐжности архитектуры программного
обеспечения позволяет учитывать введение программной избыточности
различными методами, трудозатраты на реализацию компонентов, и среднее время
выполнения программных модулей.
2. Применение модифицированного оператора кроссинговера с заданной
вероятностью разрыва связанных генов, повышает эффективность генетического
алгоритма оптимизации.
3. Генетический алгоритм многокритериальной условной оптимизации
отказоустойчивой программной архитектуры позволяет осуществлять поиск
эффективных характеристик архитектуры программного обеспечения.
Апробация работы. Результаты проведенных исследований докладывались
в период 2011-2013 гг. на 9 конференциях различного уровня, в том числе:
– XV научно-техническая конференция КрИЖТ ИрГУПС (Красноярск,
2011);
5
– Вторая межвузовская научно-практическая конференция «Транспортная
инфраструктура Сибирского региона» (Иркутск, 2011);
– VIII Международная заочная научно-практическая конференция
«Актуальные вопросы технических, экономических и гуманитарных наук»
(Георгиевск, 2012);
– IV Международная научная конференция «Актуальные вопросы
современной науки» (Санкт-Петербург, 2012);
– Международная научно-практическая конференция «Логистические
системы в глобальной экономике» (Красноярск, 2013);
– XI международной научно-практической конференции «Перспективы
развития информационных технологий» (Новосибирск, 2013);
– VIII Международная научно-практическая конференция «Техника и
технология: новые перспективы развития» (Москва, 2013);
– I Международная конференция «Научные аспекты инновационных
исследований» (Самара, 2013).
– Международная научно-практическая конференция «The Strategies of
Modern Science Development» (Елм, США, 2013).
Диссертационная работа в целом обсуждалась на научных семинарах
кафедры
«Математика
и
информатика»
Красноярского
института
железнодорожного транспорта (2010-2012 гг.) и кафедры «Системный анализ и
исследование операций» Сибирского государственного аэрокосмического
университета (2012-2013 гг.).
Публикации. По теме диссертации опубликовано 20 работ, среди которых 6
статей в журналах, входящих в перечень ВАК.
Структура и объем работы. Диссертация состоит из введения, пяти глав,
заключения, списка использованной литературы и приложения.
Основное содержание работы
Во введении обоснована актуальность работы, определены цель и
поставлены задачи исследования, обоснована научная новизна, теоретическая и
практическая значимость проведенного исследования, приведены основные
положения, выносимые на защиту.
В первой главе описан этап архитектурного проектирования в жизненном
цикле ПО. Рассмотрены методы повышения отказоустойчивости программных
систем, модели оценки надѐжности и стоимости программного обеспечения, а
также предложен подход по использованию зависимости надѐжности
функциональных точек от трудозатрат, требуемых на еѐ достижение, при
разработке крупномасштабных программных проектов.
Одной из наиболее перспективных и положительно зарекомендовавших себя
методологий обеспечения высокой надѐжности программного обеспечения
является введение программной избыточности. Но простое дублирование
компонентов, как при аппаратном резервировании, недопустимо, так как в отличие
от аппаратуры, программные ошибки имеют внутреннюю природу и при
дублировании не исчезнут. При введении программной избыточности
возникновение сбоя в функционально эквивалентных модулях (версиях) на одних и
тех же входных данных происходит в различных точках его исполнения.
6
Создание функционально-эквивалентных, но, тем не менее, разных модулей
может быть достигнуто при разработке версий одного модуля разными
специалистами или применением разных языков программирования. Программную
избыточность используют для разработки компонентов, к которым происходит
наиболее частое обращение, или результаты работы которого участвуют в
критически важных циклах управления.
Существует два основных метода реализации программной избыточности:
1.
NVP (N-version programming – N-версионное программирование) – был
предложен в 1985 году А. Авижиенисом. При реализации данного метода версии
выполняются параллельно во времени, а результат их работы выбирается с
помощью какого-либо алгоритма голосования. Алгоритмы голосования могут быть
различными в зависимости от задачи, при этом сравниваемые значения считаются
идентичными с учетом заданной погрешности.
2.
RB (Recovery Block – блок восстановления) – был предложен в 1975
году Б. Ренделом. При реализации данного метода версии выполняются
последовательно. После выполнения первой версии программного компонента
приемочный тест по результатам выполнения принимает результаты вычисления,
либо запускает следующую версию компонента.
Далее рассматриваются модели оценки надѐжности программного
обеспечения. Следует признать, что абсолютно надѐжных программных систем не
может быть, т.к. количество всех возможных вариантов исполнения программы
огромно, и не подлежит полной проверке корректности. Однако важно знать,
насколько надѐжно конкретное программное обеспечение. Описанные модели
представляют теоретический подход и имеют ограниченное применение. До сих
пор не предложено ни одного метода оценки надѐжности ПО, содержащего
минимальное количество ограничений.
Практика программной инженерии предполагает больший приоритет задачи
обеспечения надѐжности, чем задачи еѐ оценки. Но, очевидно, что прежде чем
обеспечить надѐжность, необходимо еѐ измерить, а для этого нужно иметь
приемлемую единицу измерения надѐжности ПО и модель для еѐ расчета.
Учитывая сложность современных программных систем, к расчетам
надѐжности их функционирования не могут предъявляться очень высокие
требования по точности. Несмотря на это, расчеты надѐжности позволяют
обосновать трудоемкость разработки, что повышает уверенность заказчика в
качестве готового программного продукта.
Затем рассматриваются модели оценки стоимости программных систем.
Одной из наиболее хорошо зарекомендовавших себя является модель СОСОМО II,
которая впервые была опубликована в 1999 году. Для калибровки параметров
модели использовались данные по 161 проекту. Среди сильных сторон модели
COCOMO II можно выделить следующие:
‒ позволяет оценить трудоемкость исходя из разных уровней
определенности требований;
‒ поддерживает современный процесс разработки программного
обеспечения.
Основным недостатком моделей стоимости программного обеспечения
является необходимость производить калибровку модели, а это требует большого
количества сведений о предыдущих проектах. Также недостаком является
7
невозможность задать более менее точный уровень надѐжности разрабатываемой
программной системы.
При заключении контрактов на разработку или модернизацию
крупномасштабных программных систем большую роль играет адекватная оценка
и прогноз трудозатрат исполнителя. Расхождение планируемых затрат с
фактическими может привести к применению штрафных санкций со стороны
заказчика, и даже судебным искам.
Также серьезным фактором является качество готового в срок программного
продукта и, в частности надѐжности его функционирования в таких критически
важных областях как управление технологическими процессами, управление
движением, финансовые операции, военная и космическая техника. Неадекватная
оценка трудозатрат на разработку системы ведет к срыву сроков и низкому
качеству конечного программного продукта.
Для того, чтобы адекватно спланировать сроки реализации системы и
оценить еѐ трудоемкость, необходимо выполнить предварительное проектирование
программного продукта. В результате декомпозиции проекта получается некоторое
количество компонентов, которые составляют программный продукт. В модели
оценки стоимости программного обеспечения COCOMO II такие компоненты
называются функциональными точками.
Под функциональной точкой понимается метод измерения размера
программного обеспечения, основывающийся на оценке функциональности, исходя
из описания логики и функциональных спецификаций в технических требованиях
на разработку.
Использование функциональных точек удобно тем, что они основываются на
информации, доступной на ранних этапах жизненного цикла программного
обеспечения. В качестве функциональных точек (или объектных указателей) могут
быть взяты элементы типа экранной формы, аналитического отчета, алгоритма
расчетов и т.д.
Каждый экземпляр этих функциональных типов разделяется по уровню
сложности – простой, средний и сложный. Уровням сложности соответствует
набор весовых коэффициентов, которые применяются к соответствующему
значению трудозатрат.
Для планирования затрат на достижение заданного уровня надѐжности
требуется построение модели, которую можно было бы применить к новому
программному компоненту. Предполагается, что функциональные точки одного
типа и сложности потребуют аналогичных затрат на достижение заданного уровня
надѐжности. Поэтому необходимо для каждого типа и сложности функциональной
точки
получить
зависимость
времени
разработки
от
надѐжности
функционирования, используя статистические данные предыдущих проектов.
Модель оценки надѐжности Джелинского-Моранды позволяет рассчитать по
статистическим данным процесса тестирования вероятность работы без отказа на
заданном промежутке времени функционирования. Модель основывается на
предположении, что в процессе тестирования значение интервалов времени
тестирования между обнаружением двух ошибок имеет экспоненциальное
распределение с интенсивностью отказов, пропорциональной числу еще не
обнаруженных ошибок. Каждая обнаруженная ошибка исправляется и число
оставшихся ошибок уменьшается на единицу.
8
Если каждой обнаруженной ошибке сопоставить время на еѐ устранение, то
можно получить зависимость:
Ri(Ti),
где Ti – время разработки и тестирования программного компонента,
соответствующего функциональной точке, после устранения i-ой ошибки; Ri –
надѐжность функционирования программного компонента после устранения i-ой
ошибки, i = 1, 2,…n; n – количество обнаруженных и исправленных ошибок.
Рассмотрим пример разработки программного модуля определенной
сложности. По модели Джелинского-Моранды получена зависимость надѐжности
от времени тестирования (таблица 1). Также было зафиксировано время
исправления ошибки.
Таблица 1 – Зависимость надёжности от времени тестирования
№
ошибки
1
2
3
4
5
6
7
8
Время
тестирования
до
обнаружения
ошибки ttesti,
час.
0.2
0.3
0.5
0.3
0.6
1
1.2
1
Надѐжность
после
устранения
ошибки Ri.
Время
Время
устранения разработки
ошибки tei, tdevi, час.
час.
0.61
0.67
0.73
0.80
0.82
0.90
0.92
0.97
0.9
1.2
4.6
1
0.2
2.1
0.3
0.4
5.9
7.1
11.7
12.7
12.9
15
15.3
15.7
Время
разработки и
тестирования
Ti, час.
6.1
7.4
12.2
13
13.5
16
16.5
16.7
По полученным данным можно построить зависимость надѐжности от
трудозатрат для каждого типа и сложности функциональной точки с учетом затрат
на устранение ошибок. По аналогии с определением затрат на разработку новых
программных компонентов по типу функциональной точки также могут быть
определены затраты на достижение необходимого уровня надѐжности
функционирования соответствующего компонента.
Во второй главе приведена модификация модели архитектуры
программного обеспечения, учитывающая введение программной избыточности
различными методами, затраты на введение программной избыточности и среднее
время выполнения программных модулей.
Модель архитектуры программного обеспечения сложных информационноуправляющих систем представлена следующим образом:
М – количество архитектурных уровней в архитектуре ПО;
Nj – количество компонентов на уровне j, j {1,.., M } ;
Dij – множество индексов компонентов, зависимых от компонента i на уровне
j, i {1,.., N j } , j {1,.., M } ;
Eij – множество индексов компонентов, от которых зависит компонент i на
уровне j, i {1,.., N j } , j {1,.., M } ;
9
Fij – событие сбоя, возникшего в компоненте i на уровне j, i  {1,.., N j } ,
j {1,.., M } ;
PUij – вероятность, того что компонент i на уровне j будет использоваться;
PFij – вероятность, того, что в компоненте i на уровне j возникнет сбой;
Rij – вероятность того, что в компоненте i на уровне j сбой не появится;
PLnmij – условная вероятность того, что в компоненте m на уровне n возникнет
сбой, если возникнет сбой в компоненте i на уровне j,
i {1,.., N j } ,
j {1,.., M } , n {1,.., N m } , m{1,.., M } ;
TAij – относительное время доступа к компоненту i на уровне j, i {1,.., N j } ,
j {1,.., M } , определяемое отношением среднего времени доступа к компоненту i
на уровне j к числу сбойных компонентов на более низких архитектурных уровнях
во время доступа к компоненту; параметр TAij имеет смысл использовать, если
компонент работает на удаленных или изолированных системах;
Ntaij – число сбойных компонентов на более низких архитектурных уровнях
во время доступа к компоненту i на уровне j;
TCij – относительное время анализа сбоя в компоненте i на уровне j,
определяемое отношением среднего времени анализа сбоя в компоненте i на
уровне j, i {1,.., N j } , j {1,.., M } , к числу сбойных компонентов на всех
уровнях архитектуры, анализируемых в одно и тоже время; к анализу относится
время на воспроизведение ошибки и еѐ локализацию;
Ntcij – число сбойных компонентов на всех уровнях архитектуры,
анализируемых в одно и тоже время с компонентом i на уровне j;
TEij – относительное время устранения сбоя в компоненте i на уровне j,
определяемое отношением среднего времени восстановления в компоненте i на
уровне j, i {1,.., N j } , j {1,.., M } , к числу сбойных компонентов на всех
уровнях архитектуры, в которых происходит устранение сбоев в одно и тоже
время;
Nteij – число сбойных компонентов на всех уровнях архитектуры, в которых
происходит устранение сбоев во время устранения сбоя в компоненте i на уровне j;
TUij – относительное время использования компонента i на уровне j,
определяемое отношением среднего времени использования компонента i на
уровне j, i {1,.., N j } , j {1,.., M } , к числу компонентов на всех уровнях
архитектуры, используемых в одно и тоже время;
Ntuij – число компонентов на всех уровнях архитектуры, используемых в
одно и тоже время с компонентом i на уровне j;
Kij – глубина программной избыточности компонента i, на уровне j;
Zij – множество версий компонента i, на уровне j;
RTij – среднее время выполнения модуля i на уровне j;
Tij – трудоемкость разработки компонента i на уровне j;
Tijk – трудоемкость разработки версии k компонента i на уровне j, kZij, в челчасах;
NVXij – трудоемкость разработки среды исполнения версий (приемочного
теста для RB (recovery block, блок восстановления) или алгоритма голосования для
10
NVP (N-version programming, N-версионное программирование);
Bij – бинарная переменная, принимающая значение 1 (тогда NVPij=0, RBij=0),
если в программном компоненте не используется программная избыточность,
иначе равна 0;
NVPij – бинарная переменная, принимающая значение 1 (тогда Bij=0, RBij=0),
если в программном компоненте введена программная избыточность методом NVP,
иначе равна 0.
RBij – бинарная переменная, принимающая значение 1 (тогда Bij=0, NVPij=0),
если в программном компоненте введена программная избыточность методом RB,
иначе равна 0.
TR – среднее время простоя системы, которое определяется как среднее время,
в течение которого программное обеспечение не может выполнять свои функции;
MTTF – среднее время возникновения сбоя в системе, которое определяется
как среднее время, в течение которого сбоев в программном обеспечении не
возникает;
S – коэффициент готовности программной системы;
Ts – общая трудоемкость реализации программной системы.
Надѐжность мультиверсионного компонента i на уровне j, построенного из K
версий методом мультиверсионного программирования для любого K равна:
Rij 

pijv 1 


K

k 1

(1  p ijk ) ,


v
где p ij – вероятность безотказной работы алгоритма голосования, pkij – вероятность
безотказной работы версии kZij.
Надѐжность мультиверсионного компонента i на уровне j, построенного из K
версий методом блока восстановления для любого K равна:
k 1
K
Rij 

k 1
p ijk
AT
pij
 (1  p
l
ij
) p ijAT  p ijl (1  p ijAT )

l 1
,
где
– вероятность безотказной работы приемочного теста для компонента i,
i=1,..,N на уровне j, j=1,..,M; pkij – вероятность безотказной работы версии k  Zij.
Вероятность сбоя таких компонентов равна:
PFij = 1 – Rij.
Среднее время выполнения программного компонента i на уровне j
вычисляется как сумма времени работы компонента без сбоев и времени простоя
компонента:
pATij
 
 
RTij  TU ij  Ntu ij  1   PFij 
PLab
ij  PFab  PU ab
 
a ,bEnm
 



  




 TAij  Nta ij  TCij  Ntc ij  TEij  Nte ij   PFij 
PLab
ij  PFab  PU ab

a ,bEnm




11

 ,

где PLijab – условная вероятность того, что в компоненте i на уровне j возникнет
сбой, если сбой возникнет в компоненте a на уровне b, a{1,..,Nj}, b{1,..,M},
i{1,..,Nm}, j{1,..,M}; PUij – вероятность того, что компонент i на уровне j будет
использоваться; PFij – вероятность того, что в компоненте i на уровне j возникнет
сбой;
При расчете трудоемкости разработки учитываются затраты на реализацию
среды исполнения версий модуля (NVXij) и затраты на реализацию каждой версии
(Tkij). Трудоемкость разработки системы рассчитывается следующим образом:
Ts 
M
Nj
j 1
i 1


 B T  NVP  RB
ij
ij
 ij ij



 NVX 
ij



K

k 1

Tijk  


.
Среднее время сбоя в системе равно:
Nj
M
MTTF 
 {PU
j 1
Nm
M
 

( m1)&( m j ) n1
ij
 (1  PFij )  [TU ij 
i 1




ij
(
1

PL
)

TU nm 
(1  PLnm
nm
lm )  TU lm




lDnm





M


ij

 (1  PLkj )   TU kj 

kDij 
( m1)&( m j )




  






kj
(
1

PL
)

TU nm 
(1  PLnm
nm
lm )  TU lm




n1 
lDnm

Nm

 
   

   ]}
    .

Среднее время простоя системы равно:
Nj
M
TR 
 {PU
j 1
M

Nm
 
( m1)&( m j ) n1
ij
 PFij  [(TAij  TCij  TEij ) 
i 1


 ij

PLnm
lm  (TAlm  TClm  TElm )
 PLnm   (TAnm  TCnm  TEnm ) 

l

D
nm




[PL
ij
kj  [(TAkj


  


 TCkj  TEkj ) 
kDij
M
Nm
 
( m1)&( m j ) n1


 kj 
PL
PLnm
lm  (TAlm  TClm  TElm )
 nm  (TAnm  TCnm  TEnm ) 

lDnm




 ]]]}


.
Коэффициент готовности системы равен:
S
MTTF
MTTF  TR .
В третьей главе описана постановка задачи оптимизации программной
архитектуры. Приведен генетический алгоритм многокритериальной оптимизации.
Проектирование программной архитектуры – один из самых важных этапов
жизненного цикла отказоустойчивого программного обеспечения. На данном этапе
определяется глубина программной избыточности и планируются затраты на
12
достижение необходимого уровня надѐжности программных компонентов.
Количество альтернатив построения архитектуры достаточно велико и зависит от
количества разрабатываемых компонентов. Обычно проектировщик выбирает
характеристики будущих компонентов, основываясь на своем опыте и интуиции.
Но это не всегда определяет оптимальный вариант построения всей системы,
поэтому необходима автоматизация данного этапа проектирования.
На коэффициент готовности системы и трудозатраты на еѐ разработку
влияют значения PFij и Tij. Прогнозные значения вероятности сбоя могут быть
рассчитаны по моделям надѐжности ПО, а значения трудозатрат по модели
COCOMO II. Если для компонента сложно определить значения вероятности сбоя и
трудозатрат, то можно задать множество альтернативных вариантов «вероятность
сбоя/трудозатраты» с помощью модели роста надѐжности SGRM, зависимости
затрат от надѐжности или экспертной оценки.
Особую задачу составляет эффективное решение о введении программной
избыточности. Причина в том, что надѐжность компонента в этом случае зависит
не только от вероятности сбоя каждой его версии, но и от надѐжности среды
исполнения версий, количества версий, а также от метода реализации их
взаимодействия.
Так как модель архитектуры представлена большим количеством
параметров, для больших программных архитектур достаточно затратно вычислять
каждый параметр с большой точностью. Для вычисления значения каждого
параметра может также не хватать статистических данных. По этой причине
параметры могут быть оценены экспертно. При этом теряется адекватность
значений целевых функций, но найденные при оптимизации показатели все равно
будут отражать качество того или иного варианта построения архитектуры ПО.
Общий вид задачи оптимизации архитектуры следующий:
Smax, Tsmin,
при ограничениях:
RTij  RTij0 ( i {1,.., N j } , j {1,.., M } ), S S0, TsTs0.
где S0, Ts0, RTij0 – предельные значения критериев.
Программный компонент, участвующий в критически важных циклах
управления, должен выполнить вычисления за такое время, чтобы время всего
цикла не превышало критическое. Тогда для среднего времени выполнения таких
программных компонентов задается предельное время выполнения RTij0.
Если сбой происходит в одной из версий мультиверсионного компонента, то
время его восстановления равно времени переключения на другую версию, что
увеличивает время выполнения программного модуля не значительно.
Таким образом, представленная задача оптимизации архитектуры
программного обеспечения имеет два критерия оптимизации, два ограничения,
соответствующих каждому критерию, и Q ограничений, соответствующих
компонентам, к которым предъявляются требования ко времени выполнения.
Количество ограничений на среднее время выполнение программных модулей Q
может быть меньше либо равно количеству компонентов в системе.
Время расчета критериев S и Ts зависит от количества компонентов и связей
между ними. На персональном компьютере со средней производительностью
требуется около 1.5 сек. для расчета архитектуры из 10 компонентов, для
архитектуры из 1000 компонентов требуется около 150 секунд. С ростом
13
количества связей между компонентами требуется еще большее время. Эти
показатели обусловлены сложным алгоритмическим заданием функции S, а также
большим количеством вычислений на стороне БД, так как модель программной
архитектуры имеет реляционное представление.
Количество возможных решений рассчитывается следующим образом:
D
W

d 1
Ld


VardVerd
Vard  2 
Verd 2




 

F
Var ,
f
f 1
где W – количество комбинаций; D – количество программных компонентов, в
которых возможно введение избыточности; Vard – количество вариантов
«вероятность сбоя/трудозатраты» для компонента с возможностью введения
избыточности; Verd – количество используемых версий при введении избыточности
(2 ≤ Verd ≤ Ld); Ld – предельно допустимое количество версий компонента; F –
количество программных компонентов, в которых невозможно введение
избыточности; Varf – количество вариантов «вероятность сбоя/трудозатраты» для
компонента, в котором невозможно введение программной избыточности.
Проведенный анализ роста мощности пространства оптимизации позволяет
сделать вывод о том, что для решения задачи необходимо применение
генетического алгоритма (ГА). Причина в том, что количество решений задачи
определения оптимальной архитектуры ПО экспоненциально зависит от
количества компонентов архитектуры. А так как на вычисление целевых функций
требуется много времени, то перебор всех вариантов еѐ решения представляется
возможным только для малых архитектур и небольшого количества компонентов с
недетерминированными характеристиками. ГА успешно справляются с решением
такого рода задач.
Генотип решения поставленной задачи оптимизации программной
архитектуры состоит из генов компонентов, в которых возможно введение
программной избыточности и генов компонентов, в которых не предусматривается
введение программной избыточности.
Для компонентов, в которых возможно введение программной
избыточности, могут быть изменены следующие характеристики:
1.
Метод реализации программной избыточности: мультиверсионное
программирование (NVPij=1, RBij=0) или блок восстановления (NVPij=0, RBij=1).
Если выбран метод NVP, то устанавливается значение гена 0, если RB, то 1.
2.
Номер
варианта
(альтернативы)
Varv1
–
«вероятность
сбоя/трудозатраты». Возможные варианты задаются аналитиком для каждого
компонента (1≤Varv1≤Vij). Vij – количество альтернативных вариантов разработки
для каждого компонента.
3.
Номер варианта Varv2...Varv10 – вероятности сбоя для каждой версии
компонента, аналогично пункту 2 (0≤Varv2..10≤Vij, 0 – версии нет). Предельное
количество версий программного компонента, если будет применена
избыточность, заранее задается аналитиком и не может быть больше 10 версий, т.к.
большее количество вносит в компонент дополнительную сложность и стоимость,
неоправданную увеличением надѐжности.
Если гены все Varv2...Varv10 принимают значение 0, то считается, что
программная избыточность не вводится в данном компоненте (Bij=1).
14
Для компонентов, в которых не предусматривается введение программной
избыточности, изменяется только вариант Var вероятности сбоя компонента и
соответствующей трудоемкости для достижения этой вероятности сбоя (1 ≤ Var ≤
Vij).
Таким образом, фенотип особи (решения) формируется из переменных
характеристик программных компонентов. В таблице 2 представлен общий вид
фенотипа с примером аллелей.
Таблица 2 – Генотип и фенотип особи
Группа компонентов, с возможностью программной
избыточности
Компонент 1
NVP/RB
Varv1
1
3
..
Группа компонентов, без возможности
программной избыточности
Компонент N
Varv4
0
..
NVP/RB
Varv1
0
1
..
Компонент 1
Varv5
Var
0
2
Компонент M
..
Var
3
В предлагаемом генетическом алгоритме используется независимая селекция
Шаффера при многокритериальной оптимизации, а также модифицированный
оператор кроссинговера. Надѐжность и трудозатраты для компонентов с
возможной программной избыточностью определяются взаимодействующими
генами версий и метода избыточности. Разрывы хромосомы могут происходить как
между генами одного программного компонента, так и между генами разных
компонентов. Причем вероятность выбора точки разрыва хромосомы между
генами одного программного компонента (связанными генами) заранее задана
специалистом с помощью экспертной оценки.
Входные параметры ГА следующие:
размер популяции (N);
вероятность скрещивания (prob_cross);
вид скрещивания (1,2,3-точечное, равномерное);
вероятность разрыва связанных генов (prob_cross_inter);
вероятность мутации особи (prob_mutate);
вероятность мутации гена (prob_mutate_gen);
критерии останова (максимальное время работы time_ga, количество
популяций без улучшения решения (стагнация) stagnancy, количество популяций
pop_count);
процент популяций на обработку ограничений percent_bound;
количество ограничений на время выполнения компонентов B.
Собственно алгоритм реализуется следующей последовательностью
действий:
1.
Генерация родительской популяции P размером N случайных особей.
2.
Расчет критериев для всех особей популяции P.
3.
Пропорциональная селекция N/2 особей из P по критерию S в
промежуточную популяцию P’.
4.
Пропорциональная селекция N/2 особей по критерию Ts в
промежуточную популяцию P’.
5.
Скрещивание с вероятностью prob_cross N/2 случайно выбранных пар
особей из промежуточной популяции P’. Формирование основной популяции P из
N выбранных особей.
15
6.
Выполнение оператора мутации с вероятностью prob_mutate на
каждой особи основной популяции P и каждому гену особи с вероятностью
prob_mutate_gen.
7.
Расчет значений критериев оптимизации для всех особей популяции P.
8.
Выбор из популяции P недоминируемых решений. Если в найденных
ранее решениях есть решения, которые их доминируют, то stagnancy = stagnancy+1.
9.
Если сработал хотя бы один критерий останова, то остановка
алгоритма.
10. Если номер популяции меньше, либо равен percent_bound*pop_count,
то переход на шаг 3.
11. Пропорциональная селекция N/(2+Q) особей из P по критерию
нарушения ограничения на S в промежуточную популяцию P’.
12. Пропорциональная селекция N/(2+Q) особей по критерию нарушения
ограничения на Ts в промежуточную популяцию P’.
13. Пропорциональная селекция N/(2+Q) особей по каждому критерию
нарушения ограничения на время выполнения компонента RTij в промежуточную
популяцию P’.
14. Скрещивание с вероятностью prob_cross N/(2+Q) случайно выбранных
пар особей из промежуточной популяции P’. Формирование основной популяции P
из N выбранных особей.
15. Выполнение оператора мутации с вероятностью prob_mutate на
каждой особи основной популяции P и каждому гену особи с вероятностью
prob_mutate_gen.
16. Расчет критериев по ограничениям для всех особей популяции P.
17. Выбор из популяции P лучших решений по критериям ограничений.
Если в найденных ранее решениях есть лучше, то stagnancy = stagnancy+1.
18. Если сработал хотя бы один критерий останова, то остановка
алгоритма, иначе переход на шаг 11.
Недоминируемые решения, полученные на каждой итерации, отбираются в
множество Парето. Решения из множества Парето не могут быть предпочтены друг
другу, поэтому после его формирования задача может считаться математически
решенной.
В четвертой главе рассмотрена программная реализация генетических
алгоритмов, еѐ применение на реальной задаче проектирования программной
архитектуры. Также сформулирована методика применения ГА на стадии
архитектурного проектирования ПО.
ГА был применен на задаче проектирования программной архитектуры по
одной из модернизаций программно-технического комплекса «Администрирование
страховых взносов» (ПТК АСВ), используемого в Пенсионном фонде Российской
Федерации.
По оценочным данным было определено, что самое надѐжное и затратное
архитектурное решение имеет Ts = 720.2 чел-час. и S = 0.9904613, а самое
ненадѐжное и дешѐвое – Ts = 403.2 чел-час. и S = 0.9883245. Для выполнения
данной модернизации системы заданы следующие ограничения:
S ≥ 0.99,
Ts ≤ 650 чел-час.
16
Пространство оптимизации такой задачи составляет 7.03·108 решений.
Характеристики найденных недоминируемых вариантов модернизации системы
приведены в таблице 3.
Таблица 3 – Характеристики оптимальных вариантов модернизации
№ варианта
1
2
3
4
Коэффициент
готовности системы
0.9900439
0.9900628
0.9901376
0.9903010
Трудозатраты на
модернизацию,
чел-час.
549.41
561.94
564.37
578.16
Такое низкое количество найденных решений объясняется заданными
жесткими ограничениями и лимитом на количество расчетов функций критериев.
При наличии больших временных ресурсов на выполнение ГА может быть найдено
большее количество недоминируемых решений.
Разработанную систему Genetic Algorithm optimization software Architecture
можно использовать для поиска оптимальных решений при модернизации уже
существующего программного обеспечения. В этом случае характеристики
трудозатрат устанавливаются только для новых архитектурных компонентов.
На рисунке 1 представлен процесс проектирования применения архитектуры
с применением разработанной системы.
Рисунок 1 – Алгоритм применения ГА
17
Этап проектирования архитектуры носит итеративный характер, как и весь
жизненный цикл программного обеспечения. В случае если значения критериев,
найденные полным перебором или с помощью ГА, не удовлетворяют системного
архитектора, то он может принять решение об изменении компонентной структуры
и повторить поиск эффективных характеристик уже для другого архитектурного
решения.
Таким образом, разработанная автором программная система позволяет, с
одной стороны, задавать надѐжность функционирования будущей системы уже на
стадии архитектурного проектирования, с другой стороны – прогнозировать
возможность обеспечения заданной надѐжности при имеющихся ограниченных
трудовых ресурсах.
В пятой главе рассмотрена методика оценки трудозатрат на разработку
сложных программных систем, а также модернизацию уже существующих.
Обзор существующих моделей оценки надѐжности ПО и стоимости его
позволяет выделить следующие закономерности:
– нет моделей оценки стоимости, адекватно отражающих затраты на
введение программной избыточности;
– существующие модели оценки стоимости программного обеспечения не
позволяют учесть надѐжность разрабатываемой системы;
– существующие модели оценки надѐжности программного обеспечения
учитывают время тестирования, но не разработки;
Основные этапы предложенной методики оценки затрат на ПО следующие:
1.
Сбор и анализ технических требований заказчика.
2.
Декомпозиция задач, проектирование архитектуры.
3.
Группировка компонентов на типы (функциональные точки) по
аналогичному назначению и сложности.
4.
Определение избыточности программных компонентов.
5.
Оценка трудозатрат на разработку компонентов.
6.
Вычисление трудоемкости разработки.
7.
Определение затрат на этапы жизненного цикла. Предполагается, что
затраты времени на другие этапы работ в жизненном цикле программного
обеспечения пропорциональны затратам на этап разработки. На основании работ
по более ранним проектам вычисляется соотношение среднего времени,
затраченного на другие этапы жизненного цикла, к среднему времени разработки.
Вычисленные коэффициенты (соотношения) умножаются на трудоемкость этапа
разработки. Другими этапами могут быть работы по анализу или проектированию,
тестированию, документированию и работы менеджера по организации процесса.
8.
Вычисление финансовых затрат на модернизацию проекта.
Трудоемкость каждого этапа умножается на среднюю норму оплаты труда
сотрудника, работающего на данном этапе жизненного цикла. Затем полученные
суммы складываются.
Для проведения расчетов по приведенной методике используются
следующие параметры:
M – количество типов компонентов (функциональных точек);
i – тип компонента, i  M;
Ni – количество новых и подлежащих доработке компонентов i-го типа;
j – номер компонента i-го типа, j  Ni;
18
Ti – трудоемкость разработки компонента i-го типа, чел.-час;
vij – количество версий в компоненте, если вводится программная
избыточность (если программная избыточность не вводится, то vij = 1);
RBi – трудоемкость разработки среды исполнения i-й функциональной точки для
блока восстановления, чел.-час. (если RBi>0, то NVPi=0);
NVPi
– трудоемкость разработки среды исполнения i-й функциональной
точки для N-версионного программирования, чел.-час. (если NVPi>0, то RBi=0);
Tdev – трудоемкость этапа разработки, чел.-час;
Cdev – стоимость оплаты одного чел.-часа разработчика, руб;
E – количество этапов в жизненном цикле ПО, кроме этапа разработки;
ws – весовой коэффициент, определяющий долю трудоемкости этапа s от
трудоемкости этапа разработки;
Ts – трудоемкость этапа s, зависящего от этапа разработки;
Cs – стоимость оплаты одного чел.-часа сотрудника занятого на этапе s, руб;
Tp – общая трудоемкость проекта, чел.-час;
Сp – общая стоимость проекта, руб.
Трудоемкость разработки рассчитывается как сумма трудозатрат на
разработку всех компонентов каждого типа, с учетом матрицы vij, и трудозатрат на
реализацию среды исполнения, следующим образом:
M
Tdev 
Ni
 T  v
i
i 1
ij


 1  Ti  RBi  NVPi  .
j 1
Трудоемкость s-го этапа жизненного цикла рассчитывается
соответствующему весовому коэффициенту и трудоемкости этапа разработки:
Ts  ws  Tdev .
Общая трудоемкость проекта рассчитывается как:

T p  1 


E

s 1
по

ws   Tdev .


Формула расчета общей стоимости в детализированном виде выглядит
следующим образом:

Cp  


E

s 1

wsTdevCs   Cdev  

M
Ni
 T  v
i
i 1
j 1
ij


 1  Ti  RBi  NVPi 
.
Проверка методики была произведена на системе ПТК АСВ и показала
удовлетворительные результаты.
В
заключение
диссертации
приведены
основные
результаты
диссертационного исследования и выводы.
Основные результаты и выводы
В процессе диссертационного исследования были получены следующие
результаты:
1. Предложен подход к использованию зависимости надѐжности
функциональных точек и трудозатрат на еѐ достижение при планировании
трудозатрат на разработку ПО.
19
2. Модифицирована модель надѐжности архитектуры программного
обеспечения сложных информационно-управляющих систем с учетом введения
программной избыточности и трудозатрат на еѐ реализацию.
3. Модифицирован оператор кроссинговера в генетическом алгоритме,
позволяющий задавать вероятность выбора точки разрыва между связанными
генами.
4. Разработан, реализован и исследован новый генетический алгоритм
многокритериальной условной оптимизации.
5. Реализована программная система поддержки принятия решений о
выборе оптимальной архитектуры программного обеспечения.
6. Разработана методика оценки затрат на разработку или модернизацию
отказоустойчивых программных систем, позволяющая оценить трудовые и
финансовые затраты на все этапы жизненного цикла на основании оценки затрат на
этап разработки.
Апробация разработанной методики, модели, алгоритмов на тестовых и
реальных практических задачах подтвердило их эффективность при
проектировании отказоустойчивых программных систем, что является вкладом в
теорию и практику программной инженерии и системного анализа.
Таким образом, с помощью генетических алгоритмов решена техническая
задача
многокритериальной
условной
оптимизации
отказоустойчивой
программной архитектуры.
Публикации по теме диссертации
Статьи в рецензируемых изданиях, рекомендованных ВАК РФ:
1.
Шеенок Д.А., Жуков В.Г., Терсков В.А. Повышение надежности
программного обеспечения сложных систем // Вестник СибГАУ. Вып. 5(45). –
2012. – С. 28-33.
2.
Шеенок Д.А., Кукарцев В.В. Оценка затрат на модернизацию
программного обеспечения критических по надежности систем // Вестник СибГАУ.
Вып. 5(45). – 2012. – С. 62-65.
3.
Шеенок
Д.А.
Инструментальное
средство
проектирования
оптимальной архитектуры отказоустойчивых программных систем // Программная
инженерия. №6. – 2013. – С. 20-26.
4.
Шеенок Д.А. Оптимизация программной архитектуры при разработке
информационной системы Пенсионного Фонда России // Информационные
ресурсы России. №3. – 2013. – С. 30-33.
5.
Шеенок Д.А., Кукарцев В.В. Прогнозирование стоимости разработки
систем с программной
избыточностью
// Известия
Волгоградского
государственного технического университета №14(117). – 2013. (Сер. «Актуальные
проблемы управления, вычислительной техники и информатики в технических
системах». Вып. 17) – С. 101-105.
6.
Шеенок Д.А., Терсков В.А. Оптимизация программной архитектуры
на основе генетического алгоритма с аллелями в шкале порядка // Вестник
Воронежского государственного университета. Серия: Системный анализ и
информационные технологии. Вып. 2. – 2013. – С. 17-24.
20
Материалы конференций, статьи в сборниках:
7.
Шеенок Д.А., Ильин Е.С., Терсков В.А. Проблемы использования
вычислительных систем при управлении сложными технологическими процессами
// Вестник КРО РИА: сб. научн. трудов. Вып. 1(27). – 2010. – С. 98-103.
8.
Шеенок Д.А., Терсков В.А., Ильин Е.С. Повышение надежности
программного обеспечения систем управления технологическими процессами //
Труды пятнадцатой научно-технической конференции КрИЖТ ИрГУПС (5 мая
2011 г.). Т.1. – 2011. – С. 72-76.
9.
Шеенок Д.А., Программная надежность автоматизированных систем
управления технологическими процессами на железнодорожном транспорте //
Транспортная инфраструктура Сибирского региона: Материалы второй
межвузовской научно-практической конференции, 16-18 мая 2011 г. Иркутск. – том
1. – 2011. – С. 244-248.
10. Шеенок Д.А., Анализ существующих моделей оценки стоимости
разработки программного обеспечения // Электронное научно-практическое
периодическое издание «Экономика и социум». Вып. 5. – 2012. – С. 931-939.
11. Шеенок Д.А., Проектирование надежной архитектуры программного
обеспечения финансово-управленческих систем // Актуальные вопросы
технических, экономических и гуманитарных наук: Материалы VIII
международной заочной научно-практической конференции, г. Георгиевск, 5-6
декабря 2012 г. – 2012. – С. 27-30.
12. Шеенок Д.А. Генетический алгоритм поиска оптимальной
архитектуры программного обеспечения // Актуальные вопросы современной
науки: Материалы IV международной научной конференции 14-15 декабря 2012 г.
– 2012. – С.62-68.
13. Шеенок Д.А., Кукарцев В.В. Оптимизация программной архитектуры
логистических информационных систем // Логистические системы в глобальной
экономике: материалы Междунар. науч.-практ. конф. (14-15 марта 2013 г.,
Красноярск). Ч. 1. – 2013. – С.138-145.
14. Шеенок Д.А. Модификация модели программной архитектуры для
многокритериальной
условной оптимизации // Перспективы развития
информационных технологий: Материалы XI международной научно-практической
конференции. – 2013. – С.76-81.
15. Шеенок Д.А. Формирование модели трудозатрат для функциональных
точек программного обеспечения // Научные аспекты инновационных
исследований: Материалы I Международной конференции г. Самара, 6-8 марта
2013 г. – Т.1. – 2013. – С. 39-42.
16. Шеенок Д.А. Планирование трудозатрат при разработке надежных
программных систем // Техника и технология: новые перспективы развития:
Материалы VIII Международной научно-практической конференции (25.02.2013).
– 2013. – С. 46-50.
17. Sheenok Dmitry. The model dependence labor and software reliability //
The Strategies of Modern Science Development: International scientific – practical
conference (Yelm, WA, USA, 29-30 March 2013). – 2013. – P. 54-61.
21
Свидетельства о регистрации программных продуктов:
18. Шеенок Д.А. Система оценки затрат на модернизацию программного
обеспечения (Evaluation System Labor): свидетельство о государственной
регистрации программы для ЭВМ / Шеенок Д.А., Кукарцев В.В. – М.: Реестр
программ для ЭВМ, 2013. Номер гос. рег. №2013611112.
19. Шеенок Д.А. Система расчета надежности программной архитектуры
и трудозатрат (Software Architecture Reliability and Labor): свидетельство о
государственной регистрации программы для ЭВМ / Шеенок Д.А., Терсков В.А. –
М.: Реестр программ для ЭВМ, 2013. Номер гос. рег. №2013616127.
20. Шеенок Д.А. Генетический алгоритм оптимизации программной
архитектуры (Genetic Algorithm optimization software architecture): свидетельство о
государственной регистрации программы для ЭВМ / Шеенок Д.А., Терсков В.А. –
М.: Реестр программ для ЭВМ, 2013. Номер гос. рег. №2013616165.
22
Шеенок Дмитрий Александрович
Многокритериальная оптимизация отказоустойчивой программной
архитектуры специализированными эволюционными алгоритмами
Автореферат
Подписано к печати 06.11.2013. Формат 60х84/16
Уч. изд. л. 1.0 Тираж 100 экз. Заказ № 153
Отпечатано в типографии КрИЖТ ИрГУПС
660028, г. Красноярск, ул. Ладо Кецховели, 89.
1/--страниц
Пожаловаться на содержимое документа