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

Зайцева Т.В.

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

09.04.03 Прикладная информатика

Информатика

Дипломы

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5c1a879d7966e104f6f85ca2

UUID: 1e592f70-e5e6-0136-06ea-525400005860

Язык: Русский

Опубликовано: больше 5 лет назад

Просмотры: 2222

Зайцева Т.В.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 3,2 МБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У « Б е л Г У» ) ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ АНАЛИЗ И ОБОСНОВАНИЕ ВЫБОРА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ АВТОМАТИЗИРОВАННОЙ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Выпускная квалификационная работа обучающейся по направлению подготовки 09.04.03 Прикладная информатика очной формы обучения, группы 07001633 Зайцевой Татьяны Валентиновны Научный руководитель к.т.н., доцент Ломакин В.В. Рецензент к.т.н., доцент, доцент кафедры информационно-телекоммуникационных систем и технологий Балабанова Т.Н. БЕЛГОРОД 2018

СОДЕРЖАНИЕ ВВЕДЕНИЕ............................................................................................................................................. 4 1 Анализ процессов проектирования программных средств......................................................11 1.1 ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ.......................11 1.2 РОССИЙСКИЕ И МЕЖДУНАРОДНЫЕ СТАНДАРТЫ В ОБЛАСТИ ИНЖЕНЕРИИ ПРОГРАММНЫХ СРЕДСТВ............................................................................... 14 1.3 МЕТОДОЛОГИИ АНАЛИЗА И ПРОЕКТИРОВАНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ..................................................................................................18 1.4 АНАЛИЗ ПРИМЕНИМОСТИ МЕТОДОВ ПРОЕКТИРОВАНИЯ НА РАЗЛИЧНЫХ ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ...........................................24 1.5 ОБЩАЯ ХАРАКТЕРИСТИКА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ .......................25 2 Инструментальные средства автоматизированной разработки прикладного программного обеспечения корпоративных информационных систем ...................................31 2.1 ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОГО УРОВНЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ..............................................................................................................................................31 2.1.1 Общие данные об объекте исследований...................................................................31 2.1.2 Определение технического уровня и тенденций развития инструментальных средств.....................................................................................................................................................35 2.1.3 Исследование использования объектов промышленной (интеллектуальной) собственности в области инструментальных средств........................................................................37 2.1.4 Анализ деятельности в области инструментальных средств...................................42 2.2 ФОРМУЛИРОВАНИЕ ТРЕБОВАНИЙ К РАЗРАБАТЫВАЕМОЙ ПЛАТФОРМЕ....43 2.3 СТРУКТУРА ПЛАТФОРМЫ...............................................................................................47 2.3.1 Компонент разработки схемы данных основных данных и моделей бизнеспроцессов................................................................................................................................................48 2.3.2 Компонент управления интеграционным взаимодействием....................................53 2.3.3 Компонент формирования централизованной нормативно-справочной информации............................................................................................................................................56 2.3.4 Компонент формирования хранилища ретроспективных (многолетних) данных и документов..............................................................................................................................................59 2.3.5 Компонент создания форм отчетов и форм представлений многомерных данных ..................................................................................................................................................................62 2.3.6 Компонент создания форм отчетов и форм представлений многомерных данных ..................................................................................................................................................................64

3 Методики оценки программных средств для анализа и проектирования корпоративных информационных систем ...................................................................................................................68 3.1 МЕТОДИКА ОЦЕНКИ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ............................68 3.2 РАЗРАБОТКА МЕТРИК КАЧЕСТВА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ............71 3.2.1 Метрика качества на основе ГОСТ Р ИСО/МЭК 9126-93........................................72 3.2.2 Метрика качества на основе комплексного подхода.................................................74 3.3 ПРИМЕНЕНИЕ МЕТОДА АНАЛИЗА ИЕРАРХИЙ ПРИ АНАЛИЗЕ И ВЫБОРЕ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ........................................................... 80 3.3.1 Выбор критериев сравнения КИС.............................................................................. 80 3.3.2 Выбор КИС российского производства......................................................................84 3.3.3 Выбор зарубежных КИС .............................................................................................86 3.4 УЧЕТ ВЗАИМОВЛИЯНИЯ КРИТЕРИЕВ ПРИ АНАЛИЗЕ И ВЫБОРЕ КИС.........87 Заключение..........................................................................................................................................100 Список библиографических источников.......................................................................................102 ПРИЛОЖЕНИЯ..................................................................................................................................110

ВВЕДЕНИЕ ВКР выполнялась в рамках работы по проекту по теме: «Разработка методологии и инструментальных средств создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений для эффективного осуществления административно- управленческих процессов в рамках установленных полномочий», шифр «2017218-09-187».на основании между Федеральным учреждением Договора № _17/17_ от _31.01.17_, заключённого государственным высшего образования автономным образовательным «Белгородский государственный национальный исследовательский университет» и Обществом с ограниченной ответственностью «Бюджетные и Финансовые технологии» на выполнение НИОКТР. Разработка производится с целью импортозамещения наукоемких вычислительных продуктов и ликвидации двадцатилетнего отставания России в создании комплексов подобного класса. Объектом исследования являются группы технических и специальных процессов жизненного цикла программных средств. Предметом исследования являются методы и средства проектирования программных средств. Целью работы является разработка методики обоснования выбора инструментальных средств автоматизированной разработки прикладного программного обеспечения корпоративных информационных систем. Основные задачи исследования: 1. Проанализировать процессы жизненного цикла программных средств и провести обзор российских и международных стандартов в области инженерии программных средств.

2. Проанализировать возможность применения методов проектирования для групп технических и специальных процессов жизненного цикла программных средств. 3. Определить технический уровень и тенденции развития объектов хозяйственной деятельности в области развития инструментальных средств, обеспечивающих автоматизированную разработку прикладного программного обеспечения корпоративных информационных систем. 4. Сформулировать требования к разрабатываемой Платформе. 5. Обосновать методику выбора инструментальных средств разработки прикладного программного обеспечения корпоративных информационных систем. 6. Провести апробацию предлагаемых решений. Методы исследования: системный анализ, структурные методы моделирования систем (функциональные, потоков данных, бизнес-процессов, событийные, информационные, иерархические), статические и динамические объектные методы моделирования, методы оценки качества программных средств, методы экспертных оценок. Научная новизна исследования: 1. Проведена классификация методов (моделей, нотаций) проектирования программных средств. 2. Разработаны матрицы использования методов и средств проектирования для групп технических и специальных процессов жизненного цикла программных средств. 3. Разработаны обобщенные алгоритмы работы компонентов Платформы. 4. Разработаны метрики качества инструментальных средств. 5. Применен метод анализа иерархий для выбора КИС согласно заявленным требованиям. Практическая ценность работы: 1. Проведён анализ методологий проектирования программных средств.

2. Проведен патентный поиск. 3. Проведён обзор современных КИС, представленных на российском и зарубежном рынке. Положения, выносимые на защиту: 1. Результаты патентного поиска. 2. Компоненты Платформы 3. Метрики качества инструментальных средств. 4. Применение методов анализа иерархий при выборе программных средств. Апробация работы: Научные доклады на конференциях: 1) Зайцева, Т.В. Выявление взаимовлияния критериев отбора КИС с использованием семантического подхода / Зайцева Т.В., Путивцева Н.П., Ломакин В.В., Пусная О.П. // НАУЧНЫЕ ДОСТИЖЕНИЯ – 2017: Избранные материалы XV Международной научно-практической (очно-заочной) конференции студентов, аспирантов и молодых ученых «Научное творчество XXI века» (14–15 ноября 2017 г., Красноярск, Российская Федерация) и X Международной итоговой научнопрактической (очно-заочной) конференции молодых ученых и специалистов «Современная российская наука глазами молодых исследователей» (23–24 декабря 2017 г., Красноярск, Российская Федерация). – Красноярск: Научно- инновационный центр,2017. – С. 34-46. 2) Путивцева, Н.П. Процедура многокритериального выбора ERP системы как составляющая часть электронного бизнеса вуза / Н.П. Путивцева, Т.В. Зайцева // Естественнонаучные, инженерные и экономические исследования в технике, промышленности, медицине и сельском хозяйстве: материалы I Молодѐжной научно-практической конференции с международным участием; под общ. ред. С.Н. Девицыной. – Белгород: ИД «Белгород» НИУ «БелГУ», 2017. Научные публикации:

1) Lomakin, V.V. Multi-criteria selection of a corporate system by using paired comparison analysis / V.V. Lomakin, N.P. Putivtseva, T.V. Zaitseva, M.V. Liferenko, I.M. Zaitsev // Journal of Fundamental and Applied Sciences. – 2017. – 9(7S). – Р. 1472-1482. 2) Зайцев, И.М. Многокритериальный выбор корпоративной системы с применением инструментальных средств повышения степени согласованности матриц парных сравнений / И.М. Зайцев, Т.В. Зайцева, М.В. Лифиренко, В.В. Ломакин, Н.П. Путивцева // Информационные системы и технологии. – 2017. - № 6(104). – С. 85-93. 3) Путивцева, Н.П. Решение задачи выбора российских корпоративных информационных систем с использованием метода анализа иерархий / Н.П. Путивцева, Т.В. Зайцева, В.В. Ломакин, О.П. Пусная, О.С. Резниченко // Вестник ВГУ САИТ. – 2017. - № 4. – С. 85-91. 4) Ломакин, В.В. Формально-алгоритмическое представление специализированного языка управления данными / В.В. Ломакин, Р.Г. Асадуллаев, Т.В. Зайцева, Н.П. Путивцева, Ю.Ю. Белоконь // Вестник БГТУ им. В.Г. Шухова. – 2017. - № 12. – С. 173-179. 5) Асадуллаев, Р.Г. Модели и средства поддержки принятия решений в системах переподготовки кадров предприятия / Р.Г. Асадуллаев, В.В. Ломакин, Ю.Ю. Белоконь, Т.В. Зайцева, О.С. Резниченко // Научные ведомости БелГУ. Серия Экономика. Информатика. – 2017. - № 23(272). – С. 148-158. 6) Путивцева, Н.П. Разработка программной поддержки иерархической многокритериальной процедуры оценки качества экспертов. / Н.П. Путивцева, Т.В.Зайцева, О.П. Пусная, С.В. Игрунова, Е.В. Нестерова, Е.В. Калюжная, Е.А. Зайцева // Научные ведомости БелГУ Серия История. Политология. Экономика. Информатика. – Белгород: Изд-во БелГУ. – 2016. – №16(237). – Выпуск 39. – С. 172-179.

7) Путивцева, Н.П. Сравнительный анализ применения многокритериальных методов / Н.П. Путивцева, О.П. Пусная, С.В. Игрунова, Т.В. Зайцева, Е.В. Нестерова // Научный результат. Информационные технологии. – 2017. – Т.2. – №1. – С. 40-47. Пояснительная записка состоит из введения, трех разделов, заключения, списка используемых источников и приложений. В первом разделе проведен анализ процессов жизненного цикла программных средств согласно стандарту ГОСТ Р ИСО/МЭК 12207:2010; подробно рассмотрены группы технических и специальных процессов жизненного цикла ПС. Дано определение программной инженерии; проведен обзор основополагающих международных и национальных стандартов в области инженерии программных средств – описаны цели применения и основные задачи, которые стандарты помогут разрешить. Проведена группировка стандартов на стандарты, регламентирующие процессы жизненного цикла программных средств и систем, и стандарты, регламентирующие качество программных средств. Даны определения основным понятиям (методология, метод, система). Проанализированы основные методологии проектирования КИС, определены их особенности и компоненты. Проведена классификация методологий анализа и проектирования КИС на структурные методологии (SA/SD; IDEF; ARIS; ORACLE; BAAN) и объектные методологии (OSA; OMT; UML). Проведена классификация основных методов на группы структурных и объектных методов. Структурные методы можно разделить на функциональные, потоков данных, бизнес-процессов, событийные, информационные и иерархические; объектные методы включают в себя статические и динамические модели. По выделенным группам методов даны характеристики и представлены примеры видов моделей. Проведен анализ применимости групп методов

проектирования на этапах технических и специальных процессов жизненного цикла программных средств. Приведена общая характеристика инструментальных средств. Во втором разделе приведены результаты исследования по источникам патентной информации технического уровня и тенденций развития инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС, и предоставляющих среду функционирования КИС, включая типовые алгоритмы моделирования распределенного характера; бизнес-процессов создания корпоративных приложений конфигурации прикладных типовых модулей; бизнес-абстракции и генерации метаданных конфигураций объектов бизнес-приложений. Так же приведены результаты исследования использования объектов промышленной (интеллектуальной) собственности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и их правовая охрана и анализ деятельности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и перспектив ее развития. В разделе представлены требования на выполнение работ по теме: «Разработка методологии и инструментальных средств создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений административно-управленческих полномочий». для процессов эффективного в осуществления рамках установленных Также в разделе представлено описание шести компонент Платформы, для которых разработаны блок-схемы укрупненного алгоритма работы. В третьей главе проведен обзор методики оценки качества ПС, рассмотрены шесть этапов процедуры оценки: выбор и декомпозиция характеристик, по которым производится оценка качества ПС; определение

весовых коэффициентов для каждой характеристики; оценка согласованности экспертов; определение перечня средств в соответствии с требованиями заказчика и проведение их оценки; расчет комплексных характеристик качества оцениваемых ПС; анализ полученных результатов. Разработана метрика качества для оценки инструментальных средств, даны определения характеристик для оценки качества программных средств согласно ГОСТ Р ИСО/МЭК 9126-93, проведена их декомпозиция и определены весовые коэффициенты. Разработана метрика качества для оценки инструментальных средств, даны определения характеристик для оценки качества программных средств на основе комплексного подхода, проведена их декомпозиция и определены весовые коэффициенты. На основе полученных метрик проведена интегральная оценка качества инструментальных средств для моделирования бизнес-процессов управления организацией. Пояснительная записка написана на 156 страницах, содержит 37 рисунка, 14 таблиц, 9 приложений.

1 Анализ процессов проектирования программных средств 1.1 Процессы жизненного цикла программных средств Программные разрабатываемых средства сегодня информационных занимают технологий, большую а также нишу они среди являются неотъемлемой частью традиционных систем, например, транспортные, военные, здравоохранения и финансовые [43]. При этом имеется в виду, что роль стандартов, процедур, методов, средств и внешних условий для разработки и сопровождения программных средств должна быть более значимой. Подобная многоплановость подходов создает значительные трудности при управлении программными средствами и в технологиях программирования, особенно при интеграции продуктов и услуг. Требуется определённое упорядочение вопросов создания программных средств при переходе от многоплановости к общей структуре, которая может быть использована профессионалами для взаимопонимания при создании и управлении программными средствами. Одним из базовых понятий методологии проектирования программных средств (ПС) является понятие жизненного цикла. Жизненный цикл – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент его полного изъятия из эксплуатации. Стандарт ГОСТ Р ИСО/МЭК 12207:2010 «Процессы жизненного цикла программных средств» [23], использует устоявшуюся терминологию и на ее основе определяет общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Процессы, виды деятельности и задачи, которые используются при приобретении

программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов – все это определяет данный стандарт. При этом следует помнить, что понятие «программное средство» в обязательном порядке включает в себя встроенный фирменный программный компонент. Будем трактовать программное средство как единую часть общей системы, которая выполняет определённые функции в ней, что осуществляется посредством выделения требований к программным средствам из требований к системе, проектирования, производства программных средств и объединения их в систему. Процессы жизненного цикла делятся на 2 большие группы: процессы в контексте системы и специальные процессы программных средств (рис. 1.1). Процессы в контексте системы включают в себя: ˗ процессы соглашения: данные процессы очень важны, поскольку именно здесь определяются те действия, которые необходимы для выработки соглашений между двумя организациями. Процессы соглашения включают в себя процесс приобретения и процесс поставки. ˗ процессы организационного обеспечения: с помощью процессов данной группы осуществляется менеджмент возможностей организаций приобретать и поставлять продукты через инициализацию, поддержку и управление проектами. Все ресурсы и инфраструктуру, которые необходимы для поддержки проектов обеспечивают данные процессы, также они гарантируют удовлетворение организационных целей и установленных соглашений. ˗ процессы проекта: среди данных процессов рассматривают две категории – процессы менеджмента проекта и процессы поддержки проекта. Первые используют для планирования, выполнения, оценки и управления продвижением проекта, а вторые – для выполнения специализированных целей менеджмента.

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

копирования продукта (в случае необходимости), применение продукта, обеспечение требуемых услуг, поддержание обеспечения этих услуг и изъятие продукта из обращения в том случае, если он не используется при оказании услуги определенное время. Группа специальных процессов программных средств включает в себя следующие процессы. ˗ процессы реализации программных средств: данные процессы используют когда непосредственно создают конкретный элемент / элементы системы (составной части), выполненный в виде программного средства. Эти процессы преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований. ˗ процессы поддержки программных средств: предусматривают специально сфокусированную совокупность действий, направленных на выполнение специализированного программного процесса. ˗ процессы повторного применения программных средств: поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Эти процессы уникальны, поскольку, в соответствии с их природой, они используются вне границ какого-либо конкретного проекта. 1.2 Российские и международные стандарты в области инженерии программных средств По мнению ряда специалистов, программная инженерия должна

содержать аспекты программной разработки, управления программным обеспечением, организации и использования проектов [14]. Другие включают в её состав вопросы разработки программного обеспечения, проектирования, кодирования и тестирования вместе с использованием наилучших практических решений [44]. Будем придерживаться мнения, что программная инженерия включает совокупность современных методов проектирования и реализации ИС. Разработка информационных систем в последние годы является распространённой и важной задачей. Очевидно, что программные инженеры должны быть способными разрабатывать ПС с помощью наилучших практических решений с долговременной перспективой. Наиболее адекватной представляется разработка архитектуры сложных прикладных информационных систем на основе эффективного объединения разных видов оборудования и программного обеспечения, применения стандартизованных интерфейсов между компонентами системы и т.п. Дальнейшее рассмотрение будет посвящено нескольким основополагающим стандартам в области инженерии программных средств, охватывающим процессы жизненного цикла программных средств и систем и качество ПС (рис. 1.2, приложение А): ˗ ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12270 (Процессы жизненного цикла программных средств)» [27]. ˗ ГОСТ Р ИСО/МЭК ТО 12182-2010 «Классификация программных средств» [26]. ˗ ISO/IEC 14764:2006 «Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение» [29]. ˗ ISO/IEC 16085:2006 «Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками» [30]. ˗ ISO/IEC/IEEE 16326:2009 «Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление проектом» [7].

Рисунок 1.2 – Стандарты в области инженерии программных средств ˗ ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения» [16]. ˗ ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [19]. ˗ ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» [20]. ˗ ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию» [21]. ˗ ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» [24]. ˗ ГОСТ Р ИСО/МЭК 9126-93 «Характеристики качества и руководства по

их применению» [25]. ˗ ГОСТ Р ИСО/МЭК 12119-2000 «Информационная технология. Пакеты программ. Требования к качеству и тестирование» [22]. ˗ ГОСТ 28195-89 «Оценка качества программных средств. Общие положения» [15]. ˗ ГОСТ 34.320-96 «Информационные технологии. Концепции и терминология для концептуальной схемы и информационной базы» [17]. ˗ ГОСТ 34.321-96 «Информационные технологии. Эталонная модель управления данными» [18]. ˗ ISO/IEC 14598-6:2001 «Информационные технологии. Оценка программного продукта. Часть 6. Документирование модулей оценки» [28]. ˗ ISO/IEC 25000:2005 «Технология программного обеспечения. Требования и оценка качества программного продукта. Руководство» [31]. ˗ ISO/IEC 25001:2014 «Программирование. Требования к качеству программного продукта и его оценка. Планирование и менеджмент» [32]. ˗ ISO/IEC 25010:2011 «Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения» [33]. ˗ ISO/IEC 25012:2008 «Программная инженерия – Требования к качеству и оценке программного обеспечения. Модель качества данных» [34]. ˗ ISO/IEC 25020:2007 «Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Измерительная эталонная модель и руководство» [35]. ˗ ISO/IEC 25021:2012 «Разработка систем и программ. Требования к качеству систем и программ и их оценка. Элементы показателей качества» [36]. ˗ ISO/IEC 25030:2007 «Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Требования к качеству» [37]. ˗ ISO/IEC 25040:2011 «Проектирование систем и разработка программного

обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Процесс оценки» [38]. ˗ ISO/IEC 25041:2012 «Разработка систем и программ. Требования и оценивание качества систем и программ. Руководство по оцениванию для разработчиков, покупателей и независимых оценщиков» [39]. ˗ ISO/IEC 25045:2012 «Разработка систем и программного обеспечения. Требования к качеству и оценка качества систем и программного обеспечения. Модуль оценки восстанавливаемости» [40]. 1.3 Методологии анализа и проектирования корпоративных информационных систем Методология (от метод и …логия) – учение структуре, логической организации, методах и средствах деятельности. Система (от греч. systema – целое, составленное из частей; соединение) – множество элементов, находящихся в отношениях и связях друг с другом, образующих определенную целостность, единство [3]. Методология Структурный SA/SD (Structured анализ/Структурное Analysis/Structured проектирование) содержит Design – несколько вариантов систем обозначений для формальной спецификации программных систем [47]. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, функциональные диаграммы SADT, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

Диаграмма SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) разработана специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Целью модели является получение ответов на некоторую совокупность вопросов. Методология IDEF (ICAM Definition – Комплексная автоматизация производственных процессов) семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах [45]. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. Методология ARIS (Architecture of Integrated Information Systems – Архитектура интегрированных информационных систем) – методология для моделирования бизнес-процессов организаций [46]. Методология ARIS на данный момент времени является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей методологии ARIS используются в настроечном модуле интегрированной информационной системы SAP/R3, который применяется при внедрении системе и ее настройке на деятельности компании. В виду большого количества бизнес-моделей методология ARIS делит их на четыре группы: "Оргструктура", "Функции", "Информация" и "Процессы". Также инструментарий поставляется с набором референтных моделей, заранее разработанных для типичных процессов в различных отраслях. Общий принцип методологии – возможность интеграции моделей разных типов в рамках

одного репозитория посредством декомпозиции (детализации) объектов. Таким образом, любую организацию можно описать с помощью иерархии моделей. Методология ORACLE используется для поддержки всего жизненного цикла информационных технологий на предприятии, включая поддержку внедрения продуктов и технологий Oracle [49]. Данная методология универсальна и явно не привязана к конкретным продуктам и технологиям, что даёт возможность её адаптации под другие типы ИТ-проектов. Она включает набор готовых шаблонов, руководство и структуру работ, а так же содержит программные инструменты для управления рисками, связанными с проектами. Методология ORACLE состоит из трёх областей: ˗ Управление (Manage) – управления программами (Program Management Method, PGM) и проектами (Project Management Method, PJM); ˗ Представление (Envision) – поддержка ИТ-архитектуры на уровне предприятия, её стратегия развития и управления, а так же выявление и создание специфических проектов; ˗ Реализация (Implement) – реализация проектов. Каждый проект, согласно методологии, состоит из 5 фаз: ˗ Начальная фаза (Inception); ˗ Проектирование системы (Elaboration); ˗ Разработка системы (Construction); ˗ Переход к эксплуатации системы (Transition); ˗ Эксплуатация системы (Production). Каждая фаза может содержать до 15 процессов, таких как управление проектом, бизнес-требования, анализ требований, анализ, проектирование, разработка, тестирование, архитектура, конвертация контроль и перенос производительности, данных, документация, техническая управление изменениями, обучение, переход к эксплуатации, эксплуатация и поддержка.

Методология BAAN – методология описания деятельности, разработанная компанией разработчиком информационных систем BAAN, содержит бизнесмодели, с помощью которых последовательно описываются функции, бизнеспроцессы, организационная и информационная структура предприятия [54]. Методология OSA (Object-Oriented System Analysis – Объектноориентированный системный анализ) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки [43]. Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы. Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления проектируемой системы: ˗ модель зависимостей между объектами; ˗ модель поведения объектов; ˗ модель взаимодействия объектов. Методология OMT (Object Modeling Technique – Технология объектного моделирования) поддерживает две первые стадии разработки программных систем [43]. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы.

Методология UML (Unified Modelling Language – Унифицированный язык моделирования) – результат довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна [43]. Данная методология преследует три основные цели: ˗ моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик; ˗ разрешение проблем масштабирования в сложных системах; ˗ создание языка моделирования, используемого и человеком, и компьютером. В настоящее время методология UML поддерживает более 10 основных видов моделей для описания бизнес-процессов предприятия (приложение Б). Основные существующие в настоящее время методологии моделирования, используемые на этапах анализа, разработки и внедрения систем управления представлены на рис. 1.3. Их можно разделить на две большие группы: структурные и объектно-ориентированные [11]. Рисунок 1.3 – Виды методологий

Структурные методологии базируются на декомпозиции (разбиении) объекта на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на функции, подразделяемые на задачи и так далее [1; 14]. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. Наиболее известными структурными проектирование методологиями (SA/SD), являются: комплексная структурный анализ/структурное автоматизация производственных процессов (IDEF), архитектура интегрированных информационных систем (ARIS), методологии фирм-разработчиков (ORACLE, BAAN и др.). Объектно-ориентированные методологии основаны на представлении системы в виде совокупности объектов, каждый из которых является реализацией определенного типа, использует механизмы пересылки сообщений и классы, организованные в иерархию наследования [4]. Наиболее известными объектными методологиями являются: объектно-ориентированный системный анализ (OSA), технология объектного моделирования (OMT), унифицированный язык моделирования (UML). Каждая из методологий включает в себя набор методов графического моделирования аспектов предметной области (видов моделей, диаграмм, нотаций). Проведем классификацию основных методов моделирования, используемых при анализе, проектировании и реализации КИС (рис.1.4, приложение В).

Рисунок 1.4 – Классификация методов анализа, проектирования и реализации КИС 1.4 Анализ применимости методов проектирования на различных этапах жизненного цикла программных средств На основании анализа стандарта ГОСТ Р ИСО/МЭК 12207:2010 «Процессы жизненного цикла программных средств» выделены технические и специальные процессы жизненного цикла программных средств. Эти процессы являются основой для анализа, проектирования и реализации корпоративных информационных систем, потому что они используются для определения

требований к системе, преобразования требований в полезный продукт, для разрешения постоянного копирования продукта (где это необходимо), применения продукта, обеспечения требуемых услуг, поддержания обеспечения этих услуг и изъятия продукта из обращения, если он не используется при оказании услуги, преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований, поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Для анализа применимости методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств методы (модели) были сгруппированы на структурные (функциональные, потоков данных, бизнес-процессов, информационные, иерархические, событийные) и объектные (статические и динамические). Результаты анализа приведены в таблице 1.1. 1.5 Общая характеристика инструментальных средств Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле [43]. С самого начала значение термина CASE ограничивалось только лишь вопросами автоматизации разработки программных средств (программного обеспечения), но в настоящее время значение приобрело новый смысл, который охватывает процесс разработки любых сложных (в том числе и корпоративных информационных) систем в целом. Первоначально CASE-технологии развивали для того, чтобы преодолеть ограничения при использовании структурной методологии проектирования (сложность понимания, высокая трудоёмкость и стоимость использования,

трудность внесения изменений в проектные спецификации и т.д.) за счёт её автоматизации и интеграции поддерживающих средств. То есть данные инструментальные средства нельзя считать полностью самостоятельными, они всего лишь высокую эффективность их применения обеспечивают (это обязательное минимальное условие), а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Таблица 1.1 - Результаты анализа применимости групп методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Деятельностей + + Взаимодействия + + Последовательности + + использованияВариантов + Развертывания + Компонентов + Объектов Иерархические + Событийные Информационные + Классов Квалификационное тестирование системы Инсталляция программных средств Поддержка приемки программных средств Функционирование программных средств Сопровождение программных + средств Бизнес-процессов Комплексирование системы Потоков данных Функциональные Определение требований + правообладателя Анализ системных требований + Проектирование архитектуры + системы Реализация Состояний Объектные Статические Динамические Структурные + + + + + + + + + + + + + + + + + + + + + + В настоящее время большую часть существующих инструментальных

средств ориентируют на автоматизацию проектирования программного обеспечения, при этом они базируются на методологиях структурного (в большинстве случаев) или объектно-ориентированного проектирования и программирования, которые используют спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств [6]. В рамках программной инженерии подобные средства представляют собой основную технологию, используемую для создания и эксплуатации систем ПО. Под CASE-средством (в соответствии с международным стандартом ISO/IEC 14102:2008(Е)) понимается программное средство, поддерживающее процессы жизненного цикла ПС (определенные в стандарте ISO/IEC 12207:2010), включая анализ требований к системе, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПС и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО ИС. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПС. Среди всех стадий разработки ПС можно выделить наиболее трудоемкие это стадии формирования требований и проектирования, в процессе которых инструментальные средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом следует учитывать большую роль, которую методы визуального представления информации играют в процессе разработки. Это предполагает построение разнообразных графических моделей (диаграмм), использование многообразной цветовой палитры, сквозную

проверку синтаксических правил. Интегрированное CASE-средство содержит следующие компоненты: ˗ репозиторий, обеспечивать хранение являющийся версий основой проекта и CASE-средства. Он его компонентов, отдельных должен синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; ˗ графические средства анализа и проектирования, обеспечивающие создание и редактирование комплекса взаимосвязанных диаграмм, образующих модели деятельности организации и системы ПО; ˗ средства разработки приложений, включая языки 4GL (Fourth Generation Language – язык 4-го поколения) и генераторы кодов; ˗ средства управления требованиями; ˗ средства управления конфигурацией ПО; ˗ средства документирования; ˗ средства тестирования; ˗ средства управления проектом; ˗ средства реверсного инжиниринга ПО и баз данных. Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес процессов, являются следующие: ˗ Наличие графического интерфейса. Для представления моделей процессов CASE-средства должны обладать возможностью отображать процессы в виде схем. Схемы много проще в использовании, чем различные текстовые и числовые описания. Это позволяет получать легко управляемые компоненты модели, обладающие простой и ясной структурой. ˗ Наличие репозитория. Каждый объект репозитория должен обладать перечнем свойств, характерных только для этого объекта. ˗ Гибкость применения. Эта характеристика дает возможность представлять бизнес-процессы в различных вариантах, важных с точки зрения

анализа. CASE-средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия. ˗ Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек. Для одновременной работы над моделями процессов CASE-средства должны обеспечивать управление изменениями любыми фрагментами моделей и их модификацией при коллективном доступе. ˗ Построение прототипов. Прототипы процессов необходимы для того, чтобы на ранних стадиях изменения процессов можно было понять, насколько процесс будет соответствовать требованиям. Построение отчётов. CASE-средства должны обеспечивать построение отчётов по всем моделям процессов с учётом взаимосвязи элементов. Такие отчёты необходимы для анализа моделей и определения возможностей по оптимизации. За счет отчётов обеспечивается контроль полноты и достаточности моделей, уровень декомпозиции процессов, правильность синтаксиса диаграмм и типов применяемых элементов. Выводы по 1 разделу. В первом разделе проведен анализ процессов жизненного цикла программных средств согласно стандарту ГОСТ Р ИСО/МЭК 12207:2010; подробно рассмотрены группы технических и специальных процессов жизненного цикла ПС. Дано определение программной инженерии; проведен обзор основополагающих международных и национальных стандартов в области инженерии программных средств – описаны цели применения и основные задачи,

которые стандарты помогут разрешить. Проведена группировка стандартов на стандарты, регламентирующие процессы жизненного цикла программных средств и систем, и стандарты, регламентирующие качество программных средств. Даны определения основным понятиям (методология, метод, система). Проанализированы основные методологии проектирования КИС, определены их особенности и компоненты. Проведена классификация методологий анализа и проектирования КИС на структурные методологии (SA/SD; IDEF; ARIS; ORACLE; BAAN) и объектные методологии (OSA; OMT; UML). Проведена классификация основных методов на группы структурных и объектных методов. Структурные методы можно разделить на функциональные, потоков данных, бизнес-процессов, событийные, информационные и иерархические; объектные методы включают в себя статические и динамические модели. По выделенным группам методов даны характеристики и представлены примеры видов моделей. Проведен анализ применимости групп методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств. В разделе дано определение CASE-средства как среды разработки ПО ИС; проведен обзор стадий разработки программных средств, в процессе которых инструментальные средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. особенности и компоненты инструментальных средств. Рассмотрены основные

2 Инструментальные средства автоматизированной разработки прикладного программного обеспечения корпоративных информационных систем 2.1 Определение технического уровня инструментальных средств 2.1.1 Общие данные об объекте исследований Патентный поиск выполнялся в соответствии с Планом-графиком по комплексному проекту по теме: «Разработка методологии и инструментальных средств создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений для эффективного осуществления административно-управленческих процессов в рамках установленных полномочий», шифр «2017-218-09-187».на основании Договора № _17/17_ государственным от _31.01.17_, автономным заключённого образовательным между Федеральным учреждением высшего образования «Белгородский государственный национальный исследовательский университет» и Обществом с ограниченной ответственностью «Бюджетные и Финансовые технологии» на выполнение НИОКТР и Заданием на проведение патентных исследований (Приложение Г). Объектом исследований являются инструментальные средства, обеспечивающие автоматизированную разработку прикладного программного обеспечения (далее – ППО) корпоративных информационных систем (далее КИС), и предоставляющих среду функционирования КИС

Назначение объекта исследований: Автоматизированная разработка ППО КИС и предоставление среды функционирования КИС Область применения: Инструментально-технологическая поддержка деятельности разработчиков ППО российских предприятиях промышленного сектора и в научно-исследовательских и проектных учреждениях. Патентные исследования проводились с 01 июля 2017 по 15 августа 2017 Задачами патентных исследований являются: 1. Определение технического уровня и тенденций развития инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС, и предоставляющих среду функционирования КИС, включая типовые алгоритмы: ˗ моделирования бизнес-процессов корпоративных приложений распределенного характера; ˗ создания типовых конфигурации прикладных модулей ˗ бизнес-абстракции и генерации метаданных конфигураций объектов бизнес-приложений; 2. Исследование (интеллектуальной) использования собственности в области объектов промышленной инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и их правовая охрана. 3. Анализ деятельности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и перспектив ее развития. В качестве предметов поиска были выбраны следующие компоненты ИК ИСКУ, относящиеся к техническим решениям типа «способ», или комплексы, включающие в себя набор указанных компонентов: – Компонент разработки схемы данных основных данных и моделей бизнес-процессов, предназначенный для визуального конструирования объектов

предприятия ППО КИС в составе: схем данных, схем базы данных, экранных форм, моделей исполняемых бизнес-процессов, и для интерпретации метаданных сконструированных объектов при функционировании КИС; – Компонент управления интеграционным взаимодействием, предназначенный для настройки и реализации информационного взаимодействия разрабатываемой КИС с внешними информационными системами; – Компонент формирования централизованной нормативно-справочной информации (далее – НСИ), предназначенный для декларативной разработки функциональности централизованного ведения НСИ в разрабатываемой КИС, и предоставления НСИ во внешние информационные системы; – Компонент формирования хранилища ретроспективных (многолетних) данных и документов, предназначенный для организации доступного в режиме реального времени архива электронных документов и ретроспективной информации; – Компонент создания форм отчетов и форм представлений многомерных данных, предназначенный для разработки функциональности формирования отчетности и аналитической обработки и визуализации многомерных данных и предоставляющий среду их функционирования; – Компонент общесистемного администрирования, предназначенный для выполнения настроек, применимых к Платформе и КИС в целом. Анализ международной патентной классификации (МПК) последней редакции показывает, что выбранные в качестве предметов поиска компоненты (и комплексы, включающие компоненты) не имеют самостоятельного индекса. Наиболее близкими индексами, указываемыми в технических решениях типа «способ», являются следующие подклассы и группы. G06F устройств – Обработка цифровых данных с помощью электрических

G06N – Компьютерные системы, основанные на специфических вычислительных моделях. G06Q – Системы предназначенные для обработки данных административных, или способы, коммерческих, специально финансовых, управленческих, надзорных или прогностических целей; системы или способы, специально предназначенные для административных, коммерческих, финансовых, управленческих, надзорных или прогностических целей, не предусмотренные в других подклассах. В связи с тем, что детализация выбранной области поиска практически отсутствует, ширина поиска была сужена за счёт использования соответственных ключевых слов. Ретроспектива в соответствии с задачами патентных исследований – 15 лет (по данным международной исследовательской и консалтинговой компании IDC, занимающаяся изучением мирового рынка информационных технологий и телекоммуникаций - усредненный срок обновления технологий в сфере информационных технологий и телекоммуникаций составляет 15 лет). Для определения уровня и тенденций развития инструментальных средств, с целью реализации программы импортозамещения и повышения международной конкурентоспособности отечественной программной продукции в сфере разработки сложных и высоконагруженных бизнес-приложений, а так же в соответствии с требованиями пункта 8.2 Технического задания на выполнение научно - исследовательских, опытно-конструкторских и технологических работ по теме: «Разработка методологии и инструментальных средств создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений административно-управленческих полномочий» необходимо для процессов провести эффективного в патентные рамках осуществления установленных исследования для стран: Российская Федерация, Казахстан, Белоруссия, США, Канада, страны Евросоюза,

Япония, Китай, страны Ближнего Востока и Африки, страны Азии и Латинской Америки. Патентный поиск был проведён на основании Задания № 1 от 01.06.2017 в соответствии с Регламентом поиска № 1 от 01.06.2017 . Отчёт о патентном поиске № 1 (Приложение Д) содержит 103 регистрационных свидетельства программы для ЭВМ. 2.1.2 Определение технического уровня и тенденций развития инструментальных средств Патентный поиск, проведённый в этом исследовании, выявил 34 патентных документов, из них (приложение Е): – По компоненту разработки схемы данных основных данных и моделей бизнес-процессов шесть заявок. – По компоненту управления интеграционным взаимодействием две – По заявки. компоненту формирования централизованной нормативно- справочной информации три заявки. – По компоненту формирования хранилища ретроспективных (многолетних) данных и документов пять заявок. – По компоненту создания форм отчетов и форм представлений многомерных данных пять заявок. – По компоненту общесистемного администрирования двенадцать заявок На основании данных о датах публикации патентных документов, связанных с решениями в области инструментальных средств, обеспечивающих

автоматизированную разработку прикладного программного обеспечения КИС, и предоставляющих среду функционирования КИС построена кумулятивная кривая динамики патентования (рис. 2.1). Далее приведены результаты исследования технического уровня отобранных источников патентной информации, найдено 34 документа в области инструментальных средств, обеспечивающих автоматизированную разработку прикладного программного обеспечения корпоративных информационных систем, и предоставляющих среду функционирования КИС, что полностью соответствует Задания № 1 от 01.06.2017 на проведение патентных исследований. В ходе анализа и обобщения информации установлено, что при выборе направлений разработки компонентов создаваемой информационной системы следует учесть наличие действующих патентов на компоненты для соблюдения патентной чистоты разработки создаваемой информационной системы. 40 Количество патентов 35 30 25 20 15 10 5 0 2004 2006 2008 2010 2012 2014 2016 2018 Год публикации Куммулятивная кривая патентования Рисунок 2.1 – Кумулятивная кривая динамики патентования решений по годам публикации заявки

2.1.3 Исследование использования объектов промышленной (интеллектуальной) собственности в области инструментальных средств Исследование использования объектов промышленной (интеллектуальной) собственности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС выявил, что в основном данное программное обеспечение делится на две группы — свободного использования (бесплатная и открытая лицензия) и несвободного (коммерческая лицензия), а также между ними существуют условно-бесплатные программы, которые можно отнести к двум группам пополам, такое ПО можно скачать и использовать, но до оплаты могут возникнуть некоторые проблемы или ограничения (рис. 2.2). Рисунок 2.2 – Типы лицензий – К открытым относятся: Open Source программы с открытым кодом, которые можно модифицировать. – К бесплатным относятся: Freeware, GPL, Adware, Postcardware, Donationware, Nagware/Begware. – К условно-бесплатным относятся: ShareWare, TrialWare, Demoware. – К коммерческим относятся: Commercial главная цель таких программ получение прибыли, код программ закрыт.

Сравнительная характеристика условий самых распространенных лицензий приведена в виде таблицы (рис. 2.3). Все рассматриваемые лицензии одобрены Open Source Initiative для распространения ПО с открытым исходным текстом. Для защиты авторских прав разработчика имеются различные схемы лицензирования программного обеспечения. По каждому отдельному виду программного продукта применяются разные типы лицензирования (рис. 2.4). OEM. Предустановленное ПО является одним из самых дешевых вариантов. Он заключается в том, что пользователь приобретает ПО вместе с самим компьютером или сервером и использовать его можно только на купленном ПК. Full Package Product. «Коробочный» продукт применяется в основном для розничной торговли и удобен для частных лиц или малого бизнеса. Разрешение на использование программного продукта на одном компьютере дает покупка одной «коробки» и не важно, сколько людей будет пользоваться этим ПК. Так же можно сменить ПК, но определенное количество раз. Volume Licensing. Корпоративная лицензия удобна для компаний, у которых много сотрудников, компьютеров и поэтому нужно приобретать много лицензий. При этом компания получает одну именную лицензию на программное обеспечение, которая содержит информацию о заказчике (название, адрес и т.д.), перечень ПО и ключи для его установки. В основном при такой схеме лицензирования компаниям, заказывающим именную лицензию, разработчики или распространители ПО предоставляют значительные скидки, техническую поддержку, решения нестандартных ситуаций и т. п. На сегодня она является лучшей для покупки нового ПО или его обновления для компаний.

Рисунок 2.3 - Сравнительная характеристика условий самых распространенных лицензий (* Если нет письменного разрешения об использовании наименования продукта создателей лицензии; ** В данном случае речь идет об исходном тексте) Subscription. Подписка на лицензирование программного обеспечения предусматривает внесение ежемесячных или ежегодных платежей. Эта схема

удобна компаниям, которые покупают более 10 лицензий. Она позволяет пользователям за минимальные начальные затраты получить практически все основные преимущества использования данного продукта. Рисунок 2.4 – Типы лицензирования На рисунке 2.5 приведены различия типов лицензирования. Рисунок 2.5 – Различия типов лицензирования

Исходя из таблицы, можно сделать вывод о том, в каких случая лучше подходит каждый из типов лицензирования. OEM версия подойдет для тех, кто закупает новое оборудование. Если ПО будет уже предустановлено сборщиком, то оборудование обойдется намного дешевле, чем покупать самому и устанавливать на каждое устройство. Выгода, как по времени, так и по цене. FPP версия подойдет для тех, у кого уже куплено оборудование, но отсутствует на нем нужное ПО, особенно если компания маленькая и сотрудники будут пользоваться одним ПК по несколько человек. VL версия подойдет для больших компаний, которым нужна быстрая тех. поддержка и возможность решения нестандартных ситуаций. А также при покупке лицензии для всей компании всегда существуют очень хорошие скидки. SUB версия подойдет для тех, кто хочет использовать ПО кратковременно, или не знает, на сколько данное ПО ему пригодится. Если же продукт нужен на долгое использование, то лучше посмотреть версию из “коробки”. Исследование использования объектов промышленной (интеллектуальной) собственности в автоматизированную лицензирования области инструментальных разработку подобного рода ППО КИС программных средств, выявил обеспечивающих основные продуктов. Анализ тренды типов лицензирования ПО данного класса свидетельствует о необходимости выбора требуемой модели лицензирования исходя из выбранной модели продаж и монетизации разрабатываемой платформы.

2.1.4 Анализ деятельности в области инструментальных средств Анализ деятельности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и перспектив ее развития проводился в рамках задания на проведение патентных исследований. Учитывая, что патентованию подлежат методы и способы обработки информации, а не сами информационные системы, поиск проводился по непатентным источникам (заявки на регистрацию программ, научно-техническая информация) в соответствии с Регламентом поиска № 1 от 01.06.2017. Поиск среди непатентных источников, выявил 103 документов. Из них по: ˗ По компоненту разработки схемы данных основных данных и моделей бизнес-процессов 40 заявок ˗ По компоненту управления интеграционным взаимодействием 20 ˗ По заявок компоненту формирования централизованной нормативно- справочной информации 10 заявок: ˗ По компоненту формирования хранилища ретроспективных (многолетних) данных и документов 20 заявок ˗ По компоненту создания форм отчетов и форм представлений многомерных данных 3 заявки ˗ По компоненту общесистемного администрирования 10 заявок По результатам проведённого поиска построены кумулятивные кривые динамики публикаций документов по годам в разрезе вышеуказанных компонентов (Рисунок 2.6). Выполненный поиск среди непатентных документов в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС полностью соответствует Заданию № 1 от 01.06.2017 .

Проведённый анализ показал наличие большого количества публикаций в области инструментальных разработку прикладного средств, обеспечивающих программного автоматизированную обеспечения Корпоративных информационных систем. Кроме того, количество этих публикаций неуклонно увеличивается. Рисунок 2.6 - Кумулятивные кривые динамики публикаций непатентных документов по годам в разрезе компонентов 2.2 Формулирование требований к разрабатываемой платформе В настоящий момент на рынке существует ряд инструментальных средств создания корпоративных информационных систем, наиболее известными из которых являются SAP BS, Oracle Applications, Axapta. Каждый из поставщиков программных продуктов предлагает свою методологию разработки и внедрения, содержащую определенную

последовательность действий, которую необходимо выполнить в рамках проекта по созданию информационной системы. Как правило, эти методологии отличаются названиями этапов проекта и содержанием работ в рамках каждого из этапов. В то же время можно выделить работы, которые присутствуют в каждой методологии: − определение рамок, целей и задач проекта; − моделирование бизнес-процессов компании, составление карты автоматизируемых процессов; − определение требований к информационной системе; − разработка прототипа и настройка системы в инструментальной среде; − разработка проектной документации и инструкций пользователей; − опытная эксплуатация и обучение пользователей; − ввод в промышленную эксплуатацию. Новизна для внутреннего рынка заключается в идее создания российского аналога специализированного решения – комплексной интегрированной платформы для создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений для эффективного осуществления административно-управленческих процессов в рамках установленных полномочий. Разрабатываемая Платформа позволит создавать КИС, с функциональностью сопоставимой с импортным программным продуктом класса ERP «Oracle e-Business Suite» американской корпорации Oracle или SAP ERP европейской корпорации SAP. КИС, разработанная с использованием Платформы, при схожем функционале и качестве будет стоить значительно дешевле для потребителей в России. Создаваемая характеристикам: Платформа соответствует следующим инновационным

˗ полнофункциональное отраслевое интегрированное решение для разработки корпоративных приложений с высокими требованиями к надежности, масштабируемости и безопасности; ˗ максимально соответствует российской специфике во всех отраслях экономики и позволяет создать полноценное решение для реализации политики импортозамещения; ˗ базируется на уникальной расширенной модели метаданных данных бизнес-объектов, позволяющей создавать комплексных решения для корпоративного сектора и принятия качественных и эффективных управленческих решений. Создание Платформы нацелено на разработку корпоративных информационных систем. Типичные характеристики таких приложений: ˗ развитая модель данных; ˗ множество (до нескольких сотен) унифицированных экранных форм; ˗ поддержка большого количества (десятков) бизнес-процессов, в том числе бизнес-процессов со сложной логикой (десятки задач, ветвление); ˗ множество (до нескольких сотен) отчетов; ˗ требования по разграничению прав доступа к функциям и данным. В совокупности, разрабатываемая Платформа позволит минимизировать временные затраты функциональности на (модели «системные» данных, задачи экранных – разработку форм, базовой бизнес-процессов), интеграцию технологий и компонентов – и сконцентрироваться на реализации бизнес-требований. В то же время, платформа не ограничивает возможность разработки кода программ, гарантируя возможность использования его для реализации специфических функций КИС. Планируемая в ходе проекта разработка платформы с целью ее последующего тиражирования и внедрения на основных российских предприятиях промышленного сектора и в научно-исследовательских и проектных

учреждениях позволит более качественно решать следующие научно-технические и технологические задачи: ˗ Организация высокотехнологичной платформы для создания единой интегрированной среды проектирования, разработки и моделирования корпоративных бизнес-приложений. ˗ Разработка алгоритма визуального конструирования корпоративных приложений с высокими требованиями быстродействия и надежности; ˗ Разработка алгоритмов моделирования бизнес-процессов корпоративных приложений распределенного характера; ˗ Разработка стандартизированных архитектуры корпоративных для комплексного приложений с учетом построения соблюдения требований по надежности, безопасности и быстродействия. ˗ Создание высокоэффективного и стабильного программного ядра, а также алгоритмов и методик создания типовые конфигурации прикладных модулей. ˗ Разработка алгоритмов бизнес-абстракции и генерации метаданных конфигураций объектов бизнес-приложений ˗ Разработка алгоритмов и методик масштабирования корпоративных приложений в рамках интегрированной платформы разработки. Разработка укрупнённого Технического задания на разработку Платформы позволила сформулировать (приложение Л): ˗ Назначение и цели создания (развития) системы ˗ Требования к системе в целом: ˗ Требования к функциям (по подсистемам): ˗ Требования к видам обеспечения: ˗ Состав и содержание работ по созданию системы ˗ Порядок контроля и приемки системы

˗ Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие ˗ Требования к документированию ˗ Источники разработки Предоставляемые Платформой средства интеграции уже будут включать интеграционные компоненты со СМЭВ и другими общеиспользуемыми инфраструктурными компонентами Электронного правительства Российской Федерации. 2.3 Структура Платформы В состав Платформы входят следующие компоненты: – Компонент разработки схемы данных основных данных и моделей бизнес-процессов, предназначенный для визуального конструирования объектов предприятия ППО КИС в составе: схем данных, схем базы данных, экранных форм, моделей исполняемых бизнес-процессов, и для интерпретации метаданных сконструированных объектов при функционировании КИС; – Компонент управления интеграционным взаимодействием, предназначенный для настройки и реализации информационного взаимодействия разрабатываемой КИС с внешними информационными системами; – Компонент формирования централизованной нормативно-справочной информации, предназначенный для декларативной разработки функциональности централизованного ведения НСИ в разрабатываемой КИС, и предоставления НСИ во внешние информационные системы; – Компонент формирования хранилища ретроспективных (многолетних) данных и документов, предназначенный для организации доступного в режиме

реального времени архива электронных документов и ретроспективной информации; – Компонент создания форм отчетов и форм представлений многомерных данных, предназначенный для разработки функциональности формирования отчетности и аналитической обработки и визуализации многомерных данных и предоставляющий среду их функционирования; – Компонент общесистемного администрирования, предназначенный для выполнения настроек, применимых к Платформе и КИС в целом. Сущность программного обеспечения может быть проиллюстрирована графически с помощью описания логической структуры программных модулей и их блок-схем. Блок-схемы укрупненных алгоритмов работы соответствующих компонентов приведены на рисунках 2.7 – 2.15. 2.3.1 Компонент разработки схемы данных основных данных и моделей бизнес-процессов Компонент разработки схемы данных основных данных и моделей бизнеспроцессов предназначен для разработки функциональности конструирования схем данных объектов данных и моделирования исполняемых бизнес-процессов, интеграции исполняемых бизнес процессов в объекты данных и предоставляет среду для их функционирования. Компонент разработки схемы данных основных данных и моделей бизнеспроцессов должен быть реализован как совокупность функциональных модулей, реализующих группы функций, сгруппированных по иерархическому принципу в функциональные блоки. Описание функциональных модулей компонента и их назначение представлено ниже.

Компонент содержит следующие функциональные модули и функциональные блоки: Модуль разработки схемы данных основных данных: Блок функций конструирования схемы данных. Блок функций конструирования объектов и справочников. Блок функций конструирования рабочих процессов (жизненного цикла) объекта. Модуль разработки моделей бизнес-процессов: Блок функций конструирования схем и моделей данных бизнеспроцессов. Блок функций исполнения бизнес-процессов. Блок функций мониторинга, контроля и анализа исполнения бизнеспроцессов. Функциональный модуль разработки схемы данных основных данных предназначен для конструирования в системе объектов данных, обрабатываемых в разрабатываемом с использованием ИК ИСКУ приложении (далее - объектов приложения), в том числе справочников и документов. Блок функций конструирования схемы данных включает функции, реализующие возможность описания модели данных, формы редактирования и формы списка объектов приложения. Блок функций конструирования объектов и справочников включает функции, реализующие разрабатываемого возможность прикладного формирования программного объектов обеспечения приложения корпоративных информационных систем (далее – ППО КИС) на основании описания их схемы данных. Блок функций конструирования рабочих процессов (жизненных циклов) объектов данных включает функции, реализующие возможность описания статусов жизненного цикла объекта приложения.

Структурная схема функционального модуля разработки схемы данных основных данных представлена на рисунке 2.7. Рисунок 2.7 – Структурная схема функционального модуля разработки схемы данных основных данных Функциональный модуль разработки моделей бизнес-процессов предназначен для моделирования и исполнения бизнес-процессов организации, анализа показателей результата деятельности организации в ППО КИС. Блок функций конструирования схем и моделей данных бизнес-процессов включает функции, реализующие возможности создания схем бизнес-процессов в нотации BPMN 2.0 во встроенном редакторе, настройки логики обработки данных бизнес-процесса, создания и настройки моделей данных исполняемых бизнеспроцессов, а также установки свойств бизнес-процессов, определяющих регламенты их исполнения. Блок реализующие функций исполнения возможности бизнес-процессов выполнения исполняемых использованием сконструированных схем и моделей данных. включает функции, бизнес-процессов с

Блок функций мониторинга, контроля и анализа исполнения бизнеспроцессов включает функции, реализующие возможности получения и анализа ключевых показателей статистической результата информации о деятельности выполнении организации бизнес-процессов, на а основе также возможности оповещения пользователей о событиях процесса. Структурная схема функционального модуля разработки моделей бизнеспроцессов представлена на рисунке 2.8. Функциональный Функциональныймодуль модуль разработки разработкимоделей моделейбизнес-процессов бизнес-процессов Рисунок 2.8 – Структурная схема функционального модуля разработки моделей бизнес-процессов Блок-схема укрупненного алгоритма работы компонента приведена на рисунке 2.9.

Рисунок 2.9 - Блок-схема укрупненного алгоритма работы компонента разработки схемы данных основных данных и моделей бизнес-процессов

2.3.2 Компонент управления интеграционным взаимодействием Компонент управления интеграционным взаимодействием предназначен для настройки и реализации информационного взаимодействия разрабатываемой КИС с внешними информационными системами. Компонент управления интеграционным взаимодействием содержит следующие функциональный блоки: 1. Блок функций управления реестром информационных систем (ИС) и журналирования процессов информационного обмена ИС 2. Блок функций обмена сообщениями между ИС. 3. Блок функций доступа к основным данным ППО КИС. Блок функций управления реестром ИС и журналирования процессов информационного обмена ИС включает функции, реализующие возможность ввода и хранения сведений об ИС, с которыми взаимодействует разрабатываемая КИС, а также возможность автоматической регистрации, просмотра и хранения сведений о процессах информационного обмена с ИС. Блок функций обмена сообщениями между ИС включает функции, реализующие возможность управления правилами обмена сообщениями с ИС, с которыми взаимодействует разрабатываемая КИС. Блок функций доступа к основным данным ППО КИС включает функции, реализующие возможность описания web-сервисов для осуществления доступа к основным данным. Структурная схема Компонента взаимодействием представлена на рисунке 2.10. управления интеграционным

Рисунок 2.10 - Структурная схема компонента управления интеграционным взаимодействием. Блок-схема укрупненного алгоритма работы компонента управления интеграционным взаимодействием приведена на рисунке 2.11.

Рисунок 2.11 – Блок-схема укрупненного алгоритма работы компонента управления интеграционным взаимодействием

2.3.3 Компонент формирования централизованной нормативносправочной информации Компонент информации формирования (НСИ) централизованной предназначен для нормативно-справочной декларативной разработки функциональности централизованного ведения НСИ в разрабатываемой КИС и предоставления НСИ во внешние информационные системы. Компонент информации формирования должен быть централизованной реализован как нормативно-справочной совокупность следующих функциональных блоков, реализующих определенные группы функций: 1. Блок функций формирования структуры, данных и правил проверки объектов НСИ. 2. Блок функций источников ведения централизованной НСИ. 3. Блок функций обеспечения версионности объектов НСИ. 4. Блок функций поиска объектов НСИ. 5. Блок функций распространения НСИ. Блок функций формирования структуры, данных и правил проверки объектов НСИ включает функции, реализующие возможность создания, ведения и хранения объектов НСИ, также возможность определения свойств атрибутов экземпляров объектов НСИ. Блок функций источников ведения централизованной НСИ включает функции, реализующие возможность обмена справочными данными между справочниками ППО КИС и внешними системами. Блок функций обеспечения версионности объектов НСИ включает функции, реализующие возможность учета изменений атрибутов экземпляров и структуры объектов НСИ.

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

Рисунок 2.13 – Блок-схема укрупненного алгоритма работы компонента формирования централизованной нормативно-справочной информации

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

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

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

2.3.5 Компонент создания форм отчетов и форм представлений многомерных данных Компонент создания форм отчетов и форм представлений многомерных данных предназначен для разработки функциональности формирования отчетности и аналитической обработки и визуализации многомерных данных и предоставляет среду их функционирования. Компонент должен содержать следующие функциональные модули, блоки, функции (рисунок 2.15): 1. Модуль аналитических представлений многомерных данных: - Блок функций конструирования структуры многомерных данных. - Функция формирования множественных (не менее 3-х) иерархий данных. - Функция настройки правил и периодичности обновления куба из источников данных. - Функция настройки правил и периодичности обновления куба из источников данных. - Функции просмотра данных куба пользователем. - Функция выгрузки данных OLAP-куба. - Функция предоставления доступа пользователей к многомерным данным в соответствии с их полномочиями. 2. Модуль создания форм отчетов: - Функция построения форм отчетов с использованием сформированного автоматически источника данных. - Функция создания и редактирования шаблонов отчетов и форм отчетов.

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

Рисунок 2.15 - Блок-схема укрупненного алгоритма работы компонента создания форм отчетов и форм представлений многомерных данных Модуль аналитических представлений многомерных данных предназначен для обработки и получения информационных данных в виде аналитических представлений: различных диаграмм и таблиц, с целью их оперативного анализа и принятия решений. Модуль создания форм отчетов предназначен для создания отчетных форм и задания параметров отчетов. 2.3.6 Компонент создания форм отчетов и форм представлений многомерных данных Компонент общесистемного администрирования предназначен для обеспечения функционирования системы в целом. Компонент общесистемного администрирования должен быть реализован как совокупность следующих функциональных блоков, содержащих группы функций: 1. Блок функций идентификации, аутентификации и авторизации пользователей с группами функций: - администрирование учетных записей пользователей ППО КИС; - аутентификация пользователей ППО КИС по логину и паролю; - авторизация пользователей ППО КИС в соответствии с правами доступа;

- идентификация и аутентификация пользователей ППО КИС с использованием учетной записи Единой системы идентификации и пользователей и аутентификации (ЕСИА). 2. Блок функций разграничения доступа к данным. 3. Блок функций журналирования действий журналирования изменений данных. 4. Блок сервисных функций администрирования. 5. Блок функций визуального обновления и инсталляции. 6. Блок функций настройки интерфейса пользователя. Блок функций идентификации, аутентификации и авторизации пользователей предназначен для управления учетными записями пользователей, для обеспечения аутентификации и авторизации пользователей, а также для поддержки условий безопасности паролей. Блок функций разграничения доступа к данным предназначен для обеспечения настройки доступа пользователей к данным и функциям системы. Блок функций журналирования действий пользователей и журналирования изменений данных предназначен для получения информации об изменении состояния и состава данных в записи объекта ППО КИС, а также для получения информации о действиях пользователей над объектами ППО КИС. Блок сервисных функций администрирования предназначен для обеспечения функционирования ППО КИС в части: - автоматического выполнения системных задач по заданному графику и хранения информации о правилах их выполнения (планировщик задач); - возможности создания, хранения и отображения информационных сообщений для пользователей системы. Блок функций визуального обновления и инсталляции предназначен для обеспечения процессов установки и обновления ППО КИС.

Блок функций настройки интерфейса пользователя предназначен для обеспечения ввода индивидуальных настроек списков, фильтров и других параметров интерфейса ППО КИС для быстрой и удобной навигации пользователя по ее объектам. Выводы по 2 разделу В разделе приведены результаты исследования по источникам патентной информации технического уровня средств, обеспечивающих и тенденций развития инструментальных автоматизированную разработку ППО КИС, и предоставляющих среду функционирования КИС, включая типовые алгоритмы моделирования бизнес-процессов корпоративных приложений распределенного характера; создания типовых конфигурации прикладных модулей; бизнесабстракции и генерации метаданных конфигураций объектов бизнес-приложений. Так же приведены результаты исследования использования объектов промышленной (интеллектуальной) собственности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и их правовая охрана и анализ деятельности в области инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС и перспектив ее развития, что полностью соответствует Заданию № 1 от 01.06.2017 на проведение патентных исследований. Достоверность результатов проведённых патентных исследований подтверждается определением предмета поиска в соответствии с Заданием на патентные исследования и Регламентом поиска по классификационным рубрикам МПК, правильным выбором стран, занимающих ведущее положение в данной области технологий, использованием наиболее полных информационных баз патентной информации.

В ходе анализа и обобщения информации установлено, что при разработке компонентов создаваемой информационной системы следует учесть наличие действующих патентов для соблюдения патентной чистоты разработки. Анализ собранной непатентной информации и оценка тенденций развития инструментальных средств, обеспечивающих автоматизированную разработку ППО КИС, и предоставляющих среду функционирования КИС показывает необходимость приоритетной разработки выбранного направления. Также в разделе представлено техническое задание на выполнение работ по теме: «Разработка методологии и инструментальных средств создания прикладных приложений, поддержки жизненного цикла информационно-технологического обеспечения и принятия решений административно-управленческих для процессов эффективного в рамках осуществления установленных полномочий». Также в разделе представлено описание шести компонент Платформы, для которых разработаны блок-схемы укрупненного алгоритма работы: – Компонент разработки схемы данных основных данных и моделей бизнес-процессов; – Компонент управления интеграционным взаимодействием; – Компонент формирования централизованной нормативно-справочной информации; – Компонент формирования хранилища ретроспективных (многолетних) данных и документов; – Компонент создания форм отчетов и форм многомерных данных; – Компонент общесистемного администрирования. представлений

3 Методики оценки программных средств для анализа и проектирования корпоративных информационных систем 3.1 Методика оценки качества программных средств Основу методики получения итоговой оценки качества программных продуктов составляет метод, определенный в ГОСТ 28195-89, позволяющий работать с наборами характеристик качества любого уровня декомпозиции и учитывать влияние каждой характеристики на итоговую оценку качества с помощью значений весовых коэффициентов [5]. Целесообразность использования иерархической структуры характеристик качества объясняется тем, что такие емкие характеристики, как функциональность, надежность и т.п., не могут быть непосредственно оценены экспертами из-за психофизических особенностей человеческого мозга. Согласно методике, процедура оценки качества ПС состоит из шести этапов (рис. 3.1). На первом этапе происходит выбор и декомпозиция характеристик, по которым будет производиться оценка качества ПС. Построение иерархического набора характеристик качества, включает в себя следующие шаги: - Набор и утверждение рабочей группы лицом, принимающим решение. На данном шаге лицом, ответственным за принятие решения (ЛПР) по выбору программного средства, производится формирование рабочей группы, на которую возлагаются задачи проведения процедур оценки качества и сравнения ПС. К наиболее распространенным способам формирования рабочей группы относятся

способ назначения, способ взаимных рекомендаций («снежного кома»), документационный способ. Рисунок 3.1 - Методика оценки качества ПС - втором Составление первоначальной структуры характеристик качества. На шаге, после изучения рабочей группой документации ряда рассматриваемых программных продуктов, а также на основании требований и существующих стандартов, регламентирующих оценку качества ПС, разрабатывается первоначальная структура характеристик качества. - Декомпозиция характеристик до уровня показателей качества. Выбранные на предыдущем шаге характеристики качества подвергаются детализации и представляются рядом более конкретных характеристик качества. - Корректировка структуры характеристик качества. На заключительном шаге происходит повторное рассмотрение и корректировка полученной структуры

характеристик качества, в процессе чего в неё могут быть внесены как дополнительные, так и отсеяны малозначимые характеристики качества. На втором этапе методики оценки качества ПС для каждой характеристики качества определяется её весовой коэффициент относительно других характеристик качества в этой же подгруппе, что обеспечивает её сопоставимость при вычислении промежуточных значений показателей качества. Если тип родительской характеристики – «сумма всех», то суммарное значение весовых коэффициентов для всех её подхарактеристик (показателей качества) должно равняться 1. Если же тип родительской характеристики «один из», то весовой коэффициент, равный 1, должна получить самая значимая подхарактеристика качества, тогда как весовые коэффициенты менее значимых подхарактеристик должны стремиться к 0. Определение весовых коэффициентов характеристик качества в конечной многоуровневой иерархической системе должно производиться последовательно «сверху вниз» на всех уровнях иерархии и выполняться по отдельности для каждой группы характеристик, исходя из их полезности для пользователя. На третьем этапе проводится оценка согласованности экспертов, например, при помощи метода Делфи, являющегося одним из основных методов проведения экспертных опросов. В данном методе предусматривается создание условий, обеспечивающих наиболее продуктивную работу экспертной комиссии, что достигается анонимностью процедуры, с одной стороны, и возможностью пополнения информации о предмете экспертного опроса, с другой стороны. Ещё одно важное свойство – обратная связь, позволяющая экспертам корректировать свои суждения с учетом промежуточных усреднённых оценок и пояснений экспертов, высказавших крайние точки зрения. На четвертом этапе методики в соответствии с требованиями заказчика производится определение перечня средств и проведение их оценки. Под оценкой понимаются действия по применению показателей качества нижнего уровня

декомпозиции к конкретным продуктам. Значения оценочных показателей могут быть получены по результатам тестирования демо-версий и ознакомления с технической и сопроводительной документацией программных средств, а также по результатам контактов с разработчиками и экспертами, имеющими опыт работы с оцениваемым программным обеспечением. На пятом этапе методики производится расчет комплексных характеристик качества оцениваемых программных средств. Так как оценка сходства между объектами сильно зависит от абсолютного значения признака, перед началом расчётов значений комплексных характеристик качества необходимо произвести нормирование значений количественных показателей качества, например, с помощью функции естественной нормировки или нормировок сравнения. После завершения процедуры нормирования всех количественных показателей качества производится последовательный расчет оценок характеристик качества для каждого уровня иерархии. На заключительном шестом этапе выполняется анализ полученных результатов оценки и осуществляется выработка рекомендаций, на основании которых ЛПР принимает решение об окончательном выборе одного из рассматриваемых средств, либо о корректировке перечня оцениваемых программных средств и/или внесении изменений в список характеристик качества ПС. В последнем случае осуществляется переход на соответствующие этапы методики оценки качества и их повторное выполнение. 3.2 Разработка метрик качества инструментальных средств Для оценки характеристик систем должна быть разработана метрика качества.

Метрика качества ПС – это количественный масштаб и метод, которые могут быть использованы для определения значения признака, принятого для конкретной программной продукции. Для простоты расчета комплексных показателей и интегральной оценки качества, все показатели должны иметь одну и ту же область значений [11]. В метриках применяют различные методы определения значений показателей: измерительный, регистрационный, органолептический, расчётный, экспертный, социологический, а также их сочетания по установленным правилам. При определении метрики следует руководствоваться принципами реализуемости, объективности и точности оценки показателей. 3.2.1 Метрика качества на основе ГОСТ Р ИСО/МЭК 9126-93 Для разработки метрики качества использовали разработанную классификацию методов. На основе анализа систем были выбраны характеристики качества разрабатываемой Платформы на основании рекомендаций ГОСТ Р ИСО/МЭК 9126-93 и декомпозировали их. Затем для каждой характеристики качества был определен ее весовой коэффициент (важность) относительно других характеристик качества. Далее выполняется расчет комплексных характеристик качества оцениваемых инструментальных средств. Результаты определения метрики качества приведены в приложении М. Для проведения оценки были выбраны следующие инструментарии для моделирования бизнес-процессов управления организацией, представленные на российском рынке: ARIS, MS Visio, SAP Netweaver BPM, Oracle BPM Suite, IBM Websphere Business, Business Studio, Biz Agi Suite, и предлагаемая разработка.

Сравнительная оценка была проведена по результатам ознакомления с рабочими версиями и открыто рекламируемыми свойствами данных программных продуктов, а также с учётом опыта и знаний пользователей. Полученные результаты комплексной оценки качества приведены на рис.3.2. Кроме интегральных оценок, на диаграмме различными оттенками отображены оценки характеристик качества первого уровня декомпозиции. Результаты комплексной оценки качества 100 90 80 70 60 50 40 30 20 10 0 ARIS MS Visio SAP Oracle IBM Business Biz Agi NetweaverBPM SuiteWebsphere Studio Suite BPM Business Функциональные возмож ности Эффективность Сопровож даемость Новый модуль Практичность Рисунок 3.2 - Результаты комплексной оценки качества Рассмотрим результаты оценки каждой характеристики качества рис. 3.3 и Ж.1- Ж.3 таблицы Ж). Из графиков видно, что наиболее высокой эффективностью обладают SAP Netweaver BPM, Biz Agi Suite и предлагаемая разработка; широкие функциональные возможности имеют SAP Netweaver BPM, Oracle BPM Suite и предлагаемая разработка; по характеристике «Практичность» лучшие показатели у Netweaver BPM, Biz Agi Suite и предлагаемой разработки.

Функциональные возможности 30 25 20 15 10 5 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Новый модуль Рисунок 3.3 - Результаты оценки по характеристике «Функциональные возможности» 3.2.2 Метрика качества на основе комплексного подхода В качестве второго метода проведения сравнительного подхода был использован комплексный подход, включающий в себя использование метода анализа иерархий, который позволяет найти весомости критериев сравнения, которые были выделены на основе анализа литературных источников, ресурсов Интернета, а также особенностей функционала отобранных для сравнения инструментов моделирования бизнес-процессов, и формализованного подхода, позволяющего рассчитать приоритеты альтернативных программных средств моделирования в зависимости от их градаций по каждому выделенному критерию. Очень часто в задачах выбора возникает необходимость добавления в рассмотрение новых альтернатив. При использовании метода Саати добавление даже одной альтернативы приводит к необходимости перезаполнения всех матриц

парных сравнений и перерасчета векторов локальных приоритетов. В связи с этим предлагается использования комбинированного подхода, сочетающего в себе МАИ и методику учета информационных критериев. Для определения весомостей выделенных критериев был использован метод анализа иерархий, предназначенный для упорядочения конечного множества реальных вариантов А1,…,Аm, оценённых по многим количественным и качественным критериям K1,…,Kn, и выбора лучшего варианта по наибольшей общей ценности. Задача выбора представляется в виде иерархии, которая в самом простом случае состоит из 3 уровней: цель (доминанта), критерии, альтернативы (варианты). Сравнение вариантов выполняется по значениям числовой функции ценности (приоритета) v(Ai), приводится описание критериев альтернатив. Для проведения сравнительной оценки важности элементов иерархической структуры по отношению к вышележащему уровню используется унифицированная шкала [66]. Комплексную оценку программного средства будем представлять в виде обобщенной функции (Э), которая в зависимости от количественных значений оценок выбранных для анализа критериев качества равна: Э=f(ПPij), где j – номер группы (1..9), i – номер критерия в группе, Pij – i-й критерий jй группы. Методика учета информационных критериев основывается на допущении, что есть критерии, оказывающие позитивное, а есть критерии, оказывающие негативное влияние. Однако специфика данной методики позволяет перевести негативные критерии в позитивные. Кроме того, использование только позитивных критериев позволит учесть влияние и взаимовлияние критериев друг на друга как внутри одной группы, так и при их нахождении в разных группах.

Каждый критерий экспертными методами разбивается на ряд градаций, которые определяют на качественном уровне его степень влияния на эффективность обслуживания, т.е. устанавливают для каждого критерия шкалу градаций. Это позволяет провести формализацию процедуры оценки, в том числе определить критериальные значения обобщенной функции оценки. Для того чтобы учесть степень влияния каждого критерия по отношению к остальным необходимо ввести коэффициенты весомости, повышающие количественную оценку критерия и определяемые экспертным путем по известным методикам проведения экспертизы. Отсюда вытекает две задачи. Первая – найти количественные меры оценки каждого критерия по его градационной шкале. Вторая – нормировать количественные значения критериев таким образом, чтобы получить достаточно простую и наглядную форму представления результата при анализе обобщенной функции. Обобщенную функцию оценки соответствия программного средства заявленным критериям целесообразно выразим в нормированном виде величиной, находящейся в диапазоне от 0 до 100. 0<=Э<=100 Используя в качестве интегрального критерия количественную оценку Э, можно установить четкие критериальные значения для вывода о степени соответствия рассматриваемого инструментального средства заявленным требованиям. Данная методика предусматривает определение меры оценки каждого критерия выбора, на основе которых можно количественно оценивать степень их влияния на конечный результат. При этом предполагается ранжирование факторов, вычисление соответствующих рангов, нормирование последних и расчет количественных значений оценок соответствующих факторов. Предлагаемая Блюминым методика включает 4 этапа:

1. Выделение отдельных критериев, разносторонне характеризующих степени соответствия инструментального средства эталонным значениям, которые принимаются для последующей их оценки в процессе общей комплексной оценки. 2. Установление для каждого отобранного критерия градационной шкалы, каждый уровень которой отражает степень влияния этого критерия на общую интегральную оценку соответствия. Шкала градаций устанавливается таким образом, чтобы ЛПР смог экспертным путем достаточно просто оценить степень влияния критерия путем выбора соответствующей градации. Таким образом, задача переводится из неформализуемой области выбора предпочтений в область формализации на основе присвоенных количественных значений каждой градации и учета этих значений для последующего определения критериев обобщенной функции оценки. 3. С учетом вычисленных рангов каждого критерия, а также с учетом их коэффициентов весомости и коэффициентов нормирования критериев, определенных в каждой группе, определяются количественные значения каждого уровня шкалы градационного разбиения отдельных критериев. 4. Составляются опросные листы экспертной оценки соответствия инструментального средства заявленным требованиям по каждой группе критериев. Предлагаемый авторами подход позволяет внести изменения во второй и третий этапы вышерассмотренной методики за счет перехода от вычисления рангов критериев, их коэффициентов весомости и коэффициентов нормирования к весовым коэффициентам, получаемых с помощью метода МАИ. Поскольку критерии сгруппированы в 9 классов, вычисляем сначала приоритеты каждого класса критериев, после чего вычисляем приоритеты критериев внутри каждого класса и взвешиваем приоритетыов соответствующего класса.

Результаты определения метрики качества приведены в приложении Н. Для проведения оценки были выбраны следующие инструментарии для моделирования бизнес-процессов управления организацией, представленные на российском рынке: ARIS, MS Visio, SAP Netweaver BPM, Oracle BPM Suite, IBM Websphere Business, Business Studio, Biz Agi Suite, и предлагаемая разработка. Полученные результаты комплексной оценки качества приведены на рис. 3.4. Кроме интегральных оценок, на диаграмме различными оттенками отображены оценки характеристик качества первого уровня декомпозиции. Результаты комплексной оценки качества 100 90 80 70 60 50 40 30 20 10 0 ARIS MS Visio SAP Netw eaver BPM Oracle BPM Suite IBM Websphere Business Business Studio Biz Agi Suite Новый модуль Поддержка нотации BPMN 2.0 Информационное окружение Функциональность Имиджевые характеристики продукта Поддержка Имиджевые характеристики производителя Стоимость владения Производительность Практичность Рисунок 3.4 – Результаты комплексной оценки качества Рассмотрим результаты оценки каждой характеристики качества (рис. 3.5 и З.1-З.8 приложения З).

Функциональность 18 16 14 12 10 8 6 4 2 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Новый модуль Рисунок 3.5 - Результаты оценки по характеристике «Функциональность» Из 8 выбранных программных продуктов у 5 итоговое значение комплексной оценки степени соответствия инструментального средства заявленным требованиям превысило 70%, что говорит о высокой степени их соответствия. Лидером по результатам исследования является SAP ERP со значением комплексной оценки, равным 84,31%. На втором месте находится разрабатываемая Платформа с показателем, равным 82,4%. Расхождение входит в пределы статистических погрешностей. Сопоставление оценок описываемой разработки с SAP по каждому критерию позволило выявить критические зоны, в которых Платформа уступает по возможностям SAP. Предлагаемый комбинированный подход реализован таким образом, что лишен недостатков каждого из входящих в него методов Использование метода анализа иерархий было целесообразно использовать для сравнений критериев выбора, поскольку их набор является устойчивым для инструментальных средств такого типа и в дальнейшем меняться не будет

Использование формализованного подхода позволяет оценивать новые инструментальные средства без перерасчета значений для ранее рассмотренных Из рассмотренных инструментальных средств, уже используемых для моделирования деятельности организаций, наилучшими оказались системы …… Анализ проектируемого в рамках разработки Платформы компонента …… показал, что в целом он соответствует уровню ведущих инструментальных средств, а по некоторым критериям превосходит их. 3.3 Применение метода анализа иерархий при анализе и выборе корпоративных информационных систем 3.3.1 Выбор критериев сравнения КИС На российском рынке ERP-систем присутствует множество поставщиков: как иностранных, так и российских. По оценкам экспертов, основную долю рынка (свыше 48%) занимает немецкий вендор SAP AG, следом за ним идут продукты Microsoft Business Solution с долей около 13%, а замыкает тройку лидеров компания Oracle, занимающая чуть больше 11% российского рынка ERP-систем. Столь значительный отрыв SAP можно отчасти объяснить тем, что немецкий концерн первым вышел на российский рынок. На мировом рынке ситуация несколько иная и основная борьба за лидерство разворачивается между SAP и Oracle [76].

В настоящее время в СНГ присутствуют около десятка западных информационных систем и три-четыре российских, которые можно отнести к корпоративным [1-3, 56-62]. В рамках разработки методологии и инструментальных средств создания прикладных приложений, технологического поддержки обеспечения и жизненного принятия цикла решений информационно- для эффективного осуществления административно-управленческих процессов в рамках создания автоматизированных систем для органов государственной власти и местного самоуправления, а также иных российских заказчиков была поставлена задача проведения анализа рынка российских и зарубежных КИС, сравнения их функциональных характеристик, особенностей их внедрения и сопровождения и т.д., что позволило определить требования к разрабатываемой Платформе и выявить, в каких КИС функционал, необходимый для обеспечения конкурентоспособности и импортозамещения, реализован наилучшим образом, чтобы использовать передовой опыт в собственной разработке. На основе анализа библиографических источников, материалов сети Интернет было сформулировано 43 критерия, сгруппированных в 7 классов [1-3] (приложение Ж). Наиболее целесообразным подходом проведения сравнения КИС по их характеристикам и выявление наиболее важных из них для внедрения в российских организациях является многокритериальное оценивание, позволяющее учесть разную важность отдельных функциональных характеристик КИС на процесс их выбора. Существует ряд методов многокритериального оценивания, отличающихся как особенностями расчета приоритетов альтернативных объектов, так и порой порядком и степенью предпочтения. Задача выбора КИС может быть представлена графически в виде иерархии,

на верхнем уровне которой находится цель, на втором – критерии, а на третьем – альтернативы (рисунок 3.6). Рисунок 3.6 – Иерархия сравнения и выбора КИС Проанализировав публикации с описанием достоинств и недостатков методов многокритериального оценивания, в рамках данного исследования было решено использовать Метод анализа иерархий (МАИ) [66]. Данный подход довольно хорошо обоснован математически, достоинства данного метода состоят в получении количественных значений предпочтительности сравниваемых альтернативных объектов. Реализация МАИ представляет собой иерархическую процедуру парных сравнений, при которой вначале в матрице парных сравнений (МПС) сравниваются попарно между собой сформулированные качественные и

количественные признаки (критерии), по которым осуществляется отбор наилучших альтернатив после выявления степени их предпочтительности. Расчет нормированного вектора локальных приоритетов критериев позволяет определить, какие из критериев являются в конкретной ситуации выбора наиболее важными для процедуры отбора (таблица 3.1). Следующим этапом метода является заполнение матриц парных сравнений альтернативных объектов по каждому из сформулированных критериев. Расчет локальных векторов приоритетов альтернатив по каждой МПС позволяет определить те КИС, в которым данные характеристики реализованы наилучшим образом. Таблица 3.1 - Матрица парных сравнений групп критериев выбора КИС Выбор КИС No AT F S Co PoCIS ICh No 1 1/4 1/2 1/3 1/3 1/6 1/5 AT 4 1 3 1/2 2 1/3 2 F 2 1/3 1 1/4 1/2 1/5 1/2 S 3 2 4 1 3 1/2 1/3 Co 3 1/2 2 1/3 1 1/4 1/3 PoCIS 6 3 5 2 4 1 1 ICh 5 1/2 2 3 3 1 1 Вектор локальных приоритетов 0,339614986 0,084260388 0,224730595 0,079518387 0,16173539 0,044304308 0,065835948 Таким образом, наиболее важными группами при выборе КИС на основе анализа вектора локальных приоритетов являются: потребности организации, функциональность, стоимость владения. Далее внутри каждого класса вычисляются приоритеты входящих в него элементов на основе заполненных матриц их парных сравнений, отражающих степень важности каждого критерия для класса (табл. Ж.1, Ж.2 приложения Ж). Наиболее важными критериями группы «Потребности организации» являются: Соответствие бизнес процессам, Соответствие стратегии организации, Развитые средства настройки бизнес-процессов. Аналогично заполнялись таблицы МПС критериев внутри каждого класса и

были получены следующие векторы локальных приоритетов после их взвешивания значениями приоритетов соответствующих классов. Взвесив полученные вектора локальных приоритетов критериев по классам значениями приоритетов соответствующих классов, получили следующие значения компонентов вектора локальных приоритетов 43 критериев (таблица Ж.3) Далее заполняются матрицы парных сравнений КИС по каждому из критериев. 3.3.2 Выбор КИС российского производства В качестве альтернативных КИС российского производства были рассмотрены следующие системы, разработанные в России [56-62]: Альтернатива А1 – ТБ.Корпорация; Альтернатива А2 – Alfa; Альтернатива А3 – Парус; Альтернатива А4 – 1С:Предприятие; Альтернатива А5 – Omega Production; Альтернатива А6 – Компас; Альтернатива А7 – Флагман; Альтернатива А8 – Галактика. При проведении сравнительного анализа полученных результатов были выявлены те КИС, в которых критерии рассматриваемых классов реализованы наилучшим образом, для чего были заполнены матрицы парных сравнений КИС по каждому из критериев, рассчитаны и проанализированы вектора локальных приоритетов альтернатив (таблицы Ж.4, Ж.5). Как следует из таблицы, по критерию «NoO1» наиболее предпочтительны следующие КИС: 1С:Предприятие, Парус, Галактика, Omega Production. После этого вычислим приоритеты всех КИС по каждому из критериев сравнения. На основе линейной свертки были получены значения компонент вектора глобальных приоритетов альтернативных КИС (таблица3.2).

Таблица .3.2 - Вектор глобальных приоритетов КИС А1 А2 А3 А4 0,06325 0,06554 0,17905 0,21092 А5 А6 А7 0,13483 0,06663 0,09768 А8 0,18211 Наиболее предпочтительными являются 1С:Предприятие, Галактика, Парус. Данные КИС являются лидерами, но у них имеются такие характеристики, по которым они являются наименее предпочтительными. Полученные результаты являются в определенной степени усредненными. По наиболее значимым критериям каждого блока была определена КИС (одна или несколько), в которой данные характеристики реализованы наилучшим образом: – блок «Потребности организации» - Соответствие бизнес процессам – 1С:Предприятие; – блок «применяемые технологии» - Программная архитектура 1С:Предприятие, Галактика; – блок «функциональность» - Резерв функциональности - Парус, Галактика; – блок «поддержка» - Цикл поддержки - Галактика; – блок стоимость владения - Стоимость программного обеспечения – Флагман; – блок «Принципы построения КИС» - Системное окружение, в котором может работать система - Парус, Omega Production; – блок «Имиджевые характеристики» - Распространенность системы на рынке, в отрасли, в регионе, отзывы пользователей – Галактика. Тем не менее, свертка по всем критериям дала в качестве наиболее предпочтительной КИС 1С:Предприятие, которая 24 раза из 43 показала себя наиболее предпочтительной, тогда как стоящая на втором месте Галактика показала себя лучшей только 14 раз.

3.3.3 Выбор зарубежных КИС Для проведения сравнительного анализа зарубежных КИС были выбраны следующие продукты: Альтернатива А1 - SAP R/3; Альтернатива А2 - Oracle Applications; Альтернатива А3 - Oracle Business Suite; Альтернатива А4 - IFS Application; Альтернатива А5 - Baan ERP; Альтернатива А6 – iRenaissance; Альтернатива А7 - MS Dynamics AX; Альтернатива А8 - MS Dynamics NAV. Пример расчетной таблицы представлен в приложении Ж (таблица Ж.6). На основе линейной свертки были получены значения компонент вектора глобальных приоритетов альтернативных КИС (таблица 3.3). Таблица 3.3 - Вектор глобальных приоритетов КИС А1 А2 А3 А4 А5 А6 А7 А8 0,15943 0,10729 0,14768 0,10587 0,1288 0,0832 0,1322 0,13554 Таким образом, на первом месте по предпочтительности SAP R/3, на втором Oracle EBusiness Suite, на третьем Microsoft Dynamics NAV. Проведенные исследования показали, что на первом месте по предпочтительности SAP R/3, на втором Oracle EBusiness Suite, на третьем Microsoft Dynamics NAV, однако ни одна из систем по всем критериям не является общепризнанным лидером. Выбрав одну из указанных КИС, даже самую лучшую, руководству компании нужно быть готовым к тому, что потребуется адаптация и доработки приобретенной организации. системы под конкретные требования данной

3.4 Учет взаимовлияния критериев при анализе и выборе КИС На основе проведенных ранее исследований представленных на рынке отечественных и зарубежных систем [1-3] с использованием Метода анализа иерархий были выявлены наиболее предпочтительные критерии при выборе российских и зарубежных КИС. При этом оценка значимости критериев при выборе КИС проводилась как в внутри каждой группы, так и в целом по всей иерархии критериев. Однако в данных исследованиях критерии выбора КИС рассматривались обособленно без учета их возможного взаимовлияния как между группами критериев, так и между критериями внутри каждой группы, а также без учета историзма влияния критериев на самих себя. Для учета влияния критериев друг на друга, совокупного влияния нескольких критериев и определения возможного влияния критерия самого на себя в процесс выбора, внедрения и сопровождения КИС были построены графовые модели. Для отображения зависимостей между критериями были выбраны графоаналитическое и аналитическое представление. j Предварительно все критерии были представлены в виде K i , где j – номер группы (j=1..7), i – номер критерия в группе (i=1..n j, n1=6, n2=4, n3=9, n4=7, n5=4, n6=5, n7=8) С помощью графоаналитического подхода были построены следующие модели: - учета индивидуального влияния критериев друг на друга внутри каждой выделенной группы;

- учет индивидуального влияния всех возможных критериев друг на друга (рис. 3.4); - учет комплексного влияния совокупности ряда критериев (в том числе и из разных групп) на каждый критерий. Для большей наглядности на рисунке 3.4 представлены все связи, 1 характерные только для критерия K 4 . На рисунке пунктирными линиями показано 1 влияние на критерий K 4 со стороны других критериев. При анализе представленных графоаналитических моделей были выделены четыре параметра, которые позволили рассмотреть аналитические зависимости { } j j j K ij= k вхj i , k исх i , k i , k ∑ вх i каждого из критериев в виде кортежа , j где k вх i - количество других критериев, влияющих на текущий, j k исх i j ki - количество других критериев, на которые влияет текущий, - фиктивный параметр, который принимает значение 1, если имеется влияние предыдущего значения критерия на самого себя, и 0 – в противном случае, j k ∑ вх i - количество наборов критериев, влияющих на текущий. В качестве примера представим аналитически характеристики критериев из разных групп: K 21 ={18 , 23 , 1, 4| K 12 +K 22 ; K 35 +K 39 ; K 51 +K 39 +K 61 ; K 61 +K 62 +K 63 } K 35 ={4, 3, 1, 3| K 21+K 22 ; K 36 +K 39 +K 12 ; K 61 +K 62 +K 63 } { ; ; K 72 = 22 , 21 , 1, 6| K 12 +K 14 ; K 45+K 15 ; K 23+K 34+K 77 ; K 43 +K 44 +K 45 ; {∑ K 5 } ; {∑ K 6}} . При этом в формулах представлено не только количество совокупно влияющих критериев на текущий, но и перечисляются все их сочетания.

1 Рисунок 3.4 – Модель влияния критерия K 4 на другие рассматриваемые критерии Данный подход позволил: - выявить возможные сочетания критериев, которые в совокупности оказывают влияние на тот или иной критерий выбора КИС; - учесть автокорреляционность ряда критериев; - определить критерии, которые оказывают наибольшее влияние на процесс выбора, и изменение которых соответственно приведет к серьезным изменениям в структуре проектируемой КИС или к смене перечня предпочтительных систем; - выявить критерии, на которые оказывается наибольшее влияние других критериев, что позволит построить модель управляющих на него воздействий критериев и их сочетаний;

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

предприятия, заинтересованных в использовании всех возможностей КИС при управлении организацией. К заинтересованным сторонам внутри предприятия следует отнести руководство, технических специалистов, которые будут обслуживать как саму КИС, так и ее окружение, и непосредственных исполнителей – пользователей системы. Соответственно при выборе КИС необходимо учитывать мнения всех вышеперечисленных групп. Анализ опыта выбора систем управления предприятиями (ERP, CRM) показывает, что наиболее часто встречающимися критериями являются следующие: стоимость системы, гибкость, масштабируемость, открытость, возможность модификации под потребности предприятия, имидж фирмыпроизводителя, наличие успешных внедрений на предприятиях аналогичной отрасли, соотношение Цена/Качество, соотношение Цена/Функционал, функционал системы, СУБД, лежащая в основе КИС, возможность работы в КИС удаленных подразделений и др. Значения критериев, выдвигаемых в процессе выбора к желаемому объекту, и позволяют принимать решения. Чем более точны и детальны эти критерии, тем, с одной стороны, более сложен механизм выбора, но, с другой стороны, и более правильный, так как учитывает достаточно большое количество различных факторов. Но для того, чтобы грамотно и однозначно определить эти критерии необходимо знать предметную область проблемы выбора. Что касается критериев выбора предъявляемых к КИС как специалистами в области информационных технологий, так и сотрудниками предприятий, осуществляющих выбор, то для них характерны следующие особенности: общий характер, низкая степень детализации или отсутствие таковой; отсутствие четких формулировок; ориентация критериев на рекламные материалы фирм- производителей; отсутствие системы критериев; малая доля охвата характеристик объекта выбора; отсутствие систематизации критериев; низкая связь критериев с бизнес-процессами предприятия.

Структурный подход к выбору критериев КИС предполагает выделение следующих когнитивных элементов знаний: понятия, взаимосвязи, метапонятия, семантические отношения. Существует достаточное количество методов, с помощью которых можно построить семантическую модель, при отборе критериев для выбора КИС использовались: 1. Метод формирования перечня понятий (критериев), который заключался в том, что каждый из сотрудников предприятия, относящийся к одной из трех выделенных групп, составлял свой собственный список критериев. Затем проводился анализ полученной информации, и отбирались наиболее значимые критерии для каждой группы специалистов по принципу – критерий, который был выбран всеми членами группы включается в обязательном порядке, а остальные либо рекомендуются к рассмотрению, либо отклоняются. 2. Текстологический метод, который заключается в формирования системы понятий из сферы ответственности опрашиваемого лица. 3. Метод составления списка элементарных действий, который позволил сгруппировать все предложенные предыдущими методами критерии в 7 классов и выявить взаимозависимости как между классами, так и внутри каждого класса (рисунок 3.5). Установление взаимосвязей предполагало установление семантической близости между отдельными критериями, для чего использовались два метода: 1. Метод свободных ассоциаций, который основан также фундаментальная категория близости объектов или концептов. 2. Метод сортировки карточек, в котором опрашиваемых просили сгруппировать критерии в соответствии с интуитивным пониманием семантической близости предъявляемых понятий. Опрос заинтересованных во внедрении КИС на предприятии сторон показал, что всех опрошенных можно объединить в три группы, для каждой из которой предлагается выделить следующие требования (рис. 3.6):

Рисунок 3.5 – Взаимосвязь классов критериев отбора КИС Рисунок 3.6 – Диаграмма Эйлера-Венна при анализе кортежей требований к КИС

Группа 1 – Менеджеры высшего звена предприятия (ТОР) ТОР = {No = {NoO1 - Соответствие бизнес процессам, NoO3 Соответствие стратегии организации, NoO4 - Наличие отраслевых решений}, AT = {AT4 - Использование стандартных широко распространенных ИТ-технологий}, F = {F2 – Наглядность, F3 - Соответствие нормативной базе, F4 - Использование лучших, наиболее эффективных, проверенных мировой практикой методов организации работ, F7 - Контролируемость и надежность системы, F8 - Сроки внедрения}, S = {S2 - Наличие технологии обучения работе с системой и учебных материалов, S3 - Опыт внедрения, S6 - Качественная документация и контекстная помощь, S7 - Наличие службы поддержки}, Co = {CoO1 - Стоимость программного обеспечения, CoO2 - Стоимость аппаратного обеспечения, CoO3 Стоимость обслуживания, CoO4 - Стоимость модернизации и обновления, ежегодные инвестиции в развитие системы}, PoCIS ={PoCIS4 - Поддержка технологии принятия решений, PoCIS6 – Наличие системы управления базой данных}, ICh ={ICh1 Распространенность - Устойчивость системы на рынке, производителя в отрасли, системы, в регионе, ICh2 - отзывы пользователей, ICh3 - Присутствие поставщика и системы на локальном рынке, ICh5 - Структура и возможности партнерской сети по внедрению системы, ICh6 Распространенность специалистов на рынке, ICh7 - Оценки опыта успешных и неудачных проектов, ICh8 - Квалификационный уровень специалистов}} Группа 2 – Специалисты по внедрению и сопровождению системы (IT) IT = {No = {NoO2 – Масштабируемость, NoO5 - Простота использования обслуживающим персоналом, NoO6 - Развитые средства настройки бизнеспроцессов}, AT = {AT1 - Программная архитектура, AT2 - Техническая архитектура, AT3 - Технология внедрения ERP системы, AT4 - Использование стандартных широко распространенных ИТ-технологий}, F = {F1 – Интеграция, F5 - Резерв функциональности, F6 - Простота модернизации и дополнения функциональности системы, F7 - Контролируемость и надежность системы, F8 -

Сроки внедрения, F9 - Состав модулей}, S = {S1 - Цикл поддержки, S2 - Наличие технологии обучения работе с системой и учебных материалов, S4 - Наличие средств, упрощающих процесс внедрения, S5 - Наличие стандартной технологии внедрения для всех партнеров, S6 - Качественная документация и контекстная помощь, S7 - Наличие службы поддержки}, Co = {}, PoCIS ={PoCIS1 - Системное окружение, в котором может работать система, PoCIS2 - Открытая платформа и открытые системные интерфейсы, PoCIS3 - Открытая структура системы и открытый исходный код всех приложений, PoCIS4 - Поддержка технологии принятия решений, PoCIS5 - Поддержка CASE-технологии, PoCIS6 – Наличие системы управления базой данных}, ICh ={ICh1 - Устойчивость производителя системы, ICh2 - Распространенность системы на рынке, в отрасли, в регионе, отзывы пользователей, ICh4 - Стратегия развития и модернизации системы, ICh5 Структура и возможности партнерской сети по внедрению системы, ICh7 - Оценки опыта успешных и неудачных проектов}} Группа 3 – Пользователи КИС (USER) USER = {No = {NoO4 - Наличие отраслевых решений, NoO5 - Простота использования обслуживающим персоналом}, AT = {AT4 - Использование стандартных широко распространенных ИТ-технологий}, F = {F1 – Интеграция, F2 – Наглядность, F3 - Соответствие нормативной базе}, S = {S2 - Наличие технологии обучения работе с системой и учебных материалов, S7 - Наличие службы поддержки}, Co = {}, PoCIS ={PoCIS6 – Наличие системы управления базой данных}, ICh ={ICh2 - Распространенность системы на рынке, в отрасли, в регионе, отзывы пользователей, ICh6 - Распространенность специалистов на рынке, ICh8 - Квалификационный уровень специалистов}} Как видно из рисунка, пересечением всех трех множеств требований является множество критериев: ТОР ∩ IT ∩ USER = {AT4, S2, S7, PoCIS6, ICh2}. Проект по выбору КИС обычно включает следующие этапы работ:

1. Экспресс-диагностика предприятия, в ходе которой определяются цели внедрения КИС, и происходит их увязка со стратегическими целями предприятия. 2. Формирование описания бизнес-процессов верхнего уровня. 3. Разработка требований к системе и поставщику. 4. Установление границ проекта внедрения КИС, уточнение описания наиболее критичных бизнес-процессов, проведение аудита ИТ-инфраструктуры и существующих на предприятии программных решений. 5. Формирование требований к системе и поставщику. 6. Сбор и актуализация информации по КИС и поставщикам. 7. Проведение тендера путем составления и рассылки поставщикам запроса коммерческого предложения, содержащего перечень требований к ИТ-решению, сбор и оценка коммерческих предложений с использованием специальной методики. 8. Осуществление (в ряде случаев) "пилотного" внедрения на одном процессе (возможно, вспомогательном) предприятия. Работы 1-6, 8 достаточно подробно представлены в литературе. Определенный интерес представляет формализация процедура отбора и оценки альтернативных вариантов КИС, особенности требуемого функционала которых будет зависеть от конкретных условий использования данных программных продуктов. Выбор компонентов КИС и его окружения представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке корпоративных информационных систем (КИС). Этот выбор должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты не только на приобретение, но и на разработку системы, сопровождение, а также обучение персонала. При этом следует также учитывать несогласованность мнений заинтересованных в приобретении КИС сторон.

Поскольку предыдущий анализ показал, что СУБД является для всех заинтересованных одним из важнейших компонентов, то ограничимся в данной статье подробным рассмотрением параметров выбора именно этого компонента КИС. Важно выбрать СУБД, которая не только удовлетворяет сегодняшним потребностям организации, но и имеет «запас развития и прочности» для дальнейшего расширения и интеграции. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, доработку программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды. Можно выделить ряд критериев, по которым следует проводить выбор СУБД (рисунок 3.7): ˗ модель данных; ˗ дополнительные возможности; ˗ особенности архитектуры и функциональные возможности; ˗ особенности разработки приложений; ˗ производительность; ˗ надежность; ˗ требования к рабочей среде; ˗ смешанные критерии.

Рисунок 3.7 – Семантическая модель критериев выбора СУБД Четкий и глубокий сравнительный анализ на основании вышеперечисленных критериев поможет рационально выбрать подходящую СУБД, удовлетворяющую запросам конкретной организации. Согласно рейтингу систем управления базами данных (СУБД), проведенному в 2016 году крупным русскоязычным аналитическим агентством Тэглайн, наиболее часто используемыми являются: MySQL, PostgreSQL, MS SQL Server, MongoDB, SQLite, Oracle Database, Firebird, CouchDB, DB2, MariaDB, RavenDB, Redis. SAP ASE (ex: Sybase), Percona Server. Используя семантическую модель, представленную на рисунке 3, для рассматриваемой организации из предложенных 11 систем была подобрана СУБД PostgreSQL, как отвечающая большинству требований, сформированных в процессе опроса будущих пользователей системы.

Выводы по 3 разделу В данной главе проведен обзор методики оценки качества ПС, рассмотрены шесть этапов процедуры оценки: выбор и декомпозиция характеристик, по которым производится оценка качества ПС; определение весовых коэффициентов для каждой характеристики; оценка согласованности экспертов; определение перечня средств в соответствии с требованиями заказчика и проведение их оценки; расчет комплексных характеристик качества оцениваемых ПС; анализ полученных результатов. Разработана метрика качества для оценки инструментальных средств, даны определения характеристик для оценки качества программных средств согласно ГОСТ Р ИСО/МЭК 9126-93, проведена их декомпозиция и определены весовые коэффициенты. Разработана метрика качества для оценки инструментальных средств, даны определения характеристик для оценки качества программных средств на основе комплексного подхода, проведена их декомпозиция и определены весовые коэффициенты. На основе полученных метрик проведена интегральная оценка качества инструментальных средств для моделирования бизнес-процессов управления организацией. Результаты оценки качества представлены в виде графиков.

Заключение В данной работе проведен анализ процессов жизненного цикла программных средств; проведен обзор основополагающих международных и национальных стандартов в области инженерии программных средств – описаны цели применения и основные задачи, которые стандарты помогут разрешить. Проведена группировка стандартов на стандарты, регламентирующие процессы жизненного цикла программных средств и систем и стандарты, регламентирующие качество программных средств. Был проведен анализ методологий и методов проектирования программных средств и разработана их классификация. Классификация поможет ориентироваться во множестве методов при решении задач выбора оптимального набора моделей, необходимых для анализа и проектирования систем управления конкретной предметной области. На основании классификации проведен анализ применимости методов проектирования для групп технических и специальных процессов жизненного цикла программных средств. Современные инструментальные средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПС. Был проведен патентный поиск с целью определения технического уровня инструментальных средств. Обоснование использованием выбора инструментальных разработанных метрик средств качества. проводилось Были с определены характеристики качества программных продуктов, их весовые коэффициенты. Затем был проведен расчет комплексных характеристик качества оцениваемых средств. На заключительном этапе был проведен анализ результатов, которые представлены в виде наглядных графиков.

Результаты проведенного анализа будут полезны всем, кто занимается проектированием систем управления предприятием и находится в поиске средства проектирования, наиболее полно удовлетворяющего потребности фирмы. Планируемая разработка позволит создавать КИС с функциональностью, сопоставимой с импортным программным продуктом класса ERP «Oracle eBusiness Suite» американской корпорации Oracle или SAP ERP европейской корпорации SAP. КИС, разработанная с использованием Платформы, при схожем функционале и качестве будет стоить значительно дешевле для потребителей в России. Создаваемая Платформа должна удовлетворять следующим инновационным характеристикам: - полнофункциональное отраслевое интегрированное решение для разработки корпоративных приложений с высокими требованиями к надежности, масштабируемости и безопасности; - максимально соответствует российской специфике во всех отраслях экономики и позволяет создать полноценное решение для реализации политики импортозамещения; - базируется на уникальной расширенной модели метаданных данных бизнес-объектов, позволяющей создавать комплексных решения для корпоративного сектора и принятия качественных и эффективных управленческих решений.

Список библиографических источников 1) Lomakin, V.V. Multi-criteria selection of a corporate system by using paired comparison analysis / V.V. Lomakin, N.P. Putivtseva, T.V. Zaitseva, M.V. Liferenko, I.M. Zaitsev // Journal of Fundamental and Applied Sciences. – 2017. – 9(7S). – Р. 1472-1482. 2) Зайцев, И.М. Многокритериальный выбор корпоративной системы с применением инструментальных средств повышения степени согласованности матриц парных сравнений [Текст] / И.М. Зайцев, Т.В. Зайцева, М.В. Лифиренко, В.В. Ломакин, Н.П. Путивцева // Информационные системы и технологии. – 2017. - № 6(104). – С. 85-93. 3) Путивцева, Н.П. Решение задачи выбора российских корпоративных информационных систем с использованием метода анализа иерархий [Текст] / Н.П. Путивцева, Т.В. Зайцева, В.В. Ломакин, О.П. Пусная, О.С. Резниченко // Вестник ВГУ САИТ. – 2017. - № 4. – С. 85-91. 4) Ломакин, В.В. Формально-алгоритмическое представление специализированного языка управления данными [Текст] / В.В. Ломакин, Р.Г. Асадуллаев, Т.В. Зайцева, Н.П. Путивцева, Ю.Ю. Белоконь // Вестник БГТУ им. В.Г. Шухова. – 2017. - № 12. – С. 173-179. 5) Асадуллаев, Р.Г. Модели и средства поддержки принятия решений в системах переподготовки кадров предприятия [Текст] / Р.Г. Асадуллаев, В.В. Ломакин, Ю.Ю. Белоконь, Т.В. Зайцева, О.С. Резниченко // Научные ведомости БелГУ. Серия Экономика. Информатика. – 2017. - № 23(272). – С. 148-158. 6) Путивцева, Н.П. Разработка программной поддержки иерархической многокритериальной процедуры оценки качества экспертов [Текст] / Н.П. Путивцева, Т.В.Зайцева, О.П. Пусная, С.В. Игрунова, Е.В. Нестерова, Е.В. Калюжная, Е.А. Зайцева // Научные ведомости БелГУ Серия История.

Политология. Экономика. Информатика. – Белгород: Изд-во БелГУ. – 2016. – №16(237). – Выпуск 39. – С. 172-179. 7) Путивцева, Н.П. Сравнительный анализ применения многокритериальных методов [Текст] / Н.П. Путивцева, О.П. Пусная, С.В. Игрунова, Т.В. Зайцева, Е.В. Нестерова // Научный результат. Информационные технологии. – 2017. – Т.2. – №1. – С. 40-47.Александров Д. В. Инструментальные средства информационного менеджмента. CASE-технологии и распределенные информационные системы: Учебное пособие. – М.: Финансы и статистика, 2011. – 224 с. 8) Зайцева, Т.В. Выявление взаимовлияния критериев отбора кис с использованием семантического подхода [Текст] / Зайцева Т.В., Путивцева Н.П., Ломакин В.В., Пусная О.П. // НАУЧНЫЕ ДОСТИЖЕНИЯ – 2017: Избранные материалы XV Международной научно-практической (очно-заочной) конференции студентов, аспирантов и молодых ученых «Научное творчество XXI века» (14–15 ноября 2017 г., Красноярск, Российская Федерация) и X Международной итоговой научно-практической (очно-заочной) конференции молодых ученых и специалистов «Современная российская наука глазами молодых исследователей» (23–24 декабря 2017 г., Красноярск, Российская Федерация). – Красноярск: Научно-инновационный центр,2017. – С. 34-46. 9) Зайцева, Т.В. Вовлечение студентов в совместные научно-практические исследования с использованием междисциплинарного подхода [Текст] / Т.В. Зайцева, Н.П. Путивцева, В.В. Ломакин, О.П. Пусная // Образование, инновации, исследования как ресурс развития сообщества : материалы Междунар. науч.-практ. конф.— Чебоксары: ИД «Среда», 2017. 10) Путивцева, Н.П. К вопросу об организации курсов переподготовки сотрудников с использованием подсистемы электронного индивидуально- ориентированного обучения [Текст] / Н.П. Путивцева, Т.В. Зайцева, В.В. Ломакин, Р.Г. Асадуллаев, О.П. Пусная // Экономика и управление: проблемы, анализ

тенденций и перспектив развития: сборник материалов I Международной научнопрактической конференции. – Новосибирск: Изд-во ЦРНС, 2017. – С. 129-134. 11) Амбалова, З.А. Проектный подход при внедрении информационной системы при распределении обязанностей участников комплексных проектов [Текст] / З.А. Амбалова, Т.В. Зайцева // ИССЛЕДОВАНИЕ, РАЗРАБОТКА И ПРИМЕНЕНИЕ ВЫСОКИХ ТЕХНОЛОГИЙ В ПРОМЫШЛЕННОСТИ: Сборник статей по итогам Международной научно-практической конференции (Тюмень, 17 января 2018 г.). - Стерлитамак: АМИ, 2018.- С. 13-18. 12) Путивцева, Н.П. Процедура многокритериального выбора ERP системы как составляющая часть электронного бизнеса вуза [Текст] / Н.П. Путивцева, Т.В. Зайцева // Естественнонаучные, инженерные и экономические исследования в технике, промышленности, медицине и сельском хозяйстве: материалы I Молодѐжной научно-практической конференции с международным участием; под общ. ред. С.Н. Девицыной. – Белгород: ИД «Белгород» НИУ «БелГУ», 2017. 13) Александров, Д.В. Инструментальные средства информационного менеджмента. CASE-технологии и распределенные информационные системы: Учебное пособие [Текст] / Д.В. Александров. – М.: Финансы и статистика, 2011. – 224 с. 14) Большой Российский энциклопедический словарь [Текст]. – М.: БРЭ, 2013. – 1437 с. 15) ГОСТ 28195-89 Оценка качества программных средств. Общие положения [Электронный ресурс] / http://docs.cntd.ru/document/1200009135 (дата обращения 12.12.2017). 16) ГОСТ 34.003-90 Автоматизированные системы. Термины и определения [Электронный ресурс] / http://docs.cntd.ru/document/1200006979 (дата обращения 12.12.2017).

17) ГОСТ 34.320-96 Информационные технологии. Концепции и терминология для концептуальной схемы и информационной базы [Электронный ресурс] / http://docs.cntd.ru/document/1200017661 (дата обращения 12.12.2017). 18) ГОСТ 34.321-96 Информационные технологии. Эталонная модель управления данными [Электронный ресурс] /– http://docs.cntd.ru/document/1200017662 (дата обращения 13.12.2017). 19) ГОСТ 34.601-90 Автоматизированные системы. Стадии создания [Электронный ресурс] / http://docs.cntd.ru/document/1200006921 (дата обращения 13.12.2017). 20) ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные автоматизированной системы. системы Техническое задание [Электронный на создание ресурс] / http://docs.cntd.ru/document/gost-34-602-89 (дата обращения 13.12.2017). 21) ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию [Электронный ресурс] / http://docs.cntd.ru/document/1200030195 (дата обращения 13.12.2017). 22) ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование [Электронный ресурс] / http://docs.cntd.ru/document/1200025075 (дата обращения 13.12.2017). 23) ГОСТ Р ИСО/МЭК 12207:2010 Системная и программная инженерия. Процессы жизненного цикла программных средств [Электронный ресурс] / http://docs.cntd.ru/document/gost-r-iso-mek-12207-2010 (дата обращения 14.12.2017). 24) ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем [Электронный ресурс] / http://docs.cntd.ru/document/gost-r-iso-mek-15288-2005 (дата обращения 14.12.2017).

25) ГОСТ Р ИСО/МЭК 9126-93 Характеристики качества и руководства по их применению [Электронный ресурс] / http://docs.cntd.ru/document/gost-r-iso-mek9126-93 (дата обращения 14.12.2017). 26) ГОСТ Р ИСО/МЭК ТО 12182-2010 Классификация программных средств. 27) ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12270 (Процессы жизненного цикла программных средств). 28) ISO/IEC 14598-6:2001 Информационные технологии. Оценка программного продукта. Часть 6. Документирование модулей оценки. 29) ISO/IEC 14764:2006 Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение. 30) ISO/IEC 16085:2006 Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками. 31) ISO/IEC 25000:2005 Технология программного обеспечения. Требования и оценка качества программного продукта. Руководство. 32) ISO/IEC 25001:2014 Программирование. Требования к качеству программного продукта и его оценка. Планирование и менеджмент. 33) ISO/IEC 25010:2011 Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения. 34) ISO/IEC 25012:2008 Программная инженерия – Требования к качеству и оценке программного обеспечения. Модель качества данных. 35) ISO/IEC 25020:2007 Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Измерительная эталонная модель и руководство. 36) ISO/IEC 25021:2012 Разработка систем и программ. Требования к качеству систем и программ и их оценка. Элементы показателей качества.

37) ISO/IEC 25030:2007 Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Требования к качеству. 38) ISO/IEC 25040:2011 Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Процесс оценки. 39) ISO/IEC 25041:2012 Разработка систем и программ. Требования и оценивание качества систем и программ. Руководство по оцениванию для разработчиков, покупателей и независимых оценщиков. 40) ISO/IEC 25045:2012 Разработка систем и программного обеспечения. Требования к качеству и оценка качества систем и программного обеспечения. Модуль оценки восстанавливаемости. 41) ISO/IEC/IEEE 16326:2009 Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление проектом. 42) Документация. поддержки жизненного 50.1.028-2001. цикла продукции. Информационные Методология технологии функционального моделирования 43) Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2006. – 544 с. 44) Гетьман, В.В. Методы и средства оценки качества автоматизированных систем управления для предприятий пищевой промышленности. Автореф. дис. к.т.н. – М.: Издательский комплекс МГУПП, 2007. – 25 с. 45) Дэвид А. Марка, Клемент МакГоуэн. Методология структурного анализа и проектирования SADT. М: Эксмо-Пресс, 2009. – 240 с. 46) Иванова Г. С., Ничушкина Т. Н., Пугачев Е. К. Объектно- ориентированное программирование: Учеб. для вузов/ Под. Ред. Г.С. Ивановой. — М.: Изд-во МГТУ им. Н.Э.Баумана, 2001. — 320 с.

47) Черемных С. В., Семенов И. О., Ручкин В. С. Моделирование и анализ систем. IDEF-технологии: практикум – М.: Финансы и статистика, 2005. – 192 с. 48) Электронный ресурс http://citforum.ru 49) Электронный ресурс http://proft.me 50) Электронный ресурс http://www.businessstudio.ru 51) Электронный ресурс http://www.interface.ru 52) Электронный ресурс http://www.oracle.com 53) ТБ.Корпорация. - Режим доступа: http://www.trisoft.ru/DesktopDefault.aspx?tabid=168&Mnu=2.164.168 54) Система Alfa - инструмент повышения производительности труда в условиях неопределенности. - Режим доступа: http://alfasystem.ru/ 55) КИС "Флагман". - Режим доступа: http://www.infosoft.ru/ 56) 1С:ERP Управление предприятием 2. - Режим доступа: http://v8.1c.ru/erp/ 57) ПАРУС: информационные системы управления. Решения для предприятий ОПК и бизнеса. - Режим доступа: http://www.parus.com/ 58) Галактика ERP. - Режим доступа: https://www.galaktika.ru/ 59) Описание "Omega Production". - Режим доступа: https://omegasoftware.ru/ 60) ERP-система "КОМПАС". - Режим доступа: http://www.compas.ru/ 61) Зыков С. В. Основы проектирования корпоративных систем / С. В. Зыков. - М.: Изд. дом Высшей школы экономики, 2012.- 600 с. 62) Ковалев С., Ковалев В. Секреты успешных предприятий: бизнеспроцессы и организационная структура / С. Ковалев, В. Ковалев. - М.: БИТЕК, 2012. – 498 с. 63) Саати Т. Принятие решений. Метод анализа иерархий / Т. Саати. - М., Радио и связь, 1993. – 278 с.

64) Управление корпоративными программами. Date Views 03.06.2017 www.market-journal.com/ukp/index.html. 65) Степанов Д.Ю., 2015. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика. Российский технологический журнал. Т.8. №3: 227-238. 66) Карева И.Н., 2014 Сравнительная характеристика ERP-систем SAP и Oracle. Молодой ученый. №20: 279-281. 67) Clash of the Titans 2012: An Independent Comparison of SAP, Oracle and Microsoft Dynamics. Date Views 07.06.2017 https://www.panorama- consulting.com/resource-center/clash-of-the-titans-sap-vs-oracle-vs-microsoftdynamics/. 68) Ковалев С. и Ковалев В., 2012. Секреты успешных предприятий: бизнес-процессы и организационная структура. М.: БИТЕК. Сс: 498. 69) Зыков С.В., 2012. Основы проектирования корпоративных систем. М.: Изд. дом Высшей школы экономики. Сс: 600. 70) Информационно-консалтинговый центр по электронной коммерции "ERP-системы (Enterprise Resources Planning - планирование ресурсов корпорации)". Date Views 07.06.2017 www.e-Commerce.ru. 71) Петровский А.Б., 2009. Теория принятия решений: Университетский учебник. М.: Академия. С. 400. 72) 75) Сравнительный анализ ERP систем. - Режим https://drive.google.com/file/d/0B0ZlC1_wa7XzRzVLNHlpdXlybDA/view доступа:

ПРИЛОЖЕНИЯ

Приложение А Российские и международные стандарты в области инженерии программных средств ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12270 (Процессы жизненного цикла программных средств)» [27]. В настоящем стандарте приведены рекомендации по практическому применению ГОСТ Р ИСО/МЭК 12207 в условиях реализации конкретных проектов создания программных средств. Опытное применение ГОСТ Р ИСО/МЭК 12207 в ряде организаций подтвердило необходимость выработки таких рекомендаций для однозначного понимания требований и норм, установленных в ГОСТ Р ИСО/МЭК 12207. Вместе с тем, ряд концептуальных положений и понятий, определённых в указанном стандарте, требуют дополнительного пояснения и более расширенной трактовки. В настоящем стандарте учтены обобщенные предложения по практическому применению ГОСТ Р ИСО/МЭК 12207, представленные Техническим комитетом по стандартизации ТК 22 "Информационные технологии". Настоящий стандарт может быть использован субъектами (лицами, организациями), желающими применить ГОСТ Р ИСО/МЭК 12207 при реализации договоров независимо от объема или сложности проекта, конкретной организацией для самоконтроля или работ по совершенствованию процессов жизненного цикла программных средств. В настоящем стандарте указано, как можно использовать ГОСТ Р ИСО/МЭК 12207 применительно к различным типам программных средств и какие процессы соответствуют каждому случаю. ГОСТ Р ИСО/МЭК ТО 12182-2010 «Классификация программных средств» [26]. Настоящий стандарт предназначен для специалистов в области программной инженерии, пользователей и разработчиков стандартов в данной области. Специалистам в области программной инженерии настоящий документ должен помочь в определении вида (типа) программного средства, для которого применимы конкретные стандарты программной инженерии, установлении критериев запланированного риска, определения соответствия применяемой модели жизненного цикла (ЖЦ) условиям реализации конкретного проекта, определении усилия, необходимых для конкретной фазы жизненного цикла, и соответствующего для нее инструментария. Пользователям и разработчикам стандартов настоящий документ должен помочь в определении подходов к классификации программных средств (ПС) и возможных вариантов стандартов для них на базе принятой схемы классификации и в последующем использовании данной схемы применительно к соответствующим ПС и стандартам программной инженерии. Настоящий стандарт определяет основы классификации ПС, схему классификации и содержит примеры применения соответствующих стандартов. ISO/IEC 14764:2006 «Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение» [29]. Из-за ограничений в стоимости и сроках разработки в ПС нередко возникают ошибки в процессе эксплуатации. Часто приходится модернизировать ПС, чтобы удовлетворить изменившимся требованиям пользователя. Сопровождение ПС может в стоимостном отношении составлять наибольшую часть ЖЦ. Настоящий стандарт детализирует процесс сопровождения, описанный в ISO/IEC 12207. В стандарте также установлены определения различных типов сопровождения, приведены рекомендации по планированию и выполнению процесса сопровождения, контролю и надзору за

ним, оценке и прекращению указанного процесса. ISO/IEC 16085:2006 «Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками» [30]. Настоящий стандарт устанавливает процесс менеджмента риска на различных стадиях ЖЦ ПС. Рекомендуется применять этот стандарт совместно с ISO/IEC 12207 и ISO/IEC 15288. Согласно этим стандартам менеджмент риска является одним из основных факторов, обеспечивающих успех организации при проектировании ПС. ISO/IEC/IEEE 16326:2009 «Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление проектом» [7]. Настоящий стандарт уточняет и дополняет ISO/IEC 12207-99 в части процесса управления проектом. Приведенные в настоящем стандарте рекомендации охватывают: ˗ общие рекомендации для управления программным проектом (УПП) по применению работ процесса управления в части их реализации в каждом из процессов; ˗ применимость УПП для каждого основного процесса; ˗ ключевые вопросы, относящиеся к УПП в целом; ˗ руководства РМВОК™ в части определения и описания общепризнанного подмножества из данного руководства. Общее признание означает, что описанные знания и опыт применены во многих проектах и единодушно признаны их значимость и полезность; ˗ ISO 10006 в части рекомендаций по реализации основных концепций, элементов и опыта применения систем качества, влияющих на практику управления проектом. ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения» [16]. Настоящий стандарт устанавливает термины и определения основных понятий в области автоматизированных систем (АС) и распространяется на АС, используемые в различных сферах деятельности (управление, исследования, проектирование и т.п., включая их сочетание), содержанием которых является переработка информации. Настоящий стандарт не распространяется на системы, предназначенные для обработки (изготовления, сборки, транспортирования) любых изделий, материалов или энергии. Термины, установленные настоящим стандартом, обязательны для применения во всех видах документации и литературы по автоматизированным системам, входящих в сферу работ по стандартизации и использующих результаты этих работ и рекомендуются для применения в научно-технической, справочной и учебной литературе. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [19]. Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т. п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях. Стандарт устанавливает стадии и этапы создания АС. Согласно ГОСТ 34.601-90, процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания АС выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС. Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяют в соответствующей документации организаций, участвующих в создании конкретных видов АС. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» [20]. Настоящий стандарт устанавливает состав, содержание, правила оформления документа «Техническое задание на создание системы». В стандарте присутствует образец первого и

последнего листа данного документа. ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию» [21]. Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения. Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определённых заказчиком типов ПО. Стандарт неприменим для аппаратных элементов программно-аппаратного обеспечения. В рамках конкретного проекта создания ПО должны быть установлены одна или несколько моделей жизненного цикла ПО, в соответствии с которыми выбирают необходимые работы для каждого процесса, определяют последовательность их выполнения, назначают ответственных за выполнение работ. ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» [24]. Настоящий стандарт устанавливает общие основы для описания жизненного цикла систем, созданных людьми, определяет детально структурированные процессы и соответствующую терминологию. Определённые совокупности этих процессов могут быть реализованы на любом иерархическом уровне структуры системы. Выбранные из этих совокупностей процессы могут быть использованы в течение всего жизненного цикла системы для реализации и управления отдельными стадиями жизненного цикла, что осуществляется путем вовлечения всех участников, заинтересованных в достижении конечной цели — удовлетворенности заказчиков. В настоящем стандарте представлены также процессы, которые поддерживают определение, контроль и совершенствование процессов жизненного цикла внутри организации или в рамках какого-либо проекта. Организации и проекты могут применять эти процессы при приобретении и поставке систем. Настоящий стандарт применим к полному жизненному циклу системы, включая замысел, разработку. производство, эксплуатацию и снятие с эксплуатации, а также приобретение и поставку систем, осуществляемых внутри или вне организации. Процессы жизненного цикла, представленные в стандарте, могут применяться однократно, многократно и рекурсивно по отношению к системе и её элементам. ГОСТ Р ИСО/МЭК 9126-93 «Характеристики качества и руководства по их применению» [25]. Настоящий стандарт определяет шесть характеристик, которые с минимальным дублированием описывают качество программного обеспечения. Данные характеристики образуют основу для дальнейшего уточнения и описания качества программного обеспечения. Руководства описывают использование характеристик качества для оценки качества программного обеспечения. Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402. Определения характеристик и соответствующая модель процесса оценки качества, приведенные в настоящем стандарте, применимы тогда, когда определены требования для программной продукции и оценивается её качество в процессе жизненного цикла. Эти характеристики могут применяться к любому виду программного обеспечения, включая программы ЭВМ и данные, входящие в программно-технические средства (встроенные программы). Настоящий стандарт предназначен для характеристик, связанных с приобретением, разработкой, эксплуатацией, поддержкой, сопровождением или проверкой программного обеспечения. Качество программного обеспечения может быть оценено следующими

характеристиками: 1. Функциональные возможности (Functionality). 2. Надежность (Reliability). 3. Практичность (Usability). 4. Эффективность (Efficiences). 5.Сопровождаемость (Maintainability). 6. Мобильность (Portability). ГОСТ Р ИСО/МЭК 12119-2000 «Информационная технология. Пакеты программ. Требования к качеству и тестирование» [22]. Модернизированный международный стандарт ISO/IEC 25051 – результат замены ISO/IEC 12119:1994. Настоящий стандарт применяется для пакетов программ, например, для текстовых процессоров, электронных таблиц, программ баз данных, графических пакетов, программ, реализующих технические и научные функции, и для сервисных программ (утилит). Стандарт устанавливает требования к пакетам программ (требования к их качеству); инструкции по испытанию пакета программ на соответствие его установленным требованиям (инструкции по тестированию, в частности по тестированию третьей стороной). ГОСТ 28195-89 «Оценка качества программных средств. Общие положения» [15]. Настоящий стандарт устанавливает общие положения по оценке качества ПС вычислительной техники, номенклатуру и применяемость показателей качества в зависимости от назначения и области применения. ГОСТ 28195–99 определяет оценку качества программного средства как совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого программного средства, определение значений этих показателей и сравнение их с базовыми значениями. В соответствии с данным стандартом оценка качества должна проводиться применительно ко всем работам жизненного цикла ПС при планировании показателей качества ПС, контроле качества в процессе разработки, проверке эффективности модификации ПС в процессе сопровождения. Стандартом ГОСТ 28195–99 рекомендован метод оценки обобщенного качества программного обеспечения, основанный на иерархической модели качества. ГОСТ 28195–99 предлагает следующую терминологию для показателей качества каждого уровня: ˗ уровень 1 - факторы качества; ˗ уровень 2 - критерии качества; ˗ уровень 3 - метрики; ˗ уровень 4 - оценочные элементы или единичные показатели. ГОСТ 34.320-96 «Информационные технологии. Концепции и терминология для концептуальной схемы и информационной базы» [17]. Настоящий стандарт устанавливает основные понятия и термины концептуальных схем и информационных баз, охватывающие разработку, описание и применение концептуальных схем и информационных баз, манипулирования информацией, а также описание и реализацию информационного процесса. Стандарт определяет роль концептуальной схемы. Положения, изложенные в стандарте, носят рекомендательный характер и могут использоваться для оценки систем управления базами данных (СУБД). Стандарт не описывает конкретные методы применения средств поддержки концептуальных схем. Описанные в стандарте языки концептуальных схем не следует рассматривать как стандартные. ГОСТ 34.321-96 «Информационные технологии. Эталонная модель управления данными» [18]. Настоящий стандарт устанавливает эталонную модель управления данными. Эталонная модель определяет общую терминологию и понятия, относящиеся к данным информационных систем. Такие понятия используются для определения услуг, предоставляемых

системами управления базами данных или системами словарей данных. Эталонная модель не рассматривает протоколы для управления данными. Область применения эталонной модели включает процессы, которые касаются управления постоянными данными и их взаимодействия с процессами, отличающимися от требований конкретной информационной системы, а также общие услуги управления данными, для определения, хранения, поиска, обновления, ввода, копирования, восстановления и передачи данных. ISO/IEC 14598-6:2001 «Информационные технологии. Оценка программного продукта. Часть 6. Документирование модулей оценки» [28]. Настоящий стандарт обеспечивает руководство для того, чтобы документировать модули оценки. Эти модули должны содержать спецификацию модели качества (т.е. характеристики, подхарактеристики, внутренние или внешние метрики), связанные с процессом оценки данных, информацию о запланированном применении модели и информации о её фактическом применении. Для каждой оценки должны быть отобраны соответствующие модули. Стандарт допускает, при необходимости, разработку новых модулей оценки. ISO/IEC 14598-6 может использоваться организациями, производящими новые модули оценки. Для эффективного управления потоками информации оценка должна быть структурирована в управляемые единицы. Информация, необходимая для проведения оценки одного или более аспектов качества должна быть собрана и укомплектована для последующего использования. Такой комплект называется модулем оценки. Модуль оценки включает полную информацию, необходимую для выполнения оценки определённого аспекта качественной характеристики и определённую технику оценки. Модуль включает информацию по начальным условиям и точности измерения. ISO/IEC 25000:2005 «Технология программного обеспечения. Требования и оценка качества программного продукта. Руководство» [31]. Международный стандарт, который представляет собой краткий обзор и руководство для применения серии разработанных стандартов в области оценки качества ПС. Разрабатываемая серия основана на действующих международных стандартах ISO/IEC 9126, ISO/IEC 14598 и ряда других стандартов в области оценивания ПС. Стандарты серии ISO/IEC 25000 имеют своей целью единое обобщение, разрешение противоречий, нестыковок и ссылок международных стандартов в этой области. Стандарт устанавливает следующую классификацию стандартов в этой области: ˗ ISO/IEC 2500N: Менеджмент качества ПС. Содержит краткий обзор и руководства для применения серии разработанных стандартов в области оценки качества ПС. ˗ ISO/IEC 2501N: Модели качества ПС. ˗ ISO/IEC 2502N: Модели измерения качества ПС ˗ ISO/IEC 2503N: Требования к качеству ПС ˗ ISO/IEC 2504N: Оценка качества ПС ˗ ISO/IEC 25050-25099: зарезервированы для международных стандартов и технических отчетов в области качества продукции. ISO/IEC 25001:2014 «Программирование. Требования к качеству программного продукта и его оценка. Планирование и менеджмент» [32]. Международный стандарт, представляющий сведения о планировании и управлении требований, связанных с качеством программного средства, а также требований, связанных с его оценкой. Стандарт направлен на уточнение требований, которые должны быть определены организацией для того, чтобы обеспечить успех указанием требований к качеству и выполнению оценки. Настоящий стандарт соответствует техническим процессам, определённым в ISO/IEC 15288, и связанных с анализом требований и определением качества. ISO/IEC 25010:2011 «Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения» [33]. Международный стандарт, определяющий

модели качества продукта и качества в использовании. Обе модели применяются как для программных продуктов, так и для компьютерных систем. Они позволяют обеспечить согласованную терминологию для определения, измерения и оценки системы и качества программного продукта. Они также предоставляют набор характеристик качества, которые следует использовать при формировании требований к ПС и сверять эти требования с имеющимся результатом на конкретном этапе ЖЦ ПС. Модель качества продукта состоит из 8 характеристик (функциональные возможности, надежность, эффективность производительности, удобство в использовании, безопасность, совместимость, ремонтопригодность, переносимость), которые далее разделены на подхарактеристики. В неё входят статические свойства ПС и динамические свойства в компьютерной системе. Модель качества в использовании состоит из 5 характеристик, разделенных далее на подхарактеристики. Модель связана с результатом взаимодействия, когда продукт используется по назначению. ISO/IEC 25012:2008 «Программная инженерия – Требования к качеству и оценке программного обеспечения. Модель качества данных» [34]. Международный стандарт, определяющий общую модель качества данных для данных, хранимых в структурированной форме в компьютерной системе. Стандарт может быть использован для установления требований качества данных, определить действия, направленные на повышение качества данных или планирование и проведение их оценки. Модель может быть использована для определения и оценки качества данных в соответствии с требованиями в процессах приобретения, производства и интеграции; для определения критериев качества данных при реинжиниринге, оценке и совершенствовании данных; для оценки данных в соответствии с требованиями и законодательством. Стандарт классифицирует атрибуты качества на 15 характеристик, которые можно разделить на 2 группы – зависящие и не зависящие от системы. Характеристики данных имеют различный приоритет для разных заинтересованных сторон. Стандарт применяется совместно с ISO/IEC 9126. ISO/IEC 25020:2007 «Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Измерительная эталонная модель и руководство» [35]. Международный стандарт, устанавливающий требования к формированию метрики качества, которая строится на основе модели, определённой в стандартах ISO/IEC 2501N. Он также содержит информативные приложения, рассматривая следующие темы: выбор характеристик качества ПС и атрибутов качества, демонстрируя измерения оценок надежности и примерный формат для документирования мер качества ПС. Требования данного стандарта служат основанием для использования стандартов ISO/IEC 25030 и ISO/IEC 25040. ISO/IEC 25021:2012 «Разработка систем и программ. Требования к качеству систем и программ и их оценка. Элементы показателей качества» [36]. Международный стандарт, определяющий набор элементов показателей качества, которые используются на протяжении всего ЖЦ ПС для целей определения требований и оценки соответствия ПС этим требованиям качества. Настоящий стандарт содержит ISO/IEC TR 9126 2-4 и серию стандартов ISO/IEC 25000. Требования данного стандарта служат основанием для использования стандартов ISO/IEC 25030 и ISO/IEC 25040. ISO/IEC 25030:2007 «Разработка программного обеспечения. Требования к качеству и оценка качества программного продукта. Требования к качеству» [37]. Международный стандарт, который устанавливает требования и рекомендации для спецификации требований к ПС для покупателей и поставщиков. Спецификация требований фокусируется на требованиях к качеству ПС, но принимает точку зрения ПС в составе системы для покупателя (заказчика). Требования к ПС необходимы для: составления спецификации (включая конкретные соглашения и тендер), планирования (в т.ч. технико-экономическое обоснование), развития (в т.ч. раннее выявление потенциальных проблем в процессе разработки), оценивания (включая объективную

оценку и сертификацию качества ПС). Данный стандарт способствует улучшению формирования перечня требований и рекомендаций к ПС на основе стандарта ISO/IEC 9126. ISO/IEC 25040:2011 «Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Процесс оценки» [38]. Международный стандарт (результат замены ISO/IEC 14598-1:1999), содержащий общие требования к качеству ПС, отражаемые в спецификации, а также основные определения в области требований к качеству ПС и их оценки. Содержит описание процесса оценки качества ПС и устанавливает требования к этому процессу. Процесс оценки ПС очень важен на различных этапах ЖЦ ПС. Перечень действий процесса применим для измерения внутреннего, внешнего качества и качества в использовании ПС и также может быть использован на этапе квалификационного тестирования. Оценку ПС могут проводить покупатель, организацияразработчик или независимая сторона. Эти 3 различных подхода представлены в приложении. ISO/IEC 25041:2012 «Разработка систем и программ. Требования и оценивание качества систем и программ. Руководство по оцениванию для разработчиков, покупателей и независимых оценщиков» [39]. Международный стандарт (результат замены ISO/IEC 14598 3-5:1998-2000), определяющий структуру и содержание документации, которая будет использоваться при формирования модулей оценки. Эти оценочные модули содержат спецификацию модели качества (т.е. характеристики, подхарактеристики и атрибуты внешнего, внутреннего качества и качества в использовании), соответствующие данные и информацию о планируемом применении модели. Для каждого конкретного случая выбирается свой модуль оценки, но в некоторых случаях может возникнуть необходимость в разработке нового модуля. Руководство по разработке нового модуля можно найти в настоящем стандарте. ISO/IEC 25045:2012 «Разработка систем и программного обеспечения. Требования к качеству и оценка качества систем и программного обеспечения. Модуль оценки восстанавливаемости» [40]. Международный стандарт, описывающий модуль для оценки характеристик восстановления. Он определяет внешние атрибуты качества для отказоустойчивости и восстанавливаемости для ПС. При измерении атрибутов, один или несколько ПС в процессе выполнения некоторых действий подвергают серии нарушений – например, оперативному закрытию процесса операционной системы или значительному увеличению пользователей в системе.

Приложение Б Основные виды моделей методологии UML В настоящее время методология UML поддерживает более 10 основных видов моделей для описания бизнес-процессов предприятия: o Диаграммы, описывающие поведение системы: a. Диаграммы состояний (State diagrams): включает в себя состояния, переходы, события и виды действий. b. Диаграммы прецедентов: описание бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые. c. Диаграммы деятельностей (Activity diagrams): частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. d. Диаграммы классов: позволяют создавать логическое представление системы, на основе которого создается исходный код описанных классов. e. Диаграммы взаимодействия (Collaboration diagrams): связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. f. Диаграммы последовательностей (Sequence diagrams): частный случай диаграммы взаимодействия, отражают временную упорядоченность сообщений. o Диаграммы, описывающие физическую реализацию системы: a. Диаграммы компонент (Component diagrams): организация совокупности компонентов и существующие между ними зависимости; b. Диаграммы развертывания (Deployment diagrams): обрабатывающих узлов системы и размещенных в них компонентов. конфигурация

Приложение В Классификация основных методов моделирования, используемых при анализе, проектировании и реализации КИС Функциональные модели (метод структурного анализа и проектирования SADT; функциональная модель IDEF0) – модели, ориентированные на функции, и представляющие собой структурированное изображение функций системы или среды, информации и объектов, связывающих эти функции [2]. Функциональная модель – это искусственный объект, представляющий собой виртуальный образ системы и ее компонентов, в виде функциональной структуры объекта (совокупности диаграмм), отображающих производимые им действия и связи между этими действиями. Функциональные модели применяют при анализе требований к системе, при проектировании новой системы, а также для анализа бизнес-процессов при принятии решений о реконструкции (реинжиниринге) системы управления. Модели потоков данных (диаграмма потоков данных DFD; диаграмма потоков управления CSD; модель потоков данных ORACLE; модель управления BCM) – модели графического структурного анализа, описывающие внешние по отношению к системе источники и приемники данных, процессы, потоки данных и хранилища данных, к которым осуществляется доступ [9]. Модель системы представляет иерархию диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) передают и/или принимают информационные потоки, переносящие информацию к/от системы; процессы отображают выполняемые системой функции; хранилища данных моделируют отдельные объекты (сущности, таблицы) базы данных; потоки данных описывают информационные взаимосвязи между процессами, а также операции чтения/записи информации отдельными процессами в таблицы базы данных. Модели потоков данных используются на этапе проектирования систем управления. Модели бизнес-процессов (диаграмма потоков работ WFD; диаграмма потоков работ IDEF3; диаграмма окружения процесса FAD; диаграмма цепочки добавленной стоимости VACD; матрица выбора процессов PSM; расширенная цепочка процессов, управляемая событиями eEPC; модель бизнес-процессов «Swimmer Lanes»; модель бизнес-процессов BPM) – модели видов деятельности организации, включающие описание деловых объектов (процессов, бизнес-функций, потоков работ, подразделений, должностей, ресурсов, ролей, информационных систем, носителей информации и т. д.) и указание связей между ними. Модель показывает взаимосвязи между функциями и последовательность их выполнения, а также материальные и информационные потоки, имеющие место при функционировании организации. Отметим, что модели бизнес-процессов являются динамическими моделями, т.к. описывают последовательность (и иногда условия) выполнения бизнес-процессов, в отличие от остальных групп структурных моделей, описывающих исключительно статику системы. Модели бизнес-процессов используются при описании и реинжиниринге видов деятельности компании, на этапах анализа и определения требований к системе, а также при внедрении систем управления на предприятиях. Событийные модели (диаграмма переходов состояний STD; модель динамического моделирования развития систем IDEF2) – это модели, в которых функционирование системы представляется в виде набора состояний объектов и перечня событий (функций) системы. События происходят в определенные моменты времени и знаменуют собой изменение

состояний отдельных объектов системы. Событийные модели используются на этапах анализа требований и проектирования поведения динамических объектов (элементов) системы. Информационные модели (диаграмма сущность-связь ERD; диаграмма структур данных DSD; информационная модель IDEF1X; ER-модель ORACLE; модель Чена; информационная модель ERM) – модели данных конкретной предметной области или ее объектов, они отображают структуру данных проектируемых систем. Информационная модель описывает сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Информационные модели разрабатывается на этапах проектирования и реинжиниринга систем управления. Иерархические модели (диаграмма архитектуры системы SAD; диаграмма целей OD; дерево продуктов и услуг PST; дерево функций FT; модель организационной структуры ORG; диаграмма типов информационных систем ASTD; модель иерархии функций ORACLE; модель метаструктуры предприятия ESM; модель функций BFM; организационная модель BOM) – модели представления системы в виде древовидной (иерархической) структуры, состоящей из объектов различных уровней. Иерархическая модель описывает отношения между главными (родительскими) и подчиненными (дочерними) объектами в системе. С помощью иерархических моделей для организаций и подразделений описывают организационные структуры, деревья целей, выполняемых функций, выпускаемых продуктов и оказываемых услуг и т.д. Иерархические модели используют в управленческом консалтинге при реинжириринге систем управления. Объектные статические модели (диаграмма классов; диаграмма компонентов; диаграмма композитной структуры; диаграмма развертывания; диаграмма объектов; диаграмма автомата; диаграмма зависимостей между объектами; диаграмма поведения объектов; диаграмма взаимодействия объектов; диаграмма инстанций) – модели, которые не отражают динамику системы, т.е. изменения, происходящие с течением времени [10]. Статические модели описывают основные концепции предметной области системы, а также внутренние концепции элементов системы, необходимые для ее реализации. Основными статическими моделями на этапах объектно-ориентированного анализа и проектирования систем служат диаграммы, представляющие классы, объекты или компоненты системы и их отношений между собой: ассоциации, обобщения и различные виды зависимостей. Объектные динамические модели (диаграмма деятельности; диаграмма вариантов использования; диаграмма последовательности; диаграмма синхронизации; диаграмма событий; диаграмма переходов состояний) – модели, описывающие изменение (динамику) функций (параметров, состояний объектов) системы. Объектные динамические модели используются на этапах объектно-ориентированного анализа и проектирования и отображают процесс изменения состояний реальной или проектируемой системы, показывают различия между состояниями объектов, последовательность смены состояний и последовательность выполнения функций системы в течение времени.

Приложение Г Задание на проведение патентных исследований №1 от 01.06.17

Приложение Д ОТЧЁТ О ПОИСКЕ № 1 В.1 Поиск проведен в соответствии с заданием Проректора по научной и инновационной деятельности № 1 от 01.06.2017 и Регламентом поиска № 1 от 01.06.2017 В.2 Этап работы 2 В.3 Начало поиска 01 июля 2017 г. Окончание поиска 15 августа 2017 г. В.4 Сведения о выполнении регламента поиска Поиск выполнен полностью В.5 Предложения по дальнейшему проведению поиска и патентных исследований Отсутствуют В.6 Материалы, отобранные для последующего анализа Таблица В.6.1 – Патентная документация Предмет поиска Страна выдачи, вид и Заявитель Название изобретения (полезной Сведения о (объект номер охранного (патентообладатель), модели, образца), товарный знак действии исследования, его документа. страна. Номер заявки, охранного составные части) Классификационный дата приоритета, документа индекс конвенционный или причина приоритет, дата его публикации* аннулирован ия (только для анализа патентной чистоты) 1 2 3 4 5 RU2005130349 Майкрософт «Поддержка графических  Компонент Корпорейшн (US) представлений, основанная на разработки пользовательских настройках» схемы RU2010100807 Майкрософт «Поддержка графических данных Корпорейшн (US) представлений, основанная на основных пользовательских настройках» данных и моделей RU2008139610 Майкрософт «Основанное на разрешениях бизнесКорпорейшн (US) преобразование процессов пользовательского интерфейса». RU 2004118670/09  Компонент управлени RU2014126210/08 я интеграци онным взаимодей ствием RU2005138784/09  Компонент Майкрософт «Инфраструктура для создания Корпорэйшн (US) модульных Web-приложений» Гуанчжоу юсивэб «Метод просмотра web компьютер тэкнолоджи -страниц, платформа web-app, КО., ЛТД (CN) метод и устройство для исполнения javascript для мобильных терминалов» Майкрософт «Многоуровневый графический корпорейшн (US) пользовательский интерфейс»

формирова RU 2012125441/08 ния централиз ованной нормативн RU2012145856/08 осправочно й информац US20120059917 ии  Компонент RU 2016122010 формирова ния хранилища ретроспект RU2009112044/07 ивных (многолетн их) данных и RU2005114658/09 документо в Общество ограниченной ответственностью "ТатАСУ" (RU) с «Унифицированная система управления информационными потоками предприятия» Майкрософт «Интеграция клиентского текнолоджи приложения и web страницы» лайсенсинг, ЭлЭлСи (US) Dawson Christopher «Software license management J.International Business within a cloud computing Machines Corporation environment». Общество с «Информационная система ограниченной автоматизированной подготовки ответственностью статистической отчетности» "ТатАСУ" (RU) Савант системс ЛЛС «Среда программирования и (US) управление метаданными для программируемого мультимедийного контроллера» Майкрософт «Способ и система Корпорэйшн (US) согласования схем баз данных web»  Компонент RU2005114657/09 создания форм отчетов и RU2004136278/09 форм представле ний многомерн RU2006102136/08 ых данных Майкрософт корпорейшн (US) RU2008137598/  Компонент общесисте RU2011133680 много администр ирования RU2390834 09 Эндо Хироюки «Система предоставления (JP) данных, сервер и программа» Майкрософт «Отображение множества Корпорейшн (US) областей заголовков строк и столбцов в сводной таблице». Майкрософт «Способ и устройство для Корпорейшн (US) просмотра и взаимодействия с электронной таблицей из веббраузера». Хансен Игорь (GB) «Система баз данных персональных данных и способ управления доступом к базам данных персональных данных». Нокиа Корпорейшн «Система для web – (FI) публикации» RU2003124659 RU2007148280/09 RU2014101039/08 «Способ и система для индексирования и поиска в базах данных» Интернэшнл бизнес «Хранилище данных для машинз корпорейшн основанной на знаниях системы (US) извлечения информации из данных» Майкрософт «Автоматизированная корпорейшн (US) организация данных» Общество ограниченной ответственностью "ТатАСУ"(RU) с «Система создания отчетных форм»

RU2014104096 RU 85248 RU2012122760 RU2012122803 RU2571609 RU2014102164 RU2507577 RU2004129895 WO/2007/146941 RU2009126832 (RU) RU2007110938/09 Нек Корпорейшн (JP) «Устройство управления лицензиями, система для управления лицензиями, способ управления лицензиями и программа для управления лицензиями». ЗАО "Лаборатория «Система управления Касперского" (RU) лицензионными ключами с изменяемым сроком действия» Рикох Компани, ЛТД. «Система управления (JP) лицензиями, устройство управления продажами и устройство управления лицензиями». Рикох Компани, ЛТД. «Система управления (JP) лицензиями, устройство управления лицензиями и компьютерно-читаемый носитель записи, на котором имеется программа управления лицензиями». Нек Корпорейшн (JP) «Устройство управления лицензиями, система для управления лицензиями, способ управления лицензиями и программа для управления лицензиями». Нек Корпорейшн (JP) «Устройство администрирования лицензий и способ администрирования лицензий» Рикох Компани, ЛТД. «Система управления (JP) лицензиями, устройство управления лицензиями и компьютерно-читаемый носитель записи, на котором имеется программа управления лицензиями» Майкрософт «Система управления Корпорейшн (US) цифровыми правами» Insight Direct USA, «Version compliance system». INC. [US] "Информационная «Способ управления внедренческая идентификацией пользователей компания" (ЗАО информационных ресурсов не "ИВК") однородной вычислительной сети». Открытое акционерное «Распределенная система общество "Московский контроля и управления» завод тепловой автоматики" (RU)

RU2009144604/08, Государственное «Способ управления доступом к образовательное информационным ресурсам учреждение высшего компьютерных сетей различных профессионального уровней конфиденциальности и образования Академия устройство, его реализующее» Федеральной службы охраны Российской Федерации (Академия ФСО России) (RU) Таблица В.6.2 – Научно-техническая, конъюнктурная, нормативная документация и материалы государственной регистрации (отчеты о научно-исследовательских работах) Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4  Компо RU2013618212 Унифицированная среда Олейник Павел Петрович (RU) ФИПС, 2013 быстрой разработки нент корпоративных разраб информационных систем отки SharpArchitect RAD схемы Studio данны RU2013619548 Платформа быстрой Общество с ограниченной ФИПС, 2013 х разработки веб- ответственностью «Октоника» основ приложений Колибри (RU) ных данны RU Программа Web-сервиса Федеральное государственное ФИПС, 2015 х и 2015613394 моделирования процессов бюджетное образовательное модел учреждение высшего ей профессионального бизнес образования «Кубанский государственный университет» проце (ФГБОУ ВПО «КубГУ») (RU) ссов RU Платформа для Общество с ограниченной ФИПС, 2014 2014619466 разработки ответственностью «НМТ-Новые распределенных Мобильные Технологии» (RU)  Компо мобильных сервисов Ubiq нент Mobile управ ления RU Система для разработки Общество с ограниченной ФИПС, 2015 интегр 2015614327 кросс-платформенных ответственностью «НМТ-Новые ацион мобильных приложений Мобильные Технологии» (RU) ным Ubiq Mobile взаим RU M VisiData - Открытое акционерное ФИПС, 2016 одейст 2016660196 модернизированная общество «АйСиЭл - КПО ВС» вием платформа быстрой (RU) разработки прикладных  Компо информационных систем (М ВизиДата) нент форми RU Программный комплекс Общество с ограниченной ФИПС, 2016 рован 2016660656 для быстрой разработки ответственностью «М-Софтер»

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 ия мобильных систем (RU) центр онлайн заказа ализов RU2017611654 «Библиотека быстрой Черников Дмитрий ФИПС, 2017 анной разработки бизнес Александрович (RU) норма приложений» тивно- RU Программа генерации ФЕДЕРАЛЬНОЕ ФИПС, 2016 справо 2016618340 исходного кода ГОСУДАРСТВЕННОЕ чной текстового редактора БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ инфор специализированного НАУКИ ИНСТИТУТ мации языка для СИСТЕМНОГО интегрированной среды ПРОГРАММИРОВАНИЯ  Компо разработки Eclipse на РОССИЙСКОЙ АКАДЕМИИ нент основе описания НАУК (RU) форми грамматики рован специализированного ия языка храни RU Аналитическая система Закрытое Акционерное ФИПС, 2015 лища 2015662161 «ПрограмБанк.БизнесАна Общество «ПрограмБанк» (RU) ретрос лиз» пекти RU Платформа «Эскулап» Масленников Юрий ФИПС, 2013 вных 2013614447 Владимирович (RU) (много RU «Flexbby» Общество с ограниченной ФИПС, 2014 летни 2014611578 ответственностью «Флексби х) Солюшнс» (RU) данны RU «ЕАЕ.ВАР» Общество с ограниченной ФИПС, 2013 х и 2013618028 ответственностью «ЕАЕдокум Консалт» (RU) ентов RU Tebico Business Общество с ограниченной ФИПС, 2014 2014610761 Orchestration ответственностью «Технологии  Компо бизнес-коммуникаций» (RU) нент RU «Платформа N2О» Общество с ограниченной ФИПС, 2014 создан 2014660448 ответственностью ия «Корпоративные форм информационные рутины отчето (КИР)» (RU) в и RU Luxoft Horizon Люксофт Глобал Оперейшенс ФИПС, 2014 форм 2014618089 Visualization Framework ГмбХ (Luxoft Global Operations предст GmbH) (CH) авлен RU «Web-платформа быстрой Общество с ограниченной ФИПС, 2013 ий 2013619162 разработки бизнес- ответственностью «Диджитал много приложений Апрентис» Зон» (RU) мерны RU «Платформа Единой Публичное акционерное ФИПС, 2017 х 2017617419 Фронтальной Системы, общество «Сбербанк России» данны версия 6» (RU)

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 х RU «InMeta» Закрытое акционерное ФИПС, 2016 2016611111 общество «Центр системных исследований «Интегро» (RU)  Компо ОТР.ОПОРА:СТУДИЯ Общество с ограниченной ФИПС, 2016 нент RU 2016615480 ответственностью общес "Организационноистем технологические решения 2000" ного (RU) админ истри RU Медтера Общество с ограниченной ФИПС, 2016 рован 2016617431 ответственностью ия «Медлайнсофт» (RU) RU Инструментальное Общество с ограниченной ФИПС, 2016 2016611752 программное средство ответственностью «ДИАВЕР» автоматизации (RU) разработки Webприложений «KOMETAJS» RU RVML editor Федеральное государственное ФИПС, 2017 2017618446 бюджетное учреждение науки Институт динамики систем и теории управления имени В.М. Матросова Сибирского отделения Российской академии наук (ИДСТУ СО РАН) (RU) RU Web-ориентированный Федеральное государственное ФИПС, 2017 2017618430 редактор моделей бюджетное учреждение науки трансформаций Институт динамики систем и теории управления имени В.М. Матросова Сибирского отделения Российской академии наук (ИДСТУ СО РАН) (RU) RU Imin Web Routing v1.0 Федеральное государственное ФИПС, 2016 2016662179 бюджетное учреждение науки Институт минералогии Уральского отделения Российской академии наук (RU) RU Технологическая Общество с ограниченной ФИПС, 2016 2016618882 платформа «РАМЗЭС 2.0» ответственностью «ФИНАТЕК» (RU) RU «Интеграционная Общество с ограниченной ФИПС, 2015 2015660754 программноответственностью «Инфокомтехнологическая С» (RU) платформа Uniplatform» RU «Среда Интегрированной Илюхина Мария Анатольевна ФИПС, 2014 2014610073 Разработки (RU) Информационных

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 Управленческих Систем» («СИРИУС») RU Rand Model Designer 7 2014619722 RU 2013615588 RU 2016614704 RU 2017612213 RU 2016660266 RU 2013614485 RU 2017611262 RU 2017612671 RU 2015614075 RU 2016663527 Колесов Юрий Борисович (RU) ФИПС, 2014 Сениченков Юрий Борисович (RU) Инихов Дмитрий Борисович (RU) Исаков Андрей Алексеевич (RU) Среда разработки Кручаненко Александр ФИПС, 2013 мобильных и Юрьевич (RU) мультиплатформенных приложений Платформа разработки Закрытое акционерное ФИПС, 2016 Xafari общество «Корпорация Галактика» (RU) «Платформа разработки Общество с ограниченной ФИПС, 2017 корпоративных ответственностью «АйПиДжи» приложений «Интеллект- (RU) 8»» Платформа КУРС Общество с ограниченной ФИПС, 2016 ответственностью «КУРС-ИТ» (RU) «Облачная платформа Общество с ограниченной ФИПС, 2013 Cloud2» ответственностью «КлоуДуо» (RU) «Программная платформа Общество с ограниченной ФИПС, 2017 для разработки ответственностью «АСТЕХ» приложений» («ADK (RU) Platform») Программа для ЭВМ Общество с ограниченной ФИПС, 2017 «Технологическая ответственностью «Сумма платформа разработки технологий» (RU) производственных информационных систем. Версия С#». («СТ: Технологическая платформа. Версия С#») Платформа «OPTI» для Общество с ограниченной ФИПС, 2015 создания WEB- ответственностью «АТБ Групп» приложений (RU) «Программа создания Общество с ограниченной ФИПС, 2016 базовой платформы для ответственностью «ЮЭНСИ разработки и МЕДИА» (ООО «ЮЭНСИ усовершенствования МЕДИА») (RU) программного

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 обеспечения технологии дополненной реальности» (1R-PLATFORM) RU «Вектор» Общество с ограниченной ФИПС, 2015 2015618847 ответственностью «СибирьСофтПроект» (RU) RU $mol Закрытое акционерное ФИПС, 2017 2017611605 общество "САПРАН Групп" (RU) RU «Облачная платформа для Общество с ограниченной ФИПС, 2013 2013619152 разработки ответственностью универсальных бизнес «Софтлоджик Рус» (RU) приложений» RU Автоматизированная Сарасеко Максим Васильевич ФИПС, 2016 2016619668 программная платформа (BY) разработки прикладных Дикарев Денис Евгеньевич (RU) приложений Курбатов Эдуард Алексеевич «МЕТАЛАБ» (RU) RU Платформа для Закрытое научно- ФИПС, 2015 2015617785 разработки бизнес- производственное акционерное приложений «Мелисса» общество «Отделение проблем военной экономики и финансов» (RU) RU iSimpleCore Общество с ограниченной ФИПС, 2016 2016660121 ответственностью «АйСимплЛаб» (RU) RU Платформа Х360. версия Общество с ограниченной ФИПС, 2016 2016614285 1.21 ответственностью «АйДиЭс» (RU) RU Платформа для Общество с ограниченной ФИПС, 2015 2015662387 разработки бизнес- ответственностью "Лаборатория приложений Pl.Platform Свободных Решений" (RU) (Pl.Platform) RU Ядро промышленной Общество с ограниченной ФИПС, 2014 2014660814 платформы «СМАРТ» ответственностью (Ядро «СМАРТ») «Кейсистемс» (RU) RU ERP-Платформа Кольцов Евгений Алексеевич ФИПС, 2017 2017610911 (RU) RU «GL Enterprise Platform» 2017615021 Общество с ограниченной ФИПС, 2017 ответственностью «Грейс Лоджик» (RU) RU CROC Java eXtendable Общество с ограниченной ФИПС, 2017 2017618147 FrameWork ответственностью «КРОК Регион» (RU)

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 RU CROC Application Общество с ограниченной ФИПС, 2017 2017618476 Framework for .NET ответственностью «КРОК Регион» RU «Техносфера» Общество с ограниченной ФИПС, 2015 2015614585 («Technosphere») ответственностью «ТехноСофт» RU «Radar Jet» 2016662076 Общество с ограниченной ФИПС, 2016 ответственностью «РАДАР ИАС» (RU) RU Платформа для создания Коломоец Евгений (RU) ФИПС, 2017 2017619097 веб-приложений «ISWT» RU Платформа СМАРТ 2017616076 Онопин (RU) Михаил Викторович ФИПС, 2017 RU «Программный комплекс Общество с ограниченной ФИПС, 2016 2016660186 «КСК.Платформа» ответственностью «КСК (КСК.Платформа) ТЕХНОЛОГИИ» (RU) RU Инструментальная Общество с ограниченной ФИПС, 2016 2016661120 платформа автоматизации ответственностью «Компания бизнес-процессов Информационных Технологий» eplat4m. (RU) RU Программная платформа Общество с ограниченной ФИПС, 2016 2016616318 Distributed Data ответственностью «Центр Manipulation (DDM) для разработок информационных создания систем с технологий «Аргонавт» (RU) распределенными базами данных RU Платформа для Общество с ограниченной ФИПС, 2017 2017612786 модульной разработки ответственностью "ФИГАРУ веб-сайтов и веб- ГРУПП" (RU) ориентированного программного обеспечения (Фигару Энжин) RU Workflow Forms Общество с ограниченной ФИПС, 2015 2015611043 ответственностью «Программные системы» (RU) RU «ПрограммноОбщество с ограниченной ФИПС, 2015 2015614418 технологическая ответственностью «КВАРТА платформа «Scala» ВК» (RU) RU Программная платформа Закрытое акционерное ФИПС, 2013 2013660455 Jigsaw общество "Информатика Сибири" (RU) RU «ГРОСС. Платформа» Общество с ограниченной ФИПС, 2013 2013615244 ответственностью «Объединенный

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 процессинговый центр» (RU) RU ПП "Платформа Eludia" 2016619204 RU 2014619651 RU 2016618070 RU 2015619112 RU 2016617038 RU 2015615734 RU 2015619451 RU 2016618575 RU 2015618526 RU 2015618095 RU 2016660196 Общество с ограниченной ФИПС, 2016 ответственностью "Фастек" (RU) Программная платформа Общество с ограниченной ФИПС, 2014 SoftNeva.Core для ответственностью "НТЦ разработки портальных и "Программные решения" (RU) системных клиентсерверных решений «Платформа Общество с ограниченной ФИПС, 2016 программных решений» ответственностью «ЛикоФинанс» (RU) «Шерп. Студия 2.0» Общество с ограниченной ФИПС, 2015 ответственностью «Шерп Софт» (RU) АИС «Интеграционно- Общество с ограниченной ФИПС, 2016 аналитическая ответственностью «Открытый платформа» код» (RU) Интегрированная среда Российская Федерация, от ФИПС, 2015 разработки приложений имени которой выступает Министерство промышленности и торговли Российской Федерации (Минпромторг России) (RU) Автоматизированная Российская Федерация, от ФИПС, 2015 информационная система имени которой выступает «Единая проектная Министерство экономического среда» развития Российской Федерации (RU) Comindware Business Общество с ограниченной ФИПС, 2016 Application Platform ответственностью «Колловэар» (RU) ЛОГИКА BPMs Общество с ограниченной ФИПС, 2015 ответственностью «Логика ВРМ» (RU) Среда разработки Антонов Антон Анатольевич ФИПС, 2015 алгоритмов TMachine (RU) Алутин Петр Петрович (RU) M VisiData - Открытое акционерное ФИПС, 2016 модернизированная общество «АйСиЭл - КПО ВС» платформа быстрой (RU) разработки прикладных информационных систем (М ВизиДата)

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 WO2017111880 DECLARATIVE INTEL CORP [US]; YANG ФИПС, 2017 (A1) MACHINE-TOSHAO-WEN; CHEN YENMACHINE KUANG [US]; KOO NYUK APPLICATION KIN [MY] + PROGRAMMING WO2017095290 METHOD AND TELEFONAKTIEBOLAGET LM ФИПС, 2017 (A1) APPARATUS FOR ERICSSON (PUBL) [SE] DECLARATIVE ACTION ORCHESTRATION US2017139979 DECLARATIVE AND NETCRACKER TECH CORP ФИПС, 2017 (A1) UNIFIED DATA [US] + TRANSITION US2017090875 DECLARATIVE DESIGN- SAP PORTALS ISRAEL LTD ФИПС, 2017 (A1) TIME EXPERIENCE [IL] + PLATFORM FOR CODE GENERATION US2017017469 Declarative Software ENTPR LLC [US] ФИПС, 2017 (A1) Application Meta-Model and System for SelfModification US9507882 (B1) Declarative language AMAZON TECH INC [US] ФИПС, 2013 dynamic web platform US2017192762 DECLARATIVE MICROSOFT TECHNOLOGY ФИПС, 2017 (A1) PROGRAMMING LICENSING LLC [US] MODEL WITH A NATIVE PROGRAMMING LANGUAGE US2017242667 SOFTWARE HELIX DATA SOLUTIONS ФИПС, 2017 (A1) DEVELOPMENT TOOL LLC [US] USING A WORKFLOW PATTERN THAT DESCRIBES SOFTWARE APPLICATIONS US2016299748 DECLARATIVE ORACLE INT CORP [US] ФИПС, 2016 (A1) PROGRAM ENGINE FOR LARGE-SCALE PROGRAM ANALYSIS US2016092474 DECLARATIVE ORACLE INT CORP [US] ФИПС, 2016 (A1) LANGUAGE AND VISUALIZATION SYSTEM FOR RECOMMENDED DATA TRANSFORMATIONS AND REPAIRS

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 US2016034478 INCREMENTAL IBM [US] ФИПС, 2016 (A1) INFORMATION INTEGRATION USING A DECLARATIVE FRAMEWORK US9239773 (B1) Method and system for CADENCE DESIGN SYSTEMS ФИПС, 2015 debugging a program that INC [US] includes declarative code and procedural code US2015261861 Framework for Composing FUTUREWEI TECHNOLOGIES ФИПС, 2015 (A1) Real-Time Media Using a INC [US] Declarative Mark-Up Language US2015242189 DECLARATIVE IBM [US] ФИПС, 2015 (A1) CONFIGURATION AND EXECUTION OF CARD CONTENT MANAGEMENT OPERATIONS FOR TRUSTED SERVICE MANAGER US2017262279 METHODS AND WIPRO LTD [IN] ФИПС, 2017 (A1) SYSTEMS FOR DEVELOPING USER CUSTOMIZABLE WEB APPLICATION FRAMEWORKS US2017262422 FRAMEWORK FOR SAP SE [DE] ФИПС, 2017 (A1) CLASSIFYING FORMS AND PROCESSING FORM DATA KR2017009688 RESTful RESTful BASED 한남대학교 산학협력단 ФИПС, 2017 8 (A) WEBSITE AND FRAMEWORK WITH APPLICATION LINK US2017249198 Software Development Kit GOOGLE INC [US] ФИПС, 2017 (A1) Platform US2017249139 SOFTWARE GOOGLE INC [US] (A1) DEVELOPMENT AND DISTRIBUTION PLATFORM AU2017200055 INTEGRATED ACCENTURE (A1) DEVELOPER SOLUTIONS LTD WORKFLOW FOR DATA VISUALIZATION DEVELOPMENT ФИПС, 2017 GLOBAL ФИПС, 2017

Предмет поиска Наименование источника информации с Автор, фирма (держатель) Год, место и указанием страницы источника технической документации орган издания (утверждения, депонирования источника) 1 2 3 4 US2017220011 DEVELOPMENT GEN ELECTRIC [US] ФИПС, 2017 (A1) PLATFORM FOR INDUSTRIAL INTERNET APPLICATIONS US2017185395 DEVELOPMENT, SAP SE [DE] ФИПС, 2017 (A1) DELIVERY, DEPLOYMENT AND OPERATION OF AN APPLICATION CN103412745 Development and CHINA UNICOM ФИПС, 2013 (A) application platform US2017262262 APPLICATION EMBARCADERO TECH INC ФИПС, 2017 (A1) PLATFORM FOR [US] DESIGNING AND EXECUTING APPLICATIONS US2017257425 Scalable Local Cache in DATATORRENT INC [US] ФИПС, 2017 (A1) Distributed Streaming Platform for Real-Time Applications US2017249198 Software Development Kit GOOGLE INC [US] ФИПС, 2017 (A1) Platform US2017249139 SOFTWARE GOOGLE INC [US] ФИПС, 2017 (A1) DEVELOPMENT AND DISTRIBUTION PLATFORM WO2017109791 A SYSTEM AND TANGIRALA SRINIVAS; ФИПС, 2017 (A1) METHOD FOR CLARENCE MARIO [IN]; BUILDING ENTERPRISE KARUNAKARAN T [IN]; APPLICATIONS VEER RAJU Y TW201719396 Application dynamic- NATIONZ TECH INC [CN] ФИПС, 2017 (A) loading system and method

Приложение Е Патентные документы, найденные в процессе патентного поиска По компоненту разработки схемы данных основных данных и моделей бизнеспроцессов шесть заявок: 1. Заявка RU2005130349 от 10.04.2007 г. «Поддержка графических представлений, основанная на пользовательских настройках» 2. Заявка RU2010100807 от 20.07.2011 г. «Поддержка графических представлений, основанная на пользовательских настройках». 3. Заявка RU2008139610 от 20.04.2010 г. «Основанное на разрешениях преобразование пользовательского интерфейса». 4. Заявка RU2004118670/09 от 07.12.2017 г. «Инфраструктура для создания модульных Web-приложений» 5. Заявка RU2014126210/08 от 20.06.2016 г. «Метод просмотра web -страниц, платформа web-app, метод и устройство для исполнения JavaScript для мобильных терминалов» 6. Заявка RU2005138784/09 от 27.05.2006 г. «Многоуровневый графический пользовательский интерфейс» По компоненту управления интеграционным взаимодействием две заявки: 1. Заявка RU 2012125441/08 от 27.12.2013 г. «Унифицированная система управления информационными потоками предприятия» 2. Заявка RU2012145856/08, от 10.05.2014 г. «Интеграция клиентского приложения и web страницы» По компоненту формирования централизованной нормативно-справочной информации три заявки: 1. Заявка US 20120059917 от 08.03.2012 г. «Software license management within a cloud computing environment». 2. Заявка RU 2016122010 от 07.12.2017 г. «Информационная система автоматизированной подготовки статистической отчетности» 3. Заявка RU 2009112044/07, от 20.10.2010 г. «Среда программирования и управление метаданными для программируемого мультимедийного контроллера» По компоненту формирования хранилища ретроспективных (многолетних) данных и документов пять заявок: 1. Заявка RU 2005114658/09 от 20.11.2006 г. «Способ и система согласования схем баз данных web» 2. Заявка RU 2005114657/09 от 20.11.2006г. «Способ и система для индексирования и поиска в базах данных» 3. Заявка RU 2004136278/09, от 20.08.2005 г. «Хранилище данных для основанной на знаниях системы извлечения информации из данных» 4. Заявка RU 2006102136/08, от 10.08.2007 г. «Автоматизированная организация данных»

5. Заявка RU 2008137598/09, от 27.03.2010 г. «Система предоставления данных, сервер и программа» По компоненту создания форм отчетов и форм представлений многомерных данных пять заявок: 1. Заявка RU 2011133680 от 19.08.2010 г. «Отображение множества областей заголовков строк и столбцов в сводной таблице» 2. Заявка RU 2390834 от 27.05.2010 г. «Способ и устройство для просмотра и взаимодействия с электронной таблицей из веб-браузера» 3. Заявка RU 2003124659 от 27.02.2005 г. «Система баз данных персональных данных и способ управления доступом к базам данных персональных данных». 4. Заявка RU 2007148280/09 от 20.08.2009 г. «Система для web –публикации» 5. Заявка RU 2014101039/08, от 20.07.2015 г. «Система создания отчетных форм». По компоненту общесистемного администрирования двенадцать заявок: 1. Заявка RU 2014104096 от 19.02.2014 г. «Устройство управления лицензиями, система для управления лицензиями, способ управления лицензиями и программа для управления лицензиями». 2. Заявка RU 85248 от 27.07.2009 г. «Система управления лицензионными ключами с изменяемым сроком действия» 3. Заявка RU 2012122760 от 10.12.2013 г. «Система управления лицензиями, устройство управления продажами и устройство управления лицензиями». 4. Заявка RU 2012122803 от 10.12.2013 г. «Система управления лицензиями, устройство управления лицензиями и компьютерно-читаемый носитель записи, на котором имеется программа управления лицензиями». 5. Заявка RU 2571609 от 10.09.2015 г. «Устройство управления лицензиями, система для управления лицензиями, способ управления лицензиями и программа для управления лицензиями». 6. Заявка RU 2014102164 от 10.08.2015 г. «Устройство администрирования лицензий и способ администрирования лицензий» 7. Заявка RU 2507577 от 20.02.2014 г. «Система управления лицензиями, устройство управления лицензиями и компьютерно-читаемый носитель записи, на котором имеется программа управления лицензиями» 8. Заявка RU 2004129895 от 20.03.2006 г. «Система управления цифровыми правами» 9. Заявка WO/2007/146941 от 21.12.2007 г. «Version compliance system». 10. Заявка RU 2009126832 от 20.01.2011 г. «Способ управления идентификацией пользователей информационных ресурсов не однородной вычислительной сети». 11. Заявка RU 2007110938/09 от 10.10.2008 г. «Распределенная система контроля и управления» 12. Заявка RU 2009144604/08, от 10.06.2011 г. «Способ управления доступом к информационным ресурсам компьютерных сетей различных уровней конфиденциальности и устройство, его реализующее»

Приложение Ж Метрика качества (по ГОСТ) Таблица Ж.1 - Метрика качества инструментальных средств Коэффициенты № Показатели качества 1 2 уровня уровня Функциональные 1 0,5 возможности 1 Поддерживаемые методы 0,4 1 Структурные 1 Функциональные 2 Потоков данных 3 Бизнес-процессов 4 Событийные 5 Информационные 6 Иерархические 2 Объектные 1 Классов 2 Объектов 3 Компонентов 4 Развертывания 5 Состояний 6 Вариантов использования 7 Последовательности 8 Взаимодействия 9 Деятельностей 2 Пригодность 0,2 1 Построение моделей 1 Возможность декомпозиции Свойства объектов, 2 определяемые пользователем Наличие сопутствующей 3 документации 2 Экспорт отчётов 1 Формат текстового документа 2 Форматы MS Office 3 Формат HTML 4 Формат XML Способность к 3 0,2 взаимодействию 1 SAP/R3 2 MS Visio 3 уровня 4 уровня 0,5 0,2 0,2 0,2 0,2 0,1 0,1 0,5 0,2 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,6 0,7 0,2 0,1 0,4 0,25 0,25 0,25 0,25 0,1 0,1

3 4 5 6 7 8 9 10 11 12 13 14 4 1 2 3 4 5 6 7 8 9 10 2 1 1 2 3 2 1 2 3 4 5 6 3 1 1 ERwin Requisite Pro Performance Studio ClearCase Oracle SQL Developer Lotus Arena Paradigm Plus Rational Data Architect Oracle Designer PVCS SoDA Поддерживаемые процессы ЖЦ ПО Определение требований правообладателя Анализ системных требований Проектирование архитектуры системы Реализация Комплексирование системы Квалификационное тестирование системы Инсталляция программных средств Поддержка приемки программных средств Функционирование программных средств Сопровождение программных средств Эффективность 0,2 Стоимость пакета Низкая Средняя Высокая Требования к операционной системе Windows 8 Windows 7 Windows Vista Windows XP Windows Server Linux/Unix Сопровождаемость 0,1 Изменяемость Способ модификации отчётов 0,1 0,1 0,05 0,05 0,05 0,05 0,1 0,05 0,05 0,1 0,05 0,05 0,2 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,7 1 0,6 0,4 0,3 0,1 0,3 0,15 0,15 0,2 0,1 0,6 0,6

1 2 2 1 2 2 4 1 1 1 2 3 2 3 2 1 2 3 3 Создание отчётов на основе стандартных и настраиваемых пользователем макросов Визуальная настройка отчётов Сложность разработки нестандартных отчётов Просто Сложно Совместимость версий Практичность 0,2 Простота использования Простота работы Низкая Средняя Высокая Возможность отмены/повтора последних изменений модели Наличие русского интерфейса Обучаемость (Сумма вариантов) Учебный центр Документация на иностранном языке Документация на русском языке Возможность групповой работы над проектом 0,5 1 0,4 1 0,6 0,4 0,5 0,5 0,5 0,7 1 0,2 0,3 0,3 0,3 0,25 0,45 0,2 Эффективность 35 30 25 20 15 10 5 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Новый модуль Рисунок Ж.1 - Результаты оценки по характеристике «Эффективность»

Сопровождаемость 35 30 25 20 15 10 5 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Новый модуль Рисунок Ж.2 - Результаты оценки по характеристике «Сопровождаемость» Практичность 18 16 14 12 10 8 6 4 2 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Новый модуль Рисунок Ж.3 - Результаты оценки по характеристике «Практичность»

Приложение З Метрика качества (комбинированный подход) Таблица З.1 - Метрика качества инструментальных средств Коэффициенты № Показатели качества 1 2 уровня уровня Функциональные 1 0,5 возможности 1 Поддерживаемые методы 0,4 1 Структурные 1 Функциональные 2 Потоков данных 3 Бизнес-процессов 4 Событийные 5 Информационные 6 Иерархические 2 Объектные 1 Классов 2 Объектов 3 Компонентов 4 Развертывания 5 Состояний 6 Вариантов использования 7 Последовательности 8 Взаимодействия 9 Деятельностей 2 Пригодность 0,2 1 Построение моделей 1 Возможность декомпозиции Свойства объектов, 2 определяемые пользователем Наличие сопутствующей 3 документации 2 Экспорт отчётов 1 Формат текстового документа 2 Форматы MS Office 3 Формат HTML 4 Формат XML Способность к 3 0,2 взаимодействию 1 SAP/R3 2 MS Visio 3 уровня 4 уровня 0,5 0,2 0,2 0,2 0,2 0,1 0,1 0,5 0,2 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,6 0,7 0,2 0,1 0,4 0,25 0,25 0,25 0,25 0,1 0,1

1 2 2 1 2 2 4 1 1 1 2 3 2 3 2 1 2 3 3 Создание отчётов на основе стандартных и настраиваемых пользователем макросов Визуальная настройка отчётов Сложность разработки нестандартных отчётов Просто Сложно Совместимость версий Практичность 0,2 Простота использования Простота работы Низкая Средняя Высокая Возможность отмены/повтора последних изменений модели Наличие русского интерфейса Обучаемость (Сумма вариантов) Учебный центр Документация на иностранном языке Документация на русском языке Возможность групповой работы над проектом 0,5 1 0,4 1 0,6 0,4 0,5 0,5 0,5 0,7 1 0,2 0,3 0,3 0,3 0,25 0,45 0,2 Поддержка нотации BPMN 2.0 40 35 30 25 20 15 10 5 0 ARIS MS Visio SAP Oracle IBM Business Netweaver BPM Suite Websphere Studio BPM Business Biz Agi Suite Рисунок З.1 - Результаты оценки по характеристике «Поддержка нотации BPMN 2.0» Новый модуль

Поддержка 4 3,5 3 2,5 2 1,5 1 0,5 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.2 - Результаты оценки по характеристике «Поддержка» Информационное окружение 12 10 8 6 4 2 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.3 - Результаты оценки по характеристике «Информационное окружение» Имиджевые характеристики продукта 8 7 6 5 4 3 2 1 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.4 - Результаты оценки по характеристике «Имиджевые характеристики продукта»

Имиджевые характеристики производителя 3 2,5 2 1,5 1 0,5 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.5 - Результаты оценки по характеристике «Имиджевые характеристики производителя» Стоимость владения 4 3,5 3 2,5 2 1,5 1 0,5 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.6 - Результаты оценки по характеристике «Стоимость владения»

Производительность 8 7 6 5 4 3 2 1 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.7 - Результаты оценки по характеристике «Производительность» Практичность 4 3,5 3 2,5 2 1,5 1 0,5 0 ARIS SAP Netweaver BPM IBM Websphere Business Biz Agi Suite Рисунок З.8 - Результаты оценки по характеристике «Практичность»

Приложение И Выбор КИС методом анализа иерархий Классы критериев для выбора КИС: Класс 1 - Потребности организации (NoO1 - Соответствие бизнес процессам, NoO2 Масштабируемость, NoO3 - Соответствие стратегии организации, NoO4 - Наличие отраслевых решений, NoO5 - Простота использования обслуживающим персоналом, NoO6 - Развитые средства настройки бизнес-процессов); Класс 2 – Применяемые технологии (AT1 - Программная архитектура, AT2 Техническая архитектура, AT3 - Технология внедрения ERP системы, AT4 - Использование стандартных широко распространенных ИТ-технологий); Класс 3 – Функциональность (F1 – Интеграция, F2 – Наглядность, F3 - Соответствие нормативной базе, F4 - Использование лучших, наиболее эффективных, проверенных мировой практикой методов организации работ, F5 - Резерв функциональности, F6 - Простота модернизации и дополнения функциональности системы, F7 - Контролируемость и надежность системы, F8 - Сроки внедрения, F9 - Состав модулей); Класс 4 – Поддержка (S1 - Цикл поддержки, S2 - Наличие технологии обучения работе с системой и учебных материалов, S3 - Опыт внедрения, S4 - Наличие средств, упрощающих процесс внедрения, S5 - Наличие стандартной технологии внедрения для всех партнеров, S6 Качественная документация и контекстная помощь, S7 - Наличие службы поддержки); Класс 5 – Стоимость владения (CoO1 - Стоимость программного обеспечения, CoO2 Стоимость аппаратного обеспечения, CoO3 - Стоимость обслуживания, CoO4 - Стоимость модернизации и обновления, ежегодные инвестиции в развитие системы); Класс 6 – Принципы построения КИС (PoCIS1 - Системное окружение, в котором может работать система, PoCIS2 - Открытая платформа и открытые системные интерфейсы, PoCIS3 - Открытая структура системы и открытый исходный код всех приложений, PoCIS4 Поддержка технологии принятия решений, PoCIS5 - Поддержка CASE-технологии); Класс 7 - Имиджевые характеристики (ICh1 - Устойчивость производителя системы, ICh2 - Распространенность системы на рынке, в отрасли, в регионе, отзывы пользователей, ICh3 - Присутствие поставщика и системы на локальном рынке, ICh4 - Стратегия развития и модернизации системы, ICh5 - Структура и возможности партнерской сети по внедрению системы, ICh6 - Распространенность специалистов на рынке, ICh7 - Оценки опыта успешных и неудачных проектов, ICh8 - Квалификационный уровень специалистов). Таблица И.1 - Заполнение МПС критериев внутри класса на примере класса «Потребности организации» (No) NoO NoO1 NoO2 NoO3 NoO4 NoO5 NoO6 Вектор локальных приоритетов NoO1 1 5 3 6 6 4 0,452038347 NoO2 1/5 1 1/3 1/2 1/2 2 0,071325711 NoO3 1/3 3 1 4 4 2 0,224022333 NoO4 1/6 2 1/4 1 1 1/3 0,069190941 NoO5 1/6 2 1/4 1 1 1/3 0,069190941 NoO6 1/4 1/2 1/2 3 3 1 0,114231727

Таблица И.2 - Сводная таблица приоритетных критериев каждого класса Ранг NoO AT F S CoO PoCIS ICh 1 NoO1 AT1 F5 S1 CoO1 PoCIS1 ICh2 2 NoO3 AT2 F1 S7 CoO2 PoCIS2 ICh3 3 NoO6 AT3 F3 S4 CoO3 PoCIS3 ICh6 Таблица И.3 - Сводная таблица нормированных приоритетов критериев NoO1 NoO2 NoO3 NoO4 NoO5 NoO6 AT1 0,15352 0,024228 0,0760841 0,02350 0,02350 0,03880 0,04592 AT2 AT3 AT4 F1 F2 F3 F4 0,01962 0,01167 0,00705 0,04018 0,01128 0,03796 0,02648 F5 F6 F7 F8 F9 S1 S7 0,06574 0,01791 0,01165 0,00622 0,00731 0,03155 0,01581 S3 S4 S5 S6 S2 CoO1 CoO2 0,00276 0,00989 0,00949 0,00392 0,00609 0,08867 0,03789 CoO3 CoO4 PoCIS1 PoCIS2 PoCIS3 PoCIS4 PoCIS5 0,01925 0,01593 0,02006 0,00786 0,00786 0,00426 0,00426 ICh1 ICh2 ICh3 ICh4 ICh5 ICh6 ICh7 0,00410 0,02048 0,01545 0,00410 0,00253 0,01047 0,00161 ICh8 0,00710 Таблица И.4 - Матрица парных сравнений КИС по критерию (для российских КИС) NoO1 А1 А2 А3 А4 А5 А6 А7 А8 вектор А1 1 2 1/7 1/8 1/6 1 1/2 1/7 0,030067376 А2 1/2 1 1/9 1/9 1/8 1/2 1/4 1/9 0,018979423 А3 7 9 1 1/2 2 7 6 1 0,212495103 А4 8 9 2 1 3 8 7 2 0,305571551 А5 6 8 1/2 1/3 1 6 5 1/2 0,144352016 А6 1 2 1/7 1/8 1/6 1 1/2 1/7 0,030067376 А7 2 4 1/6 1/7 1/5 2 1 1/6 0,045972051 А8 7 9 1 1/2 2 7 6 1 0,212495103 Таблица И.5 - Сводная таблица результатов сравнения КИС по каждому критерию (для российских КИС) Ранг NoO1 NoO2 NoO3 NoO4 NoO5 NoO6 AT1 1 А4, А4, А8 А4, А8 А4 А4, А5 А4 А4, А8 2 А3, А8 А3, А5 А3, А5 А8 А8, А3 А8, А3, А5 А3, А5 3 А5 А3, А5

AT2 AT3 AT4 F1 F2 F3 F4 1 А6 А4, А8 А3 А3 А4 А4 А8 2 А1, А2, А8 А3 А7 А7 А5 А3, А8 А4, А3 А5 А4, А8 А6, А8 А8 F5 F6 F7 F8 F9 S1 S7 1 А3, А8 А3 А8 А7 А3 А8 А8, А4, А3 2 А4 А5 А3 А2 А4, А5 А4 3 А5 А4, А8 А4 А1, А6 А8 А3, А5 S3 S4 S5 S6 S2 CoO1 CoO2 1 А4 А8 А4 А4 А4 А7 2 А8 А4, А3 А8 А8 А3, А8 А2, А5 А1, А2, А6, А7 3 А3 А3 А3 3 А5 А1 CoO3 CoO4 PoCIS1 PoCIS2 PoCIS3 PoCIS4 PoCIS5 А1, А2, А6, А7 А5 А8 А3, А5 А3, А4 А4 А3, А4 А8 А4 А7 А5, А8 А5 А1, А6 А4 А3 А8 ICh1 ICh2 ICh3 ICh4 ICh5 ICh6 ICh7 1 А8 А8 А4 А4, А8 А4 А4 А4 2 А4 А4 А3, А8 А3 А3, А8 А8 А3, А8 3 А3 А3 1 2 3 А3 А3 А3 ICh8 1 А4 2 А8 3 А3 Таблица И.6 – Сводная таблица приоритетов рассматриваемых КИС (зарубежные КИС) Критерии 1 приоритет 2 приоритет 3 приоритет NoO1 SAP R/3 Oracle EBusiness Suite Microsoft Dynamics NAV NoO2 BAAN iRenaissance SAP R/3 NoO3 SAP R/3 BAAN Oracle EBusiness Suite NoO4 SAP R/3 IFS Applications Oracle EBusiness Suite NoO5 IFS Applications Oracle EBusiness Suite Microsoft Dynamics AX NoO6 Oracle EBusiness Suite SAP R/3 Oracle Applications AT1 Oracle EBusiness Suite BAAN IFS Applications AT2 Microsoft Dynamics AX Microsoft Dynamics NAV IFS Applications AT3 SAP R/3 Oracle Applications Microsoft Dynamics AX AT4 Microsoft Dynamics AX iRenaissance Microsoft Dynamics NAV F1 Oracle EBusiness Suite Microsoft Dynamics AX Microsoft Dynamics NAV F2 Oracle EBusiness Suite BAAN iRenaissance

Критерии 1 приоритет 2 приоритет 3 приоритет F3 BAAN IFS Applications Microsoft Dynamics NAV F4 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV F5 SAP R/3 Oracle EBusiness Suite Microsoft Dynamics NAV F6 IFS Applications Microsoft Dynamics AX Microsoft Dynamics NAV F7 SAP R/3 Oracle Applications Oracle EBusiness Suite F8 Microsoft Dynamics NAV Microsoft Dynamics AX iRenaissance F9 Oracle Applications SAP R/3 Oracle EBusiness Suite S1 SAP R/3 IFS Applications Oracle Applications S2 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV S3 SAP R/3 Microsoft Dynamics NAV Microsoft Dynamics AX S4 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV S5 SAP R/3 Oracle Applications Oracle EBusiness Suite S6 Oracle EBusiness Suite BAAN Oracle Applications S7 SAP R/3 Oracle Applications Oracle EBusiness Suite CoO1 BAAN iRenaissance Microsoft Dynamics AX CoO2 Oracle EBusiness Suite Microsoft Dynamics AX Microsoft Dynamics NAV CoO3 IFS Applications Microsoft Dynamics AX Microsoft Dynamics NAV CoO4 SAP R/3 Oracle Applications Microsoft Dynamics AX PoCIS1 SAP R/3 Oracle Applications IFS Applications PoCIS2 Oracle Applications Oracle EBusiness Suite IFS Applications PoCIS3 IFS Applications Microsoft Dynamics NAV Microsoft Dynamics AX PoCIS4 BAAN Microsoft Dynamics NAV Microsoft Dynamics AX PoCIS5 iRenaissance Microsoft Dynamics NAV Microsoft Dynamics AX ICh1 SAP R/3 Oracle Applications Oracle EBusiness Suite ICh2 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV ICh3 SAP R/3 Oracle Applications Oracle EBusiness Suite ICh4 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV ICh5 Microsoft Dynamics NAV SAP R/3 Oracle Applications ICh6 SAP R/3 Microsoft Dynamics AX Microsoft Dynamics NAV ICh7 IFS Applications iRenaissance Microsoft Dynamics AX ICh8 SAP R/3 Oracle Applications Oracle EBusiness Suite

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв