СИСТЕМА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ГИБКОМ ПОДХОДЕ К ИНЖЕНЕРИИ ТРЕБОВАНИЙ НА ОСНОВЕ OWL-ОНТОЛОГИИ
Авторы:
1.
Новосибирский государственный технический университет
Тип:
Статья
Страницы:
с 43
по 55
Статус:
Опубликован
Получено:
05.10.2018
Одобрено:
25.10.2018
Опубликовано:
25.10.2018
Классификаторы:
ВАК 05.12.2013 Системы, сети и устройства телекоммуникаций
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 004.89
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 004.89
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
Язык материала:
русский
Ключевые слова:
онтология, инженерия требований, гибкое управление проектами, построение логического вывода, системы поддержки принятия решений
Аннотация (русский):
Предлагается подход к интеллектуальной поддержке принятия решений в области инженерии требований к программному обеспечению на основе OWL-онтологии. Представленный в работе подход учитывает особенности инженерии требований при гибком управлении проектами. Архитектура разрабатываемой системы поддержки принятия решений состоит из интерфейса пользователя, приложения на языке Python, включающего машину логического вывода, OWL-онтологии и файловой базы данных. Онтологический уровень представлен OWL-онтологией, которая аккумулирует в себе знания о критериях оценки качества требований, позволяет накапливать в форме экземпляров классов информацию о требованиях к программному продукту, артефактах требований, источниках требований. Онтология включает аксиомы дескриптивной логики, позволяющие выполнять рассуждения о требованиях, выявлять неявные отношения между требованиями. Онтология включает знания, необходимые для анализа соответствия пользовательских историй и сценариев поведения критериям оценки их синтаксического качества, определения приоритета и уровня риска пользовательских историй. Также онтология позволяет выполнять трассировку требований вверх и вниз, оценивать полноту отдельных требований. Применение разработанной системы позволяет уменьшить число ошибочных решений при управлении требованиями к программному обеспечению.
Предлагается подход к интеллектуальной поддержке принятия решений в области инженерии требований к программному обеспечению на основе OWL-онтологии. Представленный в работе подход учитывает особенности инженерии требований при гибком управлении проектами. Архитектура разрабатываемой системы поддержки принятия решений состоит из интерфейса пользователя, приложения на языке Python, включающего машину логического вывода, OWL-онтологии и файловой базы данных. Онтологический уровень представлен OWL-онтологией, которая аккумулирует в себе знания о критериях оценки качества требований, позволяет накапливать в форме экземпляров классов информацию о требованиях к программному продукту, артефактах требований, источниках требований. Онтология включает аксиомы дескриптивной логики, позволяющие выполнять рассуждения о требованиях, выявлять неявные отношения между требованиями. Онтология включает знания, необходимые для анализа соответствия пользовательских историй и сценариев поведения критериям оценки их синтаксического качества, определения приоритета и уровня риска пользовательских историй. Также онтология позволяет выполнять трассировку требований вверх и вниз, оценивать полноту отдельных требований. Применение разработанной системы позволяет уменьшить число ошибочных решений при управлении требованиями к программному обеспечению.
Ключевые слова:
онтология, инженерия требований, гибкое управление проектами, построение логического вывода, системы поддержки принятия решений
онтология, инженерия требований, гибкое управление проектами, построение логического вывода, системы поддержки принятия решений
Разработка программного обеспечения - это наукоемкий труд, в котором обсуждение требований и результатов работы, а также коммуникация между командой разработки и стейкхолдерами являются залогом успеха. Выявление требований и управление ими - это чрезвычайно сложная задача для всех методологий управления проектами разработки программного обеспечения. Результаты исследований компании Standish Group показали, что доля успешных ИТ-проектов за 2011-2015 гг. в среднем составила 28,8 %, доля проблемных - 52,4 %, доля неуспешных - 18,8 %. При этом из 50 000 проектов, участвовавших в исследовании, только 29 % завершились успешно. Из анализа проектов 2011-2015 гг. в разрезе аналитики по методологиям разработки следует, что для каскадной метрологии доля успешных проектов составила 11 %, а для гибких методологий - около 39 % [1]. Ключевой особенностью гибких методологий является готовность команды разработки к постоянной адаптации требований в условиях изменчивости факторов бизнес-среды, иными словами, инженерия требований в гибких проектах - это процесс, выполняемый в течение всего процесса разработки. Опыт многих команд разработки, практиковавших предиктивную (каскадную) модель жизненного цикла проекта, показал нецелесообразность попыток определить все требования перед началом создания программного продукта в рамках отдельной (закрытой) стадии. Такие команды зачастую сталкивались с последствиями ошибочных представлений о продукте вплоть до полного провала проекта. Реальность была такова, что, насколько бы тщательно ни проводился анализ предметной области, насколько скрупулезно бы ни описывались документы с требованиями, часть требований все равно упускалась, а часть оказывалась фактически ненужной (ситуация «раздутых» требований). Также часть первоначально задокументированных требований оказывалась не соответствующей фактическим потребностям стейкхолдеров (ситуация устаревших и нерелевантных требований). Популяризация гибкого подхода (Agile-подхода) к управлению проектами по разработке программного обеспечения стимулировала развитие методов гибкого выявления и управления требованиями. Подходы к документированию требований при гибкой разработке стали краеугольным камнем множества споров. Даже появился миф, что Agile-подход подразумевает разработку без документирования требований. Указанный миф с успехом опровергается опытными специалистами. Так, в работе [2] показывается, что следование положению Манифеста гибкой разработки «Работающий продукт важнее исчерпывающей документации» ни в коем случае не отменяет документирования требований. Данное положение способствует изменению документирования в сторону фиксации только того, что действительно имеет ценность для пользователя. Практики разработки и управления требованиями в гибких проектах отличны от традиционных практик, но также необходимы для достижения успешных результатов. В большинстве гибких методологий требования оформляются как пользовательские истории. Пользовательская история (user story) - это простой рассказ, иллюстрирующий цели пользователя, которые будут удовлетворяться функциями программного обеспечения [3]. Все большее число исследований затрагивает вопросы применения онтологий в инженерии требований. Рост популярности онтологического подхода к программной инженерии обусловлен, по мнению авторов работы [4], двумя причинами. С одной стороны, онтологии обеспечивают семантическую интероперабельность, с другой - возможность машинного рассуждения. Требования к программному обеспечению являются сложными знаниями по своей природе. Онтологии хорошо зарекомендовали себя как один из возможных способов представления сложных знаний и рассуждения о них. В работе [5] указано, что онтологии полезны для представления и взаимосвязи многих типов знаний и существует множество потенциальных применений онтологий в инженерии требований. В частности, это могут быть онтологии предметных областей, онтологии, формализующие процесс сбора знаний о предметных областях, онтологии, содержащие знания об атрибутах качества требований. Научный дискурс последних лет характеризуется ориентацией на проблемы инженерии требований при гибком подходе к разработке программного обеспечения. Это включает и построение новых систем критериев оценки качества пользовательских историй, и разработку онтолого-ориентированных подходов к инженерии требований. Значимыми для первого направления можно назвать работы [6-8]. Среди проблем в практике оценки пользовательских историй, которые могут быть решены с помощью онтологий, авторы работы [9] выделили неточность оценки усилий гибкой команды. Проблемы формулирования пользовательских историй и онтологический подход к совершенствованию инженерии требований в Agile-процессе представлен в работе [10]. В работе [11] представлен подход к разработке рекомендательной системы, поддерживающей процесс эволюции Agile-требований. Проведенный анализ публикаций позволяет говорить о перспективности применения онтологий для поддержки процесса инженерии требований. Основываясь на научных работах [9, 12-16], в исследованиях возможностей применения онтологии в области инженерии требований можно выделить следующие направления работ: - разработка онтологий предметных областей проектов, которые описывают отношения между разными ролями пользователей, действия пользователей в системе, компоненты программного продукта; - разработка онтологий-руководств для интеллектуальной поддержки определенной техники работы с требованиями; - разработка онтологий для оценки качества требований в соответствии с некоторым стандартом или совокупностью стандартов и методологий. В этой статье предлагается концепция системы поддержки принятия решений в области инженерии требований при гибком подходе к разработке программных продуктов. Основой системы является OWL-онтология, которая позволяет выполнять рассуждения о требованиях к программному продукту на основе аксиом дескриптивной логики. Техники работы с требованиями при гибком подходе Под требованием будем понимать зафиксированное при помощи некоторой техники утверждение о некотором свойстве программного продукта. Требования подразделяются на функциональные и нефункциональные. Функциональные требования описывают поведение программного продукта. Нефункциональные требования определяют характеристики качества программного обеспечения, которые делятся на два типа: внешнее и внутреннее. Внешнее качество программного продукта - качество программного продукта с точки зрения пользователя, например быстродействие. Внутреннее качество - это качество программного продукта с точки зрения разработчиков, например читабельность кода. Для облегчения работы с заказчиками совокупность нефункциональных требований также называют качеством сервиса (quality of service, QoS), поскольку понятие «качество сервиса» является более привычным и понятным для заказчика. Для записи функциональных требований при применении гибких методологий наиболее распространенной формой является пользовательская история (user story). Согласно ISO/IEC/IEEE 26515-2011 пользовательская история должна включать [3]: - роль пользователя; - цель, которая достигается пользователем; - ценность для заказчика/пользователя; - критерии приемки, позволяющие определить, что пользовательская история реализована (acceptance criteria). Традиционно пользовательские истории записываются на карточке, в которой указывается идентификатор, название, текст истории, критерии приемки пользовательской истории и ее оценка (приоритет, риск, оценка объема работ и т. д.). Приоритет пользовательской истории может быть комбинацией ценности для бизнеса, приоритета клиента и других критериев в зависимости от выбранной стратегии определения приоритетов историй. Популярным способом оценки объема работ является абстрактная единица размера, называемая сторипоинт (story point). Данная метрика имеет смысл для конкретного проекта и позволяет произвести оценку сложности пользовательской истории по сравнению с некоторой пользовательской историей проекта. В начале работы над проектом команда разработки определяет самую простую для реализации пользовательскую историю (из имеющихся), а затем производит оценку остальных историй относительно нее. К настоящему времени разработано множество вариаций шаблонов карточек. На рис. 1 представлен типовой шаблон карточки пользовательской истории. Рис. 1. Шаблон карточки пользовательской истории Из проведенного анализа следует, что одним из слабых мест работы с карточкой является заполнение критериев приемки, поскольку они обычно записываются в свободной форме. В автоматизированных системах управления гибкими проектами пользователю обычно предоставляется текстовое поле под написание истории и критериев принятия. И если типовая формулировка пользовательских историй знакома участникам гибких команд, то написание критериев может вызывать затруднения. Проведенный опрос показал, что критерии принятия зачастую не указываются, что в дальнейшем вызывает проблемы при написании части проверочных тестов. Крайне важной частью работы с требованиями является оценка приоритетов и рисков реализации пользовательских историй. Наиболее простым, с точки зрения организации процесса оценивания, является ранжирование по качественной шкале (например, «высокий», «средний» и «низкий»). При этом количество делений шкалы обычно выбирается от 3 до 9. Оценка может производиться по разным наборам параметров. Количество измерений чаще всего выбирается равным двум, т. к. это удобно представить в виде матрицы. Пример матрицы для определения приоритета пользовательской истории по двум измерениям - ценность для бизнеса и срочность - представлен на рис. 2. Рис. 2. Пример матрицы для определения приоритета Для оценки каждого измерения можно использовать опросник, который позволит легко ответить на вопросы, какую ценность для бизнеса представляет пользовательская история и как быстро заказчик хочет получить ее реализацию (в этом спринте, не позднее следующего, в течение двух-трех спринтов и т. д.). Оценка срочности может быть построена исходя из количества зависимостей других пользовательских историй от рассматриваемой истории. Например, критический уровень зависимости других элементов программного продукта от реализации пользовательской истории может соответствовать ситуации, когда программный продукт без реализации истории не пригоден к использованию или функциональность работает частично. Оценка риска реализации каждой пользовательской истории может производиться по видам рисков в два этапа. На первом этапе оценки для каждого вида риска может быть построена матрица, где первое измерение - вероятность возникновения, второе - последствия, каждое из которых измеряется по качественной шкале (рис. 3). Рис. 3. Определение уровня риска для каждого вида На втором шаге каждой пользовательской истории присваивается значение уровня риска, равное максимуму по всем классам: где R1, R2, …, Rn - уровни рисков, полученные на шаге 1. Текст пользовательской истории обычно служит основанием для проведения беседы между командой разработки и владельцем продукта (заказчиком) с целью выяснения деталей реализации. Инженерия требований при гибком подходе к разработке программных продуктов является итеративным процессом, а требования эволюционируют в каждом спринте. Спринт - это отрезок времени, за который команда разработки создает пригодную к эксплуатации версию программного продукта (инкремент). Для каждой пользовательской истории, реализуемой в спринте, должны быть установлены критерии приемки - набор утверждений, которые определяют как функциональные, так и нефункциональные требования для разработки пользовательской истории, и имеют ясные критерии определения удачного и неудачного результатов реализации. Критерии приемки могут быть записаны в различных форматах. Существует два основных подхода: правило-ориентированный и сценарно-ориентированный. Правило-ориентированный подход предполагает использование утверждений на естественном языке. Каждое утверждение - это положение, определяющее или ограничивающее детали реализации пользовательской истории. Например, Рекомендации должны быть видны справа на страницах раздела «Новинки» или Пользователь должен видеть только те поля, которые соответствуют выбранному варианту оплаты. В рамках гибкого подхода BDD (behaviour-driven development - разработка на основе поведения) для описания сценариев, раскрывающих пользовательские истории, применяется нотация Gherkin, в которой используется следующая схема записи: Допустим <условие 1> [И / Но < условие 2> … И / Но < условие N>] Когда <выполняется действие 1> [ И / Но < выполняется действие 2> … И / Но < выполняется действие M>] Тогда <результат 1> [И / Но < результат 2> … И / Но < результат K>] Оператор «И» используется, когда пользователь должен выполнить действие, например: Когда я залогинился в системе, И я выбрал «Запомнить меня»… Оператор «Но» используется, когда пользователь не должен выполнять действие, например: Когда я залогинился в системе, Но я не выбрал «Запомнить меня»… И пользовательские истории, и сценарии на языке Gherkin представляют собой тексты на контролируемом естественном языке (controlled natural language). Простота их формы обеспечивает человекочитаемость, достижение понимания между стейкхолдерами, бизнес-аналитиками и технической командой. Для обеспечения единообразия записи требований при правило-ориентированном подходе можно следовать паттернам описания бизнес-правил, например, нотации RuleSpeak. Нефункциональные требования могут записываться по форме отдельных пользовательских историй, могут рассматриваться как критерии приемки пользовательской истории, а также как часть критериев готовности (definition of done) для каждой итерации программного продукта. Подход и качество определения и реализации нефункциональных требований играет значимую роль. Если нефункциональные требования излишни, то реализация продукта может оказаться очень затратной и невыгодной. Если же эти требования недооценены, то программный продукт может оказаться непригодным для использования. Онтология в области инженерии требований при гибком подходе к разработке В 1993 г. Т. Р. Грубер определил данный термин следующим образом: «Онтология - это явная спецификация концептуализации» [17]. Термин «онтология» заимствован из философии, где он означает учение об общих категориях и закономерностях бытия. В информатике под онтологией понимается набор репрезентативных примитивов, таких как классы (или наборы), атрибуты (или свойства) и взаимосвязи (или отношения между членами класса), с помощью которых можно моделировать некоторую область знаний [18]. Основная задача языков описания онтологий - это представление семантически связанных данных предметной области. В настоящее время выделяется три группы языков описания онтологий: формализованные технические языки на базе естественных (например, язык Gellish), машинно-ориентированные языки (например, CycL) и универсальные языки, основанные на веб-стандартах (XML, RDF и т. д.) [19]. Для реализации поставленной в работе задачи был выбран рекомендуемый консорциумом W3C онтологический язык Web Ontology Language (OWL), поддерживающий дескриптивную логику и стандарты семантической разметки. Одной из ключевых особенностей OWL DL является возможность их обработки при помощи резонера (машины логического вывода). Резонер обеспечивает решение таких задач, как проверка консистентности, классификация (вычисление всех предполагаемых подклассов) и определение типов индивидов и их принадлежности к определенному классу. OWL-онтологию можно представить следующим кортежем: , где - конечное непустое множество классов (концептов), описывающих основные понятия предметной области; - конечное множество бинарных отношений, заданных на классах, , включая антисимметричное, транзитивное, нерефлексивное отношение иерархии ; Ао - конечное множество логических аксиом онтологии; I - множество экземпляров (индивидов) классов. Для построения семантического графа онтологии использован редактор онтологий и фреймворк для построения баз знаний Protégé 5.2. Каждый класс OWL-онтологии является дочерним классом предопределенного класса owl:Thing, содержащего все объекты предметной области. На рис. 4 показана таксономия классов верхнего уровня. Рис. 4. Классы верхнего уровня Описание назначения классов верхнего уровня приведено в таблице. Классы верхнего уровня Класс Описание AttributeOfUserStory Класс, подклассами которого являются атрибуты пользовательских историй, такие как приоритет, уровень риска и т. д. BacklogProject Класс, подклассами которого являются бэклоги проекта (журналы оставшейся работы) LevelOfEvaluation Класс, подклассами которого являются качественные шкалы, используемые при оценке приоритетов, рисков и т. д. Product Концепт, соответствующий понятию «программный продукт». Включает подкласс «инкремент продукта», экземплярами которого являются версии разрабатываемого продукта ProductFeature Класс, экземплярами которого являются разрабатываемые функциональности продукта Requirement Класс, содержащий подклассы, соответствующие понятию «требование» RequirementsArtefact Класс, содержащий подклассы, соответствующие понятию «артефакт требования» RequirementType Класс, содержащий подклассы, описывающие классификацию типов требований RiskClass Класс, содержащий подклассы, описывающие классификацию рисков Stakeholder Концепт, соответствующий понятию «стейкхолдер» StatusReq Класс, содержащий подклассы, описывающие классификацию статусов, которые могут быть назначены требованиям StructuralElement Класс, содержащий подклассы, описывающие структурные элементы, которые должны включать требования, записанные при помощи определенной техники Task Класс, экземплярами которого являются задачи, выполняемые командой разработки Theme Класс, экземплярами которого являются темы, объединяющие несколько пользовательских историй TeamMember Класс, содержащий подклассы, описывающие роли в команде TestType Класс, содержащий подклассы, описывающие классификацию типов тестов СonstraintType Класс, содержащий подклассы, описывающие виды ограничений для нефункциональных требований Построение онтологии в области инженерии требований произведено исходя из понимания термина требования, приведенного в предыдущем разделе. Утверждения, зафиксированные в форме пользовательских историй, рассматриваются как подклассы класса «Requirement». Также подклассами класса «Requirement» являются критерии приемки и критерии готовности. Критерии приемки и критерии готовности записываются в форме сценариев поведения или правил. Требованием верхнего уровня будем считать пользовательские истории. Крупные пользовательские истории, называемые эпиками, подразделяются на более мелкие пользовательские истории. Пользовательские истории группируются по темам. Поскольку критерии приемки и критерии готовности представляют собой также информацию о требованиях, которая создается, изменяется и используется в процессе реализации требований, отнесем их также к классу «RequirementsArtefact». Онтология хранит информацию о требованиях, артефактах требований, источниках требований, включая стейкхолдеров, и участниках команды, добавляющих требования в форме знаний об экземплярах классов. Установленные между экземплярами отношения могут использоваться для идентификации прямо или косвенно затрагиваемых требований и артефактов при внесении изменений в требования к программному продукту. На рис. 5 показаны свойства объектов (object properties), отражающие отношения между концептами онтологии. Рис. 5. Свойства объектов На рис. 6 представлены связи структурных элементов пользовательской истории с использованием отношений «hasActionGoalUser», «hasGoalUser», «hasObjectGoalUser», «hasUserBenefit», «hasUserRole». Рис. 6. Структура пользовательской истории В онтологической модели определены правила оценки синтаксического качества пользовательских историй и сценариев поведения. Рассмотрим пример качества «Хорошая формализованность пользовательской истории». Это качество реализуется следующими правилами: IF UserStory has (UserRole and WellFormedGoalUser and UserBenefit) THEN UserStory is WellFormedUserStory. IF UserGoal has (ActionUserGoal and ObjectUserGoal) THEN UserGoal is WellFormedGoalUser. На рис. 7 приведены соответствующие этим правилам аксиомы. Рис. 7. Аксиомы для оценки качества «Хорошая формализованность пользовательской истории» Критерий качества «Хорошая формализованность» (Well-formed) предполагает, что пользовательская история включает в себя роль, цель пользователя и получаемую выгоду. Цель пользователя грамматически состоит из глагола действия и объекта, на который направлено действие. Экземпляры данных классов могут быть получены вручную или извлекаться автоматически из текста пользовательских историй. Для автоматического извлечения действия и объекта из текста пользовательской истории может применяться Томита-парсер от компании Yandex. Далее рассмотрим пример аксиомы для определения приоритета пользовательской истории. На рис. 8 дано описание низкого уровня приоритета по шкале, представленной на рис. 2. Рис. 8. Аксиома «Низкий уровень приоритета» В онтологии выделены классы для определения уровня риска, а также классы, соответствующие распространенным рискам разработки в гибких проектах (рис. 9). Рис. 9. Типы и уровни рисков Для обеспечения возможности проверки качества свойства трассируемости требований определены связи между артефактами требований. В онтологию введены два класса отношений - это свойства объекта «traceFrom» и «traceTo». Первый класс отношений включает подклассы, которые позволяют трассировать вверх, второй - вниз. Подклассами отношения «traceFrom» являются отношения: 1 - «isTestedBy»; 2 - «checks»; 3 - «refines»; 4 - «hasSource». Отношение «isTestedBy» позволяет найти набор тестов, которыми тестируется функциональная часть программного продукта. Отношение «checks» показывает, какие критерии принятия проверяются тестом. Отношение «refines» означает, что требование уточняет другое требование и добавляет более подробную информацию. Отношение «refines» включает подклассы: 3.1 - «isVariantScenario»; 3.2 - «isKeyScenarioOfUserStory»; 3.3 - «isRule»; 3.4 - «isPartOf». Отношение «isVariantScenario» показывает связь с ключевым сценарием, который детализирует сценарий поведения. Отношение «isKeyScenarioOfUserStory» показывает связь с пользовательской историей, которую детализирует критерий принятия, сформулированный с помощью сценарно-ориентированного подхода. Отношение «isRule» показывает связь с пользовательской историей, которую детализирует критерий принятия, сформулированный с помощью правило-ориентированного подхода. Отношение «isPartOf» показывает связь с пользовательской историей, которую детализирует другая пользовательская история. Для отношения «traceFrom» и включенных в него отношений заданы обратные свойства - «Inverse Of».Это позволяет выполнять трассирование вниз при помощи отношения «traceTo». На рис. 10 приведена иерархия классов для отношения «traceFrom» и типы доменов и диапазонов для каждого из подклассов отношений. Рис. 10. Отношение «traceFrom» При описании отношений между экземплярами классов отношения «traceFrom» и «traceTo» непосредственно не задаются, они выводятся средствами рассуждения и могут использоваться. Проверка корректности работы предлагаемой онтологии была проведена на наборе тестовых экземпляров классов с помощью резонера HermiT и SQWRL-запросов. Рассмотрим пример SQWRL запроса для трассировки требования вверх. На рис. 11 приведен пример экземпляра пользовательской истории, для которой через отношение «hasScenario» указан ключевой сценарий поведения. Рис. 11. Пример трассировки вверх Для сценария поведения через отношение «hasVariantScenario» указан вариант сценария. В результатах выполнения запроса обрабатываются заданные обратные свойства - «Inverse Of». В результате выполнения запроса в переменную х выбираются все экземпляры класса «GherkinScenario». В переменную y выбираются экземпляры требований, которые уточняются ими. Системы поддержки принятия решений Архитектура разрабатываемой системы поддержки принятия решений состоит из интерфейса пользователя, приложения на языке Python, включающего машину логического вывода, OWL-онтологии и файловой базы данных (рис. 12). Рис. 12. Архитектура системы поддержки принятия решений Для манипулирования над экземплярами онтологии без использования среды Protégé был разработан прототип приложения. На рис. 13 представлен снимок экранной формы для внесения данных о пользовательской истории. Рис. 13. Экранная форма для ввода пользовательской истории При разработке приложения использован язык программирования Python 3.7.0 с библиотекой для онтолого-ориентированного программирования Owlready2 и библиотекой для создания графического интерфейса пользователя PyQt5. Библиотека Owlready2 позволяет загружать онтологии OWL 2.0 как объекты Python, изменять их, сохранять и выполнять рассуждения с помощью резонера HermiT. В OWL-файле сохраняется основная часть данных, которые обрабатывает система - это данные об экземплярах классов. Вспомогательные данные сохраняются в базе данных системы. К таким данным, например, относится путь к OWL-файлу проекта, счетчики требований по проекту, которые необходимы для задания их идентификаторов в системе. Заключение В результате проведенного исследования была предложена система поддержки принятия решений для процесса инженерии требований при гибком подходе. Инженерия требований предполагает получение и анализ информации из различных источников, в том числе от множества стейкхолдеров. Понимание потребностей стейкхолдеров, определение приоритетности требований и оценка рисков реализации являются жизненно важными задачами для проектов по разработке программного обеспечения. На основе техник работы с требованиями при гибком подходе к разработке программного обеспечения была разработана OWL-онтология, которая включает знания о наиболее популярных техниках записи гибких требований и их оценки. Применение разработанной системы позволяет уменьшить число ошибочных решений при управлении требованиями к программному обеспечению.
1. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. URL: https://www.infoq.com/ articles/ standish-chaos-2015 (дата обращения: 20.07.2018).
2. Moccia J. Agile Requirements Definition and Management (RDM): How Agile requirements help drive better results. Atlanta: OneSpring LLC, 2013. 5 p.
3. ISO/IEC/IEEE 26515:2011(E). Systems and software engineering. Developing user documentation in an Agile environment (Version 1.0, 2011-12-01).
4. Ajmeri N., Sejpal R., Ghaisas S. A Semantic and Collaborative Platform for Agile Requirements Evolution // Global Journal of Researches in Engineering. 2010. V. 10. Iss. 6 (Ver 1.0). P. 2-8.
5. Dobson G., Sawyer P. Revisiting Ontology-Based Requirements Engineering in the age of the Semantic Web // Dependable Requirements Engineering of Computerised Systems at NPPs. Halden: Institute for Energy Technology (IFE), 2006. 12 p.
6. Heck P., Zaidman A. A quality framework for agile requirements: a practitioner's perspective. URL: https://arxiv.org/abs/1406.4692 (дата обращения: 20.07.2018).
7. Lucassen G., Dalpiaz F., van der Werf J., Brinkkemper S. Improving agile requirements: the quality user story framework and tool // Requirements Eng. 2016. V. 21 (3). P. 383-403.
8. Lucassen G., Dalpiaz F., van der Werf J., Brinkkemper S. Forging High-quality user stories: towards a discipline for agile requirements // Proceedings of the IEEE 23rd International Requirements Engineering Conference (RE). Ottawa, ON, Canada, 2015. P. 126-135.
9. Adnan M., Afzal M. Ontology Based Multiagent Effort Estimation System for Scrum Agile Method // IEEE Access. 2017. V. 5. P. 25993-26005.
10. Thamrongchote С., Vatanawood W. Business process ontology for defining user story // 15th International Conference on Computer and Information Science (ICIS) (Okayama, Japan, 26-29 June, 2016). 2016. Vol. 00. P. 1-4. DOI:https://doi.org/10.1109/ICIS.2016.7550829.
11. Sitthithanasakul S., Choosri N. Using ontology to enhance requirement engineering in agile software process // 10th International Conference on Software, Knowledge, Information Management & Applications (SKIMA 2016) (Chengdu, China, 15-17 December, 2016). NY: Curran Associates, Inc., 2016. P. 181-186.
12. Kaiya H., Saeki M. Ontology Based Requirements Analysis: Lightweight Semantic Processing Approach // Proc. QSIC '05 Proceedings of the Fifth International Conference on Quality Software (Melbourne, Australia, September 19-20, 2005). 2005. P. 223-230. DOI:https://doi.org/10.1109/QSIC.2005.46.
13. Goknil A., Kurtev I., van den Berg K. A Metamodeling Approach for Reasoning about Requirements // Proc. Int. Conf. on Model Driven Architecture - Foundations and Applications (Springer-Verlag Berlin Heidelberg). 2008. P. 310-325.
14. Kroha P., Janetzko R., Labra J. E. Ontologies in Checking for Inconsistency of Requirements Specification // Third International Conference on Advances in Semantic Processing (11-16 October, Sliema, Malta). 2009. P. 32-37. DOIhttps://doi.org/10.1109/SEMAPRO.2009.11.
15. Siegemund K. Contributions To Ontology-Driven Requirements Engineering: Dissertation to Obtain the Academic Degree Doctoral Engineer (Dr.-Ing.). Dresden: Technischen Universität Dresden, 2014. 236 p.
16. Пустовалова Н. В., Авдеенко Т. В. Построение согласованной модели требований для процесса программной инженерии // Тр. СПИИРАН. 2016. № 1 (44). С. 31-49.
17. Gruber T. A Translation Approach to Portable Ontology Specifications. California: Stanford University, 1993. 26 p.
18. Gruber T. Ontology // Entry in the Encyclopedia of Database Systems. Boston, MA, USA: Springer, 2009. Р. 1963-1965. DOI:https://doi.org/10.1007/978-0-387-39940-9_1318.
19. Буракова Е. Е., Боргест Н. М., Коровин М. Д. Языки описания онтологий для технических предметных областей // Вестн. Самар. гос. аэрокосм. ун-та им. акад. С. П. Королева. 2014. № 3 (45). С. 144-158.
