Содержание к диссертации
Введение
Глава 1.Оценка рисков и проблема выбора 17
Корпоративных информационных систем с сервис-ориентированной архитектурой
1.1 Оценка рисков информационных систем с сервис- 18
ориентированной архитектурой
1.1.1 Метод COCOMO 19
1.1.2 Метод вероятностного анализа дерева рисков 24
1.1.3 Метод анализа ежегодного ожидаемого убытка 26
1.1.4 Метод анализа функциональных точек 27
1.1.5 Методы взвешенных рисков 31
1.1.6 Метод управления рисками ПО 32
1.1.7 Метод проектных рисков 36
1.1.8 Общая модель оценки рисков ИС 37
1.1.9 Метод анализа убытков при возникновении рисков на основе 38 биномиального, пуассоновского и нормального распределений
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. Анализ и моделирование операционных рисков информационных систем с сервис-ориентированной архитектурой
2.1 Операционные риски информационных систем 66
2.1.1 Существующие классификации ошибок информационных систем
2.1.2 Классификация рисков информационных систем 69
2.2 Операционные риски информационных систем с сервисориентированной архитектурой
2.3 Новая классификация ошибок информационных систем с сервис-ориентированной архитектурой
2.4 Анализ и имитационное моделирование ошибок информационных систем с сервис-ориентированной архитектурой
2.5 Анализ убытков при реализации операционных рисков 91
2.5.1 Описание опроса экспертов компании 91
2.5.2 Оценка убытков при реализации операционных рисков 95
2.6 Метод ранжирования рисков сервис-ориентированной 102
архитектуры при оценке проектов внедрения ИС
Глава 3. Выбор эффективного проекта реализации информационной системы с сервис- ориентированной архитектурой с использованием пк смаимр
3.1 Критерии качества проекта 108
3.1.1 Разработка критериев для задачи выбора референциальной архитектуры корпоративной ИС
3.1.2 Разработка критериев для задачи гармонизации структуры 119
4 профиля сотрудников в гетерогенном ландшафте приложений SAP
3.2 Метод порогового агрегирования 122
3.2.1 Модификация алгоритма ранжирования в виде таблицы с исключениями
3.2.2 Переход от числовых оценок к рангам 131
3.3 Процедура построения, оценки и выбора вариантов сервис- ориентированной архитектуры информационных систем
Глава 4. Моделирование рисков и выбор проектов информационных систем с сервис-ориентированной архитектурой с использованием пк смаимр
4.1 Экспериментальное исследование методов оценки рисков и выбора референциальной архитектуры корпоративной ИС
4.2 Экспериментальное исследование методов оценки рисков и выбора оптимального проекта в задаче гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений SAP
Заключение 154
Список терминов 156
Список литературы
- Метод анализа ежегодного ожидаемого убытка
- Классификация рисков информационных систем
- Оценка убытков при реализации операционных рисков
- Экспериментальное исследование методов оценки рисков и выбора оптимального проекта в задаче гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений SAP
Введение к работе
Актуальность. Широкое применение информационных систем (ИС) автоматизации функционирования предприятия и постоянное совершенствование подходов к проектированию архитектуры ИС привело к постановке ряда важных вопросов, в частности, вопроса выбора наиболее подходящего типа архитектуры и способа реализации ИС. Одним из наиболее распространенных типов архитектуры на сегодняшний день является сервис-ориентированная архитектура (СОА), которая рассматривается не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой архитектура приложения строится на основе сервисов, предоставляемых другим приложениям в сетевой среде.
Поставив цель перед ИТ-организацией осуществить переход на сервис-ориентированную архитектуру, ИТ-директор и ИТ-архитекторы сталкиваются с большим количеством предложенных вариантов информационных систем, реализующих СОА, для выбора которых составляются требования к ИС и объявляется тендер. Каждый из возможных проектов реализации таких систем имеет свои преимущества и недостатки, предоставляет разные виды платформы, разные механизмы организации работ и управления сервисами. Поэтому для того, чтобы принять решение, необходим инструмент анализа различных альтернатив на этапе, предваряющем начало проекта реализации. Использование такого инструмента позволит своевременно реагировать на изменения и потребности бизнеса. Для того чтобы выбрать правильный проект реализации информационной системы, соответствующий всем требованиям и характеристикам СОА, а также минимизирующий риски, необходимо использовать более эффективные методы анализа и ранжирования проектов, чем те, которые используются сегодня.
Успешность реализации информационных систем с сервис-ориентированной архитектурой во многом зависит от того, как далеко от первоначальной концепции СОА находятся потенциальные проекты реализации, и какие проекты больше отвечают требованиям и основным характеристикам концепции. Поэтому актуальным вопросом сегодня является разработка метода оценки операционных
рисков и выбора проекта реализации информационной системы с сервис-ориентированной архитектурой.
Цель диссертационной работы состоит в определении и моделировании операционных рисков информационных систем с сервис-ориентированной архитектурой, а также в разработке методов и прототипа комплекса программ, поддерживающих выбор оптимальных проектов с СОА с учетом критериев качества системы и потенциальных рисков.
Основные задачи диссертации. В работе проводится
исследование проблем классификации, математического
моделирования и оценки операционных рисков информационной системы с сервис-ориентированной архитектурой, а также выбора проекта реализации таких систем. В диссертационной работе поставлены следующие задачи:
-
разработка метода сбора данных, классификации и анализа операционных рисков сервис-ориентированной архитектуры ИС,
-
математическое моделирование потока ошибок (операционных рисков) информационной системы на основе выведенных распределений типов рисков,
-
разработка критериев качества проектов на примере двух проектов
-
разработка метода выбора проекта сервис-ориентированной информационной системы с использованием многокритериального анализа вариантов архитектуры,
-
реализация прототипа комплекса программ, поддерживающего математическое моделирование рисков и выбор оптимальных проектов.
Использование предложенных методов позволит ИТ-директорам и ИТ-архитекторам принимать более качественные решения о стратегии развития ИС с сервис-ориентированной архитектурой.
Научная новизна результатов работы, выносимых на защиту, состоит в том, что:
-
Разработан новый метод классификации и оценки рисков ИС с СОА.
-
Предложен метод выбора оптимальных проектов ИС с СОА.
-
Разработан новый метод математического моделирования операционных рисков ИС с СОА.
-
Сформулирована новая двухэтапная процедура построения, оценки и выбора проектов архитектуры ИС с использованием генерации оценок на основе эквивалентного числового ключа, соответствующая правилу порогового агрегирования при любых га-градационных оценках по п критериям проекта ИС с сервис-ориентированной архитектурой.
-
Разработан прототип комплекса программ системы многокритериального анализа и математического моделирования рисков (СМАиМР), который позволяет проводить имитационное моделирование рисков, и поддерживает быстрое ранжирование альтернативных проектов методом порогового агрегирования.
Практическая значимость. Разработанные методы оценки рисков и выбора проектов, включая прототип комплекса программ СМАиМР, могут применяться на предприятиях для выбора альтернативных проектов ИС с СОА, в частности для поддержки процесса выбора на тендерах или конкурсах. Результаты работы также могут применяться для учета потенциальных рисков от внедряемой ИС с СОА.
Реализация и внедрение. Разработанные методы оценки рисков и выбора проектов, а также прототип комплекса программ СМАиМР, были применены в компании ООО «САП Лабе» для решения задачи выбора референциальной корпоративной ИС и задачи гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений, а также в компании 000 «Миттель-МГУ» при решении задачи выбора единой системы ведения данных клиентов, их сегментации и управления маркетинговыми мероприятиями.
Практическая значимость результатов работы подтверждена актами о внедрениях от 000 «САП Лабе» и 000 «Миттель-МГУ».
Апробация работы. Результаты работы докладывались на общемосковском семинаре "Экспертные оценки и анализ данных" в ИЛУ РАН в 2012 г., на международной конференции по ИТ, 2012 г., Венеция, Италия (ICIT 2012) и на международной конференции по информатике и информационным технологиям, 2012 г., Мадрид, Испания (ICCSIT 2012).
Публикации. По результатам исследований опубликовано 6 печатных работ, в том числе 5 в журналах, одобренных ВАК РФ для
публикации основных результатов диссертационных исследований, и одна публикация в базе патентного ведомства США.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка терминов, списка используемой литературы и шести приложений. Объем работы - 156 стр., приложения - 37 стр.
Метод анализа ежегодного ожидаемого убытка
Дерево рисков используется в модели для того, чтобы проанализировать все события, приводящие к нежелательным последствиям реализации ИС. Для этого составляется список всех возможных нежелательных последствий и список всех возможных причин возникновения таких последствий.
Вероятностный анализ дерева рисков используется для того, чтобы вычислить вероятность ключевого события, используя вероятности событий предшественников. Для этого дерево рисков описывается с помощью операторов «ИЛИ»/«И», которые потом переводятся в следующие формулы где n - число рассматриваемых событий, pi - вероятность возникновения событий, приводящих к нежелательным последствиям реализации ИС (при этом события считаются независимыми), S - ключевое событие, A и B -события-предшественники.
В случае если события-предшественники являются зависимыми, тогда используются следующие формулы Для каждого события риска также необходимо определить влияние события риска, что позволяет оценить суммарный риск. Риски с наибольшими вероятностями возникновения рекомендуется рассматривать с особым вниманием и продумывать мероприятия по их устранению.
В модели вероятностного анализа дерева рисков рассматриваются в основном риски этапа проектирования ИС. К таким рискам относятся, например, риски бюджета, риски планирования, риски сбора требований. На этапе эксплуатации используются риски технических ресурсов. Затрагиваются также риски, относящиеся как к этапу проектирования ИС, так и к этапу эксплуатации ИС, такие как риски персонала и риск связующего ПО.
Метод анализа ежегодного ожидаемого убытка Оценка рисков сервис-ориентированной архитектуры с учетом метода анализа ежегодного ожидаемого убытка упоминается в [Das, Hanf, 2008] при анализе величины возврата инвестиций от СОА. В соответствие с моделью [Verdon, Mcgraw, 2004], убыток при реализации рисков оценивается с помощью показателя ежегодного ожидаемого убытка
Годовая норма возникновения риска показывает частоту, с которой ожидается возникновение риска. Частота или вероятность возникновения риска варьируется от 0 до 1.
Для того чтобы оценить ежегодный ожидаемый убыток, сначала оцениваются ресурсы информационных систем, которые уязвимы и подвержены сбоям. Затем с помощью экспертов оцениваются потенциальные угрозы, приводящие к сбоям работы данных ресурсов. Уязвимость каждого ресурса выражается как вероятность возникновения угрозы в год, умноженная на единовременно ожидаемый убыток. Единовременно ожидаемый убыток вычисляется как SLE = AV-EF, где AV - стоимость ресурса ИС, EF - фактор влияния. Фактор влияния - это процент негативного влияния реализовавшегося риска на ресурс. Единовременно ожидаемый убыток обычно представляет собой оценку влияния риска [Rainer и др., 1991].
Таким образом, данный метод ориентирован на определение рисков на этапе эксплуатации ИС. Однако он не приводит определения каких-либо отдельных типов рисков.
Метод анализа функциональных точек
Метод анализа функциональных точек (FPA) был предложен А.Альбрехтом в 1979 г. и используется для оценки сложности ИС. Сложность системы часто оценивается по количеству строк кода. К недостаткам показателя можно отнести неопределенность понятия «строка кода» и различие в стилях и языках программирования, при которых одна и та же ИС будет содержать разное количество строк кода. Метод анализа функциональных точек устраняет недостатки оценки сложности ИС по количеству строк кода. Данный метод изначально основывался на анализе четырех базовых компонент ИС и десяти основных факторов ИС. Затем метод был усовершенствован в 1983г., была добавлена дополнительная компонента ИС и четыре дополнительных фактора ИС [Khalid и др., 2011]. Таким образом, риски и влияние на проект отражаются в рамках четырнадцати факторов (и, соответственно, типах риска):
Классификация рисков информационных систем
В [Ahituv, 1980], [Grochow, 1972], [Klein, Beck, 1987], [Подиновский, Ногин, 2007], [Подиновский, 2008] предлагается использовать многокритериальную функцию полезности ИС при выборе проектов. Для построения функции полезности необходимо определить параметры оценки информационной системы. Обычно к ним относятся своевременность, точность, и надежность. В [Ahituv, 1980] рассматриваются четыре группы критериев Информационной системы отчетности, к которым относятся:
Группа критериев «Своевременность» Содержит критерии с учетом предметной области ИС, если целью ИС является предоставление информации в кратчайшие сроки, то к критериям данной группы можно отнести время отклика ИС, если ИС спроектирована так, чтобы предоставлять данные с определенной частотой, то частота должна быть так же критерием. Критерии, входящие в данную группу:
Критерий «время отклика» определяется как разница между временем, когда информация была получена, и временем, когда она была запрошена. Функция полезности данного критерия -невозрастающая функция от времени t, она может быть непрерывной или дискретной.
Критерий «частота» отражает насколько важно предоставлять данные с определенной частотой, в силу природы области применения. Например, для рынка акций данные к концу торгового дня теряют свою важность и затем приобретают важность опять и в начале торгового дня, поэтому функция полезности в данном случае будет убывающей циклической функцией от
Группа критериев «Содержание системы». Содержит критерии оценки содержания отчетности. Они могут отражать несколько аспектов - частоту, значимость, высокое качество (уровень агрегирования), размер. В статье рассматриваются схожесть данных и уровень агрегирования.
Критерий «схожести данных» приведен для того, чтобы определить значимость и точность данных. После того как решение было принято, положим ЛПР может определить, какие данные он должен был получить, чтобы решение было оптимальным. Тогда предположим, что
D - это набор данных, полученных ЛПР, D - это набор данных, который бы привел к наилучшему решению, mх = m(D гл D ) - набор данных, общих для D и D , m2 = m(D -Dr\ D ) - набор данных, которые не были предоставлены для принятия решения ЛПР, m3 =m{D-D D ) - набор данных, которые были предоставлены ЛПР, однако не нужны для принятия решения. Определим схожести данных s следующим образом s=m1 l(ml +m2)-m3 l(ml +m3). Вероятности ошибки, исходя из исследований, подчиняются закону скользящего среднего или экспоненциальному закону. Функция полезности в данном случае неубывающая функция от s.
Критерий «степень агрегации данных» постоянно обсуждается в области систем отчетности и корпоративных ИС. В общем, в статьях принимается, что часть информации теряется при агрегации, вопрос значимости этой части остается открытым и является предметом постоянных обсуждений.
ЛПР сталкивается с большим числом критериев и данных по ним, человеческое восприятие ограничено с одной стороны, с другой стороны ЛПР может пропустить важные факторы, влияющие на решение. Часто агрегирование данных облегчают процесс принятия решений и ведут к тому же решению, что и при рассмотрении всех критериев.
Функция полезности в данном случае является квадратичной функцией и должна иметь единственное максимальное значение. 3. Группа критериев «Формат представления информации ИС» Существует много разных критериев оценки формата. В статье [Ahituv, 1980] предлагается рассмотреть 3.1 Критерий «средства передачи данных», например печатный отчет, портал, видео ролик, график 3.2 Критерий «порядок» - организация подачи данных в отчете 3.3 Критерий «графический дизайн», например, фон, шрифт, цвет.
Данную группу критериев довольно сложно оценить, поскольку критерии являются качественными, а не количественными. Поэтому пользователя можно попросить проранжировать данные, что определит функцию предпочтения.
Или же можно установить зависимости качественных критериев от количественных. Например, если выбрано средство передачи данных -принтер, то он ограничивает время ответа. Если для пользователя важно высокое время ответа, то оценка в критерии формат будет низкой, что будет означать необходимость замены формата в ИС. 4. Группа критериев «Стоимость» сравнивает системы по стоимости их внедрения. Функция стоимости работы имеет линейную зависимость от ключевых критериев ИС (например, время ответа, содержание системы).
В [Ahituv, 1980] определяется функция полезности исходя из следующих трех предположений:
1. Функция полезности схожести данных U, О) = -а2е( hs), где а2, Ъ2 0, а2 - коэффициент, переводящий функцию полезности и,в денежное выражение, s - вероятность ошибок в схожести данных.
s = \-p1-p2, где р1 - вероятность, что существующие данных не будут предоставлены, р2 - вероятность, что предоставленные данные не являются теми, которые нужны.
2. Функция полезности для времени отклика ИС Ut (t) = a/ V), а,, \ 0, ах - коэффициент, переводящий функцию полезности с/, в денежное выражение.
3. Критерий стоимости имеет линейную зависимость от схожести данных и времени отклика
Оценка убытков при реализации операционных рисков
При расчете величины убытка были использованы четыре варианта стоимости человеко-дня. Каждый уровень соответствует одной из четырех ролей сотрудников (администратор, инженер, ведущий инженер, менеджер). Обозначим множество ролей L. Разные приоритеты сообщений об ошибках в среднем по статистике выставляются разными группами пользователей.
Как показано на рисунке (Рисунок 2.5), в среднем, наблюдается зависимость приоритета сообщения от роли сотрудника - Низкому приоритету ошибок соответствует стоимость рабочего дня инженера, - Среднему и высокому приоритетам соответствует стоимость рабочего дня ведущего инженера, - Очень высокий приоритет соответствует стоимость рабочего дня менеджера.
Стоимость системных ошибок зависит от стоимости рабочего дня администратора. Стоимость указанных дней включает в себя не только заработную плату соответствующих специалистов, но и административные затраты на сотрудников и налоги. Иными словами предполагается, что величина Wij зависит от множества {wi1, w i2,w i3, w i4}, где wi1 соответствует ставке в день 4600 руб., wi2 - ставке 6600 руб., wi3 – ставке 6600 руб., w i4 – ставке 8600 руб. (Таблица 2.15). администратор. 5% администратор 0% Приоритет админи-_ Приоритет Приоритет Приоритет Рисунок 2.5 Статистика по типу роли сотрудника, выставляющего сообщение об ошибке
Из регрессии видно, что длительность устранения ошибки обратно пропорциональна стоимости (в день) устранения ошибки. Полученные условия и оценки были использованы для анализа операционных убытков. В Таблице 2.16 отражена полученная статистика в результате применения классификации ошибок из пункта 2.3 и оценки убытка по введенной формуле (5) при внедрении сервис-ориентированных ИС для двух предприятий металлургической и нефтегазовой отрасли. Здесь приведена лишь выборка наиболее показательных сообщений об ошибках из общей статистической базы.
Операционные убытки нефтегазового (выборка) клиента за 2006-20 № Короткий текст ошибок Основная категория Приоритет Устранение Операционные ошибок убытки (в (дни) руб./день) 1 Обозначения для сценария, выполняемого в форме Adobe Interactive FormsНезарегистрированные Ошибки ввода –выводарезультатовОшибки ввода – 4 3 18 92 000 2 92 000 пользователи не видят вывода содержания KM результатов 3 Ошибки при изменении данных системы в портале поддержки Ошибки ввода – вывода 3 8 92 000
Не все компоненты отражены после запуска BOM explosionОшибки создания нового документы отмены при работе с функцией отменыНе работает отчет Сравнение цен Разные экраны конфигурации в инструменте Integration BuilderОшибки связующего ПО – ошибка проверки BdocДиректория связующего ПО- результатовФункциональные ошибкиФункциональные ошибкиФункциональные ошибкиОшибки связующего ПООшибки связующего ПООшибки 2 22 4 2 3 21 11364 12 4 66 000
Канал передачи данных не найден связующего ПО 10 Нет прав для доступа к мастер-данным хранилища BI Ошибки данных 3 39 23 000
11 Ошибки по тайм-ауту при обработке мастер данных Ошибки данных 2 1 66 000 № Короткий текст ошибок Основная категория Приоритет Устранение Операционные ошибок убытки (в (дни) руб./день) 12 Ошибка распределения данных каталога продуктов Ошибки данных 2 5 330 000 Ошибка категоризации данных Системные в базе данных SDB ошибки 14 Высокое потребление сервером Системные памяти процессора (CPU) ошибки 2 7 000 920 0 15 Во время экспорта данных ошибка отсутствия памяти
Дополнительно в таблице отражено общее количество дней, которое потребовалось для устранения ошибки, что дает представление об общей величине операционных убытков ИТ, и, по сути, является примером операционных убытков информационных систем с сервис-ориентированной архитектурой.
Экспериментальное исследование методов оценки рисков и выбора оптимального проекта в задаче гармонизации структуры профиля сотрудника в гетерогенном ландшафте приложений SAP
Архитектура: информационной системы определяется как организация системы, которая охватывает механизмы обработки данных, систему памяти и процессоров, структуру системной шины, организацию ввода-вывода [Барановская, 2003], [Базель, 2004]. Существует несколько типов архитектур информационных систем: монолитная, двухзвенная, трехзвенная, распределенная, сервис-ориентированная и ориентированная на события. Архитектура ИС определяет 1) где находится логика приложения – это правила и алгоритмы, которые на основе входящей информации преобразуют данные, сохраняют их в базу данных и вызывают функции других систем [Fowler и др., 2002] (например, на уровне базы данных в двухзвенной архитектуре или на отдельном сервере в случае с трехзвенной архитектурой), 2) как строится интерфейс системы (в виде Web-интерфейса в распределённой архитектуре или в виде полноценного приложения со встроенной логикой в двухзвенной архитектуре), 3) какие требуются технические ресурсы для ее поддержки, 4) должна ли использоваться интеграционная платформа или шина данных (или связующее ПО) – единый интерфейс [McGovern и др., 2006] как для потребителей, так и для поставщиков отдельных компонент и приложений ИС, который дает возможность на уровне конфигурации контролировать адресацию приложений (как в случае с распределенной архитектурой, так и сервис-ориентированной архитектурой).
Бизнес-сервис: под бизнес-сервисом в данном случае понимается область деятельности предприятия, где реализация приложений с сервис-ориентированной архитектурой будет иметь наибольшую выгоду для предприятия. Определим бизнес-сервис как совокупность 1. функций, объединенных по критичным для бизнеса атрибутам, 157 2. системных операций, обернутых в web-сервисную оболочку, 3. технических ресурсов, реализующих приложения, на базе которых работают технические сервисы (например, web- сервисы).
Гармонизация: вариант оптимизации информационных систем, при котором осуществляется консолидация данных и функций в центральной системе, и добавление локальных данных и функций в прикладные системы, что является необходимым условием дальнейшего взаимодействия интегрируемых систем между собой. Гетерогенный ландшафт ИС: это совокупность разнородных информационных систем, имеющих разную архитектуру, программный код и систему интеграции. Гранулярность: в СОА [Azevedo, 2009] означает уровень функций и технических решений, поддерживающих эти функции, а также количество процессов, охватываемых или выполняемых сервисом. Информационная система: [Дика, 1996] определяется как система, предназначенная для сбора, передачи, обработки, хранения и выдачи необходимой информации потребителям, а также для выполнения функции управления. Она состоит из следующих основных компонент: - программное обеспечение (ПО), - информационное обеспечение, - технические средства, - обслуживающий персонал.
Информационная система также может являться компонентой (или подсистемой) более сложной информационной системы [Когаловский, 2003]. Например, информационная система развития и управления персоналом и информационная система бухгалтерского учета являются компонентами информационной системы предприятия.
Операционный риск (далее риск): по соглашению «Базель II» [Базель II, 2004], представляет собой риск убытка в результате неадекватных или ошибочных внутренних процессов, действий сотрудников и систем или внешних событий.
Основные данные: это условно-постоянная часть всей корпоративной информации, не претерпевающая существенных изменений в процессе повседневной деятельности организации, в отличие от текущей информации, которая формируется непосредственно в процессе деятельности организации. Ошибки памяти: ошибки, связанные с некорректным обращением к оперативной памяти.
Ошибки ПО: Под ошибкой ПО или программной ошибкой [IEEE Standard, 1983] понимается недостижение или отличие от запрограммированного результата, ради которого была создана программа. Ошибки ПО включают в себя дефекты в ходе исполнения программы и определения данных, неправильный результат исполнения программы.
Подсистема ввода-вывода: (или пользовательский интерфейс) различные технологии пользовательского интерфейса для работы с системой («Тонкий» клиент на базе Web-технологий, и «Толстый» клиент в виде специализированных клиентских приложений).
Прикладное программное обеспечение (функциональные или прикладные ресурсы): набор программных приложений, «обеспечивающий решение некоторого комплекса задач в интересах какой-либо сферы деятельности» [Когаловский, 2003]. Прикладное программное обеспечение состоит из приложений, решающих логически завершенную прикладную задачу или автоматизирующих отдельные бизнес-процессы. Прикладное ПО [Когаловский, 2003] используется для решения конкретного класса задач и обычно представляет собой коммерческие программные продукты: СУБД общего назначения, Web-серверы, системы управления документами, информационные системы, имеющие узкое назначение (используемые для поддержки конкретных процессов предприятия).
Похожие диссертации на Риски и выбор оптимальных проектов: сервис-ориентированная архитектура информационных систем
