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

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

Что теперь?

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

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

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

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

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

1 Определите текущее состояние

для

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

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

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

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

проекте.

Попросите нескольких аналитиков нарисовать,

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

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

они должны добавлять определенную ценность проекту.

Глава

18.

Принципы и приемы

управления

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

Изменения случаются

'•Как

продвигается разработка,

Гленн?»

—

спросил

Дейв,

ме-

неджер проекта Chemical Tracking System на совещании, по-

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

"Я не так далеко продвинулся, как рассчитывал, — признался

Гленн. — Сейчас я добавляю новую функцию запроса в катало-

ге для

Шэрон,

и это требует намного больше времени, чем я

предполагал».

Дейв был озадачен. «Я не помню, чтобы мы обсуждали новую

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

управлению изменениями. Шэрон подала этот запрос через

процесс контроля изменений?»

«Нет, она обратилась ко мне напрямую с этим предложением, —

сказал Гленн. — Мне следовало попросить ее оформить его,

как официальный запрос на изменение, но все выглядело

на-

столько просто, что я сказал ей, что поработаю над этим.

Вы-

яснилось, что не все так просто. Каждый

раз,

когда мне кажет-

ся, что закончил, я

понимаю,

что я пропустил изменение, кото-

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

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

Я думал, мне хватит шести часов, однако я уже потратил на это

четыре дня. Вот почему я не закончил другие,

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

ные, задачи. Знаю, что задерживаю следующую сборку. Мне

закончить с этой функцией или заняться тем, над чем я

рабо-

тал

раньше?»

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

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

ожидали. Разработчики иногда не выполняют — или не могут

выпол-

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

нить — реалистичные расчеты затрат и других последствий предло-

женного изменения ПО. И когда

разработчик,

который хочет быть

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

вателем, требования изменяются через «заднюю

дверь»,

а не

утверж-

даются

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

Tsi-

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

проекте, нарушения графика и проблем с качеством, особенно если

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

няя организация.

Организация,

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

своими проектами по разработке ПО, должна убедиться, что:

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

вода в дело;

I соответствующие лица принимают

бизнес-решения,

будучи

хорошо

информированными о запрошенных изменениях;

одобренные изменения доведены до

сведения

всех

участников

проекта;

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

другом.

Изменение ПО само по себе неплохое дело. Виртуально определить

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

про-

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

Эффективная

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

ИЗ'

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

по

ставлен клиентам.

Однако у изменений всегда есть цена. Простая Web-страница

кор

ректируется быстро и легко; новшества же в дизайне интегрированной

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

откло-

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

по-

дачи, оценки и принятия решения. Если заинтересованные в проекте

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

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

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

ше вам следует противиться желанию внести изменения в эту версию,

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

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

менения в проектную документацию требований, Принцип все тот же:

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

продукт. Если вы не будете обновлять спецификацию требований по

мере разработки

продукта,

его

ценность будет снижаться, и команде

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

кой спецификации.

Глава

19.

Изменения случаются 357

Если вам нужно внести изменение, начните с наивысшего уровня

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

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

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

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

требования,

однако никак

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

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

ний к ПО. Некоторые изменения касаются только внутренних компо-

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

взаимодействия.

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

зайна или кода.

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

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

проблемы. Описание функций

продукта,

как оно приведено в специ-

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

код—

это

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

хрупким,

если изменения вносятся без соотношения с архитектурой и структу-

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

существующую функциональность, о чем остальные члены команды не

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

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

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

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

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

Управление незапланированным

ростом объема

Capers Jones

(1994)

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

ставит под удар:

I 80% проектов по разработке систем управления информацией;

1 70% проектов по разработке военных систем ПО;

9. 45% проектов по созданию ПО, выполняемых по контракту.

Незапланированным изменением требований считается

предложе-

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

ут-

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

дольше

продол-

жается работа над проектами, тем

больше

их объем. Требования к сис-

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

увеличиваются

на 1% в

месяц (Jones, 1996b). Темп прироста может составлять до 3,5% в ме-

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

сяцдля

коммерческого ПО, при этом темпы роста других типов проек-

тов

входят

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

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

на

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

одобряется, то

тем,

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

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

завершен

— и дейст-

вительно,

такая возможность

существует,

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

избежны и даже благоприятны. Бизнес-процессы, рыночные возмож-

ности,

конкурирующие продукты, и технологии — все они могут

ме-

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

определить,

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

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

посте

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

графика

или целей качества, гораздо коварнее. Небольшая модификация

здесь, неожидаемое улучшение там, и скоро нет никакой надежды

раз-

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

дают к определенному сроку.

Первый шаг при управлении незапланированным ростом объема —

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

ка<

части бизнес-требований (см. главу 5). Оценивайте каждое

предло-

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

обра

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

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

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

поели

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

(Jones,

1996а).

Составление прототипов — это еще один эффективный прием

управления

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

ростом объема (Jones,

1994).

Прото-

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

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

зователей и необходимых решений. Короткие циклы разработки при

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

изменение

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

быстро

изменяются

(Beck,

2000).

Наиболее эффективный прием для управления незапланированным

ростом

объема—

это умение сказать: «Нет» (Weinberg, 1995). Люди в

принципе не любят

отказывать,

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

по поводу каждого предложенного требования. Такие принципы, как

"Клиент

всегда

прав»

и «Мы сделаем все, чтобы клиент остался дово-

лен»,

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

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

Глава

19.

Изменения случаются 359

не могут произойти просто так. Президент одной компании, специали-

зирующейся на поставке программного

обеспечения,

привык слышать

от менеджера по

разработке

в ответ на предложение новой функции:

«Не

сейчас».

«Не

сейчас»,—

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

стой отказ. В этом слышится обещание включить функцию в следую-

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

специалистами отдела маркетинга, менеджерами продукта и разра-

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

истощению разработчиков и созданию ПО с избыточной функциональ-

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

смысл, поэтому фиксируйте их идеи — возможно, их стоит включить в

последующие версии.

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

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

разработки. Это основа последовательной или водопадной модели

разработки ПО, но на практике так не бывает. На определенном этапе

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

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

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

руете то

обстоятельство,

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

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

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

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

тролируемым способом.

Ловушка «Заморозить» требования для новой системы после выполнения пер-

воначального сбора информации - не умно и не практично. Лучше

опредепите

ба-

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

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

минимизировать их негативное влияние на проект.

Процесс контроля изменений

Как-то, оценивая процесс разработки ПО, я спросил специалистов, ра-

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

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

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

щается к Брюсу или Сэнди, потому что они всегда соглашаются, а мы

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

мне

хорошей.

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

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

к ПО

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

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

ет клиента и имеет коммерческую ценность, при этом контролируются

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

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

вания не были потеряны или упущены. После утверждения базовой

версии набора требований придерживайтесь этого порядка для внесе-

ния всех предлагаемых изменений в нее.

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

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

для модификации. Это механизм суммирования и фильтрации, даю-

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

изменение.

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

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

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

во-

обще. Процесс управления должен быть тщательно

задокументиро-

ван, максимально прост и, что важнее всего, эффективен.

Ловушка Если вы предложите заинтересованным лицам новый процесс контро-

ля изменений - неэффективный, громоздкий или слишком сложный, они постара-

ются найти способ избежать этого - и, возможно, будут правы.

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

тия решений по отчетам об ошибках. Эти же средства могут поддержи-

вать обе задачи. Однако следует помнить: инструмент не

заменяет

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

про-

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

требований

не за-

менит описание процесса, где

объясняются

содержимое и

обработка

запроса на изменение.

Политика контроля изменений

Руководство должно ясно довести до сведения сотрудников

политику,

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

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

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

проводят-

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

поло-

жения политики контроля изменений:

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

цессом. Если запрос на изменение подается каким-то иным спосо-

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

Глава 19. Изменения случаются 361

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

менения,

кроме проверки их осуществимости;

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

изменения.

Совет

по управлению изменениями проекта (change

control board, CCB) решает, какие изменения следует реализовать.

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

лее в этой

главе.);

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

всех заинтересованных в проекте лиц;

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

или

удаляться;

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

менения;

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

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

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

менение необходимо документировать.

Разумеется, мелкие изменения

вряд

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

ственные воздействуют довольно сильно. В принципе, любые из них

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

практике вы можете делегировать принятие определенных детальных

решений, касающихся

требований,

разработчикам, однако ни одно

ре-

шение, влияющее на работу более чем одного человека, не должно

ид-

ти в обход процесса контроля изменений. Однако процесс должен

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

вые изменения в сжатом цикле принятия решений.

Ловушка Разработчики не должны использовать процесс контроля изменений

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

неизбежно - работайте над ним.

Описание процесса контроля изменений

На рис.

19-1

показан шаблон описания процесса контроля изменений

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

Вы можете загрузить его образец с

http://www.processimpact.com/goo-

dies.shtml.

Далее речь пойдет в основном о том, как процесс будет об-

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

дующие четыре компонента во все процедуры и описания процесса:

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

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

до выполнения процесса или процедуры;

различные задачи, задействованные е процессе или процедуре,

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

другие лица, принимающие участие в выполнении задачи;

последовательные

действия

для подтверждения того, что задачи

были выполнены правильно;

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

или

процедура считаются успешно завершенными.

Введение

1.1.

Назначение

1.2.

Границы

1.3.

Определения

2. Роли и

ответственности

3. Состояние запроса на изменение

4. Входной критерий

Задачи

5.1.

Оценка запроса

5.2. Принятие решения

5.3. Внесение изменения

5.4. Уведомление всех

задействованных

лиц

6. Проверка

6.1.

Проверка изменения

6.2, Установка продукта

7. Выходной критерий

8. Отчет о состоянии контроля изменений

Приложение. Элементы данных,

сохраненные для каждого запроса

Рис.

19-1,

Пример шаблона описания процесса контроля изменений

Введение

Во введении описывается назначение процесса и определяются орга-

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

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

определить здесь. Также укажите, существуют ли какие-то

специаль-

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

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

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

нимания остальной информации,

Глава

19.

Изменения случаются

363

2. Роли и ответственности

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

именам,

которые уча-

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

табл. 19-1 приведены некоторые типичные роли; адаптируйте их в со-

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

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

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

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

ся одним человеком.

Таблица

19-1.

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

Роль

Описание и

ответственность

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

по управлению измене-

ниями

Совет по управлению

изменениями

Тот, кто оценивает

изменение

Тот, кто вносит изменение

Возглавляет совет по управлению изменениями; как правило,

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

не приходит к согласию; выбирает тех, кто оценивает и вносит

изменения для каждого запроса на изменение

Группа, принимающее решение утвердить или отклонить каждое

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

изменение для определенного

прооекта

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

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

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

ник, занимающийся всем этим понемногу

Отвечает за внесение изменений в продукт, когда запрос

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

Тот, кто инициирует запрос Некто, подающий новый запрос на изменение

Получатель

зал

роса

Тот, кто проверяет

изменение

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

Человек, определяющий, корректно ли

выполнено

изменение

3. Состояние запроса на изменение

Запрос на изменение проходит через определенные стадии на протя-

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

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

пользуя диаграмму перехода состояний, как показано на рис. 19-2.

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

деленные критерии.

364

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

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

к ПО