Базовая версия (baseline) — это набор функциональных и нефункциональных требований, которые разработчики обязались реализовать в определенной (выбранной) версии. Определение базовой версии позволяет заинтересованным в проекте лицам выработать общее понимание возможностей и свойств, которые они хотят видеть в данной версии. Принятая базовая версия требований — как правило, версия становится базовой после официальных экспертизы и утверждения — передается для управления конфигурацией. Последующие изменения разрешается вносить в нее только через определенный в проекте процесс управления изменениями. До принятия базовой версии требования все еще изменяются, поэтому не имеет смысла ограничивать модификацию какими-то процедурами. Однако начинайте контролировать версии, уникальным образом идентифицируя разные версии каждого документа требований, сразу после того, как сделаете предварительный набросок этого документа,
С практической точки зрения, положения в базовой версии должны отличаться от предложенных, но не принятых требований. Необходимо, чтобы основная версия спецификации требований к ПО содержала только те требования, которые запланированы для конкретного выпуска. Этот документ должен быть ясно определен как базовый, чтобы отличать его от серии выполненных ранее набросков версий, которые еще не утверждены. Сохранение требования в средстве управления требованиями облегчает идентификацию требований, принадлежащих определенной базовой версии, и управление изменениями в ней. В этой главе описываются некоторые способы управления требованиями в базовой версии.
Процедуры управления требованиями
|
|
Необходимо определить действия, которые, как ожидается, проектная команда будет выполнять для управления требованиями. Задокументируйте эти действия и организуйте тренинг для специалистов, чтобы сотрудники организации могли выполнять их последовательно и эффективно. Обратите внимание на следующее:
· на инструменты, приемы и соглашения для управления версиями
· различных документов требований и отдельных требований;
· на то, как составляется базовая версия требований;
· на статус требований, которые будут использоваться, и лица, которые имеют право изменять их;
· на процедуры контроля за статусом требования;
· на способы, с помощью которых новые требования и изменения существующих требований предлагаются, обрабатываются, обсуждаются и передаются всем заинтересованным лицам;
· на методы анализа влияния предложенного изменения;
· на то, как на планах и обязательствах проекта отразятся изменения требований.
Вы можете включить всю эту информацию в одно описание процесса управления требованиями. Или же разработать отдельные процедуры для контроля за изменениями, анализа влияния и контроля за состоянием. Эти процедуры следует довести до сведения каждого сотрудника организации, поскольку они представляют общие функции, которые должны выполняться каждым проектной командой.
| Дополнительная информация В главе 22 описано несколько полезных образцов документов для управления требованиями. |
Кто-то должен выполнять действия при управлении требованиями поэтому в описаниях процесса также следует определить роли участников, ответственных за выполнение каждой задачи. Проектный аналитик требований, как правило, несет основную ответственность за управление требованиями. Он выбирает механизм сохранения требований (например, средство управления требованиями), определяет атрибуты требований, скоординирует обновление данных о состоянии и трассируемости требований и сгенерирует отчеты об изменении действий.
|
|
| Ловушка Если никто из участников проекта не несет ответственности за выполнение этапов управления требованиями, не следует ожидать их выполнения. |
Контроль версий
«Я наконец доделала функцию запроса по каталогу различных поставщиков, — сообщила Шери на еженедельной встрече, посвященной состоянию проекта Chemical Tracking System. — Вот это была работа!»
«О, клиент отказался от этой функции две недели назад, — подал реплику менеджер проекта Дейв. — Ты разве не получила новую версию спецификации?»
Шери была озадачена. «Как это понимать, отказался? Эти требования черным по белому напечатаны вверху страницы в самой последней версии моей спецификации».
«Мм, их нет в моей копии. У меня версия 1.5 спецификации. А у тебя?»
«У меня тоже 1.5, — с отвращением сказала Шери. — Эти документы должны быть идентичны, но очевидно, это не так. И что, эта функция все еще включена в базовую версию или я потратила впустую 40 часов моей жизни?»
Если вы когда-либо слышали подобный разговор, вы знаете, как расстраиваются люди, когда тратят впустую время, работая над устаревшими или непоследовательными требованиями. Контроль версий — это важный аспект управления спецификациями требований и другими проектными документами. Каждой версии следует присвоить уникальный идентификатор. У каждого члена команды должен быть доступ к текущей версии требований, а изменения необходимо ясно документировать и передавать всем заинтересованным сторонам. Чтобы минимизировать путаницу, конфликты и непонимание, назначьте право обновления требований строго определенным лицам и убедитесь, что идентификатор версии изменяется при каждом изменении требования.
|
|
| Это не ошибка, а функция! Разработчики-контрактники как-то получили массу отчетов об ошибках от людей, тестировавших последнюю версию систему, которую они только что поставили клиенту. Разработчики были в недоумении — система успешно прошла все их собственные проверки. После обстоятельного изучения проблемы, выяснилось, что клиенты тестировали новое ПО, сверяясь с устаревшей спецификацией требований. То, что тестеры в отчетах называли ошибками, на самом деле оказалось функциями. (В обычной ситуации это просто шутка, из тех, что любят программисты.) Масса усилий была потрачена впустую, поскольку тестеры неправильно представляли себе поведение системы. Им понадобилось много времени, чтобы переписать тесты в соответствии с последней версией спецификации и повторно протестировать продукт, а все из-за контроля версий. |
Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Возможно, следует добавлять номер версии к названию каждого отдельного требования, который можно последовательно увеличивать при модификации требований, например Print.ConfirmCopies-1.
Простейший механизм управления версиями — именовать вручную каждую версию спецификации требований к ПО согласно соглашению. Попытка различать версии документов по дате изменения или дате печати часто приводит к ошибкам и неразберихе; я не рекомендую их использование. Несколько команд, в которых я работал, успешно применяли такое соглашение: первая версия любого нового документа называется «Версия 1.0, набросок 1». Следующий черновик называется «Версия 1.0, набросок 2». Автор последовательно увеличивает номер наброска при каждом изменении и так до тех пор, пока документ не будет утверждена базовая версия документа. Тогда название меняется на «Версия 1.0, утвержденная». Следующие версии называются «Версия 1.1 набросок 1» при небольшом изменении или «Версия 2.0, набросок 1» при значительном изменении. (Разумеется, термины «небольшой» и «значительный» субъективны или, по крайней мере, зависят от контекста.) При применении этой схемы ясно различаются наброски и версии базового документа, однако необходимо соблюдать строгий порядок в ведении документации.
Если вы сохраняете требования в текстовом редакторе, вы можете отследить коррективы с помощью режима изменений текста. Эта функция выделяет внесенную правку, зачеркивая удаленные фрагменты, подчеркивая добавленные и помечая вертикальными линиями на полях положение каждого изменения. Так как откорректированный документ трудно читать, в текстовом редакторе предусмотрена возможность просмотреть и распечатать документ с пометками или его окончательную версию с принятой правкой. После того как вы составите базовую версию документа с такими пометками, сначала создайте архив версии с пометками, затем примите все коррективы, а затем сохраните очищенную версию как новую базовую версию для следующего раунда изменений.
Более сложный метод предполагает сохранение спецификации требований в таком средстве контроля версий, как тот, что применяется для контроля исходного кода с помощью системы контроля версий (check-in и check-out). Для этой цели разработана масса коммерческих средств управления конфигурацией. Я знаю об одном проекте, когда несколько сотен написанных в Microsoft Word вариантов использования продукта сохраняется в таком средстве контроля версий. Члены команды имеют доступ ко всем предыдущим версиям каждого варианта использования, для которых фиксируется история изменений. Аналитику требований этого проекта и его заместителю, отвечающему за архивирование, предоставлен доступ на чтение и запись; остальным членам команды — доступ только на чтение.
Наиболее надежный метод контроля версий заключается в хранении требований в базе данных коммерческого средства управления требованиями, как описано в главе 21. Эти средства отслеживают полную историю изменений требований, что особенно важно, если нужно вернуться к более ранней версии требования. Такое средство позволяет вносить комментарии, где можно разумно обосновать решение о добавлении, изменении или удалении требования; эти комментарии могут оказаться полезными при необходимости обсуждения требования в будущем.
Атрибуты требований
Представьте себе каждое требование в виде объекта, который обладает свойствами, отличающими его от других требований. В дополнение к тестовому описанию, каждое функциональное требование должно иметь несколько поддерживающих его фрагментов информации или атрибутов (attributes), связанных с ним. Эти атрибуты представляют содержимое и подноготную каждого требования, они располагаются за описанием предполагаемой функциональности. Вы можете сохранить атрибуты в таблице, базе данных или, что наиболее эффективно, в средстве управления требованиями. Последние предоставляют несколько сгенерированных системой атрибутов, а также предоставляют возможность определить другие атрибуты. Эти средства позволяют фильтровать, сортировать выбранные подмножества требований на основании значений их атрибутов и запрашивать базу данных для их просмотра. Например, вы можете вызвать список всех высокоприоритетных требований, которые Шерп должна реализовать в версии 2.3 и которые имеют статус Approved (Одобрено).
Большой набор атрибутов особенно важен для громадных и сложных проектов. Возможно, вам следует указать для каждого требования такие атрибуты, как:
· дата создания требования;
· номер его текущей версии;
· автор требования;
· лицо, ответственное за удовлетворение требования;
· ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);
· состояние требования;
· происхождение или источник требования;
· логическое обоснование требования;
· подсистема (или подсистемы), для которых предназначено требование;
· номер версии продукта, для которого предназначено требование;
· используемый метод проверки или критерий тестирования приемлемости;
· приоритет реализации;
· стабильность (показатель того, какова вероятность изменения требования в будущем; нестабильность требований может показывать плохо определенные или изменчивые бизнес-процессы или бизнес-правила).
| Для чего же нужно это требование? Менеджер продукта в компании, выпускающей электронные измерительные приборы, хотел просто записать включенные требования, потому что продукт конкурентов обладал теми же функциями. Такие функции хорошо отмечать с помощью атрибута Rationale (Логическое обоснование), позволяющего указать, почему конкретное требование включено в продукт. |
Выберите наименьший набор атрибутов, с помощью которого вам удастся эффективно управлять проектом, Например, вряд ли вам одновременно потребуются и имя того, кто отвечает за требование, и название подсистемы, в которой расположено требование. Если какая-либо информация об атрибуте хранится в другом месте, например в общей системе контроля разработки, не следует копировать его в базе данных требований.
| Ловушка Множество атрибутов требований могут настолько озадачить разработчиков. что они просто не смогут предоставить все значения для всех атрибутов и эффективно использовать информацию об атрибутах. Начните с трех или четырех ключевых атрибутов. Добавьте другие атрибуты, когда вы будете знать, каким образом они улучшат ваш проект. |
Основные версии требований динамичны. Набор требований, запланированный для определенной версии, будет изменяться по мере добавления новых положений и удаления или отсрочки до более поздних версий существующих требований. Разработчики могут жонглировать» отдельными документами требованиями для текущего проекта и будущих версий. Управление этими изменяющимися базовыми версиями и спецификацией требований на их основе — нудное дело. Если отложенные требований или те, от которых вы решили отказаться, остаются в спецификации требований, читатели спецификации могут запутаться в том, какие требования включены в конкретную базовую версию. Однако вам вряд ли захочется тратить много времени впустую, перетаскивая требования из одной спецификации требований в другую. Один из способов решения этой проблемы — сохранить требования в средстве управления требованиями и определить атрибут Release Number (Номер версии). Отсрочка требования означает изменение его запланированного выпуска, поэтому просто обновив номер версии, вы передвинете требование в другую базовую версию. Теми требованиями, от которых вы решили отказаться, лучше всего управлять с помощью атрибута статуса, как описано в следующем разделе.
На определение и обновление этих атрибутов требуется часть затрат, отведенных на управление требованиями, однако эти инвестиции в значительной степени окупаемы. В одной компании периодически генерировался отчет о требованиях, в котором показывалось, какое из 750 требований в трех связанных спецификациях назначено каждому проектировщику. Один из проектировщиков обнаружил несколько требований, которые он не считал своими. Он рассчитал, что сэкономил от одного до двух месяцев, отведенных на переделку проекта, которые бы понадобились, если бы он выяснил ситуацию с этими требованиями позднее.