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

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

Средство

контроля версий

)

^~*^

Средство

трассирования

проектов

Средство

управлении

тестированием

Средство

управления

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

Средство

изменения

запросов

Средство

моделирования

дизайна

Средство

оценки проекта

Рис.

21-1.

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

с другими видами программных средств

Реализация автоматизации управления

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

Любой из этих продуктов позволяет управлять требованиями на

более

тонком

производительном уровне. Тем не менее старание

пользова-

телей инструментальных средств остается критическим фактором

ус-

пеха. Усердные, дисциплинированные и знающие люди

добиваются

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

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

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

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

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

кривую обучения

(learning

curve) и затраты времени]. Вы не можете

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

проект сразу станет успешным из-за применения

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

средства. Прежде наберитесь опыта, работая с инструментом над

пробными проектами, и лишь затем применяйте его в важном проекте.

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

описано,

как кривая обучения

связа-

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

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

407

Выбор инструментального средства

Выбирайте инструментальное средство,

учитывая

такие параметры,

как платформа, цена, режим доступа и способ хранения данных для

требований —

документальный

или в базе

данных,

которые лучше все-

го подходит вашей среде разработки и

кульгуре.

Некоторые компании

нанимают для оценки

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

средств консультантов, кото-

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

продукт. Если вы проводите оценку

самостоятельно,

перечисленные

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

Во-первых, определите требования организации к средству управ-

ления требованиями. Установите, какие возможности для вас наи-

более существенны, с какими еще

средствами

вам хотелось бы ин-

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

данным через Интернет. Решите, хотите ли вы использовать для

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

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

2. Перечислите 10-15 факторов, которые влияют

на

ваш выбор. Учти-

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

ной настройки, эффективность продукта и интерфейса пользова-

теля. Стоимость, конечно же, важна, но прежде оценивайте инстру-

ментальные средства, не оглядываясь на их цену.

3. Оцените факторы выбора, перечисленные в пункте 2, в очках (всего

100 очков), назначая большее значение гем факторам, которые вы

считаете более важными.

4. Соберите текущую информацию о доступных инструментальных

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

определенных вами факторов. С оценкой субъективных факторов

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

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

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

щи, но

скорее

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

румента. Демонстрация не заменит самостоятельную работу с

продуктом в течение нескольких часов.

5. Подсчитайте общую сумму отдельно для каждого инструмента,

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

мете, какие продукты подходят вам лучше всего.

6. Попросите других пользователей составить отчеты об использова-

нии каждого продукта, например разместив запросы на форумах в

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

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

просите у поставщика литературу,

демо-версию

продукта и данные

о цене.

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

рументальные средства, занявшие верхние места в вашем рейтин-

ге. Определите, как будете проводить оценку до того, как

устанав-

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

необходимую для принятия решения информацию.

8. Оцените инструментальные средства, применяя их в реальном про-

екте, а не только в обучающем проекте, поставляемом с продуктом.

Завершив оценку, при необходимости уточните параметры оценки

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

9. Примите решение, учитывая как количество очков, набранных каж-

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

сопровожде-

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

впечатге-

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

Изменение

культуры

работы

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

органи-

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

мальную пользу, гораздо сложнее. Большинство организаций уже при-

выкли

(и

чувствуют себя при этом весьма комфортно!) хранить требо-

ваний в форматах текстовых редакторов. Для перехода к оперативным

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

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

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

решения. Некоторые воспринимают это как уменьшение контроля над

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

ния требований или над тем и другим. Другие предпочитают не пока-

зывать миру неполные или несовершенные спецификации требований

к ПО, но содержание базы данных доступно всем. Скрывая требования

до

того,

как они «готовы», вы упустите возможность показать их мно-

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

можных проблем.

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

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

стями. Я знаю команду, которая, работая над проектом, прилежно

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

этих требований никаких атрибутов или связей трассирования. Не

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

проек-

те лицам. Тот факт, что требования хранились в иной форме, не дал су-

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

Глава

21.

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

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

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

ния. Но

единственное,

для чего использовались эти данные, была ге-

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

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

эти отчеты не изучал, и никто не считал

базу

данных заслуживающим

доверие хранилищем требований. Ни одна из этих организаций не по-

лучила полной выгоды от существенных инвестиций времени и денег в

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

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

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

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

ниями:

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

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

требований к ПО на бумаге. Если ваша основная проблема связана

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

ва вам не помогут;

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

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

выявления требований. Однако,

по

мере

того

как требования начнут

обретать устойчивые

формы,

хранение их в программе откроет дос-

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

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

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

личных регионах. Установите доступ и измените привилегии раз-

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

давая при этом им права изменять всю базу данных;

I тщательно продумывайте, какие типы требований вы определяете.

Не считайте каждый раздел вашей нынешней спецификации требо-

ваний отдельным типом требований, но и не помещайте все содер-

жимое спецификации в единственный тип требований. Инструмен-

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

ждого определяемого типа

требований,

так что выбор

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

ных типов требований определять;

i назначьте ответственного для каждого типа

требований,

который

будет отвечать за управление информацией этого типа в базе дан-

ных;

используйте деловую, а не

ИТ-терминологию,

определяя новые по-

ля данных или атрибуты требований;

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

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

устойчивые формы. В противном случае вам придется исправлять

массу связей по мере изменения требований;

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

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

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

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

По-

сле этой даты все требования, содержащиеся в формате текстовых

редакторов, не будут считаться документами, имеющими силу;

не ожидайте фиксации требований на ранних стадиях проекта, вы-

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

каждого конкретного выпуска. При необходимости динамически пе-

реносите требования из основной версии одного выпуска в

основ-

ную версию другого выпуска.

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

говорилось об использовании

атри-

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

выпусков.

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

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

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

эле-

мент работы, как, например, кодирование. Команда будет

открывать

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

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

нениями в них. Вместе с тем помните: даже самое лучшее инструмен-

тальное средство не сможет восполнить пробелы неэффективною

процесса разработки требований. Программа не поможет вам

оцени"

масштабы своего проекта, определить пользователей, поговорить с

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

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

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

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

назнач

те «защитника» инструментального средства, энтузиаста, который сам

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

и следить, чтобы его применяли как нужно. Начните с пробного

приме-

нения инструментального средства в не очень важном проекте. Это

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

ментальным средством и его поддержки. Первый «защитник» инстру-

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

Глава

21.

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

411

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

го средства в других проектах. Несомненно члены вашей команды со-

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

инструмент. Они, конечно же, додумаются, как осуществлять основные

операции, но полный набор возможностей инструмента и их эффек-

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

Учитывайте, что загрузка требований проекта в базу данных, опре-

деление атрибутов и связей трассирования, своевременное обновле-

ние содержимого базы данных, определение доступа групп и их при-

вилегий, а также подготовка пользователей потребуют усилий. Руково-

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

Доведите до сведения всех сотрудников вашей фирмы

просьбу

дейст-

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

тится в дорогое

украшение,

которое лежит на полке.

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

вить недостатки процесса, то скорее всего согласитесь с тем, что ком-

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

лять требованиями к ПО. Если вы заставите базу данных с требования-

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

бумаге.

Что теперь?

1 Проанализируйте недостатки вашей существующей организации управления

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

ли оно вложения. Важно, чтобы вы понимали причины существующих проблем;

не нужно слепо верить, что инструмент решит

их,

i До сравнения предлагаемых продуктов оцените готовность вашей команды

к использованию инструмента. Вспомните

предыдущиеые

попытки включить но-

вые инструментальные средства в процесс разработки ПО. Проанализируйте их

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

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

Особенности

реализации

процесса

построения

Совершенствование процессов

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

В предыдущих главах описано несколько дюжин «хороших приемов»

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

тике. Применение лучших приемов — это основа совершенствования

процесса разработки ПО. Если кратко, совершенствование технологи-

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

показывают хорошие результаты, и отказе от тех, которые в прошлом

приносили одну головную боль. Однако

путь

к совершенствованию

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

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

времени на решение текущих задач, не говоря уже о совершенствова-

нии программ.

Конечная цель совершенствования процессов

разработки

ПО —

уменьшить стоимость создания и сопровождения продукта. Существу-

ет несколько способов достижения этой цели:

1 исправление проблем, выявленных в

придыдущих

или текущих про-

ектах,

которые возникали из-за недостатков в технологическом

процессе;

предупреждение и предотвращение проблем, которые возможны в

будущих проектах;

I применение технологических

процессов,

более действенных, чем

те, что используются в настоящее время.

Если кажется, что методы,

применяемые

вашей командой в настоя-

щем, работают хорошо, или сотрудники настаивают на этом, несмотря

на свидетельства об обратном, не всегда очевидна необходимость ме-

нять подходы к работе. Тем не менее даже успешные организации —

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

заниматься крупными

проектами,

новыми клиентами, удаленным

414

Часть IV. Особенности реализации процесса построения требований

взаимодействием, когда ужесточаются сроки или возникает

необходи-

мость осваивать новые области применения ПО. Методы, отлично за-

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

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

ных по двум часовым поясам и обслуживающих 40 корпоративных кли-

ентов. По меньшей мере вам стоит иметь представление о других спо-

собах конструирования требований, которые могут оказаться ценным

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

В этой главе рассказано, как требования связаны с

различными

ключевыми технологическими процессами и заинтересованными в

проекте лицами. Я познакомлю вас с некоторыми основными концеп-

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

ПО, опишу примерный их цикл, а также перечислю материалы,

состав-

ляющие образцы документов (process

assets}

для работы с требова-

ниями,

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

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

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

тре-

бований,

Как требования связаны

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

Требования составляют основу любого хорошо организованного про-

екта по разработке ПО, поддерживая технические и организационные

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

повлияют на эти задачи, и наоборот. Рис. 22-1 иллюстрирует

некото-

рые взаимосвязи между требованиями и другими процессами

проек-

та; далее кратко описаны взаимосвязи этих процессов.

Планирование проекта. Требования служат основой для процесса

планирования проекта. Те, кто отвечает за планирование, выбирают

подходящий жизненный цикл разработки ПО и разрабатывают ресурс-

ные сметы и график работы на основе требований. Эта процедура

^о-

жет выявить невозможность реализации всего желаемого набора воз-

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

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

или выбрать инкрементальную модель либо модель постадийной реа-

лизации необходимой функциональности.

Глава 22. Совершенствование процессов работы с требованиями 415

служат входными уточняет

данными

для границы

проекта

до построения

основной

версии

Процесс

трассирования

и контроля проекта

запрашивает

изменения

в границах

Процесс

управления

изменениями

Рис.

22-1.

Взаимоотношения требований и других процессов проекта

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

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

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

ся согласно принятому по плану. Если

нет,

он может потребовать су-

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

изменениями.

Управление изменениями. После того как набор требований внесен

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

через определенный процесс управления изменениями. Этот процесс

помогает гарантировать, что:

I все понимают эффект предлагаемого изменения;

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

ния об изменениях;

8 все люди, которых затронут изменения, осознают их;

1 ресурсы и обязательства выверены;

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

416

Часть

IV.

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