Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем
Приведены результаты анализа существующих инструментальных средств управления требованиями для программного обеспечения, дается оценка преимуществ их практического применения. Рассмотрены и обобщены недостатки, затрудняющие перспективу их дальнейшего развития. Предложено одно из направлений их дальн...
Збережено в:
| Дата: | 2005 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Russian |
| Опубліковано: |
Інститут програмних систем НАН України
2005
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/1363 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем /М.Н. Лаба, С.Н. Матвейшин // Проблеми програмування. — 2005. — N 3. — С. 42-52. — Бібліогр.: 5 назв. — рос. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
nasplib_isofts_kiev_ua-123456789-1363 |
|---|---|
| record_format |
dspace |
| spelling |
Лаба, М.Н. Матвейшин, С.Н. 2008-07-28T18:46:51Z 2008-07-28T18:46:51Z 2005 Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем /М.Н. Лаба, С.Н. Матвейшин // Проблеми програмування. — 2005. — N 3. — С. 42-52. — Бібліогр.: 5 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1363 004.52 Приведены результаты анализа существующих инструментальных средств управления требованиями для программного обеспечения, дается оценка преимуществ их практического применения. Рассмотрены и обобщены недостатки, затрудняющие перспективу их дальнейшего развития. Предложено одно из направлений их дальнейшего усовершенствования и развития. ru Інститут програмних систем НАН України Методи і засоби програмної інженерії Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем Some aspects of development and the further development of tool control facilities by requirements at creation of complex program systems Article published earlier |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| title |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| spellingShingle |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем Лаба, М.Н. Матвейшин, С.Н. Методи і засоби програмної інженерії |
| title_short |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| title_full |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| title_fullStr |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| title_full_unstemmed |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| title_sort |
некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем |
| author |
Лаба, М.Н. Матвейшин, С.Н. |
| author_facet |
Лаба, М.Н. Матвейшин, С.Н. |
| topic |
Методи і засоби програмної інженерії |
| topic_facet |
Методи і засоби програмної інженерії |
| publishDate |
2005 |
| language |
Russian |
| publisher |
Інститут програмних систем НАН України |
| format |
Article |
| title_alt |
Some aspects of development and the further development of tool control facilities by requirements at creation of complex program systems |
| description |
Приведены результаты анализа существующих инструментальных средств управления требованиями для программного обеспечения, дается оценка преимуществ их практического применения. Рассмотрены и обобщены недостатки, затрудняющие перспективу их дальнейшего развития. Предложено одно из направлений их дальнейшего усовершенствования и развития.
|
| issn |
1727-4907 |
| url |
https://nasplib.isofts.kiev.ua/handle/123456789/1363 |
| citation_txt |
Некоторые аспекты разработки и дальнейшего развития инструментальных средств управления требованиями при создании сложных програмных систем /М.Н. Лаба, С.Н. Матвейшин // Проблеми програмування. — 2005. — N 3. — С. 42-52. — Бібліогр.: 5 назв. — рос. |
| work_keys_str_mv |
AT labamn nekotoryeaspektyrazrabotkiidalʹneišegorazvitiâinstrumentalʹnyhsredstvupravleniâtrebovaniâmiprisozdaniisložnyhprogramnyhsistem AT matveišinsn nekotoryeaspektyrazrabotkiidalʹneišegorazvitiâinstrumentalʹnyhsredstvupravleniâtrebovaniâmiprisozdaniisložnyhprogramnyhsistem AT labamn someaspectsofdevelopmentandthefurtherdevelopmentoftoolcontrolfacilitiesbyrequirementsatcreationofcomplexprogramsystems AT matveišinsn someaspectsofdevelopmentandthefurtherdevelopmentoftoolcontrolfacilitiesbyrequirementsatcreationofcomplexprogramsystems |
| first_indexed |
2025-11-25T20:54:30Z |
| last_indexed |
2025-11-25T20:54:30Z |
| _version_ |
1850543439682207744 |
| fulltext |
Методи і засоби програмної інженерії
42 © М.Н. Лаба, С.Н. Матвейшин, 2005
ISSN 1727-4907. Проблеми програмування. 2005. № 3
УДК 004.52
М.Н. Лаба, С.Н. Матвейшин
НЕКОТОРЫЕ АСПЕКТЫ РАЗРАБОТКИ И ДАЛЬНЕЙШЕГО РАЗВИТИЯ
ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
ПРИ СОЗДАНИИ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ
Приведены результаты анализа существующих инструментальных средств управления требова-
ниями для программного обеспечения, дается оценка преимуществ их практического применения.
Рассмотрены и обобщены недостатки, затрудняющие перспективу их дальнейшего развития. Пред-
ложено одно из направлений их дальнейшего усовершенствования и развития.
Введение
Прогресс современного развития
компьютерной техники и программного
обеспечения предоставил возможность в
настоящее время создавать сложнейшие
программно-технические комплексы, ко-
торые позволяют автоматизировать про-
цессы в различных отраслях жизнедея-
тельности человека. При этом качест-
венно изменился и сам процесс про-
граммирования. Новые средства напи-
сания программ, такие как объектно-
ориентированное программирование,
различные типы систем управления ба-
зами данных, язык универсального мо-
делирования UML и т.д., позволяют за
короткий срок относительно небольшим
коллективам программистов выполнять
разработку программного обеспечения
(ПО) для решения сложнейших задач.
Исследования показали, что все сущест-
вующее в настоящее время разработки
ПО условно можно разбить на три сле-
дующие категории [1].
■ Информационные системы и
другие приложения, разработанные для
использования внутри компании. Эта
категория является основой индустрии
информационных систем/информации-
онных технологий, или IS/IT.
■ Программное обеспечение, раз-
рабатываемое и продаваемое как ком-
мерческий продукт. Разрабатывающие
такое ПО компании обычно называют
независимыми поставщиками про-
граммного обеспечения, или ISV.
■ Программное обеспечение ком-
пьютеров, встраиваемое в другие при-
боры, машины или сложные системы.
Программное обеспечение такого типа
назовем приложениями для встроенных
систем или встроенными приложениями.
Эти три типа приложений
существенно отличаются по своей при-
роде и имеют различные стратегические
цели. Однако все они разрабатываются
для выполнения конкретных задач и
должны удовлетворять определенному
набору требований. В связи с необходи-
мостью планирования и систематизации
выполнения работ по проектированию,
разработке и внедрению таких про-
граммных продуктов для решения слож-
ных заданий, а главное, чтобы функцио-
нальные и прочие характеристики ко-
нечного продукта соответствовали тре-
бованиям заказчика, возникла необхо-
димость создания и развития направле-
ния по разработке и управлению требо-
ваниями для них. Большинство сущест-
вующих методов и инструментальных
средств, используемых для разработки и
управления требованиями ПО, приме-
нимы для всех типов приложений.
Данное направление состоит из
двух основных процессов: разработка
требований для программного обеспече-
ния и управление ими. Процесс разра-
ботки требований в настоящее время
достаточно изучен, имеет множество
классических методов и средств получе-
ния, анализа и их классификации. Ста-
дия разработки подразумевает сбор ин-
формации, анализ, уточнение и утвер-
ждение требований. Как правило, она
заканчивается созданием пакета доку-
ментов: об образе и границах продукта,
документации к вариантам использова-
Методи і засоби програмної інженерії
43
ния, спецификации требований к ПО,
словаря данных и соответствующих мо-
делей анализа. После проверки и одоб-
рения этот пакет определяет базовую
версию требований, соглашение между
разработчиками и клиентами. Такой
процесс является относительно статич-
ным и бывает актуальным в основном на
начальном этапе проектирования ПО.
Иная ситуация складывается при орга-
низации процесса управления требова-
ниями. Этот процесс является динамич-
ным и остается актуальным на протяже-
нии всего жизненного цикла ПО. Со-
глашение по требованиям является свя-
зующим звеном между разработкой и
управлением требованиями. Дадим
определение этому процессу.
Процесс управления требова-
ниями (ПУТ) состоит в выявлении, орга-
низации, документировании и измене-
нии требований к ПО, в ходе которого
вырабатывается и обеспечивается со-
глашение между заказчиком и разработ-
чиками этого ПО.
В силу всего вышесказанного
анализ существующих методов и инст-
рументальных средств (ИС) автоматиза-
ции процессов управления требова-
ниями, поиск и оценка перспективных
направлений дальнейших разработок в
этой области в настоящее время явля-
ется актуальной проблемой.
1. Анализ существующих инструмен-
тальных средств управления требова-
ниями при разработке ПО
Под процессом управления
требованиями подразумевают все дейст-
вия, поддерживающие целостность, точ-
ность и своевременность обновления
соглашения о требованиях в ходе всего
жизненного цикла ПО. Основными со-
ставляющими ПУТ являются [2]:
- управление изменениями базовой
версии требований;
-поддержка планов проекта актуаль-
ными в соответствии с меняющи-
мися требованиями;
-управление версиями отдельных
требований и документации требо-
ваний и контроль их состояния;
-контроль состояния требований в
базовой версии;
-управление логическими связями
между отдельными требованиями,
другими материалами для работы с
проектом и контроль их корректно-
сти.
Обычный документальный спо-
соб формирования и хранения требова-
ний имеет ряд недостатков, которые оп-
ределяются необходимостью:
-обновления и синхронизации доку-
ментов;
-хранения дополнительной инфор-
мации атрибутов для каждого тре-
бования;
-определения взаимосвязей между
функциональными требованиями и
другими элементами системы;
-осуществления ручной передачи из-
менений всеми членами группы
разработчиков ПО;
-трассирования статуса требований,
который представляет собой трудо-
емкий и неудобный процесс;
-одновременного управление набо-
рами требований, запланированных
для различных выпусков продук-
тов;
-дублирования требований для раз-
личных версий;
-модификации требований несколь-
ким территориально распределен-
ным коллективам разработчиков
ПО;
-дополнительного сохранения откло-
ненных или удаленных из основной
версии требований и т.д.
ИС управления требованиями,
хранящие информацию в многопользо-
вательской базе данных, позволяют уст-
ранить эти недостатки. В небольших
проектах для управления требованиями
иногда достаточно использовать элек-
тронные таблицы или простые базы
данных, сохраняя текст и отдельные ат-
рибуты каждого требования. В более
крупных проектах выгодно применять
коммерческие средства управления тре-
бованиями, которые позволяют пользо-
вателям: импортировать требования из
исходных документов; определять зна-
Методи і засоби програмної інженерії
44
чения атрибутов; фильтровать и выво-
дить на экран содержание базы данных;
экспортировать требования в различных
форматах; контролировать связи трас-
сирования и соединять требования с эле-
ментами, хранящимися в других средст-
вах разработки ПО.
Таких средств в настоящее время
довольно много, они продолжают разви-
ваться и их возможности расширяются с
каждой версией. Проведенный анализ
всего этого многообразия показал, что
наиболее распространены несколько раз-
работок. Данные о производителях этих
инструментальных средств управления
требованиями и их основных функцио-
нальных свойствах приведены в таблице
[3, 4]. Важное отличие инструменталь-
ных средств заключается в способе хра-
нения данных.
Большинство из них хранит все
требования, атрибуты и информацию
трассирования в базе данных. В зависи-
мости от продукта база данных может
быть коммерческой или разработанной
собственными силами и запатентован-
ной, реляционной или объектно-ориен-
тированной. Требования могут импор-
тироваться из различных исходных до-
кументов, но затем они сохраняются в
базе данных. Как правило, текстовое
описание требования считается просто
одним из атрибутов. Некоторые про-
дукты позволяют устанавливать связи
отдельных требований с внешними фай-
лами (например, файлами Microsoft
Word, Microsoft Excel, графическими
файлами и т.д.), в которых содержится
информация, дополняющая содержимое
базы.
При документальном подходе до-
кумент, созданный при помощи тексто-
вого процессора (такого, как Microsoft
Word или Adobe FrameMaker), считается
основным хранилищем требований.
RequisitePro позволяет выбирать тек-
стовые строки в документе Word для
сохранения их в виде отдельных требо-
ваний в базе данных. После ввода требо-
ваний в базу данных можно определить
атрибуты и связи трассирования так же,
как и в продуктах, данные которых хра-
нятся в БД. Механизмы синхронизации
базы данных и содержимого документа
для этого предусмотрены. RTM Work-
shop поддерживает обе схемы: в первую
очередь хранение данных в базе данных,
но также и в документе Microsoft Word.
1.1. Преимущества использова-
ния инструментальных средств
управления требованиями. Даже если
была выполнена большая работа по
сбору требований для своего проекта,
автоматизированная поддержка поможет
Таблица
Инструмент Производитель
Способ
хранения
атрибутов в
базе данных
Связь
требований
с внешними
ИС
Active! Focus Xapware Technologies + -
CaliberRM Borland Software Corporation + +
C.A.R.E. SOPHIST Group + -
DOORS Telelogic + +
RequisitePro Rational Software Corporation - +
RMTrak RBC, Inc. - -
RTM Workshop Integrated Chipware, Inc. + +
Slate EDS + +
Vital Link Compliance Automation, Inc. - +
Методи і засоби програмної інженерії
45
оперировать этими требованиями в про-
цессе разработки. Инструментальное
средство управления требованиями ста-
новится полезным со временем, когда
детали требований постепенно забыва-
ются разработчиками ПО. Опишем не-
которые задачи, которые подобное сред-
ство поможет решать.
Управление версиями и
изменениями. Программный проект
должен определять четкий набор требо-
ваний для конкретной версии программ-
ного обеспечения. Некоторые средства
управления требованиями предлагают
функции гибкого управления базовой
версией. Они также сохраняют историю
изменений каждого требования. Предос-
тавляется возможность записывать
обоснование каждого решения об изме-
нении и при необходимости возвра-
титься к предыдущей версии требова-
ния. Некоторые средства, такие, как Ac-
tive! Focus и DOORS, содержат простые
встроенные системы изменений-пред-
ложений, устанавливающие связи между
предложениями об изменениях и изме-
ненными требованиями.
Хранение атрибутов требова-
ний. Для каждого требования необхо-
димо записывать несколько описатель-
ных атрибутов. Каждый, кто работает
над проектом, должен иметь доступ к
просмотру этих атрибутов, а некоторые
к изменению их значений. Инструмен-
тальное средство управления требова-
ниями генерирует несколько системных
атрибутов, например дату создания тре-
бования и номер его версии, а также по-
зволяет создавать дополнительные атри-
буты различных типов данных. Проду-
манное определение атрибутов даёт
возможность всем заинтересованным в
проекте лицам просматривать подмно-
жества требований, основанных на вы-
бранных комбинациях значений атрибу-
тов. Можно запросить список всех
требований, основанных на каком-либо
бизнес-правиле, чтобы принять решение
о последствиях его изменения. Один из
способов учета требований в основных
версиях различных выпусков продукта −
использовать атрибут «номер выпуска».
Облегчение анализа воздейст-
вия. Средства управления требованиями
помогают осуществлять трассирование
требований, позволяя определять связи
между различными типами требований,
между требованиями в различных под-
системах и между отдельными требо-
ваниями и связанными системными
компонентами (например, дизайном,
модулями кода, тестами и пользователь-
ской документацией). Эти связи помо-
гают анализировать воздействие, кото-
рое предлагаемое изменение окажет на
конкретное требование, выявляя другие
элементы системы, которые оно затро-
нет. Другое полезное свойство возмож-
ность отследить историю каждого функ-
ционального требования в обратную
сторону, вплоть до первоисточника.
Трассирование статусов требо-
ваний. Собрав требования в базе дан-
ных, можно узнать, сколько отдельных
требований было указано для продукта.
Трассирование статуса каждого требо-
вания в процессе разработки способст-
вует общему трассированию статуса
проекта. Менеджер проекта точно пред-
ставляет себе статус проекта, если знает,
какая часть требований для следующего
выпуска уже проверена, какая реализо-
вана, но не проверена, а какая часть еще
не до конца реализована.
Контролируемый доступ. Сред-
ства управления требованиями позво-
ляют устанавливать права доступа для
отдельных пользователей и их групп,
предоставлять информацию для общего
доступа через Web-интерфейс к базе
данных территориально распределен-
ному коллективу разработчиков ПО.
Базы данных используют блокировку на
уровне требований, позволяя многим
пользователям обновлять содержимое
базы данных одновременно.
Связь со всеми заинтересован-
ными в проекте лицами. Некоторые
средства управления требованиями по-
зволяют членам команды, которая соз-
дана для участия в проектировании и
разработке ПО, обсуждать вопросы, свя-
занные с требованиями, на тематических
дискуссиях с помощью электронных
Методи і засоби програмної інженерії
46
средств обмена сообщениями. Автома-
тически отсылаемые электронные сооб-
щения уведомляют членов команды, ко-
гда в дискуссии появляется новая запись
или какое-либо требование модифици-
руется. Возможность работы с требова-
ниями через Интернет сокращает рас-
ходы на транспорт и уменьшает доку-
ментооборот.
Повторное использование
требований. Хранение требований в
базе данных облегчает их повторное ис-
пользование в других проектах и под-
проектах. Требования, логически подхо-
дящие нескольким разделам описания
проекта, можно сохранить однажды, а
затем лишь ссылаться на них во избежа-
ние дублирования.
1.2. Возможности инструмен-
тальных средств управления требова-
ниями. Все существующие разработки
инструментальных средств управления
требованиями имеют одну общую цель -
дать разработчикам возможность авто-
матизировать процессы оперативного
управления этими требованиями на про-
тяжении всего жизненного цикла разра-
ботки, внедрения и эксплуатации ПО.
Однако практическая реализация этих
средств, их функциональные свойства,
наличие связи и обмена данными с дру-
гими инструментариями для разработки
ПО осуществляются различными спосо-
бами. Рассмотрим некоторые из них.
Коммерческие средства управле-
ния требованиями позволяют определять
различные типы (или классы) требова-
ний, такие, как бизнес-требования, вари-
анты использования, функциональные
требования, требования к оборудова-
нию, а также ограничения. Это позво-
ляет отделять задачи, с которыми можно
работать как с требованиями, от другой
полезной информации, содержащейся в
спецификации требований к ПО. Все ин-
струментальные средства обладают
мощными возможностями определения
атрибутов для каждого типа требований,
что является большим преимуществом
перед обычными способами документи-
рования спецификации требований к ПО.
Большинство инструментальных
средств управления требованиями в той
или иной степени интегрируются с Mi-
crosoft Word, на панель меню Microsoft
Word добавляется их специализирован-
ный раздел. Vital Link основан на Adobe
FrameMaker, а Slate интегрируется и с
FrameMaker и с Word. Инструменталь-
ные средства высокого уровня поддер-
живают широкий набор форматов фай-
лов для импорта и экспорта. Некоторые
инструменты позволяют пометить текст
в документе Word, чтобы обращаться с
ним как с отдельным требованием. Ин-
струмент выделяет требование и встав-
ляет в документ закладки Word и скры-
тый текст. Кроме того, пользователь по-
лучает возможность различными спосо-
бами анализировать документы, чтобы
извлекать из них отдельные требования.
Анализ документа в текстовом редак-
торе будет несовершенным, если только
при создании документа пользователь не
станет последовательно использовать
стили или ключевые слова, такие, как
«должно».
Инструментальные средства под-
держивают иерархическую систему ну-
мерации требований помимо уникаль-
ного внутреннего идентификатора для
каждого требования. Эти идентифика-
торы обычно состоят из короткого тек-
стового префикса, который указывает на
тип требования, например UR обозна-
чает требование пользователя (user re-
quirement), и уникального целого числа.
Некоторые средства предоставляют воз-
можность пользоваться Microsoft Win-
dows Explorer для отображения и управ-
ления иерархическим деревом требова-
ний. Один из способов отображения
требований в DOORS − иерархически
структурированная спецификация требо-
ваний к ПО.
К возможностям вывода данных
инструментальных средств относится
способность генерировать требования
либо в документе заданного пользовате-
лем формата, либо в табличном отчете.
CaliberRM обладает мощной функцией
Document Factory, позволяющей опреде-
лить шаблон спецификации требований
Методи і засоби програмної інженерії
47
к ПО в Word, используя простые спо-
собы для разметки макета страницы,
шаблона текстов, атрибутов для извле-
чения данных из базы и стилей текста,
которые пользователь хочет применять.
Document Factory заполняет этот шаблон
информацией, которую выбирает из
базы данных соответственно критериям
заданного пользователем запроса, чтобы
создать заказанный документ специфи-
кации требований к ПО. Таким образом,
спецификация требований к ПО, в сущ-
ности, представляет собой отчет, гене-
рируемый по некоторой выборке из со-
держимого базы данных.
Все инструментальные средства
обладают развитыми возможностями
трассирования. Например, в RTM Work-
shop каждый проект определяет схему
классов, похожую на диаграмму „сущ-
ность − связь” для всех хранящихся ти-
пов объектов. Трассирование выпол-
няют, определяя связи между объектами
двух классов (или внутри одного класса)
на основе взаимоотношений между
классами, заданными в схеме.
К числу других функций отно-
сится возможность задавать группы
пользователей и определять разрешения
некоторым пользователям или группам
на создание, чтение, обновление и уда-
ление проектов требований, атрибутов и
их значений. Некоторые продукты по-
зволяют поместить нетекстовые объ-
екты, такие, как графику и крупнофор-
матные таблицы, в базу требований. Ин-
струментальные средства предлагают
также средства обучения или проекты-
примеры, которые помогут пользовате-
лям научиться работать быстро и эффек-
тивно.
Эти продукты отражают тенденцию к
увеличению интеграции с другими инст-
рументальными средствами, используе-
мыми в разработке приложений, как по-
казано на рисунке. При выборе средства
для управления требованиями необхо-
димо выяснить, сможет ли оно обмени-
ваться данными с другими используе-
мыми пользователем инструментами.
Приведем примеры взаимосвязей между
инструментальными средствами суще-
ствующими на сегодня:
- пользователь может устанавли-
вать связи между требованиями в Requi-
sitePro и вариантами использования,
смоделированными в Rational Rose, а
также вариантами тестирования, храня-
щимися в Rational TreamTest;
- DOORS позволяет трассировать
требования вплоть до отдельных конст-
руктивных элементов, хранящихся в Ra-
tional Rose, Telelogic Tau и других инст-
рументах дизайна;
- RequisitePro и DOORS могут
устанавливать связи между отдельными
элементами проектного задания в Micro-
soft Project;
Рисунок. Интеграция инструментальных средств управления требованиями с
другими видами программных средств
Методи і засоби програмної інженерії
48
- CaliberRM имеет централизова-
нную структуру коммуникаций, которая
позволяет пользователю связывать тре-
бования с вариантами использования,
классами или элементами дизайна про-
цессов, хранящимися в TogetherSoft
Control Center, с исходным кодом, хра-
нящемся в Borland StarTeam, и с тесто-
выми элементами, хранящимися в Mer-
cury Interactive’s TestDirector. Он сможет
получать доступ к этим взаимосвязан-
ным элементам непосредственно из тре-
бований, хранящихся в базе данных
CaliberRM;
- RequisitePro позволяет взаимо-
действовать с базами данных, созданных
для Microsoft Access, Microsoft SQL
Server і Oracle.
Оценивая такие программные
средства, необходимо учесть преимуще-
ства интеграции продуктов при состав-
лении требований, тестировании, трас-
сировании проекта и других процессов.
Например, как опубликовать основной
набор требований в инструменте для
управления версиями продукта и опре-
делить связи трассирования между
функциональными требованиями и кон-
кретными элементами дизайна или кода.
2. Особенности и перспективы даль-
нейшего развития инструментальных
средств управления требованиями
Для эффективной организации и
управления процессами проектирования
и разработки сложных программных
систем в настоящее время требуется ис-
пользование различных инструменталь-
ных средств, которые позволяют проек-
тировщикам и разработчикам ПО авто-
матизировать выполнение этих процес-
сов. Одним из основных является инст-
рументальное средство управления тре-
бованиями. Любое такое инструмен-
тальное средство позволяет создать
структурную схему для организации
процесса управления требованиями,
значительно сократить время выполне-
ния отдельных операций этого процесса,
что в итоге дает возможность сократить
время проектирования и разработки са-
мого ПО, учесть все корректные и не-
противоречивые требования заказчика.
Как и любое другое инструментальное
средство аналогичного типа, данный ин-
струментарий требует определенной
подготовки и необходимой квалифика-
ции пользователей при работе с ним.
Существенное преимущество от исполь-
зования такого инструментального сред-
ства можно получить при проектирова-
нии и разработке ПО для больших и
сложных задач, в разработке которого
принимают участие многочисленные
коллективы разработчиков (от 10 чело-
век и более). Различные функциональ-
ные и прочие свойства существующих
коммерческих инструментальных
средств требуют от разработчиков на
начальном этапе проектирования ПО
проведения анализа этих средств, чтобы
выбрать такое, которое лучше других
поможет успешно выполнить разработку
требуемого ПО. При выборе инструмен-
тального средства следует учитывать та-
кие параметры, как платформа, цена, ре-
жим доступа и способ хранения данных
для требований − документальный или в
базе данных, которые лучше всего подхо-
дят данной среде разработки и культуре.
Инструментальное средство открывает
доступ к требованиям в базе данных лю-
бому разработчику ПО, имеющему соот-
ветствующие разрешения.
Однако, несмотря на
вышеописанные и некоторые другие
объективные организационные преиму-
щества работы в такой среде, все суще-
ствующие на данный момент коммерче-
ские инструментальные средства управ-
ления требованиями обладают некото-
рыми общими внутренними конструк-
тивными недостатками. Наиболее суще-
ственные среди них зачастую оказывают
решающее значение на окончательный
выбор при покупке такого инструмен-
тального средства. Перечислим главные
из них:
- сложность настройки и эксплуа-
тации таких инструментальных средств
пользователем;
- относительно высокая их стои-
мость;
Методи і засоби програмної інженерії
49
- отсутствие или ограниченность
связей автоматического обмена
информацией с другими инструменталь-
ными средствами проектирования, раз-
работки и отладки ПО.
Необходимость поиска возмож-
ных направлений для преодоления этих
недостатков разработки существующих
инструментальных средств, которые на
первый взгляд являются взаимоисклю-
чающими, потребовала проведения бо-
лее углубленных исследований в этом
направлении. Результаты анализа суще-
ствующей проблемы позволили наме-
тить несколько возможных путей для ее
преодоления. Одним из наиболее опти-
мальных, на наш взгляд, является реше-
ние, которое предложено и описано в
данной статье. Оно не заменит тех необ-
ходимых организационных потребно-
стей, которые необходимы при работе с
таким инструментальным средством,
однако позволяет устранить конст-
руктивные проблемы и недостатки са-
мого инструментального средства, рас-
ширить его функциональные возможно-
сти и существенно уменьшить цену про-
дажи конечным пользователям. В обоб-
щенном виде структура и перечень не-
обходимых составляющих предлагае-
мого варианта для разработки такого ин-
струментального средства управления
требованиями должны соответствовать
следующим обязательным условиям:
- базовым средством хранения
информации о требованиях должна быть
многопользовательская база данных;
- организация формирования всех
требований в инструментальном сред-
стве должна осуществляться по иерар-
хическому принципу от потребностей
заказчика через функции к программ-
ным требованиям к ПО;
- с целью оперативности и упро-
щения управления требованиями для
каждого из них требуется добавить па-
раметры (весовые коэффициенты): при-
оритетность, трудоемкость реализации,
степень риска;
- необходимость наличия взаимо-
связей между различными требованиями
и структура их организации должны по-
зволять организовывать такие связи как
линейно по горизонтали для требований
одного уровня, так и иерархически по
вертикали для требований разных уров-
ней;
- построение соответствующего
однотипного универсального интер-
фейса пользователя, желательно на раз-
личных языках, для работы с различ-
ными компонентами самого инструмен-
тального средства управления требова-
ниями;
- одной из основных составляю-
щих предлагаемого варианта является
необходимость разработки возможности
расширенного доступа и взаимообмена
информацией этого инструментального
средства с большинством, а в идеальном
случае со всеми другими инструмен-
тальными средствами проектирования и
разработки ПО через универсальный ин-
терфейс;
- для удобства и наглядности ра-
боты разработчиков с требованиями не-
обходимо создание компонента для воз-
можности генерирования и представле-
ния этих требований в произвольном за-
даваемом пользователем формате.
Организация хранилища
информации о требованиях в много-
пользовательской базе данных является
одним из основных условий, так как
только в этом случае может быть задей-
ствован в полной мере гибкий механизм
организации управления требованиями.
Любой другой вариант существенно ог-
раничивает такие возможности и, на наш
взгляд, неприемлем для полноценного
построения инструментария. Большин-
ство существующих средств уже ис-
пользуют базы данных, что подтвер-
ждает обязательность такого требова-
ния. При этом появляется дополнитель-
ная возможность формирования и
управления требованиями на разных
языках. Это актуально для интернацио-
нального коллектива разработчиков, ко-
гда с одними и теми же требованиями
работают специалисты, говорящие на
разных языках. В сочетании с обменом
информацией через Интернет такая
функция позволяет, например, формиро-
Методи і засоби програмної інженерії
50
вать территориально распределенные
коллективы, которые участвуют в про-
ектировании и разработке ПО для реше-
ния больших и сложных, а в некоторых
случаях и глобальных задач.
Иерархическая организация
требований по принципу от наиболее
общих потребностей через функции к
программным требованиям значительно
упрощает пользователю процесс форми-
рования и управления требованиями при
проектировании и разработке ПО и по-
зволяет детализацию требований прово-
дить поэтапно по мере надобности. Та-
кая структура предоставляет гибкий ин-
струмент формирования и управления
требованиями различных уровней для
конкретных версий. Проектировщики и
разработчики ПО получают возмож-
ность на начальном этапе проанализиро-
вать и отобрать все или большинство
требований-потребностей, предъявляе-
мых для разработки такой системы. За-
тем с помощью функций проводится
предварительная оценка необходимых
показателей данного программного про-
екта (время разработки, стоимость, не-
обходимые ресурсы и т.д.). При согласо-
вании и уточнении всех необходимых
формальностей с заказчиком одним из
важных пунктов является определение
приоритетности и последовательности
реализации этих потребностей. Таким
образом, разработка и управление непо-
средственно программных требований
осуществляются непосредственно перед
началом разработки той версии, в кото-
рую данное требование вошло. Это по-
зволяет экономить время не детализируя
разработку всех требований на началь-
ном этапе проектирования, а приступать
к нему тогда, когда оно запланировано.
Однако следует учитывать тот факт, что
в процессе разработки требования могут
изменяться, добавляться или удаляться.
Особенно это актуально для современ-
ных моделей жизненного цикла про-
граммных систем. Например, для разви-
той спиральной модели, описанной в [5].
Наличие весовых коэффициентов
приоритетности, трудоемкости реализа-
ции и степени риска для требований по-
зволяет разработчикам распределять и
оптимизировать проектирование и раз-
работку сложных программных систем
во времени и последовательности реали-
зации. Существенным преимуществом
наличия таких параметров является воз-
можность проведения оперативного
проектирования изменений в системе
путем корректирования коэффициентов
уже в процессе выполнения разработки
ПО, если возникает необходимость. Та-
кая возможность позволяет автоматизи-
ровать сам процесс управления требо-
ваниями на всех этапах разработки ПО и
быстро, без существенных затрат, про-
ектировать всю системы с учетом изме-
нившихся обстоятельств. При проекти-
ровании инструментального средства
управления требованиями весовые
коэффициенты могут присутствовать в
качестве основных атрибутов для требо-
ваний.
Система наличия взаимосвязей
между требованиями позволяет полу-
чить разработчику ПО наглядную кар-
тину проектируемой системы или ка-
кого-либо ее варианта в целом в любой
момент времени, оценить степень зави-
симости требований между собой и
сложность выполнения изменения или
модификации того или иного требования
еще до начала проведения таких изме-
нений. Такая структура предоставляет
инструментальному средству управле-
ния требованиями дополнительную воз-
можность моделировать процесс выпол-
нения всех взаимосвязанных изменений
при условии необходимости изменения
какого-либо требования. Основываясь
на результатах различных вариантов та-
кого моделирования, позволяющих оце-
нить объем необходимых затрат для вы-
полнения изменений, по согласованию с
заказчиком, можно осуществлять поиск
и принимать наиболее оптимальный и
приемлемый вариант выполнения внесе-
ния изменений.
Создание однотипного универ-
сального интернационального интер-
фейса пользователя для работы с раз-
личными компонентами внутри самого
инструментального средства управления
Методи і засоби програмної інженерії
51
требованиями является дополнитель-
ным, однако весьма важным и необхо-
димым сервисом. Важнейшим преиму-
ществом такого компонента является тот
факт, что для пользователя отпадает не-
обходимость в многочасовом или даже
многодневном изучении инструкций для
работы с такой системой и появляется
возможность непосредственно присту-
пить к работе с ней. В общем виде такой
алгоритм предусматривает начало ра-
боты пользователя с любым компонен-
том системы из одной общей панели,
затем с помощью навигатора и дополни-
тельных помощников-мастеров предос-
тавляется существующий сервис сис-
темы и проводится сопровождение его
действий на всех этапах нахождения в
системе.
Формирование возможности рас-
ширенного доступа и взаимообмена ин-
формацией с другими инструменталь-
ными средствами проектирования и раз-
работки ПО через универсальный ин-
терфейс является одной из важнейших
составляющих предлагаемого инстру-
ментального средства. Такая возмож-
ность позволяет разработчикам сложных
программных систем перейти на новый,
более высокий уровень выполнения ра-
бот - комплексную автоматизацию про-
цессов проектирования, разработки, тес-
тирования и внедрения программных
средств. При этом отпадает необходи-
мость дублирования хранения одинако-
вой информации в различных инстру-
ментальных средствах. Достаточно хра-
нить ее в одном источнике, а во всех ос-
тальных организовать связь и ссылку на
нее. Комплексная автоматизация процес-
сов, с одной стороны, значительно упро-
щает их проектирование, а в случае
необходимости внесения необходимых
корректировок, с другой – существенно
сокращает время на выполнения этих
работ.
Необходимость хранения инфор-
мации о требованиях в базе данных на-
ряду с перечисленными выше преиму-
ществами обладает одним недостатком –
недостаточная наглядность в оператив-
ной работе с ними. С целью устранения
этого недостатка предлагается разра-
ботка дополнительного программного
модуля в таком инструментальном сред-
стве, который генерирует возможность
представления требований в произволь-
ном задаваемом пользователем формате.
Этот дополнительный сервис, с одной
стороны, позволяет хранить в базе дан-
ных требования различных типов в од-
ном стандартном формате, с другой сто-
роны, при необходимости представления
их пользователю в визуальном или пе-
чатном виде осуществляется обратное
преобразование в соответствующий
формат. Следует заметить, что сам пер-
вичный процесс формирования таких
разнотипных требований осуществля-
ется с помощью этого же дополнитель-
ного сервисного модуля.
Простота в работе, универсаль-
ность и «многоязычность» пользова-
тельского интерфейса и главное наличие
связи и обмена данными с другими раз-
личными инструментальными средст-
вами проектирования и разработки ПО,
благодаря дополнительно предложен-
ным составляющим, должны заинтере-
совать и привлечь значительно большую
аудиторию потенциальных пользовате-
лей и потребителей данного продукта в
сравнении с существующими аналогами.
Этот фактор, несмотря на большие за-
траты при проектировании и разработке
такого инструментального средства, по-
зволит снизить его цену продажи до
уровня, который позволит приобретать
продукт средним и даже мелким пред-
приятиям и разработчикам ПО. Такой
дополнительный класс потенциальных
пользователей и заказчиков предлагае-
мого инструментального средства в
свою очередь будет способствовать еще
большему расширению рынка потреб-
ления.
Заключение
Основной целью предложенных в
данной работе структурной особенности
и перечня необходимых составляющих
компонентов нового инструментального
средства управления требованиями яви-
лась необходимость поиска возможных
Методи і засоби програмної інженерії
52
направлений для преодоления конструк-
тивных недостатков существующих раз-
работок в этой области. Исследования
показали эффективность применения
данного средства. Предложен комплекс-
ный вариант разработки, который по-
зволяет наряду с существенным расши-
рением функциональных возможностей
значительно снизить ее цену продажи.
Следует особенно отметить акту-
альность разработки и использования
этого инструментального средства при
переходе к перспективному направле-
нию комплексной автоматизации всего
процесса проектирования, разработки и
отладки сложных программных систем с
помощью нескольких различных ИС.
Наличие интерфейса связи и взаимооб-
мена информацией между данным сред-
ством и другими ИС, возможность авто-
матизации процесса анализа необходи-
мости внесения изменений и корректи-
ровок при внесении изменений в требо-
вания, формирование перечня таких из-
менений и оперативное занесение их в
другие ИС позволяют утверждать, что
ведущая роль в таком комплексе может
принадлежать инструментальному сред-
ству управления требованиями к ПО с
учетом описанных в данной статье ре-
комендаций и предложений к нему.
1. Леффингуел Д, Уидрих Д. Принципы ра-
боты с требованиями к программному обес-
печению. Унифицированный подход: Пер. с
англ. – М.: Изд. дом «Вильямс», 2002. –
448 с.
2. Вигерс К. Разработка требований к про-
граммному обеспечению: Пер. с англ. – М.:
Изд. дом «Русская Редакция», 2004. – 576 с.
3. Jones. D. A., Donald M. Y., John F. N.,
J.Simpson. Factors Influencing Requirement
Management Toolset Selection. Proc. of the
Fifth Annual Symp. of the National Council on
Systems Engineering., Seattle, 1995. – 2. –
р.33–58.
4. Лесин Д. А., Томащенко С. Н.. Основы
использования Rational RequisitePro. – 2001,
214 с.
5. Алексеев В.А., Терещенко В.С. Развитие
спиральной модели жизненного цикла про-
граммных систем // Проблемы программи-
рования. – 2003. – № 4. – С. 34-42.
Получено 22.02.05
Об авторах
Лаба Михаил Николаевич
заведующий отделом
Матвейшин Сергей Николаевич
кандидат технических наук,
научный сотрудник
Место работы авторов
Институт программных систем
НАН Украины,
просп. Академика Глушкова, 40,
Киев-187, 03680, Украина
Тел. 526 3225, 526 7038
E-mail: sergmmm@isofts.kiev.ua
|