Риски и выбор оптимальных проектов: сервис-ориентированная архитектура информационных систем тема диссертации и автореферата по ВАК РФ 05.13.18, кандидат наук Пырлина, Ирина Владимировна

• Пырлина, Ирина Владимировна
• кандидат наук
• 2014

Оглавление диссертации кандидат наук Пырлина, Ирина Владимировна

Оглавление

Введение 5

Глава 1 .ОЦЕНКА РИСКОВ И ПРОБЛЕМА ВЫБОРА 17 КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ С СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРОЙ

1.1 Оценка рисков информационных систем с сервис- 18 ориентированной архитектурой

1.1.1 Метод СОСОМО 19

1.1.2 Метод вероятностного анализа дерева рисков 24

1.1.3 Метод анализа ежегодного ожидаемого убытка 26

1.1.4 Метод анализа функциональных точек 27

1.1.5 Методы взвешенных рисков 31

1.1.6 Метод управления рисками ПО 32

1.1.7 Метод проектных рисков 3 6

1.1.8 Общая модель оценки рисков ИС 37

1.1.9 Метод анализа убытков при возникновении рисков на основе 3 8 биномиального, пуассоновского и нормального распределений

1.1.10 Методология Basel II 39

1.1.11 Метод оценки информационного риска 40

1.1.12 Примеры использования методов оценки рисков 42

1.2 Принципы построения сервис-ориентированной архитектуры 46 корпоративных информационных систем

1.2.1 Характеристики сервисов 48

1.3 Многокритериальный анализ информационных систем с сервис- 51 ориентированной архитектурой

1.3.1 Метод оценки производительности ИС 51

1.3.2 Метод оценки качества услуг ИС 52

1.3.3 Метод оценки функции полезности ИС 54

1.3.4 Метод оценки многокритериальной функции полезности ИС 56

1.3.5 Пример применения методов многокритериального анализа 60 информационных систем с СОА

1.4 Методы имитациоиного моделирования информационных систем 63 с сервис-ориентированной архитектурой

Глава 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ ОПЕРАЦИОННЫХ 66

РИСКОВ ИНФОРМАЦИОННЫХ СИСТЕМ С СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРОЙ

2.1 Операционные риски информационных систем 66

2.1.1 Существующие классификации ошибок информационных 68 систем

2.1.2 Классификация рисков информационных систем 69

2.2 Операционные риски информационных систем с сервис- 73 ориентированной архитектурой

2.3 Новая классификация ошибок информационных систем 77 с сервис-ориентированной архитектурой

2.4 Анализ и имитационное моделирование рисков информационных 83 систем с сервис-ориентированной архитектурой

2.5 Анализ убытков при реализации операционных рисков 91

2.5.1 Описание опроса экспертов компании 91

2.5.2 Оценка убытков при реализации операционных рисков 95

2.6 Метод ранжирования рисков сервис-ориентированной 102 архитектуры при оценке проектов внедрения ИС

Глава 3. ВЫБОР ЭФФЕКТИВНОГО ПРОЕКТА РЕАЛИЗАЦИИ 107

ИНФОРМАЦИОННОЙ СИСТЕМЫ С СЕРВИС-ОРИЕКГГИРОВАННОЙ АРХИТЕКТУРОЙ С ИСПОЛЬЗОВАНИЕМ ПК СМАиМР

3.1 Критерии качества проекта 108

3.1.1 Разработка критериев для задачи выбора референциалыюй 108 архитектуры корпоративной ИС

3.1.2 Разработка критериев для задачи гармонизации структуры 119

профиля сотрудников в гетерогенном ландшафте приложений SAP

3.2 Метод порогового агрегирования 122

3.2.1 Модификация алгоритма ранжирования в виде таблицы с 129 исключениями

3.2.2 Переход от числовых оценок к рангам 131

3.3 Процедура построения, оценки и выбора вариантов сервис- 133 ориентированной архитектуры информационных систем

Глава 4. МОДЕЛИРОВАНИЕ РИСКОВ И ВЫБОР ПРОЕКТОВ 139

ИНФОРМАЦИОННЫХ СИСТЕМ С СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРОЙ С ИСПОЛЬЗОВАНИЕМ ПК СМАиМР

4.1 Экспериментальное исследование методов оценки рисков и 140 выбора референциальной архитектуры корпоративной ИС

4.2 Экспериментальное исследование методов оценки рисков и 146 выбора оптимального проекта в задаче гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений SAP Заключение 155 Список терминов 157 Список литературы 164 Приложения 173

Введение диссертации (часть автореферата) на тему «Риски и выбор оптимальных проектов: сервис-ориентированная архитектура информационных систем»

ВВЕДЕНИЕ Актуальность проблемы

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

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

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

■ Рост производительности ИТ,

■ Увеличение производительности процессов и пользователей,

■ Увеличение гибкости систем,

■ Сокращение времени вывода на рынок новых продуктов и услуг,

■ Облегчение процесса слияния компаний (интеграция систем после слияния предприятий),

■ Увеличение прозрачности бизнеса.

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

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

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

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

Основные задачи диссертации

В работе проводится исследование проблем классификации и оценки операционных рисков информационной системы с сервис-ориентированной архитектурой, а также выбора проекта реализации таких систем. Данная диссертационная работа ориентирована на решение следующих задач:

1. разработка метода сбора данных, классификации и анализа операционных рисков сервис-ориентированной архитектуры ИС,

2. моделирование потока ошибок (операционных рисков) информационной системы на основе выведенных распределений типов рисков,

3. разработка критериев качества проектов на примере двух проектов,

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

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

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

Методы исследования

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

Научная новизна

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

Научная и практическая значимость

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

Важным показателем принятия решения по инвестиционному проекту является уровень рискованности проекта. Чтобы оценить этот показатель, проведено исследование операционных рисков в рамках создания ИС с сервис-ориентированной архитектурой и предложен новый подход к их классификации, основывающийся на ошибках систем, которые являются поставщиками сервисов для приложений с сервис-ориентированной архитектурой. Установлено, что при их классификации стоит использовать как типы ресурсов, так и категории программного обеспечения. Такой подход расширяет классификацию операционных рисков и облегчает поиск, сбор и анализ статистики по ним. С использованием предложенной классификации собрана статистика сообщений об ошибках за 5 лет по семи предприятиям нефтегазовой, металлургической и банковской отраслей. Также проведен опрос экспертов с целью определения убытков от исследованных операционных рисков и оценки возможных убытков, а также определения типов распределений в каждой группе рисков. Это позволило спрогнозировать риски как часть модели выбора оптимального проекта.

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

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

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

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

Основные результаты, выносимые на защиту:

1. Разработан новый метод классификации и оценки рисков ИС с COA.

2. Предложен метод выбора оптимальных проектов ИС с COA.

3. Разработан новый метод моделирования операционных рисков ИС с COA.

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

и

порогового агрегирования при любых /«-градационных оценках по п критериям проекта ИС с сервис-ориентированной архитектурой.

5. Разработан прототип комплекса программ СМАиМР, который позволяет проводить имитационное моделирование рисков, и поддерживает быстрое ранжирование альтернативных проектов методом порогового агрегирования.

Структура и объем диссертации

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

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

В параграфе 1.1 рассматриваются существующие методы оценки и классификации рисков информационных систем, их достоинства и недостатки. Рассматриваются методы Cocomo II, вероятностного анализа дерева рисков, анализа ежегодного ожидаемого убытка, анализа функциональных точек ИС, метод взвешенных рисков, метод управления рисками ПО, и общие модели оценки рисков ИС, такие как метод оценки рисков на основе биномиального, пуассоновского и нормального распределений, и метод BASEL II. Большинство рассмотренных методов оказались универсальными, применимыми к информационным системам в целом, а не к отдельным ресурсам ИС.

В параграфе 1.2 приводятся принципы построения ИС с сервис-ориентированной архитектурой и описываются основные характеристики сервисов. Приводится основное отличие СОА от предшествующих

технологий распределенных объектов (ССЖВА, БСОМ), которое заключается в использовании принципа слабой связанности сервисов. Раскрываются методы проектирования сервис-ориентированной архитектуры.

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

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

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

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

связующего программного обеспечения. В параграфе 2.3 разрабатывается новый подход к классификации ошибок ИС с сервис-ориентированной архитектурой, что представляет собой основу нового подхода к оценке рисков. Приведен пример собранной статистики с применением данной классификации. В параграфе 2.4 проверяются гипотезы о типе распределений вероятности с использованием собранной статистики рисков по нескольким проектам и новой классификации. В результате данного анализа каждому типу риска подбирается наиболее подходящее распределение вероятности (например, риски данных имеют экспоненциальное распределение). С использованием выбранных типов распределений ошибок строится имитационная модель, позволяющая выполнить моделирование всего процесса обработки ошибок ключевых компонент ИС с СОА от подачи заявки на решение проблемы до ее разрешения. В параграфе 2.5 описан разработанный метод анализа убытков от каждой группы операционных рисков, определенных в новой классификации. Для определения убытков проводился опрос экспертов с целью установления времени ежемесячного использования компонент ИС, по которым были зарегистрированы сообщения об ошибках, а также количество пользователей, использующих одновременно данную компоненту ИС. В параграфе 2.6 сформулирован метод ранжирования рисков на основе новой классификации и метода анализа убытков.

В главе 3 строится модель выбора оптимального проекта с учетом рисков и с использованием метода порогового агрегирования. Задача состоит в ранжировании проектов и выборе наиболее эффективного проекта реализации сервис-ориентированной архитектуры. Параграф 3.1 посвящен определению критериев качества сервис-ориентированной архитектуры, которые используются для сравнения проектов. Предложенные критерии оценивают качество ИС с сервис-ориентированной архитектурой в четырех основных областях: внутренняя организация ИС с сервис-ориентированной архитектурой, организация изменений и политик, готовность процессов и

бизнес-сервисов, а также уровень операционных рисков. В данном параграфе подробно объяснены критерии со ссылками на исходные методы и их расширения, предложенные автором для задачи выбора референциальной архитектуры корпоративной ИС и задачи гармонизации структуры профиля сотрудников в гетерогенном ландшафте приложений SAP. При подготовке требований к компетенциям сотрудников использовался национальный стандарт [НТК, 2010]. В параграфе 3.2 описывается метод порогового агрегирования. Для быстрого ранжирования с использованием метода порогового агрегирования, автором был создан программный код, алгоритм которого приведен в данном параграфе. В параграфе 3.3 описывается разработанная новая двухэтапная процедура построения, оценки и выбора вариантов проектов ИС с СОА на основе метода порогового агрегирования и нового метода анализа рисков. Сформулирована процедура генерации ошибок на основе эквивалентного числового ключа.

В главе 4 описывается апробация разработанных методов применительно к задаче выбора референциальной архитектуры корпоративной ИС (параграф 4.1) и задаче гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений SAP (параграф 4.2). Апробация проводится с использованием разработанных методов и прототипа комплекса программ, поддерживающих имитацию рисков и выбор оптимальных проектов.

Основные результаты диссертации опубликованы в следующих работах:

По теме диссертации опубликовано 6 работ. В число работ входят пять статей [1-4,6] из «Перечня ведущих и рецензируемых журналов и изданий ВАК РФ 2012 г.» (включая базу рецензирования Scopus), 2 полных текста докладов [3,4] в материалах международных конференций, одна публикация [5] в базе патентного ведомства США.

1. Пырлина И.В. Классификация операционных рисков при сервисно-ориентированном подходе к созданию информационной системы // Бизнес-Информатика. - 2011. - №4( 18). - с.54-62.

2. Пырлина И.В. Выбор эффективного проекта реализации сервисно-ориентированной архитектуры информационной системы // Проблемы управления. -2012. - № 4. — с.59-69.

3. Pyrlina I. Choice of Efficient Information System with Service-Oriented Architecture using Multiple Criteria Threshold Algorithms (With Practical Example) // Труды международной конференции по Информатике и ИТ, 2012, Венеция, Италия. ISSN: 2162-6359 Web: http://www.waset.org/iournals/iiems/v6/v6-29.pdf.-p.151-159.

4. Pyrlina I. Operational risks Classification for Information Systems with Service-Oriented Architecture (Including Loss Calculation Example) // Труды международной конференции по ИТ, 2012, Мадрид, Испания. ISSN: 21626359 Web: http://www.waset.org/iournals/iiems/v6/v6-7.pdf. - р.337-343.

5. Pyrlina I. Заявка на Патент от 22 Марта 2012 под названием «INFORMATION SYSTEM WITH SERVICE-ORIENTED ARCHITECTURE USING MULTIPLE CRITERIA THRESHOLD ALGORITHMS» // U.S. Provisional Patent Application No. 61/614,433 to Pyrlina, filed March 22, 2012. - Patent ID 81461869 (2012P00081 US01).- Publication No. US 2013-0253992 Al.

6. Пырлина И.В. Риски и выбора оптимальных проектов: сервис-ориентированная архитектура информационных систем // Управление большими системами. М.: ИПУ РАН.- 2013г.-№43. - с.132-181.

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

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

1. Международная конференция по ИТ (World Academy of Science, Engineering and Technology № 63, 2012, ICIT 2012) - 2012r.-Мадрид, Испания. ISSN2010-3778.

2. Международная конференция компьютерных наук и информационных технологий (World Academy of Science, Engineering and Technology № 64, 2012, ICCSIT 2012) - 2012r.-Венеция, Италия. - ISSN2010-3778.

3. Общемосковский семинар "Экспертные оценки и анализ данных" -Институт проблем управления им. Трапезникова (ИЛУ РАН) -Москва, Россия, - 2012.

1 ОЦЕНКА РИСКОВ И ПРОБЛЕМА ВЫБОРА КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ С СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРОЙ

Любая развивающаяся компания независимо от ее размера сталкивается с проблемой выбора информационной системы (ИС). Стимулом к внедрению новой информационной системы может являться развитие бизнеса, ведущее к появлению новых процессов в компании, или предложение новых технологий на рынке информационных систем или просто стремление исполнять текущие задачи оптимальным образом. Затраты на информационные системы в 2011 в России составили 32.11 миллиарда долларов по данным IDC [Kalabina и др., 2012]. Причиной таких затрат, в частности, в корпоративном секторе явились, по данным аналитиков, поглощения компаний в телекоммуникационном секторе, что привело к дополнительным затратам на интеграцию систем, а также активное развитие мобильных технологий и облачных сервисов. При решении данных задач особое внимание уделяется гибкости прикладного ПО и корректности выбранной архитектуры информационных систем, вследствие чего обращаются, в том числе, и к сервис-ориентированной архитектуре.

Единого определения СОА, с которым были бы согласны все эксперты, не существует. Организация по распространению открытых стандартов структурированной информации (OASIS) определяет СОА следующим образом. "Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) — это концепция организации и использования распределенных информационных ресурсов, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение" [MacKenzie и др., 2006].

Gartner Group определяет СОА следующим образом: Сервис-ориентированная архитектура (СОА) - это клиент-серверный метод

проектирования информационных систем, в рамках которого приложение состоит из прикладных сервисов и потребителей прикладных сервисов (также известных как программа формирования клиентских или сервисных запросов). COA отличается от классической клиент-серверной архитектуры слабой связностью прикладных компонент решения и их интерфейсов [Natis, Schulte, 2003].

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

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

1.1 Оценка рисков информационных систем с сервис-ориентированной архитектурой

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

Реактивные методы выполняют анализ рисков и оценку убытков после реализации рисков. Модели, используемые в реактивных методах, позволяют выполнить расчет убытков и определить перечень мероприятий по устранению уже реализовавшихся рисков [Dash, 2010].

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

1.1.1 Метод СОСОМО

Опишем метод СОСОМО, который относится к проактивным методам. Он был предложен Б.Боэмом в 1981 и основывался на результатах 63-х проектов разработки информационных систем (ИС) в аэрокосмической промышленности. В дальнейшем был разработан метод СОСОМО II (или модель издержек разработки), который представляет собой расширение исходного метода, но уже на основе анализа 161-го проекта разработки ИС. Данный метод относится к проактивным и позволяет оценить стоимость, трудоемкость и время разработки ИС. Метод различает две стадии оценки проекта: предварительная (на начальной стадии проекта), и детальная (после завершения разработки архитектуры ИС). Каждая стадия имеет свою модель оценки стоимости.

Для того чтобы оценить стоимость проекта информационной системы, необходимо выполнить оценку трудоемкости данного проекта (в человеко-месяцах). В соответствие с методом СОСОМО II оценка трудоемкости имеет вид [Sommerville, 2006], [Boehm и др., 1995]:

PM = A-SIZEK -("[[ЕМ,),

А=2,94

E=B+O,O\-1£SFj ,

5=0,91,

где общее количество множителей трудоемкости обозначено через п, а общее количество факторов масштаба равно пяти, SIZE - размер информационной системы (в тысячах строк исходного кода), А и В - константы трудоемкости,

определенные Б.Боэмом на основе анализа проектов, Е - экспоненциальный коэффициент, определяющий дополнительную трудоемкость с учетом рисков реализации ИС, ЕМ, - множители трудоемкости, SF, - факторы

масштаба,

п=1 для оценки предварительной стадии,

«=17 для оценки детальной стадии.

В методе используется пять факторов масштаба (SF;)

a) PERC - наличие опыта подобных разработок (очень низкий - опыт отсутствует, очень высокий - платформа полностью знакома),

b) FLEX - гибкость процесса разработки (очень низкий - процесс строго определен, очень высокий - определены только общие цели),

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

Использование

М:...............

Стабильность Соответствие Уровень поддержки Консистентность скорость

Линимизированн

□ Вариант 3

Уровень безопасности 4 Простота доступа к

Интегрированность 44 Прибыль/ Рост-Мотивация Успех клиентов

Безопасность данные4

Испотьзовтние Минимизированная

Гибкость

Производительность ^Масштабируемость

/ Доступность

Стабильность - - Соответствие

Уровень поддержки Консистентность

скорость реализации

^Цеюстность данных Удобный

Простота Интегрирова 4

Гибкость "Вариант 4

Уровень 4 - Производите

Масштабпру

/ Доступность

3

. • / V I _ \

\2

* К

о

Прибыль Рост Мотивация Успех клиентов

Безопасность

Яьзо_____

инимизиро

/

/

V

Стабильност Соответствие ! Уровень /Консистентн

Использован I Ми-----—"-----

скорость

Л1едлстность Удобный

□ Вариант 5 Гибкость

Уровень безопасности 4 - Производительность

Простота доступа к. Интегрированность Прибыль Рост Мотивация Успех клиентов V

Безопасность данных4

Йспользование инимизированная

(Иасштабируемость .оступность Стабильность - Соответствие

Уровень поддержки Консистентность

УдоЙьИ?0ТН0СТЬ данных

Рисунок 4.3 Графическое представление вариантов архитектуры

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

Для наглядности проведем сравнение результатов ранжирования методом порогового агрегирования и линейной свертки (Рисунок 4.4).

Пороговое агрегирование против линейного

,2 2 ■

1

4

3

1

2 3 4

Пороговое агрегирвание

Рисунок 4.4 Пороговое и линейное агрегирование

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

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

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

7, самая низкая - 1), используя метод перехода от числовых оценок к рангам из главы 3. Из таблицы 4.15 видно, что самым дешевым является 5-ый проект, однако с точки зрения архитектуры он самый не выгодный. Выбранный 4-тый вариант имеет среднюю стоимость и наиболее выгодную архитектуру.

Таблица 4.15 Итоговые ранги и стоимость проектов

Критерий Проект *:

1 2 4 "

Итоговый ранг 6 б 6 7 2

Итоговая стоимость 7 4 4 4 1

(ранг)

На практике первоначальный план проекта, выполнявшегося в ООО «САП Лабе», предполагал построение первого варианта архитектуры, используя четвертый вариант как промежуточное звено. Но в процессе реализации проекта было принято решение остановиться на третьем варианте архитектуры, который представляется оптимальным при пороговом агрегировании.

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

155

Заключение

Основные результаты работы:

1. Приведен аналитический обзор литературы по моделям оценки рисков информационных систем всех типов архитектур, методов выбора информационных систем и их сравнения. Приведен обзор вероятностных и функциональных моделей оценки рисков, а также модели Базель, СОСОМО II и Coombs et al. С точки зрения сравнения и выбора информационных систем приведено сравнение оценки производительности ИС, оценки качества услуг ИС, функции полезности ИС, а также многокритериальной функции полезности ИС.

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

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

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

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

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

СПИСОК ТЕРМИНОВ

Архитектура: информационной системы определяется как организация системы, которая охватывает механизмы обработки данных, систему памяти и процессоров, структуру системной шины, организацию ввода-вывода [Барановская, 2003], [Базель, 2004]. Существует несколько типов архитектур информационных систем: монолитная, двухзвенная, трехзвенная, распределенная, сервис-ориентированная и ориентированная на события. Архитектура ИС определяет

1) где находится логика приложения - это правила и алгоритмы, которые на основе входящей информации преобразуют данные, сохраняют их в базу данных и вызывают функции других систем [Fowler и др., 2002] (например, на уровне базы данных в двухзвенной архитектуре или на отдельном сервере в случае с трехзвенной архитектурой),

2) как строится интерфейс системы (в виде Web-интерфейса в распределённой архитектуре или в виде полноценного приложения со встроенной логикой в двухзвенной архитектуре),

3) какие требуются технические ресурсы для ее поддержки,

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

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

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

2. системных операций, обернутых в web-сервисную оболочку,

3. технических ресурсов, реализующих приложения, на базе которых работают технические сервисы (например, web- сервисы).

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

Гетерогенный ландшафт ИС: это совокупность разнородных информационных систем, имеющих разную архитектуру, программный код и систему интеграции.

Гранулярность: в COA [Azevedo, 2009] означает уровень функций и технических решений, поддерживающих эти функции, а также количество процессов, охватываемых или выполняемых сервисом. Информационная система: [Дика, 1996] определяется как система, предназначенная для сбора, передачи, обработки, хранения и выдачи необходимой информации потребителям, а также для выполнения функции управления. Она состоит из следующих основных компонент:

- программное обеспечение (ПО),

- информационное обеспечение,

- технические средства,

- обслуживающий персонал.

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

Операционный риск (далее риск): по соглашению «Базель II» [Базель II, 2004], представляет собой риск убытка в результате неадекватных или

ошибочных внутренних процессов, действий сотрудников и систем или внешних событий.

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

Ошибки ПО: Под ошибкой ПО или программной ошибкой [IEEE Standard, 1983] понимается недостижение или отличие от запрограммированного результата, ради которого была создана программа. Ошибки ПО включают в себя

• дефекты в ходе исполнения программы и определения данных,

• неправильный результат исполнения программы.

Подсистема ввода-вывода: (или пользовательский интерфейс) различные

технологии пользовательского интерфейса для работы с системой («Тонкий» клиент на базе Web-технологий, и «Толстый» клиент в виде специализированных клиентских приложений).

Прикладное программное обеспечение (функциональные или прикладные ресурсы): набор программных приложений, «обеспечивающий решение некоторого комплекса задач в интересах какой-либо сферы деятельности» [Когаловский, 2003]. Прикладное программное обеспечение состоит из приложений, решающих логически завершенную прикладную задачу или автоматизирующих отдельные бизнес-процессы. Прикладное ПО [Когаловский, 2003] используется для решения конкретного класса задач и обычно представляет собой коммерческие программные продукты: СУБД общего назначения, Web-серверы, системы управления документами, информационные системы, имеющие узкое назначение (используемые для поддержки конкретных процессов предприятия).

Проект: это ограниченное во времени целенаправленное изменение отдельного приложения или информационной системы, а также реализация новой информационной системы с сервис-ориентированной архитектурой, с определенными целями, достижение которых означает завершение проекта, а также с установленными требованиями к результату, срокам, рискам, бюджету и ресурсам [Избачков, 2006].

Ресурсы: К ресурсам, которые используют информационные системы, относятся средства вычислительной техники, системное и прикладное программное обеспечение, информационные, лингвистические и человеческие ресурсы [Когаловский, 2003].

Риски: по определению [Орлов, Пугач, 2012] «Риск - это мера количественного многокомпонентного измерения опасности с включением величины ущерба от воздействия угроз для безопасности, вероятности возникновения этих угроз и неопределенности в величине ущерба и вероятности».

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

Риски данных: риски ИС, связанные с ошибками, в результате которых изменяются данные в любом типе хранилища данных (данный класс введен автором [вио, БатраШ, 2008] для луеЬ-приложений, что применимо и для сервис-ориентированной архитектуры);

Риски персонала: представляет собой риск возникновения убытков из-за некорректной или неадекватной работы персонала, а также риск, связанный с несанкционированной работой персонала.

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

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

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

- являются востребованной функцией приложения либо системы,

- являются выполняемой функцией,

- удовлетворяют политике и требованиям к качеству сервиса -масштабируемость, надежность, соблюдение соглашения об уровне обслуживании.

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

Система управления базой данной (СУБД): Под СУБД понимается база данных со специализированным программным обеспечением, которое позволяет структурированно хранить и обрабатывать данные [Избачков, 2006].

Тайм-аут: определим как перерыв в работе приложений, связанный со слишком высокой нагрузкой на него.

Технические риски: представляют собой риски, связанные с выходом из строя аппаратного обеспечения (т.е. любого оборудования, на котором установлено ПО).

Технические ресурсы: К Техническим ресурсам (или средствам вычислительной техники) относятся серверы, телекоммуникационное оборудование, помещение, электричество и другие аппаратные ресурсы, необходимые для функционирования информационной системы. Технический сервис: Под техническим сервисом, согласно классическому определению, понимаются автономные, модульные, «самоописываемые» приложения, которые предоставляют набор выполняемых функций каждому, кто их запрашивает [Haas, Braun, 2004]. В данной работе технический сервис определяется в виде прикладных компонент или технических компонент, которые поддерживают работу бизнес-сервиса.

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

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

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

других транзакций, идущих параллельно, либо не выполнена вообще (и тогда она не должна произвести никакого эффекта на данные). Угроза: определяется как потенциальная причина возникновения нежелательных событий, которые могут нанести ущерб информационной системе или организации в целом [ISO/IEC 27000, 2009]. Уязвимость ИС: определяется как слабое место или недостаток ИС, который выявляется в рамках угрозы и атакуется в информационной системе. Уязвимость повышает вероятность успешной атаки [ISO/IEC 27000, 2009]. Функциональная точка: элемент измерения количества функциональности ИС, предоставленной пользователю [Park и др., 2012].

Функциональность: совокупность решаемых задач в рамках информационной системы, предоставленных пользователю в виде вызываемых функций.

Функциональные риски: риски связанные с прикладным уровнем ИС, на котором происходит преобразование переменных, реализация логики решения. К функциональным рискам относятся вероятные убытки, связанные с ошибками архитектуры, функций повторного использования и логики работы ИС.

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

1. Предпроектная оценка,

2. Проектирование (или дизайн) ИС,

3. Реализация и тестирование ИС,

4. Внедрение (Опытная эксплуатация) ИС,

5. Промышленная эксплуатация ИС (сопровождение и модернизация),

6. Вывод из эксплуатации.

СПИСОК ЛИТЕРАТУРЫ

Анализ математических моделей Базель II / Ф.Т.Алескеров, И.К.Андриевская, Г.И.Пеникас, В.М.Солодков. М.: Физматлит, 2010. (ISBN978-5-9221-1142-3). - 286 е.; Второе издание: Анализ математических моделей Базель II / Ф.Т.Алескеров, И.К.Андриевская, Г.И.Пеникас, В.М.Солодков. М.: Физматлит, 2013 (ISBN 978-5-92211463-9).- 296 с.

Алескеров Ф.Т., Быков A.A., Курмакаева Е.А. Анализ операционных убытков на основе биномиального, пуассоновского и нормального распределений //Банковское дело. - 2011. - №6. -С.52-57.

Алескеров Ф.Т., Якуба В.И. Метод порогового агрегирования трехградационных ранжировок // ДАН.- 2007.- т. 413.- №2. - с.181-183.

Базель II. Международная конвергенция измерения капитала и стандартов капитала: новые подходы. - Базельский комитет по банковскому надзору. Банк международных расчетов. - ISBN 92-9197-669-5. - 2004.

Байбородин Н. SOA на пальцах [Электронный ресурс] // IT спец. - №10. -2008.

Байбородин Н. Веб-сервисы: проектирование и реализация [Электронный ресурс] //IT спец.- №10.-2008.

Барановская Т.П., Лойкно В.И., Семенов М.И., Трубилин А.И. Архитектура компьютерных систем и сетей. - М.: Финансы и статистика. - 2003. -256 с.

Биберштейн Н., Боуз С., Джонс К., Фиммант М., Ша Р. Компас в мире сервис-ориентированной архитектуры (SOA): ценность для бизнеса, планирование и план развития предприятия / пер.с англ. —М.:КУДИЦ-ПРЕСС, 2007.—256 с.

Дика В.В. Информационные системы в экономике: Учебник- М.: Финансы и статистика, 1996. -272 с.

Избачков Ю.С., Петров В.Н. Информационные системы: Учебник для вузов.

2-е издание. - Спб.: Питер, 2006. - 656 с. Информационная безопасность систем организационного управления. Теоретические основы: в 2 т. / H.A. Кузнецов, В.В. Кульба, Е.А.Миркин и др.; [отв.ред. Н.А.Кузнецов, В.В.Кульба]; Институт проблем передачи информации РАН. -М.: Наука, 2006. - ISBN 5-02034145-2.

ИСО 9000: ГОСТ Р ИСО 9000-2008 Системы менеджмента качества.

Основные положения и словарь. - 2008. Канер С., Фолк Дж., Нгуен Е.К. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. -ДиаСофт, 2001.-544 с. Кендалл М., Стьюарт А. Статистические выводы и связи. — М.: Наука, 1973.

- 899 с.

Когаловский М.Р. Перспективные технологии информационных систем. -М.: ДМК Пресс; М.: Компания АйТи, 2003. - 288 с. (Серия «ИТ-Экономика»)

Лисецкий Ю.М. Метод комплексной экспертной оценки для проектирования сложных технических систем // Математические машины и системы. 2006.-№2.-С. 141-146. Лобанов A.A., Чугунов A.B. Энциклопедия финансового риск менеджмента.

- М.: Альпина Бизнес Букс, 2007. - 878 стр.

Лотов A.B., Поспелова И.И. Многокритериальные задачи принятия решений:

Учебное пособие. - М.:МАКС Пресс, 2008. - 197 с. Майерс Г. Надежность программного обеспечения. - М.: Мир, 1980. - 360 с. Маквитти Л. Архитектура SOA как она есть. Сети и системы связи реализация [Электронный ресурс] // Журнал о компьютерных сетях и телекоммуникационных технологиях. - 2006. - Режим доступа: http://www.ccc.ru/magazine/depot/06 02/read.html?0104.html

Национальный стандарт (НТК): Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB - SOVNET National Competence Baseline Version 3.0) / А.А.Андреев, В.Н.Бурков, В.И.Воропаев, В.Р.Дорожкин, М.Ф.Дубовик, Л.В.Миронова, В.С.Палагин, А.В. Полковников, Г.И.Секлетова, Б.П.Титаренко, А.С.Товб, Ю.Ю.Трубицын, Г.Л.Ципес./ под н.ред.В.И.Воропаева. ISBN 5-90457403-1. - М.: ЗАО «Проектная ПРАКТИКА», 2010 - 256 с.

Орлов А.И., Пугач О.В. Подходы к общей теории риска // Управление большими системами. М.: ИПУ РАН. - 2012. - №40. - с.49-82.

Подиновский В. В. Анализ задач многокритериального выбора методами теории важности критериев при помощи компьютерных систем поддержки принятия решений // Известия РАН. Теория и системы управления. - 2008. - №2. - С.64-68.

Подиновский В.В., Ногин В.Д. Парето-оптимальные решения многокритериальных задач. - М.: ФИЗМАТЛИТ, 2007. - С. 256.

Портье Б. Обзор терминологии SOA: Часть 1. Сервис, архитектура, управление и бизнес-термины [Электронный ресурс]. - 2008. - Режим доступа: http://www.ibm.com/developerworks/ru/library/ws-soa-

terml/index.html

Пырлина И.В. Классификация операционных рисков при сервисно-ориентированном подходе к созданию информационной системы // Бизнес-Информатика. - 2011. - №4(18). - с.54-62.

Пырлина И.В. Выбор эффективного проекта реализации сервисно-ориентированной архитектуры информационной системы // Проблемы управления. - 2012. - № 4. - с.59-69.

Пырлина И.В. Риски и выбора оптимальных проектов: сервис-ориентированная архитектура информационных систем // Управление большими системами. М.: ИПУ РАН.- 2013г.-№43. - с. 132-181.

Руководство к своду знаний по управлению проектами (Руководство РМВОК).- 4-е изд. -М.: PMI-2010. -496 с.

Сингина А. А. Взгляд на управление рисками информационных систем [Электронный ресурс] // Молодой ученый. — 2011. — №6. Т.1. — С. 101-105. - Режим доступа: http://www.moluch.ru/archive/29/3284/

Ackoff R.L. Towards a Behavioral Theory of Communication // Management Science. - 1958. - Vol. 4.- № 8. - P. 218-234.

Ahituv N. A. Systematic Approach toward Assessing the Value of an Information System // MIS Quarterly. - 1980. - Vol. 4. - No. 4. -pp. 61-75. URL: http://www.jstor.org/stable/248961.

Aleskerov F. Т., Chistyakov V. V., Kalyagin V. A. Multiple criteria threshold decision making algorithms: Working paper WP7/2010/02 // Moscow: State University - Higher School of Economics. -2010. -P.40.

Aleskerov F. Т., Chistyakov V. V., Kaliaguine V. A.. Social threshold aggregations // Social Choice and Welfare. - 2010. - Vol.35. - No. 4. - P. 627-646.

Aleskerov Ф.Т., Chistyakov V.V. The threshold decision making effectuated by the enumerating preference function // International Journal of Information Technology and Decision Making. - vol. 12.-No. 6.- 2013.-pp. 1-22.

Azevedo L.G. A Method for Service Identification from Business Process Models in a SOA Approach. Springer-Verlag, Berlin, Heidelberg, 2009.

Bell M. Service-oriented modeling. Service analysis, design, and architecture // Wiley & Sons Inc., 2008. - 387p.

Boehm В., Madachy R., Selby R. Cost models for future software life cycle processes: COCOMO 2.0 // Annals of Software Engineering. - 1995. -Vol 57.-№ 1. -p.57-94.

Brown A.W., Delbaere M., Johnston S.K. A Practical Perspective on the Design and Implementation of Service-Oriented Solutions // MoDELS 2007.-Springer-Verlag Berlin Heidelberg. - pp. 390-404.

Chandler J. S. A Multiple Criteria Approach for Evalu-ating Information Systems // MIS Quarterly. - 1982. - Vol. 6.- № 1. - P. 61 -74.

Das P., Hanf D. Applying ROI Analysis to Support SOA Information Security Investment Decisions // IEEE Conference on Technologies for Homeland Security. -2008. - E-ISBN 978-1-4244-1978-4. - pp. 359-366.

Dash R., Dash Raj. Risk Assessment Techniques for Software Development // European Journal of Scientific Research ISSN 1450-216X. - 2010. - Vol.42, №4. - P.629-636.

Embrechts P., Puccetti, Jaworski G. P., Durante F., Haerdle W., Rychlik T. Risk Aggregation. Copula Theory and its Applications, Lecture Notes in Statistics // Proceedings 198, Springer Berlin/Heidelberg. - 2010. - P. 1 linó.

Ergonos Consulting S.A.Comparative Salary Benchmark [Электронный pecypc].-Engineering. -2011. - Режим доступа:

http://www.ergonos.ch/salary_benchmarks/samples/comparativebm_head_o f_engineering_Russia-Italy.pdf

Erl Т. Service-Oriented Architecture: Concepts, Technology, and Design. -Prentice Hall PTR, 2005. - pp. 792.

Erradi A. Service Design Process for Reusable Services: Financial Services Case Study Springer-Verlag, Berlin, Heidelberg, 2007.

Finkelstein C. The Enterprise: Service-Oriented Architecture (SOA) [Электронный ресурс] // Information Management Magazine. - 2005. -Режим доступа: http://www.information-

management.com/issues/20050101/1016488-1 .html

Fowler M., Rice D., Foemmel M., Hieatt E., Mee R., Stafford R. Patterns of Enterprise Application Architecture. - Addison Wesley, 2002. - 560 c.

Grochow, J.M. A Utility Theoretic Approach to Evalua-tion of a Time-Sharing System - Statistical Computer Performance Evaluation, in Freiberger, W., Academic Press, New York, 1972.

Guo Y., Sampath S. Web Application Fault Classification—An Exploratory Study [Электронный ресурс] // ESEM '08 Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement ACM New York. - 2008. - Режим доступа: http://portal.acm.org/citation.cfm?id=1414060 Haas H., Brown A. Web Services Glossary. W3C Working Group Note 11 [Электронный ресурс] // W3C. 2004. - Режим доступа: http://www.w3 .org/TR/ws-gloss/ Higuera R.P., Haimes Y.Y. Software Risk Management [Электронный ресурс] // Technical Report CMU/SEI-96-TR-012 ESC-TR-96-012. - 1996. -p.59. -Режим доступа: http://www.rai.com Hoodat H., Rashidi H. Classification and Analysis of Risks in Software Engineering // World Academy of Science, Engineering and Technology. -2009.-№56.- pp.446-452. ISO/IEC 27000:2009, Information technology - Security techniques - Information

security management systems - Overview and vocabulary. - 2009. Kalabina L., Pratusevich V., Prokhorov A., Tsygankov V., Zagnetko A. Russia Vertical Markets 2012-2016 IT Spending Forecast [Электронный ресурс] // Market Analysis. IDC - 2012. - p.62. - Режим доступа: http://www.idc.com/getdoc.jsp?containerId=EV08U Khalid M., Manzoor M.I., Shakeel A., Bashir A. Integration Efforts Estimation in Service Oriented Architecture (SOA) Applications // Information and Knowledge Management. - 2011. - Vol.1. - № 2. -pp. 23 - 27.

Klein G., Beck P.O. A Decision Aid for Selecting among Information System Alternatives // MIS Quarterly. - 1987. - Vol. 11. - №2. -P.177-185

Krawczyk H., Wiszniewski В., Mork H. Classification of software defects in parallel programs // HPCTI Progress Report. - №1. -1995. - pp.89-111

Liu J., Qiao J., Lin Sh. Risk Prediction and Measurement for Software Based on Service-Oriented Architecture. - Springer-Verlag Berlin Heidelberg, 2009..

Liu L., Russell D., Xu J., Webster D., Luo Z., Venters C., Davies J. K. Modelling and Simulation of Network Enabled Capability on Service-Oriented Architecture // Simulation Modelling Practice and Theory. - 2009. - Vol.17. -№ 8. -pp.1430-1442.

Lokan C.J. An Empirical Analysis of Functional Point Adjustment Factors // Information and Software Technology. - 2000. - 42 (9). -pp. 649 - 659.

Luqi, Nogueria L.J. A Risk Assessment Model for Evolutionary Software Projects [Электронный ресурс] // IEEE. - 2005. - Режим доступа: http://www.disi.unige.it/person/ReggioG/PRQCEEDINGS/luqi.pdf

MacKenzie C.M., Laskey К., McCabe F., Brown P.F., Metz R., Hamilton B.A. Reference Model for Service Oriented Architecture 1.0 [Электронный ресурс] //Committee Specification 1. Oasis. - 2006. - Режим доступа: http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

Marschak J. Economics of Information Systems // Journal of the American Statistical Association. - 1971.-Vol. 66. -№ 333.-P. 192-219.

McGovern J., Sims O., Jain A.. Enterprise Service Oriented Architectures: Concepts, Challenges, Recommendations - 2006. - 448 p.

McQuire C.B., Radner R. Decision and Organization. - North Holland Publishing Co., Amsterdam, Holland, 1972.

Natis Y.V., Schulte R.W. Introduction to Service-Oriented Architecture. - Gartner, 2003.

Nogueira J.C., Luqi, Berzins V., Nada N. A Formal Risk Assessment Model for Software Evolution. PH.D. Dissertation, Naval Postgraduate School.-California., 2000.-p.74.

Park S., Choi J., Yoo H. Integrated Model of Service-Oriented Architecture and Web-Oriented Architecture for Financial Software // Journal of Information Science and Engineering. - 2012. - № 28.- pp. 925 - 939.

Pitt L.F., Watson R.T., Kavan C.B. Service Quality: A Measure of Information Systems Effectiveness // MIS Quarterly. - 1995. - Vol. 19. - №2. -P.173-187

Pyrlina I. Choice of Efficient Information System with Service-Oriented Architecture using Multiple Criteria Threshold Algorithms (With Practical Example) [Электронный ресурс] // Труды международной конференции по Информатике и ИТ, 2012, Венеция, Италия. - р. 151-159. ISSN: 2162-6359. Режим доступа: http://www.waset.org/journals/iiems/v6/v6-29.pdf

Pyrlina I. Operational risks Classification for Information Systems with Service-Oriented Architecture (Including Loss Calculation Example) [Электронный ресурс] // Труды международной конференции по ИТ, 2012, Венеция, Италия. - р.337-343. ISSN: 2162-6359. Режим доступа: http://www.waset.org/journals/ijems/v6/v6-7.pdf.

Rainer R.K., Snyder С.А., CARR Н. Н. Risk analysis for Information Technology. // Journal of Management Information Systems. - 1991. - Vol.8. - № 1. - pp. 129- 147.

Role B. Quantitative model for Information Security Risk Management. Management // Knowledge and Learning International Conference. - 2012. -pp.267-275.

Sarjoughian H., Kim S., Ramaswamy M., Yau S. A simulation framework for service-oriented computing systems //Proceedings of the 2008. - Winter Simulation Conference. IEEE. -2008. - pp. 845-853.

Sommerville I. Software Engineering, 8th ed. - Addison-Wesley Publishers Limited, ISBN 13: 978-0-321-31379-9, 2006. - 865 p.

Suddle Sh. The weighted risk analysis // Safety Sience. - 2009. - №47. - pp. 668679.

Trenaman A. Using Open Source Software for SOA. - IONA Technologies, 2005.

Verdón D., Mcgraw G. Risk Analysis in Software Design // IEEE computer society. IEEE security & privacy. - 2004. - pp.32-37.

Wang W., Wang Wei, Zander J., Zhu Y.Three-dimensional conceptual model for service-oriented simulation // Journal of Zhejiang University SCIENCE. -10(8). -2009. -pp.1075-1081.

Watson R.T., Pitt L.F., Kavan C.B. Measuring Information Systems Service Quality: Lessons from Two Longitudinal Case Studies // MIS Quarterly. -1998.-Vol. 22.-№ 1.-P. 61-79.

Werth D. Managing SOA through Business Services - A Business-Oriented Approach to Service-Oriented Architectures. - Springer-Verlag Berlin Heidelberg, 2007.

Wiehler G. Web Services and Service Oriented Architecture. The Impact on Business Applications // Siemens Business Services. - 2004.

ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ 1. Описание проектов

Таблица 30 Описание проектов

Описание проектов

Проект 1 - Нефтегазовая компания

Описание проекта Проектирование корпоративных приложений с сервисно-ориентированной архитектурой. Создание 4 композитных приложений с использованием 9 Корпоративных сервисов в рамках одного выбранного процесса.

Создание единой системы Согласования Запросов на Приобретение Дорогих Товаров (с использованием 4 композитных процессов и 9 сервисов). Она включает использование элементов процессов существующих в ландшафте предприятия систем mySAP Enterprise Resource Planning (ERP), Supply Relationship Management (SRM). С помощью интеграционной шины данных SAP NetWeaver данные передаются в приведенные выше системы. В качестве интерфейса пользователя используется корпоративный портал, для ведения основных данных используется решение SAP NetWeaver Master Data Management (MDM).

Организационное Назначение владельцев процессов, создание организационной обеспечение структуры для поддержания СОА (владельцы процессов, Архитектор

СОА, бизнес-аналитик, разработчик сервисов, интеграционный эксперт). Проект 2 - Нефтегазовая компания

Описание проекта Внедрение решения «транспорт-менеджер», реализующего

композитный процесс подачи заявки на автотранспорт на базе сервисного подхода на интеграционной платформе. Оннсаннс Создание композитного приложений на базе платформы SAP

архитектуры NetWeaver (SAP NW) для того, чтобы связать производственные и

контроллинговые системы текущего ИТ-ландшафта (ИС-АТ, ГИС, SAP системы), обеспечить создание приложений на основе бизнес-процессов, а также усовершенствовать процессы транспортного управления.

Организационное Ввод новых ролей в организационной структуре ИТ обеспеченно

Проект 3 - Банковская компания

Описание проекта Создание фронтального решения обеспечивающее «единое окно

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

Описание

архитектуры

решения

Основная задача системы - интегрировать учетные системы, системы SAP R/3 и «не-SAP системы» («Сфера», 1С, Lotus), чтобы обеспечить работу в режиме реального времени специалистов. Композитное приложение обеспечивает:

■ Единый интерфейс пользователя, ориентированный на совместную работу (Web-интерфейс)

■ Единое ведение Основных Данных " Независимость реализуемого процесса от специфики

реализации бизнес- сервисов Организационное Нет обсспсчсипс

Проект 4 - Нефтегазовая компания

Описание проекта Создание информационно-технического комплекса, решающего весь спектр задач, связанных с ведением и использованием данных в компании. В решении предусмотрена возможность интеграции различных информационных систем (ERP, учетных, производственных) на уровне данных, реализована функция разграничения прав доступа к информации. Создание Единой системы нормативно-справочной информации (ЫСИ) на платформе SAP MDM с поэтапной организацией информационно-технологического ландшафта и централизованного хранилища данных, включающего все основные справочники и классификаторы корпоративных прикладных систем (ERP-класса, учетных и производственных). Большое значение придавалось созданию базовой аппаратно-программной интеграционной инфраструктуры на основе SAP NetWeaver. Организационное Ввод новых ролей в организационной структуре ИТ и обеспечение соответствующих бизнес подразделений.

Проект 5 - Нефтегазовая компания

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

архитектуры с локальными информационными системами средствами

интеграционной платформы SAP NetWeaver. Решение предусматривает организацию работы с критическими стандартами Microsoft.NET и J2EE для интеграции современных бизнес-приложений

Организационное Ввод новых ролей в организационной структуре ИТ и обеспечение соответствующих бизнес подразделений.

Проект 6 - Нефтегазовая компания

Описание архитектуры

Описание архитектуры

Описание проекта В проекте осуществляется интеграция системы класса ERP и нефтегазовой системы OIS для реализации прозрачных бизнес-процессов с возможностью использования данных из нескольких систем. В частности реализуемый процесс призван отразить фактические показатели выполнения мероприятия с помощью стандартных документов системы класса ERP на основании акта выполненных работ из подсистемы OIS Ремонты. Описание Реализуется средство интеграции систем OIS и R/3, которое

архитектуры выполняет следующие функции:

■ Поддерживает существующие протоколы и форматы передачи данных.

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

■ Гарантирует доставку информации от отправителя к получателю, предоставляет инструменты мониторинга и администрирования потоков данных.

■ Эффективно использует имеющиеся каналы связи, при необходимости использовать резервные способы доставки информации.

Организационное Нет обеспечение

Проект 7 - Банковская компания

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

учетных систем, системы ERP и другие системы («Сфера», 1С, Lotus, TIBCO BW) для того, чтобы обеспечить бухгалтерский учет, контроль ресурсов и управление сквозными бизнес-процессами, использующими данные из различных систем. Описание Реализуется средство интеграции систем SAP R/3 и «не-SAP систем»,

архитектуры которое выполняет следующие функции:

■ Поддерживает существующие протоколы и форматы передачи данных.

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

■ Обеспечивает интеграцию проектов на организационном, информационном и технологическом уровнях.

■ Обеспечивает встраивание новых бизнес-процессов в существующую среду бизнес-процессов Корпорации.

Организационное Нет обеспечение

ПРИЛОЖЕНИЕ 2. Программный код имитационной модели

Код программы:

mainmodel Risk Model { aux Average Error Solution { autotype Real autounit Request/mo

defDELAYINF( 'Solved Errors', 'Time to Average Solution', 1, 'Solved Errors') doc The smoothed average of shipment over time.

aux Data { autotype Real autounit Request

def 'Error Processing'*0.18 }

aux Data error { type Real

def'Find Chosen Output - Data'*l«l/Request» }

aux Data error Frequency { type Real

def 0 }

aux Define error type { autotype Real autounit Request/wk

def'Types of test Input - Copy'[lNDEX('Select Test Input - Copy')]

doc This variable holds the input the user has selected from the user interface. }

aux Desired Processing { autotype Real autounit Request

def'Solved Errors' * 'Desired Processing Coverage'

doc The desired level of inventory to be maintained. }

const Desired Processing Coverage {

autotype Real

unit mo

init 3«wk»

permanent

doc Number of weeks supply that the Inventory should be able to cover. }

aux Error { autotype Real unit Request/mo dim Errorlnput

def { 'NEF SUM'* 1 «Request/wk», 'Find Chosen Test Input'}

}

const Error Control { type Integer

init 2 // 1 = Statistic flow

111 — Random generation permanent

doc 1 = Statistic flow

2 = Random genearion }

aux Error flow { autotype Real autounit mo

def EXPRND(TIMESTEP*66.7,0.01)

aux Error matrix { autotype Real autounit mo dim 'Error type' def { 0.1*'Error flow', 0.48*'Error flow', 0.07*'Error flow', 7 0.06*'Error flow', 0.25*'Error flow', 0.04*'Error flow'}

}

level Error Processing { autotype Real autounit Request

init 'Desired Processing Coverage' * 'Normal Processing' inflow { autodef 'Requests Received'} outflow { autodef 'Solved Errors'}

doc Number of items in stock is based on the normal shipments and for how many weeks you want to keep

this coverage. }

aux Error Processing Adjustment { autotype Real unit Request/mo

def ('Desired Processing' - 'Error Processing') / 'Error Processing Adjustment Time'

doc The difference between desired and actual inventory. }

const Error Processing Adjustment Time {

autotype Real

unit mo

init 2«wk»

doc Number of weeks it takes to adjust any discrepancey between desired inventory and actual stock of

inventory. }

aux Error type { autotype Real autounit Request/wk

def'Define error type' + 'Find Chosen Noise Input - Copy'

doc Adds the two types of test inputs to each other. }

aux Find Chosen Error Input { autotype Real autounit Request/mo def Error[INDEX ('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Noise Input - Copy { autotype Real autounit Request/wk

def'Noise - Copy'[INDEX('Noise Control - Copy')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Output { autotype Real unit Request

def 'Output result_NE'[INDEX('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Output - Data { autotype Real autounit Request

def'Output resultData'[lNDEX('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Output - Functional { autotype Real autounit Request

def'Output result_Functional'[INDEX('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Output - I-O { autotype Real autounit Request

def'Output result_I-0'[INDEX('Error Control')]

8doc The noise is either on or off according to the user input. }

aux Find Chosen Output - Middleware { autotype Real autounit Request

def'Output result_Middleware'[INDEX('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Output - System { autotype Real autounit Request

def'Output result_System'[INDEX('Error Control')]

doc The noise is either on or off according to the user input. }

aux Find Chosen Test Input { autotype Real autounit Request/mo

def Types of test Input'[INDEX('Select Test Input')]

doc This variable holds the input the user has selected from the user interface. }

aux Functional { autotype Real autounit Request

def'Error Processing'*0.51 }

aux Functional Error { type Real

def'Find Chosen Output - Functional'* 1«1 /Request»

aux Functional error Frequency { type Real

defO }

aux I-O Error { type Real

def'Find Chosen Output - I-O'* l«l/Request» }

aux I-O error Frequency { type Real

def 0 }

aux Input-output { autotype Real autounit Request

def'Error Processing'*0.06 }

aux Middleware { autotype Real autounit Request

def'Error Processing'*0.04 }

aux Middleware error { type Real

def'Find Chosen Output - Middleware'* l«l/Request>> }

aux Middleware error Frequency { type Real

def 0 }

aux NE { autotype Real autounit Request

def'Error Processing'*0.03 }

auxNEFSUM { autotype Real

9def 'Not error Frequency'+'Data error Frequency'+'Functional error Frequency'+'I-O error Frequency'+

'Middleware error Frequency'+'System error Frequency' }

aux Noise - Copy { autotype Real autounit Request/wk dim Errorlnput

def { RANDOM( 10«Request/wk>>, 20«Request/wk>>), 0«Request/wk>> }

}

const Noise Control - Copy {

type Integer

init 2 // 1 = Noise is on

// 2 = Noise is off permanent

doc 1 = Noise is on. 2 = Noise is off }

const Normal Processing { autotype Real unit Request/mo

init 100«Request/wk>> }

aux Normal Distribution { autotype Real unit Request/mo

def NORMAL('Volume Test Input'*TIMESTEP*l«l/wk»,0.7«Request/wk>>) }

aux Normal_Distribution - Copy { autotype Real autounit Request/wk

def NORMAL('Volume Test Input - Copy'*TIMESTEP*5«l/wk»,0.7«Request/wk>>) }

aux Not Error { type Real

def'Find Chosen Output'* l«l/Request» }

aux Not error Frequency { type Real

def 0 }

aux Output result_Data { autotype Real unit Request dim Errorlnput

def { 'Data error Frequency'* 1 «Request»,

Data* 1 } }

aux Output result_Functional { autotype Real unit Request dim Errorlnput

def {'Functional error Frequency'* 1 «Request»,

Functional} }

aux Output result_I-0 { autotype Real unit Request dim Errorlnput

def { 'I-O error Frequency'* 1 «Request»,

'Input-output' } }

aux Output result_Middleware { autotype Real unit Request dim Errorlnput

def { 'Middleware error Frequency'* 1 «Request»,

1 (Middleware } }

aux Output result_NE { autotype Real unit Request dim Errorlnput

def {"Not error Frequency'* 1 «Request», NE}

}

aux Output result_System { autotype Real unit Request dim Errorlnput