Управление рисками ИТ-проектов на основе компонентной структуры разрабатываемого программного обеспечения Текст научной статьи по специальности «Экономика и бизнес»

Управление рисками ИТ-проектов на основе компонентной структуры разрабатываемого программного обеспечения

Титов А. И.

Петербургский государственный университет путей сообщения Императора Александра I

Санкт-Петербург, Россия titovvvv@rambler.ru

Аннотация. Рассматриваются распространенные риски ИТ-проектов, приводится обзор методов управления рисками, основные этапы идентификации рисков. Для оценки влияния риска используется вербально-числовая шкала Харрингтона. Описывается агрегирование оценки рисков по каждому компоненту в общую оценку. Рассматривается задача управления идентифицированными рисками и предлагается метод управления рисками, основанный на компонентной структуре разрабатываемого программного обеспечения.

Ключевые слова: управление проектами, управление рисками, разработка програмного обеспечения.

ВВЕДЕНИЕ

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

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

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

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

Обзор рисков ИТ-проектов

Управление рисками как одна из составных частей управления проектами описано в руководствах [1-3]. Применительно к сфере информационных технологий управление рисками описывается в работах, посвященных управлению ИТ-проектами [4-6] и в методологиях разработки ПО [7, 8]. Также большое число исследований сфокусировано на опи-

сании рисков, их классификации и ранжировании по степени важности применительно к ИТ-проектам.

В работе одного из наиболее известных исследователей управления ИТ-проектами - Б. Боэма - «Software risk management: principies and practices» [9] приведен список рисков (по убыванию важности) (табл. 1).

Таблица 1

Список рисков и методик их управлением Б. Боэма

№ Риск Методика управления риском

1 Нехватка компетенций сотрудников Наем высококвалифицированных сотрудников, мероприятия по формированию команды, обучение сотрудников

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

3 Несоответствие разработанной и требуемой функциональности Анализ организации, анализ целей, опрос пользователей, прототипирова-ние, оценка производительности, проверка качества

4 Несоответствие разработанного и требуемого пользовательского интерфейса Прототипирование, разработка сценариев использования, участие пользователей

5 Неэффективное управление требованиями и качеством (Gold-plating) Уточнение требований, прототипирова-ние, анализ стоимости

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

7 Недостатки используемых внешних компонентов Сравнительное тестирование, технический аудит, анализ совместимости

8 Проблемы в задачах, выполняемых внешними подрядчиками Проверка контрагентов, подготовка макетов и прототипирование, мероприятия по формированию команды

9 Недостаточная производительность Моделирование, проведение сравнительного тестирования, прототипирование

10 Технологическое отставание Технический анализ, анализ стоимости, прототипирование

В работе Т. Аддисона перечислены наиболее часто встречающиеся риски [10]:

1) неточность и неконкретность целей ИТ-проекта;

2) недооценка требований ИТ-проекта;

3) невовлеченность пользователей;

4) ошибки в процессе реализации ИТ-проекта;

5) невовлеченность руководства;

6) нереалистичные сроки и бюджет;

7) изменения требований в процессе реализации ИТ-проекта;

8) неэффективное использование методологий проектного управления;

9) знания и умения проектной команды не соответствуют требованиям проекта;

10) завышение качества, неэффективное управление требованиями (Gold-plating).

Для крупных ИТ-проектов, срок реализации которых составляет более года, М. Самнер назвал следующие риски [11]:

1) влияние внешних факторов на проект;

2) нехватка опыта участников проектной команды;

3) нехватка компетенций;

4) неточность целей проекта;

5) изменения требований в процессе реализации ИТ-проекта;

6) неэффективное использование методологий проектного управления;

7) отсутствующая или недостаточная коммуникация с пользователем;

8) нереалистичные сроки и бюджет;

9) конфликт между заинтересованными лицами проекта.

Как можно увидеть из этих списков, в каждом присутствуют несколько наиболее часто встречающихся рисков:

1) неточная оценка сроков и бюджета;

2) расхождение между требуемой реализацией и получившимся результатом;

3) нехватка компетенций и опыта участников проектной команды;

4) проблемы коммуникации с руководством, пользователями, подрядчиками.

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

Метод управления рисками ИТ-проекта

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

1. Идентификация риска

Для идентификации риска имеется большое число методов [12]:

• анализ проектной документации;

• применение метода «блок-схема принятия решения»;

• использование опросных листов;

• применение метода «мозгового штурма»;

• интервьюирование экспертов с опытом решения аналогичных задач.

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

2. Анализ риска

Для каждого риска необходимо оценить его вероятность и влияние по 10-балльной шкале. Для увеличения качества

экспертной оценки можно использовать вербально-числовую шкалу Харрингтона [13] (табл. 2, 3);

Таблица 2

Вербально-числовая шкала Харрингтона для оценки вероятности наступления риска

Степень вероятности наступления риска в проекте Коэффициент Харрингтона (согласно PMBoK) Коэффициент Харринг-тона Вероятность

Очень высокая 8-10 5 Риск неизбежен. Гарантированное наступление риска

Высокая 6,4-8 4 Риск вероятен

Средняя 3,7-6,4 3 Нет гарантий, что риск наступит, но все же существует такая возможность

Низкая 2-3,7 2 Есть возможность наступления риска

Очень низкая 0-2 1 Есть потенциальная возможность наступления риска

Нет вероятности 0 0 Риск невозможен

3. Реагирование на риск

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

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

2) снижение - вероятности или влияния риска на проект;

3) передача - перенос ответственности за последствия риска на третью сторону (подрядчика, заказчика и т. д.);

4) принятие - формирование плана действий в случае проявления риска либо резерва ресурсов на устранение последствий.

Таблица 3

Вербально-числовая шкала Харрингтона для оценки влияния риска

После выбора стратегии остается этап контроля и мониторинга, который длится весь проект.

Пример управления рисками НА основе компонентной СТРУКТУРЫ разрабатываемого ПО

В качестве примера рассмотрим проект разработки информационной системы управления проектами (ИСУП) в сфере строительства.

На начальном этапе выполняются приблизительная декомпозиция системы на компоненты, оценка сроков и трудоемкости разработки. Список работ по проекту, выполненный в MS Project, представлен на рис. 2.

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

На основе списка работ составляется оценка рисков для каждого компонента. Для идентифицированных рисков будут использованы обозначения, представленные в табл. 4.

Таблица 4

Выбранные обозначения вероятностей и влияния рисков

Параметр Обозначение параметра Риск

Вероятность XlirnH Неточная оценка сроков и бюджета

Влияние

Вероятность и влияние риска оцениваются по шкале от 1 до 10 для каждого компонента отдельно. На момент оценки проект находится на ранней стадии, подробное проектирование еще не выполнено, и оценка носит предварительный характер (табл. 5).

Таблица 5

Оценка рисков для каждого компонента на ранних этапах проекта

Компонент Xlimit С

Управление содержанием и сроками 2 7

Управление коммуникациями 2 5

Управление ресурсами и стомостью 2 7

Управление закупками 3 4

Обмен план-фактной информацией 4 5

Вывод бизнес-аналитики 5 3

После оценки рисков определяется стратегия реагирования (табл. 6).

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

Степень влияния риска на проект Коэффициент Харрингто-на (согласно PMBoK) Коэффициент Харринг-тона Влияние

Очень высокая 8-10 5 Остановка работ в проекте

Высокая 6,4-8 4 Выполнение работ в проекте с большим опозданием

Средняя 3,7-6,4 3 Задержки в выполнении работ

Низкая 2-3,7 2 Выполнение работ в проекте с небольшим опозданием

Очень низкая 0-2 1 Незначительные отставания от намеченных планов

Нет влияния 0 0 Выполнение работ согласно плану проекта

_^ек 3. '17_, Сегодня_,Деи17, '17_^еи 24, '17

Начало

tr И/'Э й/17

а Режим " задачи Название задачи Длительность Начало Окончание

■5 ~ 2. Этап разработки ИСУП 40 дней Чт 11/30/17 Ср 1/24/18

% 2.1. Модуль управления 30дней Чт 11/30/17 Ср 1/10/18

содержанием и фонами

% 2.2. Модуль управления 20дней Чт 11/30/17 Ср 12/27/17

коммуникациями

% 2.3. Модуль управления 30дней Чт 11/30/17 Ср 1/10/18

ресурсами и стоимостью

% 2.4. Модуль управления годней Чт 11/30/17 Ср 12/27/17

закупками

% 2.5. Модуль обмена 10дней Чт 12/28/17 Ср 1/10/18

план-фактной

информацией

% 2.6. Модуль вывода 10дней Чт 1/11/18 Ср 1/24/18

бизнес-аналитики

Рис. 2. Список работ по проекту

Таблица 6

Выбор стратегий реагирования на ранних этапах проекта

Компонент Выбранная стратегия реагирования

Управление содержанием и сроками Принятие риска

Управление коммуникациями Принятие риска

Управление ресурсами и стоимостью Принятие риска

Управление закупками Снижение риска (увеличение ресурсов для сбора требований)

Обмен план-фактной информацией Снижение риска (увеличение ресурсов для сбора требований)

Вывод бизнес-аналитики Снижение риска (увеличение ресурсов для сбора требований)

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

Таблица 7

Оценка рисков для каждого компонента по завершении проектирования

Компонент Хцта е

Управление содержанием и сроками 4 7

Управление коммуникациями 2 5

Управление ресурсами и стомостью 2 7

Управление закупками 3 4

Обмен план-фактной информацией 4 5

Вывод бизнес-аналитики 8 3

На основе скорректированной оценки рисков можно скорректировать и стратегию управления рисками (табл. 8).

Таблица 8

Выбор стратегий реагирования по завершении проектирования

Компонент Выбранная стратегия реагирования

Управление содержанием и сроками Снижение риска. Увеличение ресурсов

Управление коммуникациями Принятие риска

Управление ресурсами и стоимостью Принятие риска

Управление закупками Принятие риска

Обмен план-фактной информацией Снижение риска. Увеличение ресурсов

Вывод бизнес-аналитики Передача риска. Привлечение подрядчиков для выполнения работ

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

проекту, а только для тех компонентов, где степень риска возросла.

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

Агрегирование оценки

РИСКОВ ПО КАЖДОМУ КОМПОНЕНТУ В ОБЩУЮ ОЦЕНКУ

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

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

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

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

п

У г = Х ху х е у х , ] =1

где п - число компонентов; Уг - суммарная оценка по г-му риску; х - оценка вероятности г-го риска ву'-м компоненте; е.. - оценка влияния г-го риска ву'-м компоненте; 2. - значимость '-го компонента.

Чтобы полученная в результате оценка находилась в диапазоне от 0 до 1, значения параметров ху, е., г. нормируются

к единице. Для параметра значимости должно выполняться дополнительное условие:

X П 1 = 1.

¿-4=1 }

В табл. 9 приведены значения значимости компонентов, определенные на основе экспертной оценки.

Таблица 9

Оценка значимости компонентов

Компонент Оценка значимости

Управление содержанием и сроками 0,3

Управление коммуникациями 0,2

Управление ресурсами и стомостью 0,3

Управление закупками 0,1

Обмен план-фактной информацией 0,05

Вывод бизнес-аналитики 0,05

В качестве примера вычисления общей оценки по данному методу будут взяты данные по оценке рисков на раннем этапе проекта и по завершении проектирования. Результат вычислений на раннем этапе (исходные значения параметров х.. и е.. - из табл. 5):

6

уНт и = X ху х е у х 2 у = у=1

= 0,2 X 0,7 X 0,3 + 0,2 X 0,5 х 0,2 + 0,2 х 0,7 х 0,3 + + 0,3 х 0,4 х 0,1 + 0,4 х 0,5 х 0,05 = 0,1335.

Результат вычислений по завершении проектирования (исходные значения параметров х .. и е.. - из табл. 7):

6

уНт и = X х у х е у х 2 у =

у=1

= 0,4 х 0,7 х 0,3 + 0,2 х 0,5 х 0,2 + 0,2 х 0,7 х 0,3 + + 0,3 х 0,4 х 0,1 + 0,8 х 0,5 х 0,05 = 0,18.

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

Заключение

По результатам исследований предложен подход к управлению рисками ИТ-проекта на основе компонентной структуры разрабатываемого ПО. Этот подход позволяет использовать управление рисками в распространенных методологиях разработки ПО, таких как ЯШ* и МББ, за счет оценивания рисков для проекта, декомпозированного на компоненты. Также предложен вариант объединения оценки риска по компонентам в общую оценку для проекта, что позволяет более гибко выбирать стратегию реагирования на риск, применяя ее для части проекта или для проекта целиком.

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

Литература

1. Руководство к своду знаний по управлению проектами (Руководство PMBOK. Russian). 2014. 589 с.

2. Арчибальд Р. Д. Управление высокотехнологичными программами и проектами / Р. Д. Арчибальд. - М.: ДМК-Пресс, 2002. 472 с.

3. Новиков Д. А. Управление проектами: организационные механизмы / Д. А. Новиков. - М.: ПМСОФТ, 2007. 140 с.

4. Архипенков С. Я. Лекции по управлению программными проектами / С. Я. Архипенков. - М., 2009. 127 с.

5. Фатрелл Р. Т. Управление программными проектами. Достижение оптимального качества при минимуме затрат / Р. Т. Фатрелл, Д. Ф. Шафер, Л. И. Шафер; пер. с англ. -М.; СПб.; Киев: Вильямс, 2004. 1136 с.

6. Соммервилл И. Инженерия программного обеспечения / И. Соммервилл. - М.: Вильямс, 2002. 624 с.

7. Крачтен Ф. Введение в Rational Unified Process / Ф. Крач-тен. - М.: Вильямс, 2002. 240 с.

8. Тернер М. Основы Microsoft Solution Framework / М. Тернер. - М.: Русская редакция; СПб.: Питер, 2008. 336 с.

9. Boehm B. W. Software risk management: principles and practices / B. W. Boehm // IEEE software. 1991. Т. 8, № 1. С. 32-41.

10. Addison T. Controlling Software Project Risks - An Empirical Study of Methods Used by Experienced Project Managers / T. Addison, S. Vallabh // Proc. SAICSIT. 2002. P. 128-140.

11. Sumner M. Risk Factors in Enterprise-wide/ERP Projects / M. Sumner // J. Inf. Technol. 2000. № 15. P. 317-327.

12. Дайбова К. Е. Разработка инструментария оперативной идентификации рисков в ИТ-проектах / К. Е. Дайбова, В. С. Николаенко // Ресурсоэффективным технологиям -энергию и энтузиазм молодых: сб. науч. тр. VI всерос. конф. -Томск: Изд-во Томск. политех. ун-та, 2015. С. 254-257.

13. Николаенко В. С. Внедрение риск-менеджмента в ИТ-проекты / В. С. Николаенко // Гос. управление. Электрон. вестн. 2016. № 54. C. 63-88.

14. Burkovic O. Risks in Information Systems Development Projects / O. Burkovic, L. Rakovic // Management. 2009. Т. 4, № 1. С. 13-19.

15. Булдакова Т. И. Оценка информационных рисков в автоматизированных системах с помощью нейро-нечёткой модели / Т. И. Булдакова, Д. А. Миков // Наука и образование: науч. изд. МГТУ им. Н. Э. Баумана. 2013. № 11. C. 295-310.

16. Ехлаков Ю. П. Нечеткая модель оценки рисков продвижения программных продуктов / Ю. П. Ехлаков, Н. В. Пермя-кова // Бизнес-информатика. 2014. № 3 (29). C. 69-78.

17. Карпеев Д. О. Идентификация параметров нечетких моделей оценки информационных рисков информационных систем / Д. О. Карпеев и др. // Информация и безопасность. 2010. Т. 13, № 1. С. 37-42.

18. Lee H. M. A new algorithm for applying fuzzy set theory to evaluate the rate of aggregative risk in software development / H. M. Lee et al. // Inf. Sci. 2003. Т. 153. С. 177-197.

19. Chen S. M. Fuzzy group decision making for evaluating the rate of aggregative risk in software development / S. M. Chen // Fuzzy Sets and Systems. 2001. Т. 118, № 1. С. 75-88.

20. Титов А. И. Выбор программного обеспечения с помощью алгоритма Такаги - Сугено на примере систем управления проектами / А. И. Титов, А. Д. Хомоненко // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2016. № 1 (236). С. 41-52.

Risk Management for Software Projects Based on the Component Structure

Titov A. I.

Emperor Alexander I St. Petersburg State Transport University Saint-Petersburg, Russia titovvvv@rambler.ru

Abstract. Widespread risks of IT projects are considered, the review of methods of management of risks is provided. The main stages of identification of risks are given. For an impact assessment of risk the verbal and numerical scale of Harrington is used. Aggregation of assessment of risks on each component in the general assessment is described. The task of control of the identified risks is considered and the method of management of risks based on component structure of the developed software is offered.

Keywords: project management, risk management, software development.

References

1. A Guide to the Project Management Body of Knowledge (RMVOK Guide) [Rukovodstvo k svodu znaniy po upravleniyu proyektami (Rukovodstvo PMBOK. Russian)]. 2014. 589 p.

2. Archibald R. D. Managing High-Technology Programs and Projects [Upravlenie vysokotekhnologichnymi programmami i proektami], Moscow, DMK-Press, 2002. 472 p.

3. Novikov D.A. Project Management: Organizational Mechanisms [Upravlenie proektami: organizacionnye mekhanizmy], Moscow, PMSOFT, 2007. 140 p.

4. Arhipenkov S. Ja. Software Project Management Lectures [Lekcii po upravleniju programmnymi proektami], Moscow, 2009. 127 p.

5. Fatrell R. T., Shafer D. F., Shafer L. I. Quality Software Project Management First Edition [Upravlenie programmnymi proektami. Dostizhenie optimal'nogo kachestva pri minimume zatrat], Moscow, St. Petersburg, Kiev: Vil'jams, 2004. 1136 p.

6. Sommerville I. Software Engineering [Inzheneriya pro-grammnogo obespecheniya], Moscow, Vil'jams. 2002. 624 p.

7. Kruchten Ph. The Rational Unified Process: An Introduction [Vvedenie v Rational Unified Process], Moscow, Vil'jams. 2002. 240 p.

8. Turner M. S. V. Microsoft Solutions Framework Essentials [Osnovy Microsoft Solution Framework], Moscow, Russkaja redakcija; St. Petersburg, Piter, 2008. 336 p.

9. Boehm B. W. Software Risk Management: Principles and Practices, IEEE Software, 1991, T. 8, no. 1, pp. 32-41.

10. Addison T., Vallabh S. controlling Software Project Risks - An Empirical Study of Methods Used by Experienced Project Managers. Proc. SAICSIT, 2002. Pp. 128-140.

11. Sumner M. Risk Factors in Enterprise-wide/ERP Projects, J. Inf. Technol., 2000, no. 15, pp. 317-327.

12. Dajbova K. E., Nikolaenko V. S. Development of Tools for Rapid identification of Risks in IT Projects [Razrabotka in-strumentariya operativnoj identifikacii riskov v IT-proektah]. Resource-efficient technologies - energy and enthusiasm of young people: a collection of scientific papers of the VI All-Russian Conf. [Resursoehffektivnym tekhnologiyam - ehnergiyu i ehntuziazm molodyh: sbornik nauchnyh trudov VI vserossijskoj konferencii]. Tomsk: Izdatelstvo Tomskogo politekhnicheskogo universiteta, 2015. Pp. 254-257.

13. Nikolaenko V. S. Introduction of Risk Management in IT Projects [Vnedrenie risk-menedzhmenta v IT-proekty], Public administration. Electronic Bul. [Gosudarstvennoe upravlenie. EHlektronnyj Vestnik], 2016, no. 54, pp. 53-88.

14. Burkovic O., Rakovic L. Risks in Information Systems Development Projects, Management, 2009, T. 4, no. 1, pp. 013-019.

15. Buldakova T. I., Mikov D. A. Assessment of information Risks in Automated Systems with the Help of a Neuro-fuzzy Model [Ocenka informacionnyh riskov v avtomatiziro-vannyh sistemah s pomoshch'yu nejro-nechyotkoj modeli], Sci. andEduc. [Nauka i obrazovanie]. Moscow Bauman State Tech. Univ., 2013, no. 11, pp. 295-310.

16. Ekhlakov Yu. P., Permyakova N. V. Fuzzy Model for Assessing the Risks of Promoting Software Products [Nechetkaya model' ocenki riskov prodvizheniya programmnyh produktov], Business Informatics [Biznes-informatika], 2014, no. 3 (29), pp. 69-78.

17. Karpeev D. O. et al. Identification of Parameters of Fuzzy Models for Assessing the Information Risks of Information Systems [Identifikaciya parametrov nechetkih modelej ocenki infor-macionnyh riskov informacion-nyh sistem], Information and security [Informaciya i bezopasnost'], 2010, T. 13, no. 1, pp. 37-42.

18. Lee H. M. et al. A New Algorithm for Applying Fuzzy Set Theory to Evaluate the Rate of Aggregative Risk in Software Development, Inf. Sci, 2003, T. 153, pp. 177-197.

19. Chen S. M. Fuzzy Group Decision Making for Evaluating the Rate of Aggregative Risk in Software Development, Fuzzy Sets and Systems, 2001, T. 118, no. 1, pp. 75-88.

20. Titov A. I., Khomonenko A. D. Software Selection by Using Takagi - Sugeno Algorithm on Example Project Management System [Vybor programmnogo obespecheniya s pomoshch'yu algoritma takagi-sugeno na primere sistem upravleniya proektami], St. Petersburg State Polytechnical Univ. J. Comput. Sci. Telecommunication and Control Systems [Nauchno-tekhnicheskie vedo-mosti SPbGU. Informatika. Telekommunikacii. Upravlenie], 2016, no. 1 (236), pp. 41-52.