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

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

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

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

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

процессы. Многие приемы, кажущиеся неплохими в теории, оказыва-

ются менее эффективными на практике. Поэтому

предусмотрите

пробный проект (pilot) для большинства новых процедур или шаблонов

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

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

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

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

бенности:

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

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

оценку. Это могут быть как сторонники, так и скептики, но они не

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

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

критериев, по которым команда будет оценивать пробный

проект

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

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

выполняется;

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

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

испытание

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

кликов и сторонников;

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

проектов, что бы они

почувствовали,

если бы им пришлось вернуть-

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

Даже мотивированные и восприимчивые команды весьма ограни-

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

от них с первого раза. Напишите план внедрения, в котором

укажите,

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

ботающей над проектом, обучать их и помогать им. Также, продумай-

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

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

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

Оцените результаты

Последний шаг цикла совершенствования процесса -- это оценка

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

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

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

проекты

Глава

22.

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

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

и как эффективно они разрешили неопределенности в отношении но-

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

лотных проектах?

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

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

новых процессов или шаблонов? Смогли ли участники понять и эффек-

тивно применить новые процессы?

Собираетесь

ли вы менять что-ли-

бо при проведении следующего внедрения?

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

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

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

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

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

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

время ценность нового шаблона спецификации требований к ПО ста-

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

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

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

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

первоначальное

состояние улучшенное состояние в будущем

начало

процесса

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

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

здесь не

поддавайтесь

искушению все бросить!

Рис. 22-5. Кривая обучения - неизбежная составляющая

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

Смиритесь с необходимостью учета кривой обучения (learning

curve): производительность падает, пока люди приспосабливаются к

новым способам работы, как показано на рис. 22-5. Кратковременное

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

ния»

—

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

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

вносит в совершенствование процессов. Если люди не понимают это-

го,

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

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

ну-

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

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

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

бизнесе

при ис-

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

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

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

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

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

ана-

лиза, спецификации, проверки и управления. Для облегчения

выполне-

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

образцов

документов (process assets) (Wiegers, 1998с). Любой процесс

опреде-

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

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

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

как^е

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

Набор

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

торые описаны в табл.

22-1.

Таблица

22-1.

Образцы документов

для

процесса

Тип Описание

Список Перечень действий, продуктов или других элементов, которые

следует

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

заня-

тым людям не упускать из виду важных деталей

Образец Пример рабочего продукта конкретного типа. Накапливайте хорошие

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

План Схематичное описание цели и всего необходимого для ее достижения

Политика Руководящий принцип, задающий ожидания относительно

поведения,

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

рять политики

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

Таблица

22-1.

Образцы документов

для

процесса (продолжение)

Гин

Описание

Процедура Пошаговое описание

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

задач, ведущих к выполне-

нию действия.

Опишите,

какие задачи

следуег

выполнить, и определите

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

чению. Основные документы могут содержать учебную информацию и

подсказки для процесса или процедуры

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

процесса с какой-либо целью. Описание

процесса

может включать цель процес-

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

ходные данные, связанные с

процессом

артефакты и способы настрой-

ки процесса для

различных

ситуаций

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

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

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

структурированный шаблон

предла!

ает много

возможностей

дпя

выяв-

ления и организации информации. Указания, которые содержит шаб-

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

использовать

его

эффективно

Образцы

документов

для

разработки

требований

Образцы

документов

для управления

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

Процесс

разработки

требований

Процедура размещения требований

Процедура назначения

приоритетов

требованиям

Шаблон документа об образе и границах проекта

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

Шаблон спецификации требований к ПО

Перечень дефектов спецификации требований

к ПО и вариантов использования

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

Процесс

управления

изменениями

Процедура проверки

статуса

требований

Процедура

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

требований

Устав совета по управлению изменениями

Список и шаблон

анализа

последствий

изменений

требованиях

Рис. 22-6. Основные образцы документов для разработки требований и управлению ими

На рис. 22-6 определены некоторые ценные образцы дою/ментов

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

нию ПО не

говорит,

что вам нужны все эти элементы, но они помогут

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

на

рис. 22-6,

не должны быть длиннее, чем это необходимо, чтобы позволить чле-

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

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

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

430

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

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

из

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

22-6,

доступн

по адресу http://www.processimp3ct.com/goodies.

shtml.

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

ных на рис.

22-6,

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

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

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

эффективное применение.

Образцы документов для разработки требований

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

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

стороннике'!

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

вы-

явлению требований (подходящие методики для выявления

данных,

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

дли

этого).

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

касаю-

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

ожидается,

будут

создань!

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

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

веркитребований.

Процедура размещения требований. Размещение требований

дл*

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

{с

учетом

лю-

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

аппаратные,

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

продух

тов, содержащих много программных подсистем (Nelsen,

1990).

Раз

мещение

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

системной::

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

осущест-

влять эти размещения, чтобы гарантировать, что функциональность

на-

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

тре-

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

требований

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

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

Процедура назначения приоритетов требований. Чтобы

разумнс

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

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

возможно-

стей системы имеют наименьший приоритет. В главе 14 описано таб-

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

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

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

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

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

Шаблон документа об

образе

и границах проекта. Это

сжатое,

вы-

сокоуровневое описание бизнес-требований к новому продукту. Оно

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

изменениях в них. В главе 5 показан шаблон для этого документа.

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

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

пользователям

необходимо выполнять с

помощью программы. Определение варианта использования состоит

из краткого описания

задачи,

альтернативных

режимов и известных

исключений, с которыми придется

столкнуться,

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

ин-

формации о задаче. В главе 8 предлагается шаблон вариантов исполь-

зования.

Шаблон спецификации требований к ПО. Представляет собой

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

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

применения более чем одного шаблона,

чтобы

учесть различные типы

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

вашей

организацией. Это

помо-

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

«безразмерного» шаблона или процедуры, плохо подходящих для ва-

шего проекта. В главе

описан пример шаблона спецификации тре-

бований к ПО.

Перечень дефектов спецификации требований к ПО и вариантов

использования. Официальная

экспертиза

документов, содержащих

требования, — это мощное средство улучшения качества ПО. В списке

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

типичных ошибок. Используйте список

мри

подготовке к проверке,

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

оказываются проблемными. В главе

содержатся примеры списков

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

вания.

Образцы документов для

управления

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

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

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

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

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

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

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

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

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

управления

требованиями вы можете найти в приложении J

"СММ

Im-

plementation Guide» (Caputo, 1998).

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

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

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

конечными, бесконтрольными изменениями требований. Процесс

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

передачи,

оценки и разрешения нового требования или его модификации.

Инст-

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

из-

менениями, но помните, что инструмент — не замена процессу. В

главе

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

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

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

нему.

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

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

большого

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

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

ранных требований в любое время. Больше об учете статуса требова-

ний вы можете прочитать в главе 18.

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

изменениями (change control board, CCB) входят наиболее заинтере-

сованные в проекте

лица,

которые решают, какие изменения в требо-

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

внести каждое предложенное изменение. Как вы знаете из главы 19,

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

ции и рабочие процедуры совета.

Список и шаблон анализа последствий изменений в требовани-

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

требованиях—

ключевой шаг в определении того, принимать ли его.

Анализ последствий помогает совету по управлению изменениями

принимать информированные решения. Как показано в главе 19, спи-

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

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

нения в требованиях. Рабочая таблица предлагает простой способ

оценки трудовых затрат для каждого задания. Пример шаблона для

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

19,

Процедура трассируемости требований. Матрица трассируемо-

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

конструктивных элементов и модулей

кода,

связанных с каждым тре-

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

ную реализацию. Матрица трассируемости должна также определять

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

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

функцио-

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

Глава 22. Совершенствование

процессов

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

данные по

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

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

хранятся.

Глава 20 посвящена трассируемости требований.

Дорожная карта совершенствования

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

Бессистемные подходы к совершенствованию процессов редко при-

водят к обоснованному успеху. Вместо

того

чтобы просто бросаться в

бой, разработайте дорожную карту

(road

map) реализации улучшен-

ных приемов работы с требованиями в вашей организации. Эта карта

должна стать частью вашего стратегического плана совершенствова-

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

цессов работы с

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

описанных в этой главе, у вас уже есть

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

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

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

улучшению,

которая дает

наибольшую

пользу при наименьших затратах.

обучить команду

конструированию

требований

обучить

команщ

проверке

ПО

принять процедуру I

s~-*

установки

приори-

ВЗ

тетов

требований

принять приемы

шаблон,

основанные

на вариантах

использования

принять

стандартный

шаблон спецификации

требований к

ПО

собрать совет

по

управлении:

изменениями

принять

процедуру

анализа

послед-

ствий изменений

юнг

солировать

статус

требований

Повышение

удовлетворен- 1

носги

клиентов

"—-,-1:1плр—:...л~~-

Улучшение

В5

И управления

проектом

Рис. 22-7. Пример дорожной карты совершенствования процессов работы

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

Поскольку все ситуации разные,

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

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

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

ний и здравого смысла. На рис. 22-7 изображена дорожная карта со-

вершенствования работы с требованиями одной организации.

Желае-

434

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

мые

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

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

прямоугольниках. Кружками отмечены промежуточные вехи (цели)

вдоль путей достижения бизнес-целей (В1 означает Веха

7.)

Реализуй-

те каждый набор

действий

по совершенствованию слева

направо

Создав дорожную карту, назначьте ответственного за каждую веху,

ко-

торый впоследствии составит

план

действий по достижению этой

це

ли. Затем превратите эти планы в действия!

Что теперь?

I Выполните задание приложения А. Определите три улучшенных возможности

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

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

ний, перечисленных на рис. 22-6, сейчас не используются в вашей

организации,

но оказались бы полезными.

На основе двух предыдущих заданий разработайте дорожную карту

совершенст-

вования процессов работы с требованиями по образцу рис. 22-7. Убедите не-

скольких сотрудников вашей организации стать ответственными за каждую веху

(цель).

Попросите их на основе шаблона на рис. 22-4 написать план действий

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

ствий, указанных в планах.

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

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

и управление риском

Дэйв,

менеджер проекта Chemical Tracking System для

Contoso

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

та Хелен и ведущим

тестировщиком

Рамешем.

Все выразили

радость по поводу новой

совместной

работы,

но вспомнили и

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

названием

Pharm-Simulator.

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

могут

интерфейс

Pharm-Simulator

только

после бета-тестирования?

спросила Хелен. — У нас ушло четыре недели на то, чтобы пе-

ределать и заново протестировать его. Не хотела бы я еще раз

пережить тот ужасный март».

"Это было невесело,

—согласился

Дэйв. — Также раздражает,

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

нужно много функций,

подо

сих пор с ними никто не работает.

На программирование функции моделирования

взаимодейст-

вия

препаратов

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

чем мы ожидали, и в конце

концоп

мы все равно ее исключили.

Какая трата времени!»

"Работа над

Pharm-Simulator

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

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

ния, — вспомнил

Рамеш.

— В половине случаев

тестировщи-

кам приходилось спрашивать у программиста, как должна ра-

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

про-

тестировать. Затем оказывалось, что некоторые функции,

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

того,

что желали

пользователи»

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