Библиографическое описание:

Куликов Г. Г., Яковлев Н. Н., Бармин А. А., Бармина О. В. Использование семантической аннотации для управления требованиями к IT-проектам // Молодой ученый. — 2012. — №12. — С. 133-138.

Успех программного продукта зависит не только от профессионализма команды, но и от обеспечения понимания всеми участниками целей проекта. Обеспечение участников полными, непротиворечивыми, достоверными сведениями для разработки позволяет достичь завершения проекта за меньшее число итераций и с меньшими трудозатратами. Управление требованиями позволяет актуализировать требования на всех этапах жизненного цикла программного продукта. В данной статье предлагается идентификация требований использованием семантической аннотации, а также прогнозирование характеристик требований на основе исторических данных. Аннотирование требований с использованием семантической аннотации позволяет сократить время их поиска и повысить долю повторного использования программного кода за счет возможности поиска сходных требований.
Ключевые слова: управление требованиями, семантическое расстояние, разработка программного обеспечения, повторное использование.
Введение
Основным инструментом автоматизации деятельности современного крупного предприятия является информационная система. Информационная система — это совокупность программного, аппаратного и организационного обеспечения, а также персонала, предназначенная для своевременного обеспечения лиц принимающих решения необходимой информацией. Разработку сложной информационной системы нельзя выполнить за один проход — итерацию. Это связано как со сложностью создания самой системы, так и со сложностью автоматизируемого процесса. На современном этапе развития информационных технологий разработку информационных систем выполняют в несколько итераций. Итеративная разработка соответствует спиральной модели жизненного цикла. Результатом каждой итерации является законченная версия информационной системы.
Каждая итерация в соответствии со стандартом ISO 15288-2002 состоит из следующих стадий:
  1. концепция;
  2. разработка;
  3. поставка;
  4. использование;
  5. поддержка;
  6. снятие с эксплуатации.
Одним из основных этапов в процессе жизненного цикла информационной системы является этап формирования требований, которая входит в стадию концепции. Результатом этой стадии является техническое задание и спецификация требований, на основании которых в дальнейшем и выполняется разработка всей системы.
Требование — это ограничение, которому должна удовлетворять разрабатываемая система или возможность, которую система должна представлять. Управление требованиями — процесс, включающий в себя идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашений и затем управление изменениями и уведомление заинтересованных лиц.
Каждое предприятие уникально и для автоматизации может не быть готовой версии информационной системы, которая поставляется в коробочном варианте и может быть использована с минимальными доработками. Для удовлетворения потребностей подобных предприятий информационные системы создаются на заказ и в большинстве своем, с нуля.
Чем крупнее предприятие, тем большее количество функций автоматизируется. Большое количество выполняемых функций не позволяет завершить доработку коробочной версии информационной системы за одну итерацию, в следствие чего автоматизируемые функции разделяют на несколько итераций в соответствии с приоритетом.
Для получения управляемого процесса разработки требования, получаемые от заказчика, актуализируются так, чтобы они были понятны всем участникам процесса разработки. В наиболее предпочтительном случае требования, полученные от заказчика и обработанные аналитиком должны удовлетворять следующим характеристикам:
  • единичность — требование описывает одну и только одну вещь;
  • завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует;
  • последовательность — требование не противоречит другим требованиям и полностью соответствует документации;
  • атомарность — требование нельзя разделить на более мелкие;
  • отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано;
  • актуальность — требование не стало устаревшим с течением времени;
  • выполнимость — требование может быть реализовано в рамках проекта;
  • недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено;
  • обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
  • проверяемость — реализованность требования может быть проверена.
Любая компания-разработчик старается сократить издержки своих производственных процессов. Основной производственный ресурс — человеческие ресурсы разработчиков и их рациональное использование является приоритетной задачей руководителя проекта. Также важным аспектом работы руководителя проекта является минимизация рисков.
Минимизация рисков достигается с использованием современных методологий гибкой разработки. Такие методологии называются Agile-методологиями. Agile-методологии — семейство процессов разработки, определяемые Agile Manifesto. Существуют несколько методологии, которые придерживаются принципов Agile Manifesto и наиболее распространенным подходом является SCRUM.
Цели и задачи
Целью управления требованиями при управлении проектом является предоставление возможности контроля целостности требований, то есть избежание дублирования и противоречивости требований. Требования могут дублироваться и противоречить друг другу, если в проекте участвует более одного аналитика или проект имеет большую протяженность (один год и более).
Управление требованиями является одним из ключевых процессов в течение всего периода разработки программного обеспечения.
Использование современных методологий и парадигм программирования, таких как объектно-ориентированное программирование, позволяет создавать самостоятельные законченные модули, которые могут быть использованы в нескольких проектах. Возможность повторного использования достигается за счет соблюдения основных принципов объектно-ориентированного программирования: инкапсуляции, наследования и полиморфизма.
Многие бизнес-процессы на предприятиях одной сферы деятельности протекают сходным образом. Различия в данных процессах незначительны и связаны с исторически сложившимися структурами бизнес-процессов. Кастомизация коробочных версий информационных систем позволяет адаптировать их к специфике конкретных бизнес-процессов.
При кастомизации информационной системы для нескольких предприятий одной предметной области модули, разработанные для одного предприятия, могут быть использованы при кастомизации информационной системы для другого предприятия. Время, затраченное на доработку модуля значительно ниже, чем при разработке его с нуля. С ростом числа выполненных доработок снижается необходимость новых доработок за счет повторного использования или адаптации уже существующих.
Основной задачей при этом является произведение семантической аннотации реализованных требований и разработанных программных модулей с возможностью их быстрого поиска. Также задачей управления проектом при использовании методологии гибкой разработки является прогнозирование трудоемкости реализации конкретных требований.
Решение этих задач позволит вывести процессы управления проектом и управления требованиями на более высокий уровень за счет упрощения поиска сходных требований и возможности более точного планирования трудозатрат. В работе представлена модель данных требования, которая описывает их в различных аспектах на основе связи данных и метаданных.
Проблема
Для повторного использования разработанных модулей необходимо не только соблюдение принципов объектно-ориентированного программирования, но и необходима технология, которая бы позволила выявлять модули для повторного использования без привлечения эксперта или с его минимальным участием.
В данном случае экспертом является аналитик или менеджер проекта, но так как аналитик или менеджер проекта не может участвовать во всех проектах организации и быть в курсе всех производимых доработок, то необходим аппарат для идентификации выполняемых доработок с возможностью их поиска для повторного использования.
В большинстве своем описание требований является текстовым, то есть с использованием естественного языка — ограничения и необходимые возможности описываются в виде текста с использованием терминов предметной области.
При добавлении нового требования в проект необходимо выполнить поиск среди уже имеющихся в проекте требований, чтобы исключить их дублирование. В данном случае, тождественность требований определяется семантическим соответствием текстов, которыми эти требования представлены. Для определения соответствия требований необходим механизм определения схожести текстов.
Наиболее распространенным методом определения схожести текстов является алгоритм шинглов. Данный алгоритм позволяет выявлять нечеткие дубликаты текстов и может быть использован для кластеризации документов по схожести и выделения документов-плагиата.
Использование данного алгоритма, как и его модификаций (алгоритма супершинглов и мегашинглов) не дает репрезентативного результата, так как при описании требований используется ограниченный набор лексических конструкций, что не позволяет получить точный результат.
Для решения возникшей проблемы предлагается использование семантической аннотации, что позволит с помощью набора концептов малой длины описать требование, представленное в виде текста большей длины.
Использование данного аппарата в процессе управления требованиям позволит не только автоматизировать деятельность по работе с требования, но и увеличит долю повторно разработанного кода за счет их идентификации и возможности быстрого поиска.
Планирование трудоемкости разработки новых требований предполагает анализ уже реализованных требований и прогнозирование на их основе. Для планирования необходимо отбирать требования, сходные с реализуемым, поэтому для прогнозирования трудоемкости также необходим механизм семантической аннотации как аппарат выявления сходных требований.
Рассмотрим ниже математическую постановку задачи и основные необходимые для семантической аннотации определения:
Домен — совокупность проектов одной предметной области.
Проект — совокупность требований, реализующих заданную функциональность, а также деятельность, направленная на достижение результата и создание уникального продукта или услуги.
Концепт — атрибут, идентифицирующий требование с определенной точки зрения, предметной области.
Категория — совокупность концептов, относящихся к одной предметной области или точке зрения.
Представим требование с помощью следующей модели:

, где (1)

С — условие или возможность, которую требование должно представлять,
R — реализация данного требования в системе.
Так же требование на естественном языке можно идентифицировать набором концептов:

, где (2)

Сi — концепт, описывающий требование.
Задача идентификации требований состоит в сопоставлении требованиям набора концептов из соответствующих категорий.
Похожие работы на тему
В работе [6] Николай Яковлев рассматривает возможность использования семантической аннотации для идентификации требований, однако не рассматривает возможности семантических отношений между концептами и применение многоаспектной модели данных для прогнозирования трудоемкости реализации требований.
Предлагаемый подход к семантическому поиску
Семантическая аннотация требований — это описание требований, представленных текстом на естественном языке ограниченным набором концептов малой длины.
Каждое требование обязательно должно иметь, концепты, характеризующие требование со следующих точек зрения:
  • объект,
  • субъект,
  • событие,
  • действие.
Так как требования являются составной частью проекта, а он, в свою очередь, относится к категории, то каждое требование внутри домена получает также набор категорий, определенных для данного домена.
Таким образом, требование можно представить в виде следующей модели:

, где (3)

CO — концепт, описывающий объект требования,
CS — концепт, описывающий субъект требования,
CE — концепт, описывающий событие требования,
CA — концепт, описывающий действие,
{CD} — набор концептов из категорий, полученных от домена.
Примем мерой различия двух требований семантическое расстояние, которое является показателем смыслового различия и является действительным числом в интервале от 0 до 1, где 1 — требования идентичны, 0 — требования совершенно не связаны. Исходными данными для вычисления являются концепты, которыми аннотированы требования.
Введем дополнительные понятия:
Алфавит — это произвольное непустое конечное множество , элементы которого называются буквами или символами.
Словом или цепочкой в алфавите V называют произвольный кортеж из множества (k-й декартовой степени алфавита V) для различных k = 0, 1, 2…
В данном конкретном случае алфавитом является совокупность всех имеющихся в системе концептов, концепты являются символами данного алфавита. Совокупность концептов, описывающих требование, является словом, длина которого определяется количеством категорий данного домена. Положение каждого символа в слове определяется категорией, к которому относится концепт, в следствие чего мы имеем конечный набор слов, который можно составить из символов данного алфавита.
Семантическое расстояние может быть определено на основании вычисления следующих показателей:
Расстояние Левенштейна, определяемое как минимальное количество операций вставки одного символа, удаления одного символа или замены одного символа на другой.
Расстояние Дамерау-Левенштейна является развитием расстояния Левенштейна и учитывает также перестановки символов. Использование данного метода для нахождения семантического расстояния неоправданно, так как символы занимают строго определенное положение в строке в соответствии с категорией концепта.
Расстояние Хэмминга определяет количество позиций, в которых различаются две строки.
Для нахождения семантического расстояния в данной статье за основу берется расстояние Хэмминга. В общем случае расстояние Хэмминга будет вычисляться по следующей формуле:

, где (4)

a­i1i-й символ первой строки,
ai2i-й символ второй строки.
H равно единице, если символы a­i1 и a­i2 совпадают и равно нулю во всех остальных случаях.
Для вычисления семантического расстояния между требованиями используем расстояние Хэмминга в следующем виде:

, (5)

где L — семантическое расстояние
Cii-й концепт требования
N — число концептов в требовании (длина требования).
Категории внутри домена могут иметь различный приоритет, то есть различаться весами. Совпадение по категории с большим весом должно иметь большее влияние на семантическое расстояние. Для того, чтобы отразить значимость категорий в рамках домена и в процессе вычисления семантического расстояния каждая категория снабжается весом. Веса определяются системой на основе обратной связи от эксперта:
  1. Эксперту предлагается перечень требований, сходных с введенным (или выбранным из уже существующих) на основе расчета семантического расстояния.
  2. Эксперт отмечает требования, которые, с его точки зрения, оказались сходными.
  3. Категории, по которым совпали требования, отмеченные экспертом, увеличивают свой вес на единицу.
Первоначально все категории в рамках домена имеют вес равный единице.
Представим категорию в виде следующей модели:
, где
Т — название категории,
W — вес категории в рамках домена.
Тогда семантическое расстояние с учетом весов категорий будет вычисляться по следующей формуле:

, (6)

где Wi — вес i-й категории в рамках домена.
max W –вес категории с максимальным весом в рамках домена
Использование метода Хэмминга достаточно для работы со строками, в которых каждый из символов самостоятелен и не связан с остальными. Так как концепты являются терминами, представленными на естественном языке, а не просто бинарными значениями, то между ними могут быть установлены семантические отношения, такие как синонимия, антонимия, меронимия.
Для расчета семантического расстояния с учетом семантических отношений между концептами введем следующую модель концепта:

, где (7)

С — концепт,
V — значение лингвистической переменной, описывающее концепт,
{S} — совокупность концептов, которые являются синонимами с данным. Семантическое расстояние между ними равно 1.
{M} — совокупность меронимов для данного концепта. Семантическое расстояние в данном случае определяется экспертным путем на основе словаря меронимов. Чем менее связаны между собой термины, тем меньше между ними семантическое расстояние. Оно равно единице, если термины являются синонимами и стремится к нулю по мере смыслового удаления.
Таким образом, семантическое расстояние с учетом семантических отношений можно вычислить по следующей формуле:

, (8)

где — совокупность концептов, состоящих в семантическом отношении с концептом .
В данном случае сравниваются не только исходные концепты, но и все связанные с ними семантическими отношениями концептами. В случае, если исходные концепты не совпадают, то сравниваются связанные концепты в следующей последовательности:
  1. Сравниваются все синонимичные концепты. Если среди синонимичных концептов нет совпадения, то переходим к пункту 2.
  2. Сравниваем все концепты с учетом меронимии в порядке убывания семантического расстояния. Расстояние между исходным и меронимичным концептом лежит в интервале [0..1].
Предлагаемый подход к прогнозированию трудоемкости требований
Прогнозирование трудоемкости реализации новых требований основывается на выявлении закономерностей между составом концептов уже реализованных требований и их фактической трудоемкостью реализации.
Представим трудоемкость как зависимость, между значениями категорий, которыми описано требование и временем, необходимым для реализации требования.

, где (9)

- поправочный коэффициент для категории,
- функция трудоемкости, реализации i-го концепта в n-ой категории.
Каждая категория в рамках домена имеет свою функцию трудоемкости , значение которой зависит от положения концепта в категории. Концепты в категории упорядочиваются в соответствии с трудоемкостью реализации требований, к которым они относятся.
Исходными данными для прогнозирования является трудоемкость уже реализованных требований. На ее основе вычисляется связанная с концептами трудоемкость по следующему алгоритму:
  1. Концепты, входящие в состав требования имеют трудоемкость, пропорциональную количеству концептов, описывающих требование, то есть, трудоемкость каждого входящего в состав вычисляется по следующей формуле , где T – трудоемкость реализации требования, N – количество концептов, которыми описывается требование.
  2. Если с концептом уже связана трудоемкость, то необходимо выполнить перерасчет трудоемкости. В этом случае трудоемкость равняется среднему арифметическому между уже имеющимся значением и значением частичной трудоемкости вновь добавляемого требования.
  3. В случае если концепт имеет синонимы в рамках категории, то для них также указывается трудоемкость.
В результате накопления опытных данных мы получим дискретную функцию, которая показывает соответствие между концептом и трудоемкостью его реализации и может быть описана в следующем виде:

, (10)

где - значение концепта,
- значение трудоемкости.
Поправочный коэффициент равняется весу категории в рамках домена. Таким образом, после добавления требований и, соответственно, связанных с ними концептов мы получим N функций трудоемкости, по одной для каждой из категорий. Подставляя в формулу (9) значения концептов мы получим прогнозируемую трудоемкость реализации нового требования.
Перспективы исследования
Перспективным направлением является автоматизированное извлечение требований к веб-приложениям с использованием систем веб-аналитики и автоматическая идентификация требований с использованием ключевых слов страницы в качестве концептов создаваемого требования.
Заключение
В данной статье был рассмотрен современный подход к разработке сложных систем, выявлены основные проблемы при их разработке: дублирование и противоречивость требований, сложность прогнозирования трудоемкости без привлечения непосредственных исполнителей. Для решения выявленных проблем был проведен анализ существующего математического аппарата и выделен наиболее предпочтительный метод нахождения семантического расстояния на основе расстояния Хэмминга, предложена концепция семантической аннотации. Выбранная математическая модель была адаптирована с учетом специфики предметной области.
Разработанная методика была реализована в виде системы управления требованиями с семантической аннотацией SemanticReq и апробирована на требованиях к проекту СЭД БОСС-Референт.
Использование семантического расстояния и семантической аннотации позволяет:
Выявлять сходные требования на этапе ввода и предотвращать их повторный ввод.
Искать сходные требования среди уже реализованных и использовать реализующий их код, сценарии тестирования, варианты использования и другие проектные артефакты повторно.
Выполнять кластерный анализ требований для их группировки и последующего анализа.
Прогнозировать параметры требований.
Литература:
  1. ISO 12207 Standard for software lifecycle processes.
  2. Белоусов А.И., Ткачев С.Б. Дискретная математика: Учеб. для вузов / Под ред. В.С. Зарубина, А.П. Крищенко. – 4-е изд., исправл. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2006. – 744с. (Сер. Математика в техническом университете; Вып. XIX).
  3. Блейхут Р. Теория и практика кодов, контролирующих ошибки = Theory and Practice of Error Control Codes. — М.: Мир, 1986. — 576 с.
  4. Левенштейн В.И.. Двоичные коды с исправлением выпадений, вставок и замещений символов. Доклады Академий Наук СССР, 1965. 163.4:845-848.
  5. Новак В., Перфильева И., Мочкрож И. Математические принципы нечёткой логики. пер с англ. М.: Физматлит, 2006. 352с.
  6. Яковлев Николай, Сулейманова Алла. Семантическое и многоаспектное моделирование в управлении требованиями к математическому и программному обеспечению. // Уфимский Государственный Авиационный Технический Университет.

Обсуждение

Социальные комментарии Cackle