Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

от», автоматически определяя дополнительную ссылку. То есть, если

вы укажете, что требование R отслежено до варианта тестирования Т

средство также покажет симметричное отношение, в котором Т трас-

сируется от R.

Некоторые средства автоматически каждый раз помечают ссылку

как

подозрительную,

когда объект на одном из концов связи

изменяет-

ся. Подозрительная ссылка помечается (например, знаком

вопроса

красного цвета или диагональной линией красного цвета) в соответст-

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

вы измените вариант использования 3, то матрица трассирования тре-

бований в табл. 20-2 может

выглядеть,

как показанная в табл. 20-4, ко-

гда вы на нее посмотрите в следующий раз. Указатель

подозрительной

связи

(в

данном случае знак вопроса) напоминает вам, что нужно про-

верить, следует ли модифицировать функциональные требования 3, 4

и 6, чтобы те остались совместимыми с измененным ВИ-3. После вне-

сения всех необходимых изменений необходимо вручную убрать ука-

затели подозрительных ссылок. Это процесс помогает

убедиться,

что

вы учли все возникшие в результате волнового эффекта изменения.

Таблица 20-4.

Подозрительные

связи в матрице трассирования требований

Функциональное требование (ФТ)

ФТ-1

ФТ-2

ФТ-3

Вариант использования

ВИ-1

ВИ-2 ВИ-3

(ВИ)

ВИ-4

ФТ-4

ФТ-5

ФТ-6

Средства также позволяют определить связи между проектами или

между подсистемами. Я знаю об одном крупном проекте ПО с 20 круп-

ными подсистемами, где требования к продукту высокого уровня рас-

пределены среди этих подсистем. В некоторых случаях

требование,

адресованное одной подсистеме, реализовалось с помощью службы,

предоставленной другой подсистемой. В этом проекте для успешного

Глава 20. Связи в цепи требований 39!)

трассирования этих сложных отношений трассирования использова-

лось средство

управления

требованиями.

Трассирование требований вручную невозможно выполнить ни для

одного приложения, за исключением самых маленьких. Вы можете

воспользоваться рабочей таблицей для поддержания данных трасси-

руемости почти пары сотен требований, однако для более крупных

систем необходимо решение понадежнее. Трассирование требований

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

связей хранятся в головах разработчиков. Однако после того как вы

определите связи, средства помогут вам управлять огромным объе-

мом информации трассируемости.

Процедура трассирования требований

Придерживайтесь следующей последовательности действий для реа-

лизации трассирования требований,

1. Выберите отношение связей, которое вы хотите определить, из

тех, что показаны на рис. 20-2.

2. Выберите тип матрицы трассирования требований, которую вы хо-

тите использовать: показанную в табл. 20-1 или в табл. 20-2. Выбе-

рите механизм для хранения данных: таблицу в текстовом доку-

менте, рабочую таблицу или средство управления требованиями.

3. Определите части продукта, для которой вы хотите поддерживать

информацию трассируемости. Начните с важнейших основопола-

гающих функций, фрагментов, отличающихся высоким риском, или

частей, которые, как вы и ожидали, потребуют большей части под-

держки и будут быстрее развиваться в течение жизненного цикла

продукта.

4. Модифицируйте процедуры разработки и списки вопросов, чтобы

напомнить разработчикам об обновлении связей после реализа-

ции требования или утверждения изменения. Данные трассируе-

мости должны обновляться сразу после завершения задачи, в ре-

зультате которой создается или изменяется звено в цепи требова-

ний,

5. Определите соглашения об именовании, которые вы будете ис-

пользовать для уникальной идентификации всех элементов систе-

мы таким образом, чтобы их удалось связать друг с другом (Song и

др., 1998). При необходимости напишите сценарии, которые будут

396 Часть III. Управление требованиями к ПО

выполнять анализ файлов системы для сборки и обновлять матри-

цы трассирования.

6. Определите лиц, которые будут поддерживать каждый тип инфор-

мации о связях, и

сотрудника,

координирующего трассирование и

управляющего данными.

7. Проинформируйте команду о концепции и важности

трассирове-

ния требований, о целях этого, о том, где хранятся данные

трасси-

руемое™,

и приемах для определения связей (например, с помо-

щью функции трассирования средства управления требованиями

Убедитесь, что все участники осознают их ответственность.

8. Попросите каждого участника предоставлять запрашиваемую ин-

формацию трассируемости по мере завершения небольших участ-

ков работы. Напоминайте о том, что работа над созданием

данных

трассируемости не прекращается ни на минуту; не говорите о том,

что вы попытаетесь воссоздать эти данные на важном этапе рабо-

ты или в конце проекта.

9. Периодически проверяйте информацию трассируемости, чтобы

убедиться, что она не устарела. Если поступает сообщение, что

требование реализовано и проверено, но данные трассируемое™

неполны или

неточны,

означает, что процесс трассирования требо-

ваний не работает так, как ожидалось,

Я описал эту процедуру, как если бы вы начинали собирать

инфор-

мацию трассируемости с начала нового проекта. Если вы

обслуживае-

те действующую систему, то бьюсь об заклад, что у вас нет доступных

данных трассируемости, однако у вас нет времени начинать сбор этой

полезной информации. В следующий раз, когда вы добавите

улучше

ние или внесете изменение, запишите все, что вы узнали в связях меж

ду кодом, тестами, дизайном и требованиями. Учтите необходимость

трассируемости данных в процедуре для изменения

существующего

компонента ПО. Вам уже не удастся собрать полную матрицу трасси

рования требований, однако это небольшое усилие может облегчить

работу над этой же частью системы в следующий раз.

Осуществимость и необходимость

трассирования требований

Вы можете прийти к заключению, что на создание матрицы трасси-

рования требований вы тратите больше, чем получаете, или что

она

неосуществима для вашего крупного

проекта,

поэтому я хочу привести

Глава 20. Связи в цепи требований

397

вам контрпример. Как-то на конференции один участник, занима-

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

требования для работы над последним реактивным самолетом пред-

ставляла собой кипу бумаги высотой в шесть футов. У них была полная

матрица трассирования требований. Я летал на именно этой модели

самолета и был счастлив узнать, что разработчики так тщательно по-

работали над своими требованиями к ПО. Управление трассируемо-

стью для большого продукта с множеством взаимосвязанных подсис-

тем — это большой объем работы. Мой новый знакомый

знал,

что это

очень важное дело, и Федеральное управление гражданской авиации

было с ним согласно.

Даже если в случае неудачи ваши продукты не могут стать причиной

угрозы жизни или здоровью

людей,

вам следует серьезно отнестись к

трассированию требований. Когда я рассказывал

отрассируемости

на

семинаре,

глава крупной корпорации спросил: «Почему вы не созда-

дите матрицу трассирования требований для вашей стратегической

бизнес-системы?» Это отличный вопрос. Вы должны принимать реше-

ние об использовании любых улучшенных приемов разработки требо-

ваний, принимая во внимание и затраты на внедрение приема и риск

отказа от приема. Как и со всеми процессами ПО, экономические фак-

торы должны определять, тратить ли ваше ценное время там, где воз-

можна наибольшая отдача.

Что теперь?

I Создайте матрицу трассирования требований

для

или 20 требований к важ-

ной части системы, которую вы в настоящее время

разрабатываете.

Опробуйте

приемы, показанные в табл. 20-1 и в табл. 20-2. Заполняйте матрицу по мере

разработки, в течение нескольких недель.

Оцените,

какой метод кажется наибо-

лее эффективным и какие процедуры для сбора и хранения информации грасси-

руемости

подойдут для вашей команды,

В следующий раз, когда будете обслуживать плохо задокументированную систе-

му, записывайте, чему научил вас инженерный анализ продукта, который вы мо-

дифицируете. Постройте фрагмент матрицы трассирования требований для

фрагмента головоломки, над которой вы сейчас работаете, чтобы облегчить

жизнь тому, кто займется ей в следующий раз. Расширяйте матрицу трассирова-

ния требований по мере

обслуживания

проекта.

398 Часть III. Управление требованиями к ПО

Инструментальные средства

управления требованиями

В предыдущих главах я уже говорил о создании спецификации

требо-

ваний к ПО на естественном

языке,

которая содержит функциональ-

ные и нефункциональные требования, а также, о создании

докумен-

тов, содержащих бизнес-требования и описания вариантов использо-

вания. Документальный способ хранения требований имеет массу

ограничений, в том числе:

1 трудность обновления и синхронизации документов;

всем членам команды, которым это необходимо, передачу измене-

ний приходится осуществлять вручную;

I трудность хранения дополнительной информации (атрибутов) для

каждого требования;

трудность определения взаимосвязей между

функциональными

требованиями и другими элементами системы;

1 трассирование статуса требований представляет собой трудный и

неудобный процесс;

одновременное управление наборами требований,

запланирован-

ных для различных выпусков или взаимосвязанных продуктов,

за-

труднено. Когда реализация требования откладывается до следую-

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

цификации требований в другую;

при повторном использовании какого-то требования

аналитику

приходится колировать текст исходной спецификации требований в

спецификацию требований каждой системы или продукта, где оно

будет использоваться;

1 трудность модификации требований несколькими участниками

проекта, особенно если они географически разделены;

399

14-2437

I отсутствие удобного места хранения требований, которые были

предложены, но

отклонены,

или

требований,

удаленных

из

основ-

ной версии.

Средство управления требованиями, хранящее информацию в мно-

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

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

электронные таблицы или простые базы данных, сохраняющие как

текст, так и отдельные атрибуты каждого требования. В более крупных

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

бованиями. Такие продукты позволяют пользователям импортировать

требования из исходных

документов,

определять значения атрибутов,

фильтровать и выводить на экран содержание базы данных, экспорти-

ровать требования в различных форматах, контролировать связи трас-

сирования и соединять требования с элементами, хранящимися в дру-

гих средствах разработки ПО.

Ловушка Избегайте искушения разработать собственное средство управления

требованиями или на скорую руку слепить его из средств офисной автоматизации

общего назначения в подражание коммерческим продуктам. Первоначально это ка-

жется легко, но такая работа может быстро истощить ресурсы

команды,

не обла-

дающей средствами, необходимыми для создания желаемого инструмента.

Обратите внимание, я называю эти продукты средствами управле-

ния требованиям, а не их

разработки.

Они не помогут вам определить

потенциальных пользователей или собрать нужные требования для

создаваемого продукта. Тем не менее они позволяют очень гибко

управлять изменениями в этих требованиях и использовать их как ос-

нову

для конструирования, тестирования и управления продуктом. Эти

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

которых члены вашей команды выявляют требования и управляют

ими.

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

ей не хватает

эффективности;

не надейтесь, что инструмент восполнит

недостаток трудолюбия, дисциплины, опыта или понимания.

Данная глава рассказывает о нескольких преимуществах использо-

вания средств управления требованиями и указывает на некоторые об-

щие возможности таких продуктов. В табл. 21 -1 перечислено несколь-

ко доступных в настоящее время инструментальных средств управле-

ния требованиями. В этой главе я не буду подробно сравнивать их —

функция за функцией, поскольку эти продукты еще развиваются, и их

возможности изменяются с каждой версией. Цены на них, платформы

которые они поддерживают, и даже производители также часто

изме-

400 Часть

III.

Управление требованиями к ПО

няются,

поэтому для получения текущей информации используйте Ин-

тернет-адреса, приведенные в табл.

21-1

(с учетом того, что и Интер-

нет-адреса могут изменяться, если, например, один производитель ПО

поглотит другого, как случилось за две недели до написания этого

ме-

териала). Детализированное сравнение возможностей этих и многих

других инструментальных средств вы найдете на Web-странице

Inter-

national Council on Systems Engineering

(http://www.incose.org/toc.htm!}.

Там же опубликованы рекомендации по выбору инструментального

средства

управления

требованиями

(Jones

и др.,

1995).

Таблица

21-1.

Некоторые коммерческие инструментальные

средства управления требованиями

Инструмент

Active! Focus

CaliberRM

C.A.R.E,

DOORS

RequisitePro

RMTrak

RTM Workshop

Slate

Vital Link

Производитель

Xapware Technologies,

http://www.hapware.com

Borland Software Corporation, http://www.borland.com

SOPHIST Group,

http://www.sophist.de

Telelogic,

http://www.telelogic.com

Rational Software Corporation, http://www.rational.com

RBC, Inc.,

http://www2.rbcorp.com

Integrated Chipware, Inc. http://www.chipware.com

EDS,

http://www.eds.com

Compliance Automation,

Inc.,

http://www.complianceautomation.com

Способ

хранения

данных

База

данных

База

данны)

База данных

База данны>

Документ

База данны

База данных

Документ

Важное отличие инструментальных средств заключается в способе

хранения данных. Одни хранят все требования, атрибуты и

инфор-

мацию трассирования в базе данных. В зависимости от продукта, база

данных может быть коммерческой или разработанной собственными

силами и запатентованной, реляционной или

объектно-ориенти-

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

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

текстовое описание требования считается просто одним из атрибутов.

Некоторые продукты позволяют устанавливать связи отдельных

Глава

21.

Инструментальные средства управления требованиями

401

требований с внешними файлами

(например,

файлами Microsoft

Word,

Mirosoft

Excel, графическими файлами и

т.д.).

которых содержится

информация, дополняющую содержимое базы,

При документальном подходе документ, созданный при помощи

текстового процессора (такого, как Microsoft Word или Adobe

FrameMaker), считается основным хранилищем требований. Requi-

sitePro позволяет вам выбирать текстовые строки в документе Word

для сохранения их в виде отдельных

требований

в базе данных. После

ввода требований в базу данных вы

можете

определить атрибуты и

связи трассирования так же, как и в

продуктах,

данные которых хранят-

ся в БД — механизмы синхронизации базы данных и содержимого до-

кумента для этого предусмотрены. RTM Workshop поддерживает обе

схемы: в первую очередь хранение данных в базе

данных,

но также и в

документе Microsoft Word.

Эти средства не дешевы, но высокая стоимость решения проблем

управления требованиями оправдывает инвестиции в них. Учитывайте,

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

лицензии. Вам придется потратиться на компьютер, на который будет

установлена программа, учесть ежегодные затраты на поддержку и пе-

риодическое обновление продукта, на установку ПО, администрирова-

ние, техническую поддержку и консультации производителя, а также

на обучение пользователей. Проанализируйте возможные затраты и

результаты до того, как примете решение о покупке.

Преимущества использования

инструментальных средств

управления требованиями

Даже если вы провели внушительную

рабогу

по сбору требований для

своего проекта, автоматизированная поддержка поможет

вам

оперировать с этими требованиями в процессе разработки. Инстру-

ментальное средство управления требованиями становится все по-

лезнее со временем, когда детали требований постепенно тускнеют в

памяти членов команды. В следующих разделах описаны некоторые

задачи, которые подобное средство поможет вам решать.

Управление версиями и изменениями. Ваш проект должен опреде-

лять основную версию

требований—

четкий набор требований для

конкретной версии. Некоторые средства управления требованиями

402 Часть III. Управление требованиями к ПО

предлагают функции гибкого управления базовой версией. Они также

сохраняют историю изменений каждого требования. Вы можете запи-

сывать обоснование каждого решения об изменении и при необходи-

мости возвратиться к предыдущей версии требования. Некоторые

средства, такие, как Active! Focus и DOORS, содержат простые, встро-

енные системы изменений-предложений, устанавливающие связи ме-

жду предложениями об изменениях и измененными требованиями.

Хранение атрибутов требований. Вы должны записывать несколько

описательных атрибутов для каждого требования, как говорилось в

главе 18. Каждый, кто работает над проектом, должен иметь

доступ

просмотру этих

атрибутов,

а некоторые — к изменению их значений.

Инструментальное средство управления требованиями генерирует

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

и номер его версии, а также, позволяет вам создавать дополнитель-

ные атрибуты различных типов данных. Продуманное определение ат-

рибутов позволяет всем заинтересованным в проекте лицам просмат-

ривать подмножества требований, основанных на выбранных комби-

нациях значений атрибутов. Вы можете запросить список всех

требований, основанных на

каком-либо

бизнес-правиле, чтобы при-

нять решение о последствиях изменения этого правила. Один из спо-

собов учета требований в основных версиях различных

выпусков

продукта — использовать атрибут «номер выпуска».

Облегчение анализа воздействия. Средства управления

требова-

ниями помогают осуществлять трассирование требований, позволяя

вам определять связи между различными типами требований,

между

требованиями в различных подсистемах и между отдельными

требо-

ваниями и связанными системными компонентами (например,

дизай-

ном, модулями кода, тестами и пользовательской документацией).

Эти связи помогут вам анализировать воздействие, которое

предла-

гаемое изменение окажет на конкретное

требование,

выявляя другие

элементы системы, которые оно затронет. Другой полезный способ —

отследить каждое функциональное требование назад до первоисточ-

ника, чтобы знать, откуда оно берет начало.

Дополнительная информация В главе

описан анализ воздействия, а в

главе

20 - трассирование требований.

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

данных, вы узнаете, сколько отдельных требований вы указали для

продукта. Трассирование статуса каждого требования в процессе раз-

работки способствует общему трассированию статуса проекта.

Ме-

Глава

21.

Инструментальные средства управления требованиями 403

определяя связи между объектами двух классов (или внутри одного

класса) на основе взаимоотношений между классами, заданными в

схеме.

К числу других функций относится возможность задавать группы

пользователей и определять разрешения некоторым пользователям

или группам на создание, чтение,

обновление

и удаление проектов,

требований, атрибутов и их значений.

Некоторые

продукты позволяют

поместить нетекстовые объекты, такие, как графику и крупноформат-

ные таблицы, в базу требований. Инструментальные средства предла-

гают также средства обучения или

проекты-примеры,

которые помогут

пользователям научиться работать быстро и эффективно.

Эти продукты отражают тенденцию к увеличению интеграции с дру-

гими инструментальными

средствами,

используемыми в

разработке

приложений, как показано на рис. 21-1. Выбирая средство для управ-

ления требованиями,

выясните,

сможет ли оно обмениваться данными

с другими используемыми вами инструментами. Вот лишь несколько

примеров взаимосвязей между инструментальными средствами,

су-

ществующими сегодня:

1 вы можете устанавливать связи между требованиями в RequisitePro

и вариантами использования, смоделированными в Rational Rose, a

также вариантами тестирования, хранящимися в Rational TeamTest;

1 DOORS позволяет трассировать требования вплоть до отдельных

конструктивных элементов, хранящихся в Rational

Rose,

Telelogic

Таи и других инструментах дизайна;

1 RequisitePro и DOORS могут устанавливать связи между отдельны-

ми элементами проектного задания в Microsoft Project;

CaliberRM

имеет централизованную структуру коммуникаций, кото-

рая позволит вам связать требования с вариантами использования,

классами или элементами дизайна процессов, хранящимися в

То-

getherSoft

Control

Center,

с исходным кодом, хранящемуся в Bor-

land's StarTeam, и с тестовыми элементами, хранящимися в Mercury

Interactive's

TestDirector.

Вы сможете получать доступ к этим взаимо-

связанным элементам непосредственно из требований,

хранящих-

ся в базе данных

CaliberRM.

Оценивая программные средства, подумайте, как вы сможете вос-

пользоваться преимуществом интеграции продуктов при составлении

требований, тестировании, трассировании проекта и других процес-

сах. Например, подумайте, как

опубликовать

основной набор требова-

ний в инструменте для управления версиями продукта и определить

связи трассирования между

функционапьными

требованиями и кон-

кретными элементами дизайна или кода.

406 Часть III. Управление

требованиями

ПО