CC BY
42
I выбор рациональной модели разработки безопасного программного обеспечения
Жидков И.В.1, Зубарев И.В.2, Хабибуллин И.В.3
Цель исследования: обоснование подходов к выбору рациональной модели разработки программного обеспечения на основе предлагаемой системы критериев.
Метод исследования: применялись методы теории принятия решений, метод ранжирования систем по совокупности скалярных компонент, в частности метод «жёсткого» ранжирования.
Результат исследования: проведен анализ основных моделей разработки программного обеспечения, рассмотрена система критериев, используемая для сравнения различных моделей разработки программного обеспечения, разработаны предложения по выбору рациональной модели разработки программного обеспечения на основе решения задачи гипервекторного ранжирования.
Ключевые слова: программное обеспечение, жизненный цикл программного обеспечения, модель разработки, метод ранжирования.
001: 10.21681/2311-3456-2021-5-21-29
1. Введение
Каждая из моделей разработки программного обеспечения (ПО) имеет присущие ей преимущества и недостатки, определяющие ее применение для конкретного проекта. Оптимальный выбор модели жизненного цикла (ЖЦ) ПО является комплексной задачей, требующей продолжительных исследований в данной области, накопления и систематизации знаний. Неверно выбранная модель может привести к перерасходу ресурсов и затягиванию сроков выполнения проекта, вплоть до полного провала [1]. Кроме того, правильный выбор модели ЖЦ ПО положительно скажется на его качестве и безопасности [2-6].
В литературе встречается несколько подходов к сравнению различных моделей разработки ПО.
В одном из подходов ключевыми критериям выбора методологии являются отношение методологии к каскадной или итерационной группе разработки, а также степень формальности разработки рабочих материалов. Примерами использования этих показателей для сравнения методологий можно найти, например, в [7, 8].
В [1] сделан вывод, что каждому проекту своя методология», то есть отмечено, что для каждого конкретного проекта «оптимальной» будет одна какая-то методология и существенную роль в поисках нужной методологии играет определение принципов, по которым ее можно было бы разработать. Полагается, что методологии целесообразно классифицировать по размеру команды разработчиков и критичности системы, так как именно они лучше всего подходят для изначальной оценки.
Другой подход используется в работе Эрика Дж. Брауде «Технология разработки программного обеспе-
чения» [9]. В ней сравниваются процессы разработки ПО по четырем факторам: легкость контроля документации, возможность взаимодействия с заказчиком, поддержание хорошего проектирования и сбор метрических данных, собранных в ходе проекта. Выбор осуществляется только из трех процессов разработки ПО (водопадного, спирального и инкрементального) и сводится к решению вопроса о количестве итераций.
В курсе лекций «Верификация программного обеспечения» Московского инженерно-физического института [10] С.В. Синицыным и Н.Ю. Налютиным сравниваются отдельно четыре типа жизненного цикла (каскадный; ^образный; спиральный и экстремального программирования) по трем критериям: длина цикла; верификация и внесение изменений; интеграция отдельных компонент системы. Далее осуществляется сравнение технологий MSF, RUP и ХР по четырем критериям: оптимальная команда; соответствие стандартам; допустимые технологии и инструменты; удобство модификации и сопровождения.
Приведенные подходы представляются слишком грубыми, так как сравнение моделей ЖЦ ПО осуществляется на качественном уровне, при этом не учитывается ряд других факторов. Исключительно качественное сравнение не позволяет выбрать именно оптимальную для данного проекта модель разработки ПО.
Количественное сравнение моделей разработки ПО используется в работе «Управление программными проектами: достижение оптимального качества при минимуме затрат» [11]. Специально для выбора модели ЖЦ разработаны 32 критерия, сгруппированных
1 Жидков Игорь Васильевич, кандидат технических наук, доцент, сотрудник ФГБУ «3 ЦНИИ» Минобороны России, г Москва, Россия. E-mail: igorzh@bk.ru
2 Зубарев Игорь Витальевич, кандидат технических наук, доцент, начальник департамента АО "НПК "Техмаш", г Москва, Россия. E-mail: i.v.zubarev@tecmash.ru
3 Хабибуллин Ильфат Винирович, сотрудник Восьмого управления ГШ ВС РФ, г Москва, Россия. E-mail: rainaira1632@mail.ru
по четырем категориям: характеристики требований, характеристики участников команды разработчиков, характеристики коллектива пользователей, характеристики типа проектов и рисков. Данный подход используется в сертификационных программах менеджмента качества программных проектов Института качества программного обеспечения (Техасский университет, г. Остин, США), а также программе подготовки на получение звания сертифицированного инженера от Американского общества качества. Однако, приведенная процедура выбора оптимальной модели на использовании независимых таблиц критериев для каждой категории, упорядочении их по степени важности для данного проекта, описана не подробно, из-за чего не ясна. В то же
время данный набор критериев представляется одновременно недостаточно полным и отчасти избыточным.
В работе В.В. Бахтизина и Л.А. Глуховой [12] уточняется приведенная выше классификация проектов [11], предназначенная для выбора модели жизненного цикла программных средств. В ней для сравнения к имеющимся 32 критериям добавлены еще три: масштабность, стабильность и критичность продукта проекта. Кроме того, описана процедура выбора модели жизненного цикла программных средств на основе сводной таблицы критериев классификации проектов.
В работах Барабанова А.В. и Маркова А.С. [13, 14], посвященных созданию безопасного программного
Таблица 1
Система критериев, используемая для сравнения различных моделей разработки ПО
Критерии и категории, характеризующие модели разработки ПО Обозначение Примечание
Характеристики требований к проекту
Могут ли все требования к проекту не задаваться сразу в начале ЖЦ (до начала проектирования)? 0 — нет; 1 — да.
Могут ли требования изменяться в процессе итерации? К1.2 0 — нет; 1 — возможно; 2-да.
Приветствуется ли изменение требований даже на поздних этапах разработки ради достижения заказчиком конкурентного преимущества? К,3 0 — нет; 1 — да.
Необходимо ли демонстрировать требования с целью их определения и/или для проверки концепции? К14 0 — нет; 1 — да.
Характеристики команды разработчиков К2
Являются ли проблемы предметной области проекта новыми для большинства разработчиков? К21 0 — нет; 1 — да.
Являются ли инструменты, используемые в проекте новыми для большинства разработчиков? К22 0 — нет; 1 — да.
Является ли команда разработчиков самоорганизующейся? К23 0 — нет; 1 — да.
Могут ли меняться роли участников проекта? К24 0 — нет; 1 — да.
Характеристики пользователей и заказчика К3
Частота отслеживания заказчиком хода выполнения проекта. К31 Задан интервалами значений. 0 — реже 1 раза в 2 месяца; 1- раз в 1-2 месяца; 2- раз в 1 -2 недели; 3- ежедневно / раз в несколько дней.
Критерии и категории, характеризующие модели разработки ПО Обозначение Примечание
Вовлечены ли пользователи в фазы жизненного цикла? К3.2 0 — нет; 1 — частично; 2 — на всех этапах.
Характеристики типов проектов и рисков К 4
Будет ли проект являться расширением существующей системы? К4.1 0 — нет; 1 — да.
Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла? К4.2 0 — возможно, нет; 1 — да.
Ожидается ли длительная эксплуатация продукта? К43 0 — нет; 1 — возможно; 2-да.
Будет ли продукт изменяться (возможно, с применением непредвиденных методов), на этапе сопровождения (стабильность продукта)? К4.4 Задан интервалами значений. 0 — маловероятно; 1 — возможно; 2 — постоянно.
Масштаб разрабатываемого продукта. К4.5 Задан интервалами значений. 0 — нет; 1 — средний; 2 — да.
Критичность разрабатываемого продукта, влияющая на уровень безопасности ПО. К46 Задан интервалами значений. 0 — потеря комфорта; 1 — потеря денег; 2 — потеря больших денег и бизнеса; 3 — потеря жизни.
Характеристики процесса разработки К5
Будет ли проектирование и конструирование отдельно каждого свойства системы / пошаговая детализация? К5.1 0 — нет; 1 — возможно; 2 — да.
Будет ли учитываться требования ГОСТов серий 19 и/или 34? К52 0 — нет; 1 — да.
Степень формализации разработки рабочих материалов. К5.3 0 — низкая (работающее ПО выше всеобъемлющей документации); 1 — высокая (детальная документация, большое кол-во документов, формальные процедуры рецензирования); 2 — средняя (документация в основном сконцентрирована на конечном продукте).
Необходимо ли как можно быстрее получить первые версии работающей программы? К54 0 — нет; 1 — да.
обеспечения, разработана концептуальная теоретико-множественная модель, включающая в том числе совокупность мер безопасного программирования с учетом требований «ОК».
Основным недостатком рассмотренных концептуальных подходов является недостаточная проработка выбора критериев при наличии ресурсных и временных ограничений. В данной статье сделана попытка комплексирова-ния указанных подходов по критерию рациональности.
2. Система критериев для сравнения моделей разработки ПО
Для выбора оптимальной модели разработки ПО предлагается использовать систему критериев, представленную в таблице 1.
Представленная в таблице 1 система критериев служит базой для сравнения, оценки и окончательного выбора модели разработки ПО. Она основана на подходе, используемом в работе «Управление программными проектами: достижение оптимального качества при минимуме затрат» [9] - 20 критериев предлагается разделить на 5 категорий (векторных компонент).
Первая векторная компонента - характеристики требований, классифицирует проекты в зависимости от возможности изменения требований пользователей и заказчика к разрабатываемому продукту. К ней относятся, например, такие частные критерии, как возможность формулирования требований в начале жизненного цикла, возможность изменения требований на протяжении жизненного цикла.
Вторая векторная компонента - характеристики команды разработчика, определяет проекты с учетом особенностей коллектива разработчиков и учитывают тот факт, что от этих особенностей зависит успех реализации проекта. В частности, к данной категории относятся такие частные критерии, как новизна инструментальных средств проекта для большинства разработчиков и новизна предметной области.
Третья векторная компонента - характеристики пользователей и заказчика, классифицирует проекты в зависимости от возможной степени участия пользователей (заказчиков) в процессе разработки и их взаимосвязи с командой разработчиков на протяжении проекта. Например, к данной категории относятся такие критерии, как степень вовлеченности пользователя в ЖЦ разработки и частота отслеживания заказчиком хода выполнения проекта. Заметим, что один из критериев задан интервалами значений.
Четвертая векторная компонента - характеристики типов проектов и рисков, отражает масштаб проекта, особенности эксплуатации, достаточность ресурсов для его исполнения и т.д. [15]. К данной категории относятся: предполагаемая длительность эксплуатации программных средств (ПС), требования к уровню надежности разрабатываемого ПС и другие частные критерии. Причем три критерия заданы интервалами значений.
Пятая векторная компонента - характеристики процесса разработки, отражает особенности процесса разработки, например, учет требований российских стандартов серий 19.ХХХ и 34.ХХХ, степень формализации
разработки рабочих материалов и др. То есть, в данной категории приведены частные критерии, являющиеся отличительными особенностями различных моделей разработки ПО.
3. Математическая постановка задачи
С использованием методов теории принятия решений [16, 17] предлагаемая система критериев позволяет проводить оценку множества различных моделей разработки ПО. Для такой оценки широкое применение нашли различные методы ранжирования. Удачно выбранный метод ранжирования позволяет:
- найти множество эффективных вариантов (множество Парето);
- найти множество неэффективных вариантов;
- построить упорядоченное множество эффективных вариантов (кортеж Парето). Для однозначного понимания введем следующие определения [1]: Определение 1. Многокритериальными называют
задачи, в которых векторный критерий представляет собой упорядоченное множество скалярных компонент.
Определение 2. Многовекторными называют задачи, в которых векторный критерий представляет собой упорядоченное множество векторных компонент, а каждая векторная компонента - упорядоченное множество скалярных компонент.
Определение 3. Гипервекторными называют задачи, в которых векторный критерий представляет собой упорядоченное множество многовекторных компонент, каждая многовекторная компонента - упорядоченное множество векторных компонент, а каждая векторная компонента - упорядоченное множество скалярных компонент.
Определение 4. Кортеж Парето - упорядоченное множество эффективных вариантов.
Определение 5. Подкортеж Парето - упорядоченное подмножество эффективных вариантов.
Как показывает анализ системы критериев, используемых для сравнения различных моделей разработки ПО, задача принятия решений сводится в данном случае к задаче гипервекторного ранжирования [1]. Рассмотрим математическую постановку и метод решения такой задачи.
Введём необходимые в дальнейшем обозначения:
5 = {{а = 1 п} - множество моделей разработки ПО (моделей);
= Д£ = 1 е} _ множество многовекторных компонент Ке (Ба), характеризующих модель разработки ПО (модель) 5а е 5;
КЕ(= \кс] ) 7 = 1 гЕ} - множество векторных компонент, характеризующих модель Я;
К
= {КЕРi = 1
множество скалярных
компонент, характеризующих модель 5а;
А = |аЕ, е= 1 - множество коэффициентов важноЕ
многовекторных компонент, причем = 1;
к №)
сти
м
р =
К()= &)5Р еР
=№ ) №
е Р
(3)
АЕ = |аЕ;.,у = 1 гЕ| - множество коэффициентов важности векторных компонент модели Ба, причем
£ав] =1 е=1Е ;
Л . = |а... 1 г. > - множество коэффициентов важ-
ь} ^ ЕР Е3 )
ности скалярных компонент, причем
г г _ _
Ха =1 ] =1 г^ £=1Е;
- множество эффективных (Парето оптимальных) систем с числом элементов п71, Б71 е 5; Б0р е5п - модели, которые входят в множество эффективных решений, р е {1,и};
= {А {£>а)>I = 1,М} - множество ограничений, накладываемых на модели, причем должно выполняться условие
ц(за)<{д0,/ = 1,м}, (1)
где D° - допустимое значение /'-го ограничения, М -число ограничений;
и выполняется условие (1).
Допустим, нам известен метод ранжирования систем по совокупности скалярных компонент Ке(Ба), е = 1,Е, ] = 1,ге), например, метод «жёсткого» ранжирования. После его применения будут построены частные кортежи Парето, которые позволят однозначно определить расположение модели разработки ПО относительно других моделей по каждой векторной компоненте. Причём выявляются как доминирующие (доминируемые), так и эквивалентные модели. Это позволяет придать всем векторным компонентам некоторые числа, значения которых зависят от расположения моделей: для доминируемых моделей эти значения больше, чем для доминирующих, а для эквивалентных моделей разработки ПО эти значения будут равными. Назовём такие числа псевдозначениями (рангами) векторных компонент. Введение таких псевдозначений позволяет вновь применить метод «жёсткого» ранжирования (число обращений к методу будет равно числу многовекторных компонент, т. е. Е раз) и построить частные кортежи Парето.
В результате решения задачи получаем расположение моделей по совокупности многовекторных компонент К (Б), е = 1, Е. Это, в свою очередь, позволяет обоснованно ввести псевдозначения многовекторных компонент и вновь обратиться к методу «жёсткого» ранжирования. В итоге и будет построен искомый кортеж Парето.
Таким образом, для решения задачи гипервекторного ранжирования метод «жёсткого» ранжирования при-
меняется
Е +1 +
раз.
упорядоченное множество эф-
фективных моделей (кортеж Парето); элементы кортежа ранжированы в соответствии с решающими правилами так, что выполняется условие
где «>-» — знак отношения доминирования, к;е {1,2,...,и}. Длина кортежа равна пп;
Р ={30,30,...,- упорядоченное множество эффективных моделей (подкортеж Парето). Длина подкор-тежа равна Я.
Допустим, известны множества А, А, Ае, Б, Кт(БВ(Ба), (а = 1,п; е = 1,Е, ] = 1,гЕ), решающие правила. Требуется найти кортеж Парето Р, для элементов которого справедливо
(2)
и выполняется условие (1).
При построении подкортежа Парето РЯ заданной мощности Я необходимо определить подмножество упорядоченных моделей, для элементов которого справедливо
Заметим, что многокритериальную задачу ранжирования можно представить как задачу ранжирования систем с двумя уровнями иерархии критериев, многовекторную - с тремя уровнями иерархии критериев, а гипервекторную - с четырьмя уровнями иерархии критериев. Нетрудно видеть, что предлагаемая идея последовательного ранжирования, введения псевдозначений для векторных и многовекторных компонент позволяет решать задачу ранжирования моделей с любым числом уровней иерархии критериев. В частности, рассмотренный подход применим и для решения задачи гипервекторного ранжирования, если сложная система характеризуется:
- критериями, заданными интервалами значений;
- критериями, заданными в неформализованном (нечётком) виде.
Замечание 1. При значении Е=1 имеем задачу многовекторного ранжирования.
Замечание 2. При значениях Е=1 и гс=1 имеем задачу многокритериального ранжирования. Замечание 3. Метод гипервекторного ранжирования не зависит от принятого решающего правила.
4. Сущность метода жёсткого ранжирования
Рассмотрим теперь основные идеи метода жёсткого ранжирования. Без потери общности изложение будем
проводить для моделей Ба = 1,п, свойства которых задают с помощью критериев К (Б), у = 1, г. В ходе решения задачи будем анализировать множество упорядоченных пар моделей Б (к = 1,п; I = 1,п; кф-1). а результат анализа заносить в специальную оценочную матрицу \\С
если
Определение 6.
ИI I ■
Под
если
то
если
то
если
то
если
щ щ, = {1,г},
С = 1 С = 1
щ={{7} щ=0, щ=0,
Ск1 = N2,С1к = 0, N2 »1;
Щ = 0,Щ = {1,г}, Щ = 0 С = 0 С = N
(4)
(5)
(6)
(7)
(8)
(9)
(10)
Си = N3,Сл = 0,1« N3 < N2
^ = 0,^ Ф0,К-= Ф0, С = 0 С = N
оценочной матрицей \\С\\ если
(к = 1,п; I = 1,п; Щ) понимаем такую матрицу, элементы Сы которой позволяют однозначно определить соотношение между к-й и 1-й моделями.
Сущность метода заключается в следующем: 1. На_основе_попарного сравнения моделей (k = 1, п; I = 1, п; кф1) определяем элементы Си оценочной матрицы \ \Ск\\. Значения элементов Си подбирают таким образом, чтобы отсечь неэффективные модели. У эквивалентных моделей Бк Б 1 все соответствующие критерии равны. Полагаем, Сы = 1, Ск = 1.
К числу неэффективных моделей отнесем варианты, у которых:
а) все значения критериев 1-й модели хуже, чем у к-й модели, тогда полагаем Сы = N>>1;
б) значения т(т<г) критериев 1-й модели хуже соответствующих значений критериев к-й модели при равных соответствующих значениях остальных критериев этих моделей; тогда полагаем Си = N3, 1<<^3<^2.
Если же для моделей к, / имеем лучшие, худшие и. возможно, равные критерии, то значение Си определим по методу, изложенному в [17].
Запишем теперь более строго выражения для элементов оценочной матрицы. Обозначим Nк|+, — соответственно подмножества номеров лучших, худших и равных критериев для каждой пары вариантов моделей Б^ Б(к = 1, п; I = 1, п; кф-1). Будем осуществлять попарное сравнение моделей на основе анализа критериев К.(Б/), К.'.(Б), j = 1,г). Для возможных значений подмножеств номеров Nk¡+, Nk¡, Nk= (соответственно лучших, худших и равных критериев) введем следующие значения элементов оценочной матрицы \\С\\:
К+и Ф0, Щ Ф0, >0 то определим Сы в виде [17]
Г Л-1
с* = Е V Е
V=N1,
с = с -1
' к,
(11) (12)
(13)
(14)
(15)
и=Мм
Теорема. Если в 1-м ((е{1,п} столбце оценочной матрицы максимальный элемент больше или равен значению N2, , то 1-й вариант модели не принадлежит множеству эффективных решений.
Доказательство. Из условия теоремы следует, что хотя бы для одного из вариантов к (к е{1,п},к ф I) выполняется одно из условий (6), (10). Таким образом, вариант/ доминируется вариантом к. Значит, согласно определению множества Парето, /-й вариант не может принадлежать множеству эффективных решений.
2. Для формулировки решающих правил (специальных неформальных правил, зависящих от специфики задачи и позволяющих провести ранжирование систем) введем числа: Н1 - количество элементов в /-м столбце оценочной матрицы, значение которых больше единицы; М1 -количество элементов в /-м столбце той же матрицы, значение которых меньше единицы; СМтх - максимальное значение элемента в /-м столбце матрицы || Ск/1|.
Физический смысл чисел:
мого множества превышают 1-ю;
М. - сколько вариантов доминирует /-я модель; С определяет, во сколько раз /-я модель «превы-
» к-й {к е{1, п
то
шается
Для реализации «жесткого» ранжирования перейдем от одношагового процесса поиска приоритетного расположения моделей к многошаговому процессу.
Общая идея заключается в следующем. На каждом шаге ф=1,2,...,п-1) выбираем.-ю модель, лучшую с точки зрения предлагаемого ниже решающего правила. Затем ее номер включаем в множество Р и в последующем рассмотрении ¡-я система больше не участвует (в матрице ||Ск/1| вычеркиваем_/'-ю строку и.-й столбец). Указанная процедура позволяет исключить влияние модели Б. на выбор лучшей модели, проводимый уже на шаге ^+1).
При реализации многошагового поиска необходимо сформировать такие решающие правила, которые позволяют определить на каждом шаге ф=1,2,...,п-1);
- лучшую (доминирующую) модель либо подмножество кандидатов на эквивалентные доминирующие модели;
- эквивалентные модели из числа кандидатов, а также провести ранжирование моделей, не попавших в эквивалентные.
Н. - показывает, сколько моделей из рассматривае
При формулировке решающих правил вновь используем, но теперь на каждом шаге /, числа И(,) , М(,), С№к1тах, которые имеют оговоренный ранее физический смысл. Ранжирование, как и прежде, осуществляем лишь для эффективных моделей. Все неэффективные варианты запоминаем и из решения исключаем.
5. Разработка методики «жёсткого» ранжирования
Для обоснования методики, по которой должно проводиться ранжирование, определим решающие правила «жёсткого» ранжирования:
1. Ранжирование необходимо проводить среди эффективных моделей по шагам. Число шагов (<(п-1).
2. На каждом шаге (=1,2,...,п-1) нужно:
- найти числа И(,), М(,), С(,)Мтх, и определить лучшую модель Б. с минимальным значением И(,). и
3. Найти числа м() С^ и определить л) модель Б. с минимальными значениями Щ'. Если
) чшую
' Гг»л м
С > IV/ е{1, п},/ Ф ] - номер}занести в множество Р;
исключить из оценочной матрицы ]-ю строку и ]-й столбец.
Если системы с номерами ^ е Ьк() = \11,12,...,¡),...,¡к(А имеют одинаковые минимальные значения Н, то лучшей является модель
V
Sl с максимальным значением М( = тах .
3. Если модели с номерами
I) е ьк(1) = \1х, 12,..., 1],..., 1к()} имеют соответственно
одинаковые значения Нто из оценочной матрицы надо выделить подматрицу с номерами столбцов
и строк ¡] (( = 1,k() и провести ранжирование ее элементов.
4. Эквивалентные модели Sl ,1] еLm с Lк, следует
упорядочить на основе анализа чисел МС(тах, полученных на первом шаге.
На основе метода «жесткого» ранжирования сформулируем методики многокритериального и гипервекторного ранжирования.
Методика решения задачи многокритериального ранжирования
1. Провести анализ исходной информации. Определить критерии, по которым будут сравниваться модели, коэффициенты важности критериев или группы коэффициентов важности.
Вычислить элементы оценочной матрицы ЦСЫ ||. С этой целью использовать выражения (1.4)-(1.15).
2. Определить неэффективные, в паретовском смысле, модели. Запомнить их номера.
Провести ранжирование моделей по шагам. Число шагов равно (п-1). Положить 1=0. Положить (=(+1.
таких моделей несколько, то лучшей среди них будет модель с максимальным значением Если число моделей с равными максимальными значениями Му более единицы, то лучшей будет модель с минимальным значением С/ .
к1тах
Если лучшие модели имеют соответственно равные значения Н(, С(тах , то такие модели считают эквивалентными.
Запомнить номерзанести его в кортеж Парето Р. Исключить из оценочной матрицы ]-ю строку ]-й столбец.
Если <п-1, перейти к шагу 5, иначе - к шагу 10. Занести в множество Парето Р оставшуюся модель.
4. Если задача решается для одной группы коэффициентов важности - перейти к шагу 13, иначе - к шагу 12.
5. Если задача решается для множества групп коэффициентов важности, повторить шаги 2-10 нужное число раз. Перейти к шагу 13.
6. Провести анализ результатов решения. При необходимости повторить шаги 2-12. Перейти к шагу 14.
7. Конец решения.
Методика решения задачи гипервекторного ранжирования
1. Провести анализ исходной информации, формирование критериев оценок моделей, определить коэффициенты важности критериев.
2. Провести ранжирование моделей по множеству скалярных компонент каждой векторной компоненты.
3. Определить псевдозначения векторных компонент.
4. Провести ранжирование моделей по множеству векторных компонент (построить частные кортежи Парето).
5. Определить псевдозначения многовекторных компонент.
6. Построить кортеж Парето.
7. Провести анализ результатов решения.
8. В случае необходимости уточнить исходные данные и (или) изменить коэффициенты важности критериев. Перейти к шагу 2. В противоположном случае перейти к шагу 9.
9. Конец решения.
6. Выводы
Таким образом, рассмотрена важная в прикладном плане задача гипервекторного ранжирования моделей разработки ПО.
Основу метода гипервекторного ранжирования составляет метод «жесткого ранжирования», который по-
следовательно применяется
Е +1 +
раз.
Решение задачи оказалось возможным благодаря введению псевдозначений векторных и многовекторных компонент. Более подробно методы ранжирования рассмотрены в [17].
Литература
1. Федорец О.Н., Грибков В.В. Модели и методы разработки безопасного программного обеспечения. Монография. - М.: Типография «Славянская Поляна», 2009. 187 с.
2. Буйневич М.В., Израилов К.Е. Аналитическое моделирование работы программного кода с уязвимостями // Вопросы кибербезо-пасности. 2020. № 3 (37). С. 2-12. DOI: 10.21681/2311-3456-2021-3-02-12
3. Казарин О. В., Скиба В. Ю. Реализация практически значимых проактивно безопасных компьютерных систем // Защита информации. Инсайд. 2015. № 5. С. 40-43.
4. Методы оценки несоответствия средств защиты информации / А.С.Марков, В.Л.Цирлов, А.В.Барабанов. М.: Радио и связь, 2012. 192 с.
5. Петренко А.С., Петренко С.А. Безопасная Agile-разработка системы ЭДО // Защита информации. Инсайд. 2018. № 3 (81). С. 30-35.
6. Соловьёв В.С., Язов Ю.К. Информационное обеспечение деятельности по технической защите информации // Вопросы кибербе-зопасности. 2021. №1(41). С.69-79. DOI: 10.21681/2311-3456-2021-1-69-79
7. Забродин А.А., Макарец А.Б. Преимущества и недостатки использования гибких методологий разработки программного обеспечения Microsoft solutions framework (MSF), Rational unified process (RUP) и Extreme programming / В сборнике: Математика и математическое моделирование. Сборник материалов XIII Всероссийской молодежной научно-инновационной школы. 2019. С. 335-336.
8. Никулина А.С., Тынянова С.Е., Голубева А.И. Понятие и основные принципы RUP и UML // Аллея науки. 2018. Т. 2. № 7 (23). С. 707-712.
9. Brown S. Software Architecture for Developers. Category: Computer science Software development technology. Leanpub, 2015. 275 p.
10. Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения: учебное пособие. М.: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2008.
11. Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. М.: Издательский дом «Вильямс», 2003.
12. Бахтизин В.В., Глухова Л.А. Выбор модели жизненного цикла разработки программных средств и систем на основе сводной таблицы критериев классификации проекта // Доклады белорусского государственного университета информатики и радиоэлектроники. 2005. январь - март, №1. C. 110-113.
13. Барабанов А.В., Марков А.С., Цирлов В.Л. 28 магических мер разработки безопасного программного обеспечения // Вопросы кибербезопасности. 2015. № 5 (13). С. 2-10.
14. Barabanov A., Markov A. Modern trends in the regulatory framework of the information security compliance assessment in Russia based on Common Criteria / В сборнике: ACM International Conference Proceeding Series. Proceedings of the 8th International Conference on Security of Information and Networks, SIN 2015. 2015. С. 2799980
15. Probabilistic Modeling in System Engineering / By ed. A. Kostogryzov — London: IntechOpen, 2018. 278 p. 10.5772/ intechopen.71396. DOI: 10.5772/intechopen.71396
16. Ряполова Е.И., Шрейдер М.Ю., Боровский А.С. Метод обработки информации для поддержки принятия решений в управлении облачным сервисом // Вопросы кибербезопасности. 2018. № 3 (27). С. 39-46. DOI: 10.21681/2311-3456-2018-3-39-46
17. Сафронов В.В. Основы системного анализа: методы многовекторной оптимизации и многовекторного ранжирования: Монография. - Саратов: Научная книга, 2009. 329 с.
choosing a rational model for development
secure software
ZhidkovI.V.4, ZubarevI.V.5, Khabibullin I.V.6
Objective: the purpose of the study is to justify approaches to selecting a rational software development model based on the proposed criteria system.
Methods: during the research, the methods of decision theory, the method of ranking systems by the set of scalar components, in particular, the method of "hard" ranking, were used.
Study result: analysis of the main models of software development was carried out, a system of criteria used to compare different models of software development was considered, proposals for selecting a rational model of software development based on solving the problem of hypervector ranking were developed.
Keywords: software, software lifecycle, development model, ranking method.
4 Igor Zhidkov, Ph.D., Associate Professor, FSBI «3 Central Research Institute» of the Ministry of Defense of Russia, Moscow, Russia. E-mail: igorzh@bk.ru
5 Igor Zubarev, Ph.D., Associate Professor, Head of Department, Techmash, Moscow, Russia. E-mail: i.v.zubarev@tecmash.ru
6 Ilfat Khabibullin, Russian Defense Ministry employee, Moscow, Russia. E-mail: rainaira1632@mail.ru
References
1. Fedoretc O.N., Gribkov V.V. Modeli i metody~ razrabotki bezopasnogo programmnogo obespecheniia. Monografiia. - M.: Tipografiia «Slavianskaia Poliana», 2009. 187 s.
2. BuTnevich M.V., Izrailov K.E. Analiticheskoe modelirovanie raboty~ programmnogo koda s uiazvimostiami // Voprosy~ kiberbezopasnosti. 2020. № 3 (37). S. 2-12. DOI: 10.21681/2311-3456-2021-3-02-12
3. Kazarin O. V., Skiba V. lu. Realizatciia prakticheski znachimy~kh proaktivno bezopasny~kh komp~iuterny~kh sistem // Zashchita informatcii. InsaPd. 2015. № 5. S. 40-43.
4. Metody~ ocenki nesootvetstviia sredstv zashchity~ informatcii / A.S.Markov, V.L.Tcirlov, A.V.Barabanov. M.: Radio i sviaz\ 2012. 192 s.
5. Petrenko A.S., Petrenko S.A. Bezopasnaia Agile-razrabotka sistemy~ E~DO // Zashchita informatcii. InsaPd. 2018. № 3 (81). S. 30-35.
6. Solov~yov V.S., lazov lu.K. Informatcionnoe obespechenie deiatePnosti po tekhnicheskoP zashchite informatcii // Voprosy~ kiberbezopasnosti. 2021. №1(41). S.69-79. DOI: 10.21681/2311-3456-2021-1-69-79
7. Zabrodin A.A., Makaretc A.B. Preimushchestva i nedostatki ispoPzovaniia gibkikh metodologiP razrabotki programmnogo obespecheniia Microsoft solutions framework (MSF), Rational unified process (RUP) i Extreme programming / V sbornike: Matematika i matematicheskoe modelirovanie. Sbornik materialov XIII VserossiPskoP molodezhnoP nauchno-innovatcionnoP shkoly\ 2019. S. 335-336.
8. Nikulina A.S., Ty~nianova S.E., Golubeva A.I. Poniatie i osnovny~e printcipy~ RUP i UML // Alleia nauki. 2018. T. 2. № 7 (23). S. 707-712.
9. Brown S. Software Architecture for Developers. Category: Computer science Software development technology. Leanpub, 2015. 275 p.
10. Sinitcy~n S.V., Naliutin N.Iu. Verifikatciia programmnogo obespecheniia: uchebnoe posobie. M.: Internet-Universitet Informatcionny~kh tekhnologiP; BINOM. Laboratoriia znanii\ 2008.
11. Fatrell R.T., Shafer D.F., Shafer L.I. Upravlenie programmny~mi proektami: dostizhenie optimaPnogo kachestva pri minimume zatrat. Per. s angl. M.: IzdatePskiP dom «ViPiams», 2003.
12. Bakhtizin V.V., Gluhova L.A. Vy~bor modeli zhiznennogo tcicla razrabotki programmny~kh sredstv i sistem na osnove svodnoP tablitcy~ kriteriev classifikatcii proekta // Doclady~ belorusskogo gosudarstvennogo universiteta informatiki i radioe~lektroniki. 2005. ianvaP - mart, №1. C. 110-113.
13. Barabanov A.V., Markov A.S., Tcirlov V.L. 28 magicheskikh mer razrabotki bezopasnogo programmnogo obespecheniia // Voprosy~ kiberbezopasnosti. 2015. № 5 (13). S. 2-10.
14. Barabanov A., Markov A. Modern trends in the regulatory framework of the information security compliance assessment in Russia based on Common Criteria / V sbornike: ACM International Conference Proceeding Series. Proceedings of the 8th International Conference on Security of Information and Networks, SIN 2015. 2015. S. 2799980
15. Probabilistic Modeling in System Engineering / By ed. A. Kostogryzov — London: IntechOpen, 2018. 278 p. 10.5772/ intechopen.71396. DOI: 10.5772/intechopen.71396
16. Riapolova E.I., ShrePder M.Iu., BorovskiP A.S. Metod obrabotki informatcii dlia podderzhki priniatiia resheniP v upravlenii oblachny~m servisom // Voprosy~ kiberbezopasnosti. 2018. № 3 (27). S. 39-46. DOI: 10.21681/2311-3456-2018-3-39-46
17. Safronov V.V. Osnovy~ sistemnogo analiza: metody~ mnogovektornoP optimizatcii i mnogovektornogo ranzhirovaniia: Monografiia. -Sarahtov: Nauchnaia kniga, 2009. 329 s.
