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

УДК 004.652.6: 519.816

ВЫБОР ВАРИАНТА СОЗДАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ С ИСПОЛЬЗОВАНИЕМ МЕТОДА АНАЛИЗА ИЕРАРХИЙ

А. А. Кукарцева, В. В. Пикулин

CHOOSING THE WAY TO CREATE CONTROL SYSTEM REQUIREMENTS USING THE ANALYTIC HIERARCHY PROCESS

А. A. Kukartseva, V. V. Pikulin

Аннотация. Актуальность и цели. Управление требованиями к информационной системе (ИС) - важная часть процесса создания и внедрения ИС. Цель данного исследования - определить в заданном пространстве признаков с помощью метода анализа иерархий условия, при которых целесообразно создание системы управления требованиями с использованием базы данных (БД), основанной на собственной реляционной модели, и разработать реляционную модель данных для представления основных сведений об объектах предметной области. Материалы и методы. В качестве критериев для принятия решения приняты функциональность, временные затраты на создание и внедрение программного продукта, финансовые затраты на разработку и обслуживание, простота адаптации программного продукта. Метод анализа иерархий применен при наличии следующих альтернатив: готовые программные продукты, специализированное программное обеспечение (ПО) с использованием БД, специализированное ПО с использованием БД и модулей семантического анализа текста требований. Результаты. В работе показано применение метода анализа иерархий для определения условий, при которых целесообразно создание системы управления требованиями с использованием базы данных, основанной на собственной реляционной модели, и предложена реляционная модель для представления основных сведений об объектах предметной области. Выводы. Применение метода анализа иерархий для выбора варианта создания системы управления требованиями к ИС позволило в заданном пространстве признаков определить условия предпочтения использования варианта создания специализированных программных средств на основе базы данных, для которой предложена реляционная модель.

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

Abstract. Background. Requirements management for information system (IS) is an important part of the process of creation and implementation of IS, from which the swarm depends on the success of the project and the effectiveness of the use of IP in the enterprise. The purpose of this study was to determine in a given space-characters by using the method of hierarchies analysis of the conditions under which it is advisable to establish systems requirements management using a database (DB) based on the relational model and design relational data model to represent the basic information about the domain objects. Materials and methods. As criteria for decision taken: the functionality, the time spent on the creation and implementation of a software product, the financial costs of development and maintenance, the ease of adapting the software product. Analytic hierarchy process applied under the following alternatives: ready-made software products, customized software using database, specialized software using the database and the semantic analysis modules of the text of the requirements. Results. The paper shows the application of the method of analytic hierarchy process to determine the conditions under which it is advisable to establish systems

requirements management using a database based on the relational model, and proposed the relational model for representing basic information about the domain objects. Conclusions. The application of the method of analytic hierarchy process for selecting the option to create control system requirements for IS enabled in a given feature space to determine the conditions of the preference of using options to create customized software based on the database for which the relational model is proposed.

Key words: information system, managing requirements, analytic hierarchy process, classification of requirements, data model.

Введение

Управление требованиями к информационной системе (ИС) - важная часть процесса создания и внедрения ИС, от которой зависит успешность проекта и эффективность использования ИС на предприятии [1]. По данным исследования, проведенного [компанией] IBM в области IT, 60 % затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20 % благодаря сокращению числа неточных, неполных и упущенных требований [2].

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

—Критические ■ Высокие ^^Низкие

Рис. 1. Пример изменения количества запросов пользователей на стадии внедрения ИС в течение четырех недель

1. Анализ задачи

Для управления процессом учета и выполнения работ по удовлетворению требований заказчика к ИС используют различные программные средства, при этом возможны следующие альтернативы:

1) использование готовых программных продуктов;

2) разработка специализированного программного обеспечения с использованием базы данных;

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

Первый вариант связан с необходимостью приобретения и освоения универсальных программных продуктов. В настоящее время широкое распространение получили такие системы управления требованиями, как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM [2].

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

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

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

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

Третий вариант базируется на втором и предполагает разработку программного комплекса, включающего базу данных и систему семантического анализа, позволяющего автоматически определять принадлежность требований к функциональному участку обслуживаемого программного продукта [3]. Большим преимуществом является снижение занятости специалистов, обслуживающих данный комплекс, за счет пропуска этапа анализа полноты поступающего требования. Однако, как показали исследования, далеко не всегда по описанию требования можно определить, что имел в виду пользователь. Кроме того, в ходе работы над требованием может потребоваться дополнительная информация (документы, файлы, сведения об ошибках), кото-

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

Таким образом, необходимо сопоставить следующие варианты создания системы управления требованиями:

1) использование готового продукта;

2) разработка программного обеспечения (ПО) с базой данных (БД);

3) разработка программного комплекса с системой семантического анализа требований.

2. Использование метода анализа иерархий для выбора варианта системы управления требованиями

Для выбора наиболее приемлемого к конкретным условиям варианта анализа требований к ИС в данной работе использован метод анализа иерархий (МАИ) [4]. Удобство применения МАИ заключается в том, что он позволяет:

- использовать произвольный принятый исследователем (системным аналитиком) набор показателей, характеризующий альтернативы;

- учитывать степени важности показателей с помощью весовых коэффициентов;

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

В данном случае указанные выше подходы к созданию системы управления требованиями для группы взаимосвязанных проектов оценены по следующим п показателям (п = 4):

1) функциональность;

2) временные затраты на создание и внедрение продукта;

3) финансовые затраты на разработку и обслуживание;

4) простота адаптации программного продукта.

При проведении анализа для парных сравнений альтернатив принята шкала оценок показателей со следующими предпочтениями:

- примерно равны по степени важности - 1;

- незначительное предпочтение - 3;

- значительное предпочтение - 5;

- сильное предпочтение - 7.

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

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

вычислить относительные коэффициенты важности (критериальные веса) для единичных показателей по количественным оценкам предпочтений;

2) выполнить парное сравнение альтернатив по единичным показателям;

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

В соответствии с методикой применения МАИ установлены парные предпочтения критериев относительно друг друга (табл. 1) и вычислены значения

Е = Ъу , (1)

7=1

где / - количественная оценка предпочтения 7-го показателя перед у-м при парном сравнении (у = 1, ..., 4).

Таблица 1

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

Функциональность Временные затраты Финансовые затраты Адаптация

Функциональность 1 5 3 5

Временные затраты 1/5 1 3 1

Финансовые затраты 1/3 1/3 1 1

Адаптация 1/5 1 1 1

1,733 7,333 8,000 8,000

По данным табл. 1 вычислены значения весов показателей (количественные выражения степени важности каждого показателя, табл. 2):

V" ь

кг = ^; (2) п

ЬУ = /у / Е . (3)

Затем выполнено попарное сопоставление вариантов создания системы управления требованиями по каждому показателю: по функциональности (табл. 3); по временным затратам (табл. 4); по финансовым затратам (табл. 5); по адаптивности (табл. 6). При этом вычислены веса альтернатив ат 7 по

формулам, аналогичным (1) - (3), где

т е

{ф (функционал), в (время), д (финансы), а (адаптивность)} .

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

п

Кт = '^]к7ат,у . У =1

Результаты вычисления весов показателей

Функциональность Временные затраты Финансовые затраты Адаптация Веса, кг

Функциональность 0,577 0,682 0,375 0,625 0,565

Временные затраты 0,115 0,136 0,375 0,125 0,188

Финансовые затраты 0,192 0,045 0,125 0,125 0,122

Адаптация 0,115 0,136 0,125 0,125 0,125

Таблица 3

Предпочтения альтернатив по функциональности

Альтернативы 1 2 3 Веса аф,г

1 - Готовый продукт 1 1/7 1/7 0,067

2 -ИСс БД 7 1 1 0,467

3 - Программный комплекс 7 1 1 0,467

Таблица 4

Предпочтения альтернатив по временным затратам

Альтернативы 1 2 3 Веса ав, г

1 - Готовый продукт 1 1/3 1/5 0,120

2 -ИСс БД 3 1 3 0,549

3 - Программный комплекс 5 1/3 1 0,331

Таблица 5

Предпочтения альтернатив по финансовым затратам

Альтернативы 1 2 3 Веса ад, г

1 - Готовый продукт 1 1/3 1/5 0,120

2 -ИСс БД 3 1 3 0,549

3 - Программный комплекс 5 1/3 1 0,331

Таблица 6

Предпочтения альтернатив по адаптивности

Альтернативы 1 2 3 Веса аа г

1 - Готовый продукт 1 1 3 0,429

2 -ИСс БД 1 1 3 0,429

3 - Программный комплекс 1/3 1/3 1 0,143

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

Итоговая рейтинговая таблица при исходных предпочтениях

Альтернативы Показатели Рейтинг

Функциональность Временные затраты Финансовые затраты Адаптация

1 - Готовый продукт 0,038 0,022 0,015 0,054 0,13

2 - ИСс БД 0,264 0,103 0,067 0,054 0,49

3 - Программный комплекс 0,264 0,062 0,040 0,018 0,38

Выполнен анализ альтернатив при изменении оценок предпочтений по функциональности (табл. 8) и по финансовым затратам (табл. 9) в сторону снижения предпочтения для альтернативы 2. Полученные значения рейтинга в данном случае не изменили общее предпочтение альтернатив (табл. 10).

Таблица 8

Предпочтения альтернатив по функциональности

Альтернативы 1 2 3 Веса аф,7

1 - Готовый продукт 1 1/3 1/3 0,143

2 -ИСс БД 3 1 1 0,429

3 - Программный комплекс 3 1 1 0,429

Таблица 9

Предпочтения альтернатив по финансовым затратам

Альтернативы 1 2 3 Веса ад, 7

1 - Готовый продукт 1 1/3 1 0,200

2 - ИС с БД 3 1 3 0,600

3 - Программный комплекс 1 1/3 1 0,200

Таблица 10

Итоговая рейтинговая таблица при измененных предпочтениях

Альтернативы Показатели Рейтинг

Функциональность Временные затраты Финансовые затраты Адаптация

1 - Готовый продукт 0,081 0,022 0,024 0,054 0,18

2 - ИС с БД 0,242 0,103 0,073 0,054 0,47

3 - Программный комплекс 0,242 0,062 0,024 0,018 0,35

3. Разработка модели данных для классификации требований

В процессе опытной или промышленной эксплуатации АИС от предприятия-заказчика предприятию-поставщику АИС поступают различные запросы с формулировками требований на изменение функций АИС, с описа-

нием отказов и т.п. Предприятие-исполнитель должно своевременно отреагировать на поступивший запрос, для чего необходимо классифицировать поступившее требование, чтобы направить его в соответствующее подразделение для решения поставленного вопроса. Для создания БД классификатора требований разработана реляционная модель, в которой одна часть сущностей предназначена для идентификации требований («Заказчик», «Проект», «Подразделение», «Сотрудник», «Задача»), вторая - для классификации требований по группам, типам и приоритетам, третья - для сопровождения состояния работ над требованием (рис. 2). Модель соответствует третьей нормальной форме и позволяет сгенерировать базу данных АСУТ [5].

Сотрудники

РК СотрНомер

СотрФИО СотрДолжн

Заказчик

РК ЗакКод

ЗакНазв

Проект

РК ПроектШисЬо

РК1 ПроектНазв ПроектЗакКод

СтатусТребов ан ия

РК СтатусКод

СтатусНазв

Приоритет

РК ПопорКод

ПриорНазв

Задача

РК ЗалачаНом

РК2 РКЗ РК1 ЗадачаНазв ЗадачаПрШифр ЗадачаСотрНом ЗадачаПодрНом

к 1

Требование

РК ТоебНом

П<1 Тр^бД^Вр Тоеб Описание

ТребЗадачаНом

Классифи кэцияТребова н и й

КлассДата

РК1 КлассГрТрКод

РК5 КлассТипТрКод

РК4 Кла сеСтатТрКод

РКЗ КлассПрКод

РК2 Исполнит

Подразделение

РК ПодрНом

ПодрНазв

Исполнитель

РК КодИсполнит

НазвИсполн

ТипТребования

РК ТипТоебКод

ТипТребНазв

ГруппаТребован ий

РК Го Код

ГрНазв Гр Префикс

Рис. 2. Реляционная модель данных классификатора требований

Классификация требований должна выполняться сотрудниками предприятия-разработчика ИС при получении соответствующих запросов от предприятий-заказчиков. При этом должны фиксироваться следующие сведения, связанные с применением внедряемой ИС: название предприятия-заказчика; название проекта по созданию (модернизации) ИС; данные о сотруднике предприятия-заказчика, который сформулировал запрос, о подразделении и названии решаемой пользователем задачи; содержание сформулированного запроса. Для этого в составе реляционной модели данных определены сущности: «Заказчик», «Проект», «Сотрудник», «Подразделение», «Задача», «Требование» (см. рис. 2), между которыми установлены отношения «один ко многим» (1:К).

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

Зарегистрированные требования необходимо классифицировать по следующим признакам:

- тип требования, например запрос на изменение или добавление функционала, пополнение внутренних справочников ПО, исправление ошибки и др. (сущность «ТипТребования»);

- функциональный участок, к которому относится требование (сущность «ГруппаТребований»);

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

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

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

Заключение

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

Список литературы

1. Управление требованиями к программному обеспечению. - URL: https://ru.wikipedia.org/wiki (дата обращения: 23.09.2015).

2. Бармин, А. Управление требованиями к IT-проектам / А. Бармин. - URL: http://habrahabr.ru/post/114571/ (дата обращения: 23.09.2015).

3. Бармин, А. Использование семантической аннотации для идентификации требований / А. Бармин. - URL: http://habrahabr.ru/post/126248/ (дата обращения: 23.09.2015).

4. Саати, Т. Принятие решений. Метод анализа иерархий / Т. Саати ; пер. с англ. Р. Г. Вачнадзе. - URL: http://bsuir-helper.ru/sites/default/files/2011/03/11/ met/Tomas_Saati_-_Prinyatie_Resheii._Metody_analiza_ierarhii.1993.pdf (дата обращения: 25.09.2015).

5. Шигина, Н. А. Разработка базы данных : учеб. пособие / Н. А. Шигина. - Пенза : Изд-во ПГТА, 2005. - 104 с.

Кукарцева Александра Антоновна

студентка,

Пензенский государственный технологический университет E-mail: taburetka345@yandex.ru

Kukartseva Alexandra Antonovna student,

Penza State Technological University

Пикулин Василий Васильевич

кандидат технических наук, доцент, кафедра прикладной информатики, Пензенский государственный технологический университет E-mail: vapikulin@yandex.ru

Pikulin Vasily Vasiljevich candidate of technical sciences, associate professor, sub-department of applied informatics, Penza State Technological University

УДК 004.652.6: 519.816 Кукарцева, А. А.

Выбор варианта создания системы управления требованиями с использованием метода анализа иерархий / А. А. Кукарцева, В. В. Пикулин // Модели, системы, сети в экономике, технике, природе и обществе. - 2016. - № 2 (18). - С. 195-204.