Содержание к диссертации
Введение
Глава 1 Поддержка принятия решений в области инженерии требований при управлении проектами разработки программных продуктов 12
1.1 Роль инженерии требований в успешности проекта по разработке программного продукта 12
1.1.1 Теория управления проектами как раздел теории управления социально-экономическими системами 12
1.1.2 Инженерия требований как область знаний 19
1.1.3 Инженерия требований и управление проектами 23
1.1.4 Характеристики качества требований 30
1.2 Инженерии требований и инженерия знаний 35
1.2.1 Инструментальные средства в области инженерии требований 35
1.2.2 Представление знаний в инженерии требований 37
1.2.3 Применение онтологий в инженерии требований 41
1.2.4 Применение лексических онтологий при извлечении и анализе требований 47
1.3 Выводы по главе 1 52
Глава 2 Онтолого-ориентированный подход к инженерии требований 54
2.1 Построение онтологии для инженерии требований 54
2.1.1 Формализованная модель онтологий 54
2.1.2 Модель онтологии для информационной поддержки процесса инженерии требований при гибком управлении проектом 57
2.1.3 Модель онтологии предметной области программного продукта 63
2.2 Реализация моделей онтологий в среде Protg 5.2 71
2.3 Выводы по главе 2 81
Глава 3 Извлечение и анализ требований на основе онтологической и продукционной моделей 82
3.1 Возможности автоматической обработки текстов требований на русском языке 82
3.2 Извлечение экземпляров онтологии из текстовых требований 99
3.2.1 Универсальные зависимости в разметке текста 99
3.2.2 Извлечение экземпляров классов онтологии 105
3.3 Анализ требований на основе онтологической и продукционно-логической моделей 110
3.4 Выводы по главе 3 124
Глава 4 Реализация системы поддержки принятия решений в области инженерии требований 126
4.1 Технологические инновации в системе управления проектом 126
4.2 Архитектура и описание СППР 130
4.3 Поддержка процесса управления проектом в СППР 140
4.4 Модуль «Анализ требований» 151
4.5 Выводы по главе 4 157
Заключение 158
Список сокращений и условных обозначений 160
Список литературы 162
Список иллюстративного материала 188
- Теория управления проектами как раздел теории управления социально-экономическими системами
- Модель онтологии для информационной поддержки процесса инженерии требований при гибком управлении проектом
- Универсальные зависимости в разметке текста
- Модуль «Анализ требований»
Теория управления проектами как раздел теории управления социально-экономическими системами
Теория управления проектами представляет собой раздел теории управления социально-экономическими системами, который изучает методы, формы и средства эффективного и рационального управления изменениями [10].
Проект – «это временное предприятие, направленное на создание уникального продукта, услуги или результата» [54, C.4]. Проекты реализуются путем создания поставляемых результатов. В случае проектов по разработке программного обеспечения поставляемым результатом будет готовый к использованию программный продукт.
Основные рамки управления проектом, которые действуют вне зависимости от особенностей конкретных работ по осуществлению проекта, определяет жизненный цикл проекта. По мнению Воропаева В.И. , наиболее общее и ясное представление о жизненном цикле проекта дано в Руководстве PMBOK (Project Management Body of Knowledge) [14].
Согласно Руководствy PMBOK, жизненный цикл проекта – это набор фаз, через которые проходит проект от момента его начала до завершения. Фазы проекта могут быть последовательными, итеративными или накладываться друг на друга. Жизненный цикл проектов может быть предиктивным или адаптивным (agile), может включать в себя одну или несколько фаз, связанных с разработкой продукта. Такие фазы называют жизненным циклом разработки или жизненным циклом развития. Согласно Руководствy PMBOK, модели жизненного цикла развития могут быть предиктивными, итеративными, инкрементными, адаптивными или гибридными.
Управление проектом – «это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту» [54, C.10]. Управление проектами как самостоятельная дисциплина зарождается в 1930-х гг. Современная концепция управления проектами сформировалась к середине 1950-х гг. в США. В 1980-х годах в США публикуется первая версия Руководства PMBOK [14]. На настоящий момент Руководство PMBOK является одним из самых известных зарубежных документов, стандартизирующих управление проектами. В каждом новом издании Руководства PMBOK излагаются передовые методы управления проектами. В 2017 г. вышла уже шестая версия Руководства PMBOK.
Методологические основы современного российского управления проектами были заложены в 1990-x гг. Воропаевым В.И. [10, 27]. В отечественной науке широко известна его системная модель управления проектами, представляющая собой свернутое дерево избыточного множества задач и процедур, которые могут реализовываться в процессе управления проектом. Системная модель управления проектом содержит три блока: субъекты управления, объекты управления и процесс управления [15].
Субъектами управления являются активные участники проекта, которые взаимодействуют при разработке и принятии управленческих решений в процессе реализации проекта. Объектами системы управления могут быть: программы проектов, проекты, контракты, фазы жизненного цикла объекта управления. Процесс управления выполнением проекта реализуется посредством прямой и обратной связей между субъектами и объектами управления. Процесс управления включает уровни управления, функции управления и стадии процесса управления.
Применение принципов системного подхода к управлению проектами предполагает рассмотрение проекта как социально-экономической системы. Социально-экономической системой называется сложная динамическая система, в которой люди, выступая главными ее элементами, осуществляют процесс производства, обмена, распределения и потребления востребованных материальных и нематериальных благ и знаний, необходимых для функционирования и развития общества [7, 62]. Классическими примерами социально-экономических систем является предприятие или отрасль, к которой относится предприятие. При этом отрасль по отношению к предприятию является системой более высокого порядка. Моделирование социально-экономических систем на сегодняшний день – это важный этап процедуры принятия решения, которая традиционно относится к сфере управления.
В научной и профессиональной литературе дается множество определений термина «управление». Среди них есть и определение управления как процесса, и как воздействия, и как функции и т.п. Чтобы объяснить «многогранность» данного термина, Новиков Д.А. предлагает рассматривать управление, осуществляемое субъектом, как вид деятельности. Методология управления сосредоточена на организации управленческой деятельности, которую осуществляет человек или группа людей, а теория управления – на взаимодействии субъекта управления и управляемой системы (см. рисунок 1.1). Обобщением закономерностей успешной практики управленческой деятельности занимается «философия» менеджмента, а исследованием наиболее общих закономерностей управления – кибернетика [46]. Термин «кибернетика» в его современном понимании ввел в научный оборот Н. Винер в книге «Кибернетика», где описал подход к исследованию нелинейных систем при помощи «черного» и «белого» ящиков, определил механизм прямой и обратной передачи информации [11].
Модель онтологии для информационной поддержки процесса инженерии требований при гибком управлении проектом
Построение онтологии для информационной поддержки процесса инженерии требований при гибком управлении проектом будем производить, исходя из следующего понимания термина «требование»: это утверждение о некотором свойстве программного продукта. Когда требование задокументировано, возникает артефакт требования. Знания о процессе управления гибким проектом будут основываться на подходе, применяемом во фреймворке Scrum. Знания о характеристиках качества требований – на основе модели качества программного продукта ГОСТ Р ИСО /МЭК 25010-2015. В разрабатываемой онтологии учитывается техника написания пользовательских историй и сценарии на языке Gherkin. Иерархическая структура основных классов онтологии приведена на рисунке 2.1.
К классам верхнего уровня отнесены следующие концепты предметной области: Элемент фреймворка Scrum, Груминг-встреча, Структурный элемент, Задача по элементу бэклога продукта, Статусы задач, Aртефакт требований, Критерий готовности, Критерий подготовности, Риски, Классы рисков, Вид характеристики качества требований, Группа характеристик качества, Группа стейкхолдера, Значения порядковых шкал, Цели тестирования, Виды тестов.
В классе «Элемент фреймворка Scrum» выделяются подклассы: Scrum-команд, роли в Scrum-команде, события и артефакты. Согласно Руководству по Scrum к элементам фреймворка Scrum также относятся правила. Основные правила будут преобразованы в утверждения о связях экземпляров классов остальных элементов фреймворка Scrum.
В Руководстве выделены первые три роли, четвертая роль вводится для возможности описания состава команды разработки. Класс «Артефакт» включает подклассы: бэклог продукта, бэклог спринта, инкремент. Класс «Статус» предназначен для задания статусов для элементов бэклога и задач, в нем выделяется соответственно два класса. Класс «Событие» – подклассы: спринт, обзор спринта, планирование спринта, ежедневный Scrum-митинг, ретроспектива спринта.
Класс «Груминг-встреча» необходим для накопления информации о встречах Scrum-команды, на которых происходит актуализация, уточнение и оценивание элементов бэклога продукта. Экземпляры данного класса будут соответствовать факту проведения груминга и содержать связи с составом участников и временем проведения данных встреч, что может быть полезно при трассировке требований.
В классе «Структурные элементы» выделяются подклассы «Структурный элемент бэклога продукта», «Структурный элемент бэклога спринта», «Структурный элемент дерева функциональных возможностей», «Структурный элемент Видения продукта», «Структурный элемент пользовательской истории», «Структурный элемент карточки», «Структурный элемент сценария поведения».
В классе «Структурный элемент бэклога» выделяются подклассы: пользовательская история, дефект, техническая работа, накопление знаний. Класс «Эпик» является подклассом класса «Пользовательская история», поскольку эпик – это пользовательская история с большим объемом работы, которую необходимо разделить на несколько пользовательских историй. Понятие «Тема» используется для обозначения группы связанных элементов бэклога продукта. Класс «Тема» включает в себя два подкласса «Функциональная возможность» и «Эпик». После внесения элемента бэклога продукта в план спринта для элемента указывается перечень задач. Экземпляры задач составляют класс «Задача».
Класс «Структурный элемент карточки» используется для указания атрибутов карточки элемента бэклога продукта. Одним из подклассов данного класса является «Источник элемента бэклога». В классе «Источник элемента бэклога» выделяются подклассы: документ и стейкхолдер. Согласно Руководству по Scrum, владелец продукта отражает интересы и пожелания стейкхолдеров в бэклоге продукта. В случае, если владелец продукта взаимодействует с определенным стейкхолдером, целесообразно зафиксировать его в качестве источника элемента бэклога, в других случая требования к проекту основываются на анализе портрета предполагаемого пользователя, анализе документов, а также на опыте членов команды разработки. В первом случае в качестве источника требований будет указываться владелец продукта, во втором – документ, в третьем – разработчик.
Другими подклассами класса «Структурный элемент карточки» являются критерии принятия, зависимости, проблемы, риски, связанные с выполнением элемента бэклога продукта, возникающие вопросы, зависимости. Класс «Критерии приемки» включает два подкласса: функциональный критерий и нефункциональный критерий.
В классе «Стейкхолдер» выделяются подклассы: пользователь, заказчик орган власти, инвестор, участник Scrum-команды. При разработке документа «Видение продукта» необходимо определить список стейкхолдеров. Знание о типовых классах стейкхолдеров облегчают данную задачу для разработчика документа «Видение продукта». Класс «Пользователь» в свою очередь содержит два подкласса: непосредственный пользователь и косвенный пользователь. К непосредственным пользователям относятся основной пользователь и вторичный пользователь. Под основным пользователем понимается лицо, взаимодействующее с программным продуктом для достижения основных целей. Под вторичным пользователем понимается лицо, которое осуществляет поддержку программного продукта (например, системный администратор). Косвенный пользователь – это лицо, которое получает результаты, но не взаимодействует с программным продуктом. При задании экземпляра класса «Стейкхолдер» может быть указана его группа через класс «Группа стейкхолдера»
Класс «Артефакт требований» включает артефакты документирования требований к программному продукту. К ним относятся видение продукта, дерево функциональных возможностей, пользовательские истории, сценарии поведения (в нотации Gherkin), правила поведения. Класс «Структурный элемент» включает семь подклассов: структурный элемент видения продукта, структурный элемент дерева функциональных возможностей, структурный элемент пользовательской истории, структурный элемент функциональности пользовательской истории, структурный элемент сценария поведения, структурный элемент бэклога продукта, структурный элемент бэклога спринта.
Структурными элементами документа «Видение продукта» являются цель продукта, целевая аудитория, которая состоит из списка стейкхолдеров, перечня потребностей, для которых создается программный продукт, перечня функциональных возможностей, которые должны присутствовать в программном продукте, а также перечня бизнес-целей. Структурными элементами пользовательской истории являются роль пользователя, функциональность продукта, которая необходима пользователю, и выгода, которую получает пользователь от функциональности продукта. Структурными элементами сценария поведения являются условие, действие, результат.
Универсальные зависимости в разметке текста
Языковой корпус представляет собой репрезентативную выборку текстов, размеченную по определенным правилам. Языковые корпуса используются для обучения языковых моделей. Среди языковых моделей, используемых синтаксическими парсерами, в последние несколько лет на первый план вышли модели, разрабатываемые в рамках проекта «Универсальные зависимости» (Universal Dependencies, UD). Идея проекта заключается в создании кросс-языковой нотации разметки языковых корпусов с учетом специфики национальных языков. Аннотации разметки «Универсальные зависимости» записываются в виде текстовых файлов в формате CoNLL-U.
Список частей речей является фиксированным и состоит из 17 тегов частей речи, которые подразделяются на самостоятельные (знаменательные) части речи, служебные части речи и дополнительные теги.
К самостоятельным частям речи относятся грамматические классы слов, обозначающие фрагменты действительности (предмет, событие, признак) и обладающие системой формообразования и словоизменения, определяющейся грамматической семантикой. К служебным частям речи относятся грамматические классы, используемые для выражения отношений между понятиями, которые выражают самостоятельные части речи. К категории «другие части речи» относятся символы и нераспознанные анализатором части речи.
Отдельно взятый язык может не поддерживать все позиции списка тегов частей речи, но не может использовать дополнительные теги частей речи. Аннотированный корпус русского языка UD-Russian-SynTagRus использует все 17 тегов частей речи, которые приведены в таблице 3.1. В колонке «Пример использования тега в требованиях» данной таблицы жирным шрифтом выделены слово (символы), соответствующие тегу части речи из строки «Тег».
Лексические и грамматические признаки слов задаются при помощи тегов морфологических признаков. Состав тегов морфологических признаков не является предопределенным, как состав тегов частей речи. Для каждого языка используются специфичные именно для него морфологические признаки.
Морфологические признаки частей речи, используемые в аннотированном корпусе русского языка UD-Russian-SynTagRus, приведены в таблице 3.2.
Функциональная группа показывает отношение к родительскому слову в дереве зависимостей. С точки зрения лингвистики словосочетания в предложении состоят из главного и зависимого слов. Функциональные группы зависимого слова по отношению к главному слову в словосочетании подразделяются на следующие:
- актант (core argument) - это слово-терм, зависимое от предиката (обычно, глагола) и представляющие собой субъект или объект действия,
- сирконстант (non-core dependent) - слово-терм, зависимое от предиката, и представляют собой обстоятельства, при которых совершается действие, зависимое имя (nominal dependent) - это имена (прилагательные или существительные), которые должны согласоваться по морфологическим признакам с главным словом в словосочетании.
Для остальных функциональных категорий, используемых в деревьях зависимостей, родительское слово не тождественно понятию «главное слово» в словосочетании в принятом в лингвистике смысле.
Для конкретного языка могут использоваться не все теги, а также допускается использование подтипы тегов (например, flat:foreign). Из предопределенного списка тегов синтаксических зависимостей в аннотированном корпусе русского языка UD-Russian-SynTagRus использовано 32 тега, которые приведены в таблице 3.4.
В колонке «Пример использования тега в требованиях» данной таблицы курсивным шрифтом выделено родительское слово, а жирным – дочернее.
Модуль «Анализ требований»
Разработанный модуль «Анализ требований» обеспечивает выполнение следующих функций:
- построение системы продукционно-логических правил для обработки отношений между экземплярами классов онтологии и сохранение их в виде модели в файл в формате XML (с расширением файла .confl),
- редактирование системы продукционно-логических правил, ранее сохраненных в виде модели,
- применение правил модели к требованиям, представленным в виде экземпляров классов OWL-онтологии.
Для реализации первой функции создан конструктор, который помогает пользователю в несколько «кликов» построить систему правил для анализа отношений между элементами требований. Экранная форма первого шага работы конструктора приведена на рисунке 4.29.
На первом шаге необходимо указать путь к файлу с OWL-онтологией, для которой строится модель, и указать путь к файлу, куда сохранять саму модель. На втором шаге необходимо определить, какие классы онтологии соответствуют элементам «актор», «действие» и «объект» (см. рисунок 4.30).
На третьем шаге необходимо выбрать свойства объектов, которые будут использованы для анализа. Данный шаг состоит из трех подшагов: на первом выбираются свойства-отношения между акторами требований (см. рисунок 4.31), на втором – между действиями (см. рисунок 4.32), на третьем – между объектами (см. рисунок 4.33). Это позволяет конечному пользователю самостоятельно определять правила обработки имеющихся у него данных.
На четвертом шаге работы приложения выдаются сгенерированные комбинации антецедентов для продукционно-логических правил. Пользователю необходимо определить консеквенты правил, выбрав тип отношения между требованиями для каждого правила. На рисунке 4.34 представлена экранная форма последнего шага построения модели.
Полуавтоматическая генерация правил не позволяет пользователю пропустить какое-либо правило, поскольку покрывает все возможные сочетания для антецедентов правил. При необходимости пользователь может завершить работу по формированию модели в любой момент и продолжить ее позже. Для этого в программе предусмотрена функция «Редактирование модели», которая состоит из двух шагов. Первый шаг – это выбор файла с моделью (см. рисунок 4.35).
Применение правил модели к требованиям, представленным в виде экземпляров классов OWL-онтологии, выполняется с помощью функции «Поиск конфликтов», которая состоит из двух шагов. На первом шаге указываются файлы с OWL-онтологией и с моделью для анализа требований (см. рисунок 4.37).
В ходе анализа требований данные об экземплярах классов и отношениях между ними, а также правила модели импортируются в базу фактов на языке Prolog (см. рисунок 4.39).
Аналогичным образом преобразовываются все правила модели. После наполнения внутренней базы фактов осуществляется решение задачи поиска конфликтов средствами SWI-Prolog. Для реализации указанной функциональности использованы Python-библиотека PySwip и среда разработки SWI-Prolog 7.6.4.
В файле отчета сначала перечисляются конфликтующие требования, далее дополнительно перечисляются дубликаты требований и требования, которые система посчитала пересекающимися. Для сделанных выводов указываются номера правил, чтобы при необходимости пользователь мог проверить выводы системы.
Для оценки работы модели была проведены эксперименты на наборах пользовательских историй, которые включали тексты самих историй и тексты критериев принятия историй. В ходе эксперимента добавлялось новое требование и производилась его сравнение с набором требований.