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

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

Процедуры управления требованиями

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

проектная

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

тируйте эти действия и организуйте тренинг для специалистов,

чтобы

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

фективно. Обратите внимание на следующее:

1 на инструменты, приемы и соглашения для управления версиями

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

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

на

статус

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

рые

имеют право изменять их;

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

1 на способы, с помощью которых новые требования и изменения су-

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

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

I на методы анализа влияния предложенного изменения;

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

требований.

Вы можете включить всю эту информацию в одно описание процес-

са

управления

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

Или

же разработать отдельные

процеду-

ры для контроля за

изменениями,

анализа влияния и контроля за

со-

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

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

которые должны выполняться каждым проектной командой.

Дополнительная информация В главе 22 описано несколько полезных

образ-

цов документов для управления требованиями.

Кто-то должен выполнять действия при управлении

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

поэтому в описаниях процесса также следует определить роли

участ-

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

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

управление требованиями. Он выбирает механизм сохранения требо-

ваний

(например,

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

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

определяет ат-

рибуты

требований,

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

трассируем

ости требований и сгенерирует отчеты об изменении дей-

ствий

Глава 18. Принципы и приемы управления требованиями к ПО 345

Ловушка Если никто из участников проекта не несет ответственности за выпол-

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

Контроль версий

«Я наконец доделала функцию запроса по каталогу различных

поставщиков, — сообщила Шери на еженедельной встрече,

посвященной состоянию проекта Chemical Tracking System. -

Вот

это была

работа!»

«О,

клиент отказался от этой функции две недели назад, —

по-

дал реплику менеджер проекта Дейв. — Ты разве не получила

новую версию спецификации?»

Шери была озадачена. "Как это

понимать,

отказался? Эти

тре-

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

вверху

страницы 6 са-

мой последней версии моей спецификации».

«Мм, их нет в моей копии.

меня версия 7.5 спецификации.

тебя?»

«У меня тоже 1.5,

—с

отвращением сказала Шери. — Эти доку-

менты должны быть идентичны, но очевидно, это не так. И что,

эта функция все еще включена в базовую версию или я потра-

тила впустую 40 часов моей жизни?»

Если вы когда-либо слышали подобный разговор, вы знаете, как рас-

страиваются люди, когда тратят впустую

время,

работая над устаревши-

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

версий—

это

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

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

идентификатор.

У каждого члена команды должен быть доступ к текущей

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

передавать всем заинтересованным сторонам. Чтобы минимизировать

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

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

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

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

Это не ошибка, а функция!

Разработчики-контрактники

как-то получили массу отчетов об ошибках от людей,

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

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

ные проверки. После обстоятельного изучения проблемы, выяснилось, что клиенты

тестировали новое ПО, сверяясь с устаревшей спецификацией требований. То, что

тестеры в отчетах называли ошибками, на самом деле оказалось функциями. (В

обычной ситуации это просто шутка, из тех, что любят

программисты.}

Масса уси-

лий была потрачена

впустую,

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

ведение системы. Им понадобилось много времени, чтобы переписать тесты в соот-

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

все из-за контроля версий.

Каждая версия документа требований должна содержать историю

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

них, лицо, внесшее изменение, а также причина. Возможно, следует

добавлять номер версии к названию каждого отдельного

требования,

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

бований, например

Print.ConfirmCopies-1,

Простейший механизм управления версиями — именовать вручную

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

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

по

дате изменения или дате

пе-

чати часто приводит к ошибкам и неразберихе; я не рекомендую их ис -

пользование. Несколько

команд,

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

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

вается «Версия 1.0, набросок 1». Следующий черновик называется

«Версия

1.0,

набросок 2». Автор последовательно увеличивает номер

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

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

на «Версия 1.0, утвержденная». Следующие версии называются «Вер-

сия

1.1,

набросок 1» при небольшом изменении или «Версия 2.0, на-

бросок 1» при значительном изменении. (Разумеется, термины «не-

большой» и «значительный» субъективны или, по крайней мере,

зави-

сят от контекста.) При применении этой схемы ясно различаются

наброски и версии базового документа, однако необходимо

соблю-

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

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

требования

в текстовом редакторе, вы можете

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

функция выделяет внесенную правку, зачеркивая удаленные фрагмен-

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

Глава 18. Принципы и приемы управления требованиями к ПО 347

полях положение каждого изменения. Так как откорректированный до-

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

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

чательную версию с принятой правкой. После того как вы составите

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

хив версии с

пометками,

затем примите все коррективы, а затем со-

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

го раунда изменений.

Более сложный метод предполагает сохранение спецификации тре-

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

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

(check-in и

check-out}.

Для этой цели разработана масса коммерче-

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

проекте,

когда несколько сотен написанных в Microsoft Word вариантов исполь-

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

версий.

Чле-

ны команды имеют доступ ко всем предыдущим версиям каждого ва-

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

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

за архивирование, предоставлен доступ на чтение и запись; осталь-

ным членам команды — доступ только на чтение.

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

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

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

как описано в главе

21.

Эти средства отслеживают пол-

ную историю изменений требований, что особенно важно, если нужно

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

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

добавлении, изменении или удалении требования; эти комментарии

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

ния в будущем.

Атрибуты требований

Представьте себе каждое требование в виде

объекта,

который облада-

ет свойствами, отличающими его от других требований. В дополнение

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

должно

иметь несколько поддерживающих его фрагментов информации, или

атрибутов (attributes), связанных с ним, Эти атрибуты представляют

содержимое и

поднаготную

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

за описанием предполагаемой функциональности. Вы можете сохра-

нить атрибуты в таблице, базе данных или, что наиболее эффективно,

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

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

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

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

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

на

основании значений их атрибутов и запрашивать базу данных для и:<

просмотра. Например, вы можете вызвать список всех высокоприори-

тетных

требований,

которые

Шери

должна реализовать в версии 2.3 и

которые

имеют статус Approved

(Одобрено).

Большой набор атрибутов особенно важен для громадных и слож-

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

такие атрибуты, как:

I дата создания требования;

I номер его текущей версии;

i автор

требования;

1 лицо, ответственное за удовлетворение требования;

I ответственный за требование или список заинтересованных

лиц

(чтобы принимать решения о предложенных изменениях);

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

происхождение или источник требования;

I логическое обоснование требования;

I подсистема (или подсистемы), для которых предназначено

требо

вание;

i номер версии продукта, для которого предназначено требование;

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

прием-

лемости;

i приоритет реализации;

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

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

плохо определенные или изменчивые бизнес-процессы или биз-

нес-правила).

Для чего же нужно это требование?

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

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

обладал теми же функциями. Такие функции хорошо отмечать с помощью атрибута

Rationale (Логическое обоснование), позволяющего указать, почему конкретное тре-

бование включено в продукт.

Глава 18. Принципы и приемы управления требованиями к ПО 349

Выберите наименьший набор атрибутов, с помощью которого вам

удастся

эффективно управлять проектом,

Например,

вряд ли вам

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

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

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

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

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

Ловушка Множество атрибутов требований могут настолько озадачить разработ-

чиков,

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

для

всех атрибутов и

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

ключевых

атрибутов. Добавьте другие атрибуты, когда вы будете знать, каким обра-

зом они улучшат ваш проект.

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

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

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

них версий существующих требований. Разработчики могут

^жонгли-

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

та и будущих версий. Управление этими изменяющимися базовыми

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

основе—

нудное дело.

Если отложенные требований или те, от которых вы решили отказать-

ся, остаются в спецификации требований, читатели спецификации

мо-

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

базо-

вую

версию.

Однако вам вряд ли захочется тратить много времени

впустую, перетаскивая требования из одной спецификации требова-

ний в другую. Один из способов решения этой проблемы — сохранить

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

бут Release Number (Номер версии). Отсрочка требования означает

изменение его запланированного выпуска, поэтому просто обновив

номер версии, вы передвинете требование в другую базовую версию.

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

управлять

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

деле.

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

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

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

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

750 требований в трех связанных спецификациях назначено

каждому

дизайнеру. Один из дизайнеров обнаружил несколько требований, ко-

торые он не считал своими. Он рассчитал, что сэкономил от одного до

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

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

бились,

если бы он выяснил ситуацию с этими требованиями позднее.

Контроль статуса требований

"Как движется работа над той подсистемой, Джеки», — спро-

сил

Дейв.

"Довольно хорошо, Дейв. Готово около

90%».

Дейв был озадачен: "А разве пару недель назад ты не сделала

примерно

90%?»

Джеки ответила: «Я думала, что да, но теперь эти 90%

дейст-

вительно

готовы».

Иногда разработчики ПО слишком оптимистичны, когда сообщают

об

окончании

задачи.

Часто они выдают сами себе кредит, считая

выпол-

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

закончили.

Они могут сделать первоначально определенную работу на 90%, а

за-

тем столкнуться с непредвиденными трудностями. Тенденция пере-

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

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

времени сообщается, что

выполнено

90% объемов. Контроль

статуса

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

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

«выполнения задач» означает только повторы. Например, вы плани-

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

зования, оставив полную реализацию до будущих версий. В этом слу-

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

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

набор

требований должен быть выполнен на

100%

до выпуска продукта.

Ловушка

Существует старая шутка, что на первую половину проекта по разра-

ботке тратится 90% ресурсов, а на остальную половину - оставшиеся 90% ресур-

сов. Чересчур оптимистичная оценка и попустительское отношение к контролю

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

В таблице 18-1 перечислено несколько возможных состояний

тре-

бований. (Альтернативная схема показана в

Caputo,

1998.) Некоторые

специалисты добавляют состояние Designed

(Разработано)

(если эле-

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

требования,

Глава 18. Принципы и приемы управления требованиями к ПО 351

созданы и проверены) и Delivered (Выпущено) (ПО отдано в руки поль-

зователей, как для

бета-тестирования).

Полезно отслеживать требо-

вания, от которых вы

отказались,

и причины этого, потому что отверг-

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

Статус Rejected

(Отклонено)

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

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

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

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

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

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

Определите,

кто

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

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

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

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

ния отражено требование (табл.

18-1).

Таблица 18-1. Рекомендуемые

состояния

требования

Состояние

Определение

Proposed

(Предложено)

Approved (Одобрено)

Implemented (Реализовано)

Verified

(Проверено)

Deleted

(Удалено)

Rejected (Отклонено]

Требование запрошено

авторизированным

источником

Требование проанализировано, его

влияние

на проект про-

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

ленной версии. Ключевые заинтересованные в

проекте

лица согласились с этим требованием, а разработчики ПО

обязались реализовать его

Код, реализующий требование, разработан, написан и про-

тестирован. Требование отслежено до соответствующих

элементов дизайна и кода

Корректное функционирование реализованного требования

подтверждено в соответствующем

продукте.Требование

отслежено до соответствующих вариантов тестирования.

Теперь требование считается завершенным

Утвержденное требование удалено из

базовой

версии.

Опишите причины удаления и назовите того, кто принял

это решение

Требование

предложено,

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

для

реализа-

ции ни в одной будущих версий. Опишите причины отклоне-

ния требования и назовите того, кто принял это решение

352

Часть III.

Управление

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

На рис.

18-2

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

гипотетическом 10-месячном проекте: на графике показано,

сколько

процентов требований к системе в каждом состоянии имеется в

кон

не

каждого месяца. Обратите внимание, что при этом не

устанавливав"

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

сии. Кривые иллюстрируют, как достигается такая цель проекта, как

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

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

стояние Verified (Проверено) (реализуется, как запланировано) или

Deleted (Удаленщ) (удалено из базовой версии).

— Proposed

(Предложено)

- - Approved

(Одобрено)

——

Implemented

(Реализовано)

Verified

(Проверено)

Deleted

(Удалено)

1234567

Месяц

Рис.

18-2.

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

Измерение усилий, необходимых

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

Как и при разработке требований, в ваш план проекта должны быть

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

бованиями, описанные в этой главе. Если вы выясните, сколько усилий

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

их, как надо или слишком много — и изменить рабочие процессы и

бу-

дущие планы соответствующим образом.

Глава 18. Принципы и приемы управления требованиями к ПО

35:;

В организации, где никогда не измерялась ни одна из сторон рабо-

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

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

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

культурой и дисциплиной сотрудников — только так удастся фиксиро-

вать ежедневную работу. На это уходит не так много времени, как мно-

гие боятся, Команда сможет получить ценные идеи, поняв, как на са-

мом деле тратятся усилия на различные задачи проекта (Wiegers,

1996а). Обратите внимание, что рабочие усилия — это не то же самое,

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

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

что ведет к задержкам. Прилагаемые

усилия,

необходимые для выпол-

нения

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

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

за-

дачи увеличится.

Контроль усилий также позволяет выяснить, выполняют ли

разра-

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

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

неуправ-

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

неосторожности

пропущенных

ходе реализации. Считайте усилия для выполнения следующих дейст-

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

I предложение изменения требований и новых требований;

1 оценка предложенных изменений, включая оценку влияния измене-

ния;

1 изменение работы совета по управлению;

В обновление документации требований или базы данных;

I сообщение об изменениях требований заинтересованным группам

и отдельным лицам;

контроль и отчет о состоян ии

требования;

1 сбор информации о трассируемости требований.

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

ченные на

сбор,

анализ и документацию требований не потрачены

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

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

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

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

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

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

раз-

работки.

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

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

к ПО