Интеллектуальная поддержка принятия решений в области инженерии требований на основе онтологических моделей представления знаний тема диссертации и автореферата по ВАК РФ 05.13.10, кандидат наук Муртазина Марина Шамильевна

• Муртазина Марина Шамильевна
• кандидат наук
• 2020

Оглавление диссертации кандидат наук Муртазина Марина Шамильевна

ВВЕДЕНИЕ

ГЛАВА 1 ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ В ОБЛАСТИ ИНЖЕНЕРИИ ТРЕБОВАНИЙ ПРИ УПРАВЛЕНИИ ПРОЕКТАМИ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ

1.1 Роль инженерии требований в успешности проекта по разработке программного продукта

1.1.1 Теория управления проектами как раздел теории управления социально-экономическими системами

1.1.2 Инженерия требований как область знаний

1.1.3 Инженерия требований и управление проектами

1.1.4 Характеристики качества требований

1.2 Инженерии требований и инженерия знаний

1.2.1 Инструментальные средства в области инженерии требований

1.2.2 Представление знаний в инженерии требований

1.2.3 Применение онтологий в инженерии требований

1.2.4 Применение лексических онтологий при извлечении и анализе требований

1.3 Выводы по главе

ГЛАВА 2 ОНТОЛОГО-ОРИЕНТИРОВАННЫЙ ПОДХОД К ИНЖЕНЕРИИ ТРЕБОВАНИЙ

2.1 Построение онтологии для инженерии требований

2.1.1 Формализованная модель онтологий

2.1.2 Модель онтологии для информационной поддержки процесса инженерии требований при гибком управлении проектом

2.1.3 Модель онтологии предметной области программного продукта

2.2 Реализация моделей онтологий в среде Protégé

2.3 Выводы по главе

ГЛАВА 3 ИЗВЛЕЧЕНИЕ И АНАЛИЗ ТРЕБОВАНИЙ НА ОСНОВЕ ОНТОЛОГИЧЕСКОЙ И ПРОДУКЦИОННОЙ МОДЕЛЕЙ

3.1 Возможности автоматической обработки текстов требований на русском языке

3.2 Извлечение экземпляров онтологии из текстовых требований

3.2.1 Универсальные зависимости в разметке текста

3.2.2 Извлечение экземпляров классов онтологии

3.3 Анализ требований на основе онтологической и продукционно -логической моделей

3.4 Выводы по главе

ГЛАВА 4 РЕАЛИЗАЦИЯ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ В ОБЛАСТИ ИНЖЕНЕРИИ ТРЕБОВАНИЙ

4.1 Технологические инновации в системе управления проектом

4.2 Архитектура и описание СППР

4.3 Поддержка процесса управления проектом в СППР

4.4 Модуль «Анализ требований»

4.5 Выводы по главе

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

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

СПИСОК ИЛЛЮСТРАТИВНОГО МАТЕРИАЛА

ПРИЛОЖЕНИЕ А Описание лексической онтологии RDF/OWL Wordnet

ПРИЛОЖЕНИЕ Б Реализация онтологий в Protégé

ПРИЛОЖЕНИЕ В Правила модели для анализа требований

ПРИЛОЖЕНИЕ Г Листинг базы правил (на языке Prolog)

ПРИЛОЖЕНИЕ Д Листинг программного кода процедуры анализа требований (на языке Python)

ПРИЛОЖЕНИЕ Е Описание модели для определения приоритета

ПРИЛОЖЕНИЕ Ж Свидетельства о государственной регистрации программы для ЭВМ

ПРИЛОЖЕНИЕ И Копии документов, подтверждающих использование результатов диссертационного исследования

ПРИЛОЖЕНИЕ К Копия диплома III степени за доклад на конференции

Введение диссертации (часть автореферата) на тему «Интеллектуальная поддержка принятия решений в области инженерии требований на основе онтологических моделей представления знаний»

ВВЕДЕНИЕ

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

Задача извлечения и анализа требований сходна с чрезвычайно сложной задачей извлечения знаний из экспертов при создании интеллектуальных

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

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

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

Проблематика управления проектами как социально-экономическими системами отражена в работах Демарко Т., Листера Т., Буркова В.Н., Ильиной О.Н., Коновальчука Е.В., Новикова Д.А., Воропаева В.И. Вопросы улучшения качества управления проектами разработки программного обеспечения затронуты в работах Будыльского А.В., Квятковской И.Ю. Концепция гибкого управления проектами по процессному фреймворку Scrum представлена в работах Сазерленда Дж. и Швабера К., фундаментальные основы практик оценки, планирования и гибкого управления проектами с использованием пользовательских историй заложены Кон.М.

Связь управления проектами с инженерией требований анализируется в работах Young R.R., Alexander I., Beus-Dukic L., Lampa I.L. , Contessoto A. de G., Amorim A.R., Zafalon G.F.D., Valencio C.R., de Souza R.C.G., Moorthy S. Основы

процессного подхода к инженерии требований заложены и развиты в трудах Похла К. Особенности оценки качества agile-требований проанализированы Heck P., Zaidman A., Lucassen G., Dalpiaz F., van der Werf J.M., Brinkkemper S.

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

Систематический обзор публикаций, посвященный вопросам применения онтологических моделей представления знаний в области управления проектами, проведен Fitsilis P., Gerogiannis V., Anthopoulos L. Разработке онтологий для управления проектами с учетом правил фреймворка Scrum посвящены исследования Lin Y., Hilaire V., Gaud N., Koukam A., Werewka J, Szwed P., Rogus G., Adnan M., Afzal M. и др. Вопросы применения онтологий для целей инженерии требований к программным продуктам исследованы в трудах Авдеенко Т.В., Пустоваловой Н.В., Siegemund K, Saito S., Iimura Y., Aoyama M., Adnan M., Afzal M., Liu C.-L., Huang , Dobson G., Sawyer P. и др. Применение методов автоматического семантико-синтаксического анализа текстов на естественном английском языке для целей построения онтологий требований исследовано в работах Assawamekin N., Sunetnanta T., Pluempitiwiriyawej C.

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

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

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

1) проанализировать подходы, методы и техники, используемые при принятии решений в области инженерии требований при управлении проектами разработки программных продуктов,

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

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

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

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

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

Объектом исследования является процесс принятия управленческих решений в области инженерии требований как основа управления проектом по

разработке программного продукта.

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

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

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

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

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

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

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

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

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

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

Положения работы, выносимые на защиту:

1. Онтологические модели представления знаний в области инженерии требований (соответствует п.3 паспорта специальности 05.13.10).

2. Метод извлечения экземпляров онтологии требований из результатов автоматической обработки русскоязычных текстов требований (соответствует п.6 паспорта специальности 05.13.10).

3. Метод анализа консистентности набора требований (соответствует п.10 паспорта специальности 05.13.10).

4. Интеллектуальная система поддержки принятия решений, в которой реализованы предложенные модели и методы (соответствует п.5 паспорта специальности 05.13.10).

Степень достоверности результатов работы. Обоснованность и достоверность научных результатов обусловлена применением современного научно-методического аппарата.

Представленное в диссертационной работе исследование выполнялось в рамках гранта Министерства образования и науки РФ в рамках проектной части государственного задания «Интеграция моделей представления знаний на основе интеллектуального анализа больших данных для поддержки принятия решений в области программной инженерии» (проект № 2.2327.2017/4.6, 2017-

2019 гг.).

Предлагаемые автором модели представления знаний и методы информационной поддержки принятия решений в области инженерии требований приняты к использованию в ООО «Простые решения».

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

Апробация результатов диссертации. Основные результаты диссертационной работы и выводы диссертационного исследования докладывались и обсуждались на следующих всероссийских и международных конференциях: 12th Ershov Informatics Conference (г. Новосибирск, 2019 г.); Young Scientist's Third International Workshop on Trends in Information Processing (YSIP3, г. Ставрополь, 2019 г.); 13th International symposium «Intelligent Systems» (г. Санкт-Петербург, 2018 г.); 8th International Workshop on Service Orientation in Holonic and Multi-Agent Manufacturing (SOHOMA 2018, Bergamo, Italy, 2018 г.); международная конференция и молодёжная школа «Информационные технологии и нанотехнологии» (г. Самара, 2018 г. , 2019 г.); международная научно-техническая конференция «Актуальные проблемы электронного приборостроения» (г. Новосибирск, 2018 г.); международная научно-методическая конференция «Информатика: проблемы, методология, технологии» (г. Воронеж, 2018 г., 2019 г.); международная научно-практическая конференция «Кулагинские чтения» (г. Чита, 2018 г.); ежегодная российская научно-техническая конференция «Обработка информации и математическое моделирование» (г. Новосибирск, 2018 г. , 2019 г.); всероссийская научно-техническая конференция студентов, аспирантов и молодых ученых «Современные технологии принятия решений в цифровой экономике» (г. Юрга, 2018 г.); всероссийская научно-техническая конференция

студентов, аспирантов и молодых ученых с международным участием «Измерения, автоматизация и моделирование в промышленности и научных исследованиях» (г. Бийск, 2018 г.); всероссийская научная конференция молодых ученых «Наука. Технологии. Инновации» (г. Новосибирск, 2017 г., 2018 г.).

В 2018 г. доклад «The ontology-driven approach to support the requirements engineering process in Scrum framework» занял III место на международной конференции и молодёжной школе «Информационные технологии и нанотехнологии».

Публикации по теме. Основные положения диссертационной работы изложены в 22 публикациях, из них пять публикации в изданиях, индексируемых Scopus [82, 151, 153, 155, 156], две статьи в журналах из перечня ВАК РФ (в т.ч. 1 статья единолично) [1, 39], два свидетельства о регистрации программы для ЭВМ [57, 58], 13 публикации в сборниках материалов международных и российских [13, 38, 40, 35, 41, 43, 36, 42, 37, 34, 44, 152, 154].

Личный вклад автора. Основные положения, выносимые на защиту, отражают личный вклад автора. Доля личного вклада в работах, выполненных в соавторстве, составляет не менее 50%. Автором были полностью разработаны моделей представления знаний, методы извлечения и анализа требований, осуществлена программная реализация СППР.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы, содержащего 221 наименование, и девяти приложений. Работа изложена на 227 страницах, в том числе основной текст на 144 страницах, список литературы на 26 страницах, приложения на 36 страницах; содержит 98 рисунков и 28 таблиц.

ГЛАВА 1 ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ В ОБЛАСТИ ИНЖЕНЕРИИ ТРЕБОВАНИЙ ПРИ УПРАВЛЕНИИ ПРОЕКТАМИ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ

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

1.1 Роль инженерии требований в успешности проекта по разработке

программного продукта

1.1.1 Теория управления проектами как раздел теории управления социально-экономическими системами

Теория управления проектами представляет собой раздел теории управления социально-экономическими системами, который изучает методы, формы и средства эффективного и рационального управления изменениями [10].

Проект - «это временное предприятие, направленное на создание уникального продукта, услуги или результата» [54, С4]. Проекты реализуются путем создания поставляемых результатов. В случае проектов по разработке программного обеспечения поставляемым результатом будет готовый к использованию программный продукт.

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

общее и ясное представление о жизненном цикле проекта дано в Руководстве PMBOK (Project Management Body of Knowledge) [14].

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

Управление проектом - «это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту» [54, C.10]. Управление проектами как самостоятельная дисциплина зарождается в 1930-х гг. Современная концепция управления проектами сформировалась к середине 1950-х гг. в США. В 1980-х годах в США публикуется первая версия Руководства PMBOK [14]. На настоящий момент Руководство PMBOK является одним из самых известных зарубежных документов, стандартизирующих управление проектами. В каждом новом издании Руководства PMBOK излагаются передовые методы управления проектами. В 2017 г. вышла уже шестая версия Руководства PMBOK.

Методологические основы современного российского управления проектами были заложены в 1990-x гг. Воропаевым В.И. [10, 27]. В отечественной науке широко известна его системная модель управления проектами, представляющая собой свернутое дерево избыточного множества задач и процедур, которые могут реализовываться в процессе управления проектом. Системная модель управления проектом содержит три блока: субъекты управления, объекты управления и процесс управления [15].

Субъектами управления являются активные участники проекта, которые взаимодействуют при разработке и принятии управленческих решений в

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

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

В научной и профессиональной литературе дается множество определений термина «управление». Среди них есть и определение управления как процесса, и как воздействия, и как функции и т.п. Чтобы объяснить «многогранность» данного термина, Новиков Д.А. предлагает рассматривать управление, осуществляемое субъектом, как вид деятельности. Методология управления сосредоточена на организации управленческой деятельности, которую осуществляет человек или группа людей, а теория управления - на взаимодействии субъекта управления и управляемой системы (см. рисунок 1.1). Обобщением закономерностей успешной практики управленческой деятельности занимается «философия» менеджмента, а исследованием наиболее общих закономерностей управления - кибернетика [46]. Термин «кибернетика» в его современном понимании ввел в научный оборот Н. Винер

в книге «Кибернетика», где описал подход к исследованию нелинейных систем при помощи «черного» и «белого» ящиков, определил механизм прямой и обратной передачи информации [11].

Рисунок 1.1 - Соотношение методологии управления и теории управления

Наряду с общей кибернетикой, выделяют «отраслевые» кибернетики [45]. Среди них «экономическая кибернетика», занимающаяся приложением методов кибернетики к экономическим системам. Данная научная отрасль находится на стыке математики, кибернетики и экономики. Термин «Кибернетика экономическая» начинает употребляться в начале 1960-хгг. в трудах Немчинова В.С., Ланге О., Греневского X., Вирах С. [68].

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

Воздействие окружающей среды

Вход ^

Прямая связь: передача управляющей информации

Обратная связь:

передача информации о состоянии

Выход Yi

Объект управления

Рисунок 1.2 - Кибернетическая модель управления социально-экономической системой

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

Рисунок 1.3 - Кибернетическая модель управления проектом

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

проекта (план проекта). В ходе реализации проекта может выясниться, что модель проекта неадекватна, фактический результат проекта отличается от прогнозируемого. В этом случае, на основании информации о состоянии окружающей среды, прогнозируемом и фактическом результатах, «менеджер проекта» осуществляет коррекцию модели проекта и осуществляет управляющие воздействия [30]. Структура системы оперативного управления проектом включает реальный проект и его модель (см. рисунок 1.4).

Рисунок 1.4 - Структура системы оперативного управления проектом

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

Методологии управления проектами по разработке программных продуктов формируются на базе общей теории управления проектами. На протяжении десятилетий подходы, описанные в Руководстве PMBOK, обеспечивали основу для управления проектами в разных отраслях человеческой деятельности, однако при управлении проектами в области разработки программного обеспечения зачастую возникали трудности при попытках применить стандартные подходы Руководства PMBOK в совокупности с гибкими подходами к разработке программного обеспечения. Вплоть до пятого издания, вышедшего в 2013 г., в Руководстве PMBOK не упоминался адаптивный жизненный цикл проекта. В этом же году было выпущено дополнение к Руководству PMBOK в части управления проектами в области разработки программного обеспечения - Software Extension to the

Список литературы диссертационного исследования кандидат наук Муртазина Марина Шамильевна, 2020 год

Справочная информация из открытых источников

Рисунок 4.1 - Контекстная диаграмма типовой системы управления проектом

по методологии Scrum

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

Рисунок 4.2 - Детализация потоков и активностей типовой системы управления

проектом по методологии Scrum

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

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

Рисунок 4.3 - Детализация потоков и активностей предлагаемой модели управления проектом по методологии Scrum

Рисунок 4.4 - Детализация активности «Инженерия требований и планирование работ» предлагаемой модели управления проектом по методологии Scrum

Элементы технологических инноваций активности «Инженерия требований и планирование работ» представлены на рисунке 4.5.

Рисунок 4.5 - Элементы технологических инноваций активности «Инженерия

требований и планирование работ»

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

4.2 Архитектура и описание СППР

Под архитектурой системы, согласно стандарту ГОСТ Р 57100 -2016/ISO/IEC/IEEE 42010:2011, понимают «основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития» [18]. Архитектура СППР состоит из интерфейса пользователя, программных модулей сбора и обработки данных на языке Python, машины логического вывода, файловой базы данных и OWL-онтологий (см. рисунок 4.6). Для реализации логического вывода по аксиомам онтологии используется машина логического вывода HermiT, которая входит в Python-библиотеки Owlready2. Библиотека Owlready2 позволяет загружать OWL-онтологии как объекты Python, изменять и сохранять их, а также выполнять логический вывод. Для реализации модели нечеткого логического вывода на языке Python использована библиотека инструментов нечеткой логики scikit-fuzzy-0.4.1. Смежными системами, с которыми может взаимодействовать СППР, являются: среда SWI--Prolog и анализатор UDPipe. Для взаимодействия со SWI-Prolog используется библиотека PySwip.

Для входа в систему пользователю нужно ввести имя пользователя и пароль (см. рисунок 4.7).

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

Рисунок 4.7 - Диалоговое окно «Вход в программу»

Рисунок 4.8 - Форма «Выбор проекта»

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

1) Справочники,

2) Видение продукта,

3) Дерево функциональных возможностей,

4) Бэклог продукта,

5) Бэклог спринта,

6) Анализ требований,

7) Обработка текстовых требований.

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

1) Команда,

2) Критерии подготовленности и готовности,

3) Концепты предметной области,

4) Роли пользователей,

5) Классы элементов бэклога продукта,

6) Статусы элементов бэклога,

7) Статусы задач проекта,

8) Виды рисков,

9) Задачи и техники тестирования,

10) История изменений.

На рисунке 4.10 представлена форма справочника «Команда». Данный справочник содержит список ролей Бегиш-команды с указанием персон и периодов работы, когда персона выполняла определенную роль в команде. В один и тот же момент времени только одна персона может выполнять роль владельца продукта. Бегиш-мастер может быть одновременно и членом команды разработки. Форма справочника состоит из двух вкладок. На первой

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

I 1

ВИИ

Участник Роль

1 Иванов Антон Сергеевич Разработчик, 5сгит-масгер

2 Васильев Иван Николаевич Разработчик

3 Алексеева Елена Петровна Разработчик

4 Юдин Денис Валерьевич Разработчик

5 Логинов Александр Сергеевич Владелец продукта

Рисунок 4.10 - Справочник «Команда» Справочник «Критерии подготовленности и готовности» (см. рисунок 4.11) предназначен для ввода перечня критериев, по которым команда будет оценивать подготовленность и готовность спринта, подготовленность элементов бэклога продукта к принятию в план спринта, а также готовность элементов бэклога спринта по завершения спринта.

|И1 Критерии подготовленности и готовности

Пользовательская история Прочие элементы бэклога спринта | Спринт Критерии подготовленности

ЕШВ

Описание

1 Определена цель спринта

2 В плане спринта нет элементов бэклога продукта, несоответствующих установленным для них критериям подготовленности

3 Определены человеческие ресурсы для исполнения задач спринта

Критерии готовности

ШЕИ

Описание

1 Критерии готовности выполнены для всех элементов бэклога спринта

2 Бэклог продукта актуализирован

3 Инкремент продукта успешно развернут в тестовой среде, идентичной производственной платформе

I ШШ

Справочник «Концепты предметной области» предназначен для работы с экземплярами классов «DomainConcept» и «Word» для описания понятий предметной области. Форма включает три закладки: акторы, действия, объекты. Основная задача этого справочника - указание принадлежности слов, составляющих понятие предметной области, к частям речи, а также указания семантических связей между концептами.

Для пополнения справочника «Концепты предметной области» предусмотрено два режима: режим ручного ввода и автоматического ввода из предварительно проверенных экспертом результатов извлечения концептов предметной области из текстовых данных. Экранная форма справочника для ручного ввода данных представлена на рисунке 4.12.

Рисунок 4.12 - Справочник «Концепты предметной области» Список акторов-пользователей загружается из справочника «Роли пользователей», в рамках справочника «Концепты предметной области» состав

акторов-пользователей не меняется, возможно только изменение состава акторов-систем. Для внесения данных о ролях пользователей системы предназначен справочник «Роли пользователей». В справочнике будут перечислены все варианты названия ролей, которые будут использованы при записи требований. Экранная форма справочника представлена на рисунке 4.13.

Я

Роли пользователей

Название Класс Залогиненный пользователь 3 а регистр и роаанный пользователь Родительская роль

1 : пользователь пользователь

2 гость клиент пользователь

3 посетитель клиент пользователь

А покупатель клиент пользователь

5 залогиненный покупатель клиент Да Да покупатель

5 зарегистрированный незалогиненный покупатель клиент нет Да покупатель

7 зарегистрированный незалогиненный пользователь клиент нет Да пользователь

8 контент администратор сотрудник Да Да сотрудник

9 директор сотрудник Да Да старший менеджер

10 старший менеджер сотрудник Да Да менеджер

11 менеджер сотрудник Да Да сотрудник

12 сотрудник сотрудник Да Да пользователь

Рисунок 4.13 - Справочник «Роли пользователей» Базой для справочника является список пользователей из документа «Видение продукта». Список пользователей, указанный в документе «Видение продукта» переносится в справочник автоматически, удалить данные роли нельзя, пока они присутствуют в документе «Видение продукта». Также в справочнике присутствует роль «пользователь», которая является корневым элементов всей структуры ролей и не может быть удалена или отредактирована. В справочнике указываются связи между ролями (роль - подроль) и состояния для роли (например, зарегистрированный пользователь). Перечень ролей может быть больше, чем список пользователей в документе «Видение продукта». Например, в «Видение продукта» может фигурировать только пользователь

«покупатель», а в списке ролей справочника уже покупатель, зарегистрированный покупатель, залогиненный покупатель.

В форме «Настройки роли» (см. рисунок 4.14) указывается, к какому классу принадлежит роль, состояния пользователя, родительская роль и роли, идентичные данной. Также в этой форме указываются функциональные возможности пользователя. На закладке «Индивидуальные функциональные возможности для роли» вводятся возможности, которые характерны для данного уровня роли в иерархии ролей. На вкладке «Наследование функциональных возможностей» отображаются все унаследованные от родительской роли возможности. Здесь же настраиваются исключения при наследовании функциональных возможностей от родительской роли.

Рисунок 4.14 - Форма «Настройки роли» Справочник «Классы элементов бэклога продукта» по умолчанию включает следующие классы элементов: эпик, пользовательская история, дефект, техническая работа, накопление знаний. Данные пять классов имеют тип «Системный класс» и не могут быть изменены пользователем. При необходимости командой могут быть добавлены дополнительные классы для обозначения направлений, выполняемых ими работ. Для таких классов

устанавливается тип «Пользовательский класс». Экранная форма справочника представлена на рисунке 4.15.

Справочник «Статусы элементов бэклога» предназначен для ввода перечня статусов, которые показывают текущее состояние элемента бэклога. Справочник состоит из полей: «Название», «Элементы бэклога» и «Описание».

1 'I Классы элементов бэклога продукта

Шк\Ш

ВИИ

Название Тип

1 Эпик Системный класс

2 Пользовательская история Системный класс

3 Дефект Системный класс

4 Техническая работа Системный класс

5 Накоплениезнаний Системный класс

Н Рефакторинг Пользовательский класс

Рисунок 4.15 - Справочник «Классы элементов бэклога продукта» В поле «Элементы бэклога» отображается список элементов бэклога продукта, для которых может быть назначен статус. Экранная форма справочника представлена на рисунке 4.16.

71 Статусы элементов бэклога | f1 |

ВИИ

Название Элементы бэклога Описание -

1 Добавлено Все Элемент бэклога только добавлен, никто еще не начинал над ним работать

2 Начат анализ Эпик, Пользовательская история Элемент бэклога будет уточняться и оцениваться в рамках грум и н га

3 Готово к планированию Пользовательская история Элемент бэклога может быть запланирован в спринт

4 В работе Пользовательская история. Дефект, Техническая работа, Накоплениезнаний Элемент бэклога запланирован на текущий спринт

5 Завершено Все Работы над элементом бэклога завершены

б На проверке Все Результаты работы над элементом бэклога переданы на проверкууполномоченномулицу

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

8 Заморожено Все По какой-то причине элемент бэклога не может развиваться дальше

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

10 Отклонено Все По какой-то причине элемент бэклога более не актуален

11 Заблокировано Пользовательская история Элемент бэклога заблокирован другим элементом и не может быть сделан до него -J

12 Повторно открыто Дефект Предыдущее решение оказалось недейственным

Рисунок 4.16 - Справочник «Статусы элементов бэклога» В форме для редактирования элемента (см. рисунке 4.17) указывается, для каких классов элементов бэклога продукта может быть применен тот или иной

статус. Для статусов с пометкой «Системный» операция удаления элемента не применима, также в форме редактирования нельзя изменить название статуса. Если выбраны все классы статусов, то для удобства восприятия, вместо их перечисления в поле «Элементы бэклога» формы «Статусы элементов бэклога» отображается слово «Все». По аналогии со справочником «Статусы элементов бэклога» организован справочник «Статусы задач по проекту».

Рисунок 4.17 - Справочник «Редактирование статуса элемента бэклога» Справочник «Виды рисков» (см. рисунок 4.18) содержит перечень ключевых рисков. При оценке уровня риска реализации пользовательской истории, указывается название вида риска из справочника и дается детальное описание ситуации.

Ю Виды рисков 1 У ||и£3и|

ВИИ

Название Категория

1 Значительные изменения в требованиях из-за изменения бизнес-приоритетов Бизнес-рисе

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

3 Непонятный пользователю интерфейс Риск некачественной реализации нефункциональных требований

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

5 Обновление сторонних библиотек Технический риск

6 Некорретность рассчетов, производимых программой Технический риск

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

8 Масштабируемость базы данных Технический риск

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

Справочник «Задачи и техники тестирования» (см. рисунок 4.19) предназначен для ввода одноименных данных, которые используются при выдаче рекомендаций СППР мер по уменьшению рисков некачественной реализации функциональных и нефункциональных требований.

* 1 Задачи и темники тестирования | 1?

Задачи тестирования | Техники |

иии

Название

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

Рисунок 4.19 - Справочник «Задачи и техники тестирования» Справочник «История изменений» предназначен для просмотра версий основных артефактов требований. Экранная форма справочника включает три закладки «Видение продукта», «Дерево функциональных возможностей» и «Пользовательские истории».

Функциональные модули «Видение продукта», «Дерево функциональных возможностей», «Бэклог продукта» и «Бэклог спринта» предназначены для работы с одноименными артефактами. Функциональный модуль «Анализ требований» используется для анализа требований, представленных в виде экземпляров классов OWL-онтологии. Функциональный модуль «Обработка текстовых требований» используется для извлечения экземпляров классов 0"^Ь-онтологии из текстовых требований. На рисунке 4.20 представлен фрагмент отчета, формируемого в процессе обработки текстового файла.

Результаты извлечения

Текстовый файл: us.txt

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

Как зарегистрированный покупатель я хочу аннулировать заказ

Лемма Как регистрировать покупатель - я хотеть аннулировать заказ

Тег части речи SCONJ VERB NOUN PUNCT PRON VERB VERB NOUN PU

Синтаксическая mark amod advcl pu net nsubj root xcomp obj pur

зависимость

Родительский 3 3 6 3 6 0 6 7 11

токен

Результат:

Актор

зарегистрированный покупатель Главное слово: покупатель Отношение-действие

хочу аннулировать Смысловой глагол: Объект аннулировать

заказ

Главное слово: заказ

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

4.3 Поддержка процесса управления проектом в СППР

Проект по разработке программного продукта начинается с создания документа «Видение продукта». Для обеспечения разработки данного документа используется функциональный модуль «Видение продукта». Видение продукта относится к артефактам гибкой разработки и представляет собой документ, разрабатываемый на основе анализа потребностей бизнеса, и включающий направление развития продукта, согласованное всеми стейкхолдерами. Форма для работы с видением продукта (см.рисунок 4.21) включает следующие вкладки: Целевая аудитория, Бизнес-цели, Потребности, Краткое описание продукта, Ключевые возможности, Ограничения.

Видение продукта

ЕЗ

Название продукта: Интернет-магазин ""Сувениры" Идея

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

Потребность Приоритет Описание Текущее решение Предлагаемое решение Тип

Клиентьи становятся

все более Интернет-магазин предоставит

^ Удобный способ купить продукцию Высокий склонными к покупкам в Интернете, что экономит им врем... Отсутствует покупателю доступ в любое время и в любом месте к продукции компании Клиентская

Согласно стратегии интернет-

магазина, инвестиции и расходы

2 Финансовый рост и пред ста вл ен и е това ра Высокий Техн ол оги ч еское отставание от конкурентов на рынке Отсутствует будут сокращены. Клиенты будут чувствуют себя более комфортно и будут более заинтересованы в покупках через Интернет-магазин. Компания получит финансовый рост и улучшит свой имидж на рынке Бизнеса

Сохранить Проверить Утвердить

Печать

Рисунок 4.21 - Форма «Видение продукта». Вкладка «Потребности» Вкладка «Целевая аудитория» предназначена для ввода групп пользователей разрабатываемого командой программного продукта и списка должностных лиц и организаций, которые являются стейкхолдерам проекта. Добавленные здесь пользователи отображаются в справочнике системы «Роли пользователей», где после создания видения продукта, можно на основании списка пользователей создать набор ролей, используемых при написании требований.

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

Рисунок 4.22 - Форма «Добавление пользователя»

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

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

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

Следующим шагом работ является создание такого артефакта требований как «Дерево функциональных возможностей». Для поддержки работ с данным артефактом в СППР используется одноименный функциональный модуль «Дерево функциональных возможностей». Основой для построения дерева функциональных возможностей является перечень основных функциональных возможностей из документа «Видение продукта». Экранная форма справочника «Дерево функциональных возможностей» представлена на рисунке 4.23.

Дерево функциональны* возможностей | ^ |||

ВИН

Функциональная возможность Вариабельность *

1> Авторизация и аутентификация пользователей Обязательно

Каталог продукции Обязательно

Оформление заказа Обязательно

л Регистрации пользователей Обязательно

Регистрация сотрудника администратором Обязательно —

* Самостоятельная регистрация покупателя Обязательно

Форма регистрации Обязательно

Через социальные сети Опционально

Управление аккауктом пользователя Обязательно

& Управление заказом Обязательно т

Проверить согласованность

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

Рисунок 4.24 - Форма «Редактирование элемента дерева» Далее начинаются работы по формированию бэклога продукта. Главная форма этого функционального модуля «Бэклог продукта» включает три вкладки (см. рисунок 4.25).

Рисунок 4.25 - Форма «Бэклог продукта». Вкладка «Готово к планированию» Панель инструментов вкладки «Готово к планированию» включает две кнопки для работы с элементами бэклога продукта: отредактировать и переопределить приоритеты. Панель инструментов вкладки «Ожидает груминга» включает четыре кнопки: добавить элемент, отредактировать элемент, удалить элемент, переопределить приоритеты. Третья вкладка позволяет увидеть бэклог целиком.

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

На рисунке 4.26 показана форма для ввода данных по пользовательской истории.

Рисунок 4.26 - Форма «Пользовательская история». Вкладка «История» На момент внесения пользовательской истории в бэклог продукта достаточно указать ее текст и тему. При этом пользовательской истории присваивается статус «Добавлено». Остальные данные заполняются по мере анализа пользовательской истории. При внесении любых данных помимо темы и текста истории, пользовательской истории присваивается статус «Начат

анализ». На вкладке «История» отображаются результаты подсчета числа зависимостей, уровня риска и приоритет истории. В блоке «Внутренние зависимости» отображается число элементов бэклога, для реализации которых необходимо выполнить данную пользовательскую историю. При наличии внешних зависимостей, до их устранения пользовательская история не может получить статус «Готово к планированию».

Уровень риска для каждой пользовательской истории вычисляется как:

RiskUS = max {tfi<S, Risk'f,..., RiskU }, Risj = PUS • j (4.1)

где RiskUS - уровень риска для пользовательской истории,

n - число риск-состояний, идентифицированных для пользовательской истории,

RiskUS - уровень риска реализации i-го риск-состояния,

PU - вероятность возникновения i-го риск-состояния,

jus - степень воздействия i-го риск-состояния на результат работы.

Степень воздействия риск-состояния на результат работы и вероятность возникновения риск-состояния указываются по 10-балльной шкале, где 1 обозначает низкую степень воздействия или вероятность возникновения, а 10 -высокую.

При нажатии на кнопку «Проверить» СППР проверяет, указаны ли критерии приемки истории, которые состоят из требований к поведению системы и характеристик качества продукта, определен ли уровень риска, связанный с невыполнением качественных характеристик требований, значимых для данной группы пользователей. В статус «Готово к планированию» пользовательскую историю можно перевести нажатием кнопки «Готово». При этом запустится проверка готовности пользовательской истории. Если все условия выполнены, пользовательской истории присвоится статус, в противном случае СППР укажет на упущения во внесении результатов анализа пользовательской истории.

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

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

В настоящее время существует ряд подходов к приоритизации требований. Расстановка приоритетов основывается на одном или нескольких критериях. Распространённым критерием при однокритериальном подходе является ценность для бизнеса, при многокритериальном подходе наиболее распространены такие критерии, как ценность для бизнеса, риск, стоимость, волатильность требований, сложность реализации требований и т.д. [172, 86]. К наиболее известным методам приоритизации требований можно отнести метод анализа иерархий (analytic hierarchy process, AHP), двоичное дерево поиска (англ. binary search tree, BST), минимальное остовное дерево (Minimal Spanning Tree, MST), метод игры в планирование (Planning Game), метод «100 долларов» (Hundred Dollar Method), метод приоритетных групп (Priority Groups). Одни предназначены для оценки приоритетов в условиях большого числа требований, другие - сравнительно малого [171]. Среди подходов, используемых и при большом, и при малом числе требований, можно выделить расстановку приоритетов требований на основе нечеткой логики (fuzzy logic based requirement prioritization, FLRP).

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

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

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

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

Чтобы определить значение приоритета пользовательской истории, задаваемого на основании экспертных оценок, для которых, как для любых человеческих рассуждений, характерна неопределенность лингвистического типа, в СППР использована нечеткая продукционная модель типа Мамдани (см. рисунок 4.27). Для построения модели использовано четыре критерия: бизнес-ценность, уровень риска, оценка усилий по сложности задачи, количество зависимости от элементов бэклога продукта. Для первого критерия оценка делается по шкале от 0,0 до 100,0. Для второго критерия - по шкале от 0,0 до 10,0. Для третьего критерия - по шкале от 0,0 до 13,0. Для четвертого от 0,0 до 20,0. Выходная переменная «приоритет» строится по шкале от 0,0 до 100,0. Для

переменных используются треугольные и трапециевидные функции принадлежности. Их графики приведены на рисунках Е.1 и Е.2.

Рисунок 4.27 - Схема нечеткой модели оценки уровня приоритетности элемента бэклога продукта

Модель построена с использованием редактора системы нечеткого вывода SciFLT пакета прикладных математических программ Scilab (см. рисунок Е.3). Для реализации модели на языке Python использована библиотека инструментов нечеткой логики scikit-fuzzy-0.4.1.

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

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

Каждый спринт должен иметь четко сформулированную цель. Для каждого спринта должны быть указаны участвующие в событии «Планирование спринта» лица. К ним относятся участники Scrum-команды и приглашенные стейкхолдеры. При создании бэклога спринта должен производиться учет производительности команды разработки. Для каждого спринта должен быть составлен реестр рисков. Экранная форма «Планирование спринта» представлена на рисунке 4.28.

Рисунок 4.28 - Форма «Планирование спринта» В ходе планирования пользователь СППР может добавлять элементы бэклога продукта, для которых установлен статус «Готово к планированию». После добавления элемента бэклога продукта необходимо указать задачи, необходимые для реализации элемента, определить их длительность и исполнителей. При добавлении новых данных программа суммирует оценку усилии в сторипоинтах и затраты в часах. Оценка усилий выполняется на этапе подготовки элементов бэклога продукта. Оценка трудозатрат в часах указывается при составлении плана спринта. Оценка усилий в безразмерных единицах предназначена для оценки элемента бэклога относительно других элементов. Оценка трудозатрат согласуется с исполнителями задач. Бэклог спринта заполняется согласно приоритетам элементов бэклога продукта и с учетом ограничения по трудозатратам. Результатом события «Планирования спринта» является утвержденный бэклог спринта и обновленный реестр рисков проекта. Далее на протяжении спринта в систему вносятся данные о ходе выполнения работ. Описанный программный продукт нацелен на поддержку основных событий, предусмотренных в рамках фреймворка Scrum. СППР помогает пользователю выявлять ошибки в элементах бэклога продукта, связанные с некоренным (например, ошибки циклических зависимостей) и неполным (с точки зрения знаний о необходимых для определенных групп

пользователей характеристик качества) внесением данных для артефактов требований.

4.4 Модуль «Анализ требований»

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

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

- редактирование системы продукционно-логических правил, ранее сохраненных в виде модели,

- применение правил модели к требованиям, представленным в виде экземпляров классов OWL-онтологии.

Для реализации первой функции создан конструктор, который помогает пользователю в несколько «кликов» построить систему правил для анализа отношений между элементами требований. Экранная форма первого шага работы конструктора приведена на рисунке 4.29.

На первом шаге необходимо указать путь к файлу с OWL-онтологией, для которой строится модель, и указать путь к файлу, куда сохранять саму модель. На втором шаге необходимо определить, какие классы онтологии соответствуют элементам «актор», «действие» и «объект» (см. рисунок 4.30).

0] Построение модели. Шаг 2 | || Е]

Выберите клас(ы онтологии, соответствующие концептаи «Актор», «Действиек-, «Объект»-,

Актор:

| >> | Actor Действие:

ш

Объект:

[ << Назад | Далее » ] | Отмена

Рисунок 4.30 - Экранная форма «Построение модели. Шаг 2» На третьем шаге необходимо выбрать свойства объектов, которые будут использованы для анализа. Данный шаг состоит из трех подшагов: на первом выбираются свойства-отношения между акторами требований (см. рисунок 4.31), на втором - между действиями (см. рисунок 4.32), на третьем -между объектами (см. рисунок 4.33). Это позволяет конечному пользователю самостоятельно определять правила обработки имеющихся у него данных.

Рисунок 4.31 - Экранная форма « Построение модели. Шаг 3.1»

Рисунок 4.32 - Экранная форма « Построение модели. Шаг 3.2»

Рисунок 4.33 - Экранная форма «Построение модели. Шаг 3.3» На четвертом шаге работы приложения выдаются сгенерированные комбинации антецедентов для продукционно-логических правил. Пользователю необходимо определить консеквенты правил, выбрав тип отношения между требованиями для каждого правила. На рисунке 4.34 представлена экранная форма последнего шага построения модели.

Полуавтоматическая генерация правил не позволяет пользователю пропустить какое-либо правило, поскольку покрывает все возможные сочетания для антецедентов правил. При необходимости пользователь может завершить работу по формированию модели в любой момент и продолжить ее позже. Для этого в программе предусмотрена функция «Редактирование модели», которая состоит из двух шагов. Первый шаг - это выбор файла с моделью (см. рисунок 4.35).

Рисунок 4.35 - Экранная форма «Редактирование модели. Шаг 1» Далее открывается окно для редактирования правил модели (см. рисунок 4.36).

ИЗ Редактирование модели. Шаг 2

Применение правил модели к требованиям, представленным в виде экземпляров классов OWL-онтологии, выполняется с помощью функции «Поиск конфликтов», которая состоит из двух шагов. На первом шаге указываются файлы с OWL-онтологией и с моделью для анализа требований (см. рисунок 4.37).

Рисунок 4.37 - Экранная форма «Поиск конфликтов. Шаг 1» На втором шаге указывается, куда сохранить результаты анализа (см. рисунок 4.38).

Рисунок 4.38 - Экранная форма « Поиск конфликтов. Шаг 2»

В ходе анализа требований данные об экземплярах классов и отношениях между ними, а также правила модели импортируются в базу фактов на языке Prolog (см. рисунок 4.39).

basel.pl I | Н

File Edit Browse Compile Prolog Pee Help base1.pl -hi

:- discontiguous(owlhasObject/2). _

:- discontiguous(isConflict/3).

:- discontiguous(isDuplicate/3).

:- discontiguous(isInteraction/3) .

:- discontiguous(isMotInteraction/3).

OwLRequicement('requirement02'). owlRaquicement('requirementOl').

owlhasActor('requirementDI',1actorOl'}.

owlhasActor('requirement02',1actorOl'}.

■ ■ ■

isConflict(Requirement!, Requirement2, 52):-owlhasActor{Requirement1, Actorl), owl — hasActor(Requirements, Actor2), owlhasñction(Requirement!, Action!}, owlhasñction( Requirement2, Action2), owlhasObject(Requirement!, Object!), owlhasObject(Requirem ent2, Cbject2), owlsameAsActor(Actor1, Actor2)r owlpartOfAction(Actionl, Action2), owlisaObject(Objectl, Cbject2).

Une: 14-3

L_J

Рисунок 4.39 - Фрагмент результата импорта данных в SWI-Prolog

Аналогичным образом преобразовываются все правила модели. После наполнения внутренней базы фактов осуществляется решение задачи поиска конфликтов средствами SWI-Prolog. Для реализации указанной функциональности использованы Python-библиотека PySwip и среда разработки SWI-Prolog 7.6.4.

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

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

Доля правильных ответов, полученных при применении программного инструмента, была вычислена как:

Accuracy =

AnSTrueMatchi ng (4-2)

Ат м

где АшТтеМ1(сЫщ- число правильных ответов, полученных при сравнении

требований с помощью разработанного инструмента,

Атк1 - общее число результатов.

Тестирование модели было осуществлено на 20 наборах пользовательских историй. Средний результат составил 0,81.

4.5 Выводы по главе 4

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

Разработанная система поддержки принятия решений базируется на предложенных во второй и третьей главах моделях представления знаний и методах обработки информации. Разработанный программный инструментарий прошел государственную регистрацию в качестве программ для ЭВМ, о чём Федеральной службой по интеллектуальной собственности, патентам и товарным знакам выданы свидетельства № 2018662725 от 12 октября 2018 г. и № 2019610690 от 15 января 2019 г (см. Приложение Ж). Апробации использованных с СППР моделей и методов подтверждается актами о внедрении результатов исследования (см. Приложение И).

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

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

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

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

3. Разработан метод извлечения концептов онтологии требований из результатов автоматической обработки текстов требований на основе продукционной модели. Предложенные правила модели были разработаны для применения на результатах автоматической обработки текста, выполненной по кросс-языковой нотации разметки языковых корпусов «Универсальные зависимости».

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

5. Разработана интеллектуальная СППР, обеспечивающая сбор и анализ

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

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

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

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

BABOK - Business Analysis Body of Knowledge

BDD - Behaviour-Driven Development

CPRE - Certified Professional for Requirements Engineering

CSV - Comma-Separated Values

DL - Description logics

ERM - Entity Relationship Models

EXPLODE - Extreme Programming for lightweight ontology development

GLR - Generalized Left-to-right Rightmost

IREB - International Requirements Engineering Board

ISO - International Organization for Standardization

KADS - Knowledge Acquisition Documentation System

MDRE - Model Driven Requirements Engineering

MIKE - Model-based and Knowledge Engineering

MOKA - Methodology and tools Oriented to Knowledge-Based Engineering Applications

NAF - Negation As Failure

NLP - Natural Language Processing

NLTK - Natural Language Toolkit

ODRE - Ontology-Driven Requirements Engineering

OWL - Web Ontology Language

OWR - Open World Reasoning

PMBOK - Project Management Body Of Knowledge

RDF - Resource Description Framework

RDL - Requirements Description Language

RE - Requirements Engineering

REDSS - Requirements engineering decision support systems RML - Requirements Modelling Language

RML AOT - акроним от «Рабочее Место Лингвиста» для системы автоматической обработки текста

RRO - Runtime Requirements Ontology

RSRO - Reference Software Requirements Ontology

SADT - Structured Analysis and Design Technique

SBOK - Scrum Body of Knowledge

SPARQL - Simple Protocol and RDF Query Language

SPCM - Software Product Certification Model

SQWRL - Semantic Query-enhanced Web Rule Language

SREM - Software Requirements Engineering Methodology

SWEBOK - Software Engineering Body of Knowledge

SwO - Software Ontology

SysML - Systems Modeling Language

UD - Universal Dependencies

UML - Unified Modeling Language

UNL - Universal Networking Language

URL - Uniform Resource Locator

UTF - Unicode Transformation Format

W3C - World Wide Web Consortium

XML - eXtensible Markup Language

XP - Extreme Programming

XP.K - eXtreme Programming of Knowledge-based systems

YARN - Yet Another RussNet

СППР - Система Поддержки Принятия Решений

ЭВМ - Электронно-Вычислительная Машина

ЭТАП - Электротехнический Автоматический Перевод

1. Авдеенко Т. В., Муртазина М. Ш., Гриф М. Г. О возможностях автоматической обработки текста для построения онтологии требований // Научный вестник Новосибирского государственного технического университета. - 2018. - № 4 (73). - С. 27-46.

2. Авдеенко Т.В., Пустовалова Н.В. Применение онтологического подхода для поддержки процесса инженерии требований // Актуальные проблемы электронного приборостроения АПЭП-2016: Труды XIII Международной научно-технической конференции. - В 12-ти томах. - 2016. -С. 125-130.

3. Автоматическая Обработка Текста [Электронный ресурс]. - Режим доступа: http://aot.ru/ (дата обращения: 28.08.2018).

4. Барышев М.В., Гатчин И.Ю., Гатчин Ю.А. Модели представления знаний экспертных систем // Научно-технический вестник Санкт-Петербургского государственного университета информационных технологий, механики и оптики. - 2006. - № 29. - С. 14-18.

5. Богуславский И.М., Иомдин Л.Л., Крысин Л.П. Слово и язык. Сборник статей к восьмидесятилетию академика Ю.Д. Апресяна. - М.: Языки славянских культур, 2011. - 735 с.

6. Большакова Е.И., Воронцов К.В., Ефремова Н.Э., Клышинский Э.С., Лукашевич Н.В., Сапин А.С. Автоматическая обработка текстов на естественном языке и анализ данных : учеб. пособие. - М.: Изд-во НИУ ВШЭ, 2017. - 269 с.

7. Большой экономический словарь / под ред. А.Н. Азрилияна. 5-е изд. доп. и перераб. М.: Институт новой экономики, 2002. - 1280 с.

8. Будыльский А.В., Квятковская И.Ю. Управление проектами разработки программного обеспечения с использованием агентных технологий // Прикаспийский журнал: управление и высокие технологии. - 2013. - № 3 (23). - С. 119-129.

9. Будыльский А.В. Управление ресурсами ^-проекта на основе агентных технологий: дис. ... канд. техн. наук : 05.13.10 / Будыльский Александр Викторович. - Астрахань, 2014. - 145 ^

10. Бурков В.Н., Новиков Д.А. Как управлять проектами: Научно-практическое издание. — М.: СИНТЕГ-ГЕО, 1997. — 188 с.

11. Винер Н. Кибернетика, или управление и связь в животном и машине. - 2-е издание. - Москва: Наука; Главная редакция изданий для зарубежных стран, 1983. - 344 с.

12. Виттих В.А., Ситников П.В., Смирнов С.В. Онтологический подход к построению информационно-логических моделей в процессах управления социальными системами // Вестник компьютерных и информационных технологий. - 2009. - № 5 (59). - С. 45-53.

13. Воронина П.Е., Муртазина М.Ш. Онтологический подход к поддержке процесса разработки программных продуктов по методологии BDD // Обработка информации и математическое моделирование : материалы Рос. науч.-техн. конф., [Новосибирск, 25-26 апр. 2019 г.]. - Новосибирск : Изд-во СибГУТИ, 2019. - С. 147-151.

14. Воропаев В.И. Управление проектами в России. - М.: Аланс, 1995. -

225 с.

15. Воропаев В.И., Секлетова Г.И. Системное представление Управления проектами // Управление проектами. - 2005. - № 3. - С. 20.

16. Галактионов В.А., Мусатов А.М., Мансурова О.Ю., Ёлкин С.В., Клышинский Э.С., Максимов В.Ю., Аминева С.Н., Жирнов Р.В., Игашов С.Ю., Мусаева Т.Н. Система машинного перевода "Кросслятор 2.0" и анализ ее функциональности для задачи трансляции знаний. - М.: 2007. - 27 с.

17. Гаранина Н.О., Зюбин В.Е., Лях Т.В. Онтологический подход к организации шаблонов требований в рамках системы поддержки формальной верификации распределенных программных систем // Системная информатика. -2017. - № 9. - С. 111-132.

18. ГОСТ Р 57100-2016/Is0/IEC/IEEE 42010:2011 Системная и программная инженерия. Описание архитектуры. - М.: Стандартинформ, 2016. - 36 с.

19. ГОСТ Р ИСО/МЭК 25010 -2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. - М.: Стандартинформ, 2015. - 36 с.

20. Гусев С.С. Управление процессом разработки программного обеспечения информационных систем // Прикладная математика и вопросы управления. - 2019. - № 2. - С. 23-39.

21. Данченков С.И., Поляков В.Н. Классификация текстов в системе узлов лексической онтологии // Ученые записки Казанского университета. Серия: Физико-математические науки. - 2010. - Т. 152. - № 1. - С. 255-267.

22. Демарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. - М.: Символ-плюс, 2014. - 288 c.

23. Демарко Т. Deadline. Роман об управлении проектами. - М.: Манн, Иванов и Фербер, 2013. - 352 c.

24. Евланов М.В. Разработка модели и метода выбора описания рациональной архитектуры информационной системы // Восточно-Европейский журнал передовых технологий. - 2016. - Т. 1. - № 2 (79). - С. 4-12.

25. Загорулько Ю.А., Загорулько Г.Б. Онтологический подход к разработке системы поддержки принятия решений на нефтегазодобывающем предприятии //Вестник Новосибирского государственного университета. Серия: Информационные технологии. - 2012. - Т. 10. - № 1. - С. 121-128.

26. Захарова А.А. Структура и технология функционирования среды разработки систем поддержки принятия стратегических решений // Доклады Томского государственного университета систем управления и радиоэлектроники. - 2018. - Т. 21. - № 1. - С. 86-91.

27. Ильина О. Н. Системный подход к управлению проектами в организации. Монография. - М.: Креативная экономика, 2012. - 186 с.

28. Интеграция ресурсов RussNet и YARN / И. В. Азарова, П. И. Браславский, В. П. Захаров и др. // Компьютерная лингвистика и вычислительные онтологии: сборник научных статей. Труды XIX Международной объединённой научной конференции «Интернет и современное общество» (IMS-2016), Санкт-Петербург, 22-24 июня 2016 г. — СПб : Университет ИТМО, 2016. — С. 7-13.

29. Кон М. Agile: оценка и планирование проектов. - М.: Альпина Паблишер, 2018. - 460 c.

30. Коновальчук Е.В., Новиков Д.А. Модели и методы оперативного управления проектами. - М.: ИПУ РАН, 2004. - 63 с.

31. Лагутина Н.С. , Лагутина К.В. , Адрианов А.С., Парамонов И.В. Русско-язычные тезаурусы: автоматизированное построение и применение в задачах обработки текстов на естественном языке // Моделирование и анализ информационных систем. - 2018. - Т. 25. - № 4. - С. 435-458.

32. Многоцелевой лингвистический процессор ЭТАП-3 [Электронный ресурс]. - Режим доступа: http://iitp.ru/ru/ru/researchlabs/922.htm (дата обращения: 28.08.2018).

33. Григорян Т.Г., Шатковский Л.Ю. Модели процессов принятия решений при ценностно-ориентированном управлении требованиями в ИТ-проектах // Управление проектами и развитие производства. - 2016. - № 2(58). - С. 81-98.

34. Муртазина М.Ш., Авдеенко Т.В. Построение онтологии функциональных требований на основе методов автоматического анализа текстовой информации // Измерения, автоматизация и моделирование в промышленности и научных исследованиях (ИАМП-2018) : сб. тр. 13 Всерос. науч.-техн. конф. студентов, аспирантов и молодых ученых с междунар. участием, Бийск, 1-3 нояб. 2018 г. - Барнаул : Изд-во АлтГТУ, 2018. - С. 520522.

35. Муртазина М.Ш. Моделирование онтологии предметной области программного продукта // Кулагинские чтения. Техника и технологии

производственных процессов : сб. тр. 18 междунар. науч.-практ. конф., Чита, 28-30 нояб. 2018 г. - В 3 ч. - Чита : ЗабГУ, 2018. - Ч. 3. - С. 63-67.

36. Муртазина М.Ш. Подход к построению онтологии функциональных требований к программному продукту на основе синтаксического и морфологического анализа // Информатика: проблемы, методология, технологии : материалы 18 междунар. науч.-метод. конф., Воронеж, 8-9 февр.

2018 г. : в 7 т.- Воронеж : Изд-во: Вэлборн, 2018. - Т. 5. - С. 294-299.

37. Муртазина М.Ш. Поиск конфликтов между требованиями к программному продукту // Наука. Технологии. Инновации : сб. науч. тр. : в 9 ч., Новосибирск, 3-7 дек. 2018 г. - Новосибирск : Изд-во НГТУ, 2018. - Ч. 2. -С. 250-253.

38. Муртазина М.Ш. Применение нечеткой логики для приоритизации требований к программному продукту // Информатика: проблемы, методология, технологии : материалы 19 междунар. науч.-метод. конф., Воронеж, 14-15 фев.

2019 г. - Воронеж : Изд-во: «Научно-исследовательские публикации» (ООО «Вэлборн»), 2019. - С. 1497-1502.

39. Муртазина М.Ш. Система поддержки принятия решений при гибком подходе к инженерии требований на основе OWL-онтологии // Вестник Астраханского государственного технического университета. Серия: Управление, вычислительная техника и информатика. - 2018. - № 4. - С. 43-55.

40. Муртазина М.Ш., Авдеенко Т.В. Выявление конфликтов в спецификации требований на основе онтологической модели и системы продукционных правил // Информационные технологии и нанотехнологии (ИТНТ-2019) : сб. тр. V междунар. конф. и молодеж. шк., Самара, 21-24 мая 2019 г. - Самара : Изд-во Новая техника, 2019. - С. 592-600.

41. Муртазина М.Ш., Авдеенко Т.В. Онтологический подход к поддержке процесса инженерии требований в Scrum // Информационные технологии и нанотехнологии (ИТНТ-2018) : сб. тр. 4 междунар. конф. и молодежная шк., Самара, 24-27 апр. 2018 г. - Самара : Новая техника, 2018. - С. 2610-2620.

42. Муртазина М.Ш., Швец В.Д. Онтолого-ориентированный подход к инженерии требований при разработке программного обеспечения // Наука. Технологии. Инновации : сб. науч. тр. : в 10 ч., Новосибирск, 4-8 дек. 2017 г. -Новосибирск : Изд-во НГТУ, 2017. - Ч. 1. - С. 86-90.

43. Муртазина М.Ш., Швец В.Д. Подход к организации интеллектуальной поддержки процесса разработки web-приложения с применением онтологии и wiki-технологий // Обработка информации и математическое моделирование : материалы Рос. науч.-техн. конф., [Новосибирск, 26-27 апр. 2018 г.]. -Новосибирск : Изд-во СибГУТИ, 2018. - С. 211-217.

44. Муртазина М.Ш. Возможности применения онтологий в инженерии требований // Современные технологии принятия решений в цифровой экономике : сб. тр. Всерос. науч.-практ. конф. студентов, аспирантов и молодых ученых, Юрга, 15-17 нояб. 2018 г. - Томск : Изд-во ТПУ, 2018. - С. 216-218.

45. Новиков Д.А. Кибернетика: Навигатор. История кибернетики, современное состояние, перспективы развития. - М.: ЛЕНАНД, 2016. - 160 с.

46. Новиков Д.А. Методология управления. - М.: Либроком, 2011. -

128 с.

47. О лингвистической онтологии "Тезаурус РуТез" [Электронный ресурс]. - Режим доступа: https://www.labinform.ru/pub/ruthes/ (дата обращения: 28.08.2018).

48. Обзор Rational DOORS [Электронный ресурс]. - Режим доступа: https://www.ibm.com/support/knowledgecenter/ru/SSYQBZ_9.6.1/com.ibm.doors.re quirements.doc/topics/c_welcome.html (дата обращения: 05.08.2018).