На правах рекламы:
ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Авторитетность издания

ВАК - К1
RSCI, ядро РИНЦ

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
09 Сентября 2024

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

Semantic annotation and multi-aspect data model in requirements management
Статья опубликована в выпуске журнала № 2 за 2011 год.
Аннотация:Выгода от повторного использования требований в IT-производстве ставит задачу поиска требований, учиты-вающего их семантику. Задачу предлагается решать с помощью категоризированной семантической аннотации тре-бований. Для этого используется метод категоризованной семантической аннотации, учитывающий структурные особенности формулировки требований. В качестве области применения рассматривается IT-проект по разработке и внедрению АСУ документооборотом вуза и его подразделений.
Abstract:Benefits from requirements reuse implies a problem of semantics-driven requirements retrieval. The solution employs categorized semantic annotation of requirements. Proposed is a method for semantic annotation, considering structural features of requirements wordings. The method is applied in an IT-project concerning development and deployment of computer-aided system for the university departments document workflow.
Авторы: Сулейманова А.М. (suleymanova.ufa@gmail.com) - Уфимский государственный авиационный технический университет, кандидат технических наук, Яковлев Н.Н. (nikolay.iakovlev@gmail.com) - Уфимский государственный авиационный технический университет
Ключевые слова: семантический поиск, модель данных, аспект, управление требованиями, концепт, семантическая аннотация, требование
Keywords: semantic search, Data Model, dimension, requirements management, concept, semantic annotation, requirement
Количество просмотров: 14626
Версия для печати
Выпуск в формате PDF (5.35Мб)
Скачать обложку в формате PDF (1.27Мб)

Размер шрифта:       Шрифт:

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

В научно-исследовательской работе CHAOS [1], выполненной Standish Group, указаны 10 факторов, которые не позволяют вовремя выпускать IT-проект, придерживаться установленного бюджета и предоставлять требуемую функциональность заказчику. Самые значимые из них – недостаток данных от пользователей, незаконченные требования и спецификации, изменение требований и спецификаций.

Очевидно, что все три наиболее значимых фактора неудач IT-проектов связаны с требованиями, и эффективное управление требованиями (УТ) может сократить долю неудач.

Требования являются одним из ключевых компонентов проекта в соответствии с международным стандартом PMBoK4 (свод знаний по управлению проектами) [2] и в соответствии с общепринятой методологией IBM Rational Unified Process, с которой разработка или эволюция ПО должны сопровождаться УТ к ПО и, как следствие, управлением ответами или реакциями на эти требования. Аналогичное условие выдвигают отечественные стандарты на информационные технологии – ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р ИСО/МЭК 15288.

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

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

Целью УТ при управлении одним проектом является предоставление возможности контроля целостности требований, то есть избежание их дублирования и противоречивости. Требования могут дублироваться и противоречить друг другу, если в проекте участвуют более одного аналитика или проект растянут во времени (1 год или более). Также при управлении несколькими проектами целью УТ является использование требования из одного проекта в одном или нескольких других проектах. Актуальность повторного использования обусловлена и ростом популярности СОА АПК, один из принципов которой – повторное использование требований и моделей. Основными задачами при этом являются произведение семантической аннотации (СА) требований и быстрый автоматизированный поиск требований, семантически близких к заданному, на основе имеющейся СА, а также оперативное представление данных о требованиях в виде отчетов.

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

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

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

К системам среднего масштаба относится АСУД вуза и его подразделений. Для разработки такой системы в Уфимском государственном авиационном техническом университете (УГАТУ) существует около 50 бизнес-правил, 350 функциональных требований, а также около 100 требований технологического характера.

Рассмотрим математическую постановку задачи. Домен – это группа проектов, объединенных в семантическое пространство, то есть пересечение множеств их концептов достаточно велико. Это могут быть проекты по доработке одного и того же исходного решения либо по автоматизации схожих процессов. Проект имеет множество требований, каждое включает в себя текстовую формулировку, семантические данные, служащие координатными с точки зрения поиска, и атрибутивные данные. Все требования проекта – это модель системы, являющейся целью (планируемым результатом) проекта в терминах требований: D={d1, d2, …, dn} – множество предметных областей (доменов), nÎN; Concepti – множество концептов i-го домена, , с точки зрения векторного анализа является базисом;  – множество проектов i-го домена, ;  – множество требований j-го проекта i-го домена, ;  – вектор атрибутов k-го требования, , j-го проекта i-го домена, где textkji – текстовая формулировка требования,  – множество концептов, а каждый концепт  принадлежит суммарному множеству, то есть ÎConcepti, а  – множество несемантических атрибутов требования;  – число элементов пересечения двух множеств концептов, определяет сходство требований и : чем больше элементов пересечений, тем сильнее сходство. Следует обратить внимание, что литера i не имеет штриха – домен для обоих требований один и тот же. Задача аналитика: задав множество  для исходного требования , найти одно или несколько требований , для которых , чтобы получить доступ к .

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

Данной проблематике посвящен ряд работ. Так, в [3] описывается подход к повторному использованию требований, однако не рассматриваются методы их СА. В работе [4] предлагаются подходы к семантической аннотации процессных моделей и проектируется прототип программного средства для управления семантикой процессных моделей, однако не рассматриваются УТ, представленные в виде текста на естественном языке. В работе [5] рассматривается комплексное средство использования знаний о проекте и УТ, но в ней излагаются требования не к ПО в IT-проекте, а к инженерным сооружениям. Ни в одной из перечисленных работ не рассматривается СА требований, сформулированных на естественном языке.

Подход к семантическому поиску

Семантическая аннотация требований – это смена вербальной семиотической системы выражения требования на концептуальную семиотическую систему, у которой степень формализации семантики с точки зрения требования максимальна.

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

В соответствии с устоявшейся практикой требование всегда содержит такие категории, как субъект, действие, объект и обстоятельство. В рамках определенной предметной области набор категорий можно расширить, например, для АСУД вузом можно добавить такие категории, как документ, модуль, адресат.

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

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

–    делать идентифицирующие семантические данные еще и координатными;

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

Вектор требований – это по сути (n-1)-мест­ный предикат, где n – число категорий требований, актуальных для данной предметной области. Категории образуют n-мерное пространство. В рамках одного проекта и всего домена число категорий постоянно.

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

Отметим, что авторами предпринята попытка впервые представить метод СА для требования в IT-проекте на естественном языке, учитывающий структурную специфику требования и предусматривающий единообразную категоризацию аннотирующих концептов для всех требований в рамках проекта.

Подход к логической модели данных о требованиях

Обозначим множество атрибутов одного требования как Attr(R), где R – требование.

Тогда A(F, U, S)={a1; a2; …; an}, nÎN, где F – область знаний (field, для данной работы перечень областей взят из [2]); U – роль пользователя (User); S – стадия ЖЦ; при  " aiÎAttr(R).

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

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

Перспективы исследования

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

Атрибут

Аспект

Обяз.

Тип

Многознач.

Область

Стадия

Роль

Описание

Объем

Выявление

Аналитик

 

Текст

 

Заголовок

Объем

Документирование

Аналитик

Да

Текст

 

Родительское требование

Объем

Документирование

Аналитик

 

Требование

 

Трудоемкость (план)

 

Валидация

Архитектор

 

Число

 

Аналитик

Ресурсы

Документирование

Система

 

Категория

 

Архитектор

Ресурсы

Валидация

Система

 

Категория

 

Уровень риска

Риски

Валидация

Архитектор

 

Категория

 

Классы

Интеграция

Разработка

Разработчик

Да

Категория

Да

Файлы

Интеграция

Разработка

Разработчик

Да

Категория

Да

Трудоемкость (факт)

Стоимость

Разработка

Разработчик

 

Число

 

Дата завершения (план)

Время

Валидация

Архитектор

 

Дата

 

Релиз

Интеграция

Все

Аналитик

 

Категория

 

Результатом реализации данного подхода стала система управления требованиями SemanticReq (semreq.anna-marry.ru), позволяющая вести учет требований в проектах, производить семантическую аннотацию требований с учетом их семантических категорий, а также осуществлять поиск требований на основе произведенной семантической аннотации.

Система используется в проектах, связанных с автоматизацией документооборота кафедр и деканата УГАТУ. В результате использования было выявлено 6 дубликатов и 4 противоречия внутри проектов, а также найдено 5 требований, аналогичных уже реализованным, что позволило избежать дополнительных затрат на разработку.

Литература

1.   CHAOS // The Standish Group Report, 1995. URL: http://www.cs.nmt.edu/~cs328/reading/Standish.pdf (дата обращения: 11.11.2009).

2.   Project Management Body of Knowledge v. 4 // Project Management Institute. URL: www.pmi.org (дата обращения: 14.01.2010).

3.   Park Soyong. Software Requirement Text Reuse. URL: ftp://ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ps/park2.ps (дата обращения: 18.08.2010).

4.   Yun Lin. Semantic Annotation of Process Models. Facilitating Process Knowledge Management via Semantic Interoperability // Thesis for the degree of Ph.D. URL: http://ntnu.diva-portal.org/smash/get/diva2:124135/FULLTEXT01 (дата обращения: 03.01.2010).

5.   David Baxter, James Gao, Keith Case et al. An en­gineering design knowledge reuse methodology using process mo­delling. URL: https://dspace.lib.cranfield.ac.uk/handle/1826/1856 (дата обращения: 23.01.2010).


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=2760
Версия для печати
Выпуск в формате PDF (5.35Мб)
Скачать обложку в формате PDF (1.27Мб)
Статья опубликована в выпуске журнала № 2 за 2011 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: