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

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

вание

системы — на функциональных требованиях, а тестирование це-

лостности — на архитектуре системы.

Пользовательские требования;

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

приемочных

испытаний

Функциональные

требования;

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

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

Архитектура;

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

-V\—

•• •

•у-r

Проверка

проверки целостности

\ \

целостности

Дизайн; планирование

^••••-j/f-

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

элементов

тестирования элементов

Написание

кода

Рис.

15-1.

V-образная модель разработки ПО подразумевает планирование и разработку

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

на ранней стадии проекта

Планируйте мероприятия по тестированию и начинайте

разработку

предварительных вариантов тестирования для соответствующего эта-

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

про-

водить никаких тестов, так как никакого ПО еще нет. Однако концепту-

альные (то есть, не зависящие от реализации) варианты тестировании,

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

неясно-

сти и пропуски данных в спецификации требований к ПО и проанали-

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

санию кода.

Утверждение требований является четвертым этапом — наряду со

сбором

информации,

анализом и созданием спецификации — разра-

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

(АЬгапи

Moore,

2001)*.

Утверждение

требований

по-

зволяет удостовериться в том, что:

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

"проверка»

(Thayer

Dori-

man,

1997).

При

проверке определяется, соответствует

ли

результат разработки

на

данном

эт,-\-

пе требованиям к нему (делается ли все правильно). При

утверждении

оценивается,

действи-

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

(делается

ли все в нужном

направлении}.

В этой книге я использую терминологию «Software Engineering Body

Knowledge»

(Abran

Moore,

2001)

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

Глава

15.

Утверждение требований 285

1 в спецификации требований к ПО должным образом описаны пред-

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

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

I требования к ПО точно отражают системные требования, бизнес-

правила и др.;

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

i все требования согласованы друг с другом;

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

сборки ПО.

Проверка подтверждает, что в документе представлены желаемые

характеристики отличных требований

(полные,

корректные, осущест-

вимые, необходимые, приоритетные, ясные и поддающиеся проверке)

и отличных спецификаций к требованиям (полные, согласованные, мо-

дифицируемые и поддающиеся отслеживанию). Разумеется, вы може-

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

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

Утверждение—

это не один отдельный этап процесса, выполняе-

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

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

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

ры сбора информации, ее анализа и документирования. Другие меро-

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

к ПО, обеспечивают достижение того уровня качества, которое пред-

шествует финальной версии спецификации. Включите в план проекта

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

Участники проекта иногда с неохотой тратят время на проверку и

тестирование спецификации требований к ПО. Интуитивно кажется,

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

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

шении вы можете смело ожидать нулевых результатов от всех

усилий,

затраченных на утверждение. В действительности же эти усилия могут

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

ний и ускорения интеграции и тестирования системы (Blackburn, Scud-

dei

VanWassenhove,

1996). Capers Jones (1994) отмечает, что каждый

доллар,

который вы истратили на предотвращение появления дефек-

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

долларов. Чем

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

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

ние и клиентскую поддержку продукта. Инвестируя в качество продук-

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

286 Часть II. Разработка требований к ПО

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

личные приемы (Wallace и

Ippolito,

1997).

Один из таких приемов заклю-

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

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

ние. Suzanne и James Robertson используют термин

критерий

годности

(fit criteria)

для

подобных приемов (Robertson и Robertson, 1999).

этой

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

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

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

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

Просмотр требований

Всякое исследование продукта ПО на предмет выявления проблем

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

кой (peer review). Просмотр задокументированных требований — это

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

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

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

Различные типы экспертных оценок называются по-разному (Wieg-

ers, 2002a). Неофициальные просмотры полезны при знакомстве лю-

дей с продуктом и сборе отзывов о нем (формирование обратной свя-

зи). Однако они несистематические, неполные и несогласованные.

Есть несколько видов неофициальных просмотров требований:

1 проверка «за

столом»,

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

вать ваш продукт;

коллективная

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

дпя

параллельной проверки продукта;

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

создаваемый

продукт и

просит его прокомментировать.

В отличие от нарочито естественных неформальных просмотров,

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

регламентирован-

ный процесс. По его завершении формируется отчет, в котором указа-

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

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

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

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

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

его создатели

(Freedman

nWeinberg,

1990).

Глава

15.

Утверждение требований 287

Наиболее хорошо себя зарекомендовавшая себя форма официаль-

ной оценки называется

экспертизой

(Gilb

и Graham, 1993; Radice,

2002). Возможно, инспектирование документации требований — наи-

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

сколько компаний сэкономили ни много ни мало — целых

часов тру-

да на каждый

час,

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

требований и других готовых к поставке продуктов (Grady и Van Slack,

1994). Инвестиции в проверки вернутся 1000%

выгоды,

если вы, ко-

нечно, не отнесетесь к ним небрежно.

Если вы серьезно решили совершенствовать качество вашего ПО,

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

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

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

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

соглашаются,

что каждая минута была по-

трачена не

зря.

Если у вас не хватает времени на проверку каждой де-

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

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

смотра. Начинайте экспертизу спецификации требований к ПО, когда

требования разработаны еще примерно на 10%. Выявление значи-

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

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

щения — а не только выявления — ошибок,

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

Б Chemical Tracking System представители пользователей

проводили

неофициаль-

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

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

ошибок. После

завершения

сбора информации, один аналитик свел всю информа-

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

ПО (50 страниц плюс несколько приложений). Затем два аналитика, один разработ-

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

тестировщик

проверили

этот документ за три двухчасовых совещания, проведенных в течение недели. Они

обнаружили 233 дополнительные ошибки, в том числе несколько серьезных дефек-

тов. Все проверяющие согласились, что время, потраченное на «прочесывание»

спецификации (по одному требованию за раз) сэкономило несчетное количество

ча-

сов в дальнейшем.

Проведение экспертизы

Экспертиза была разработана Майклом

Фэганом

(Michael

Pagan)

из

IBM в середине 70-х гг.

(Pagan,

1976),

а другие дополнили и модифи-

288 Часть II. Разработка требований к ПО

цировали его методы

(Gilb

и Graham, 1993). Экспертиза была признана

лучшим приемом в области разработки ПО (Brown, 1996). Этот метод

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

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

планов проекта.

Экспертиза — это четко определенный многоэтапный процесс. В

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

специалистов,

которые тщательно проверяют продукт на наличие дефектов и изучают

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

качества

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

деба-

ты, действительно ли метод Фэгана можно считать лучшей

формой

проверки (Glass,

1999),

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

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

продукт,:!.

Множество полезных советов по проведению экспертной оценки и

экс-

пертизы опубликовано на

http://www.processimpact.com/goodies.shtml,

том числе описание процесса экспертной оценки, контрольные списки

дефектов и формы экспертизы.

Участники

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

на

продукт (Wiegers,

2002a).

Автор продукта и, возможно, коллеги автора. Это может

бьгь

аналитик, составивший документацию требований.

I Автор любого предыдущего продукта или спецификации

для

элемента,

который следует проверять. В этой роли может вы-

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

подтвердить, что

в/спецификации

требований к ПО система описа-

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

высо-

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

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

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

Люди,

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

ряемом элементе. Для экспертизы спецификации требований к

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

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

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

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

тести-

ровщик,

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

технически невыполнимы.

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

проверяемым элементом. Они выявят проблемы с требованиями

Глава

15.

Утверждение требований 289

к внешнему интерфейсу. Они также могут выявить требования, изме-

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

мы (волновой

эффект}.

Постарайтесь ограничить команду шестью членами или меньше.

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

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

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

тать ошибкой. При этом снижается темп проверки и растет стоимость

обнаружения каждого дефекта.

Роли экспертов

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

можности улучшения. Отдельные участники при этом играют различ-

ные

роли.

Автор. Автор создает или поддерживает проверяемый продукт.

В роли автора спецификации требований к ПО, как правило, выступает

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

цификацию. В ходе неофициальных проверок, таких, как критический

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

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

себя обязанности других участников — координатора, читателя или

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

вательно,

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

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

ответить—

но не всту-

пать в дебаты — на их вопросы и поразмыслить. Зачастую автору уда-

ется обнаружить ошибки,

незамеченные

другими участниками.

Координатор. Координатор, или руководитель проверки, планирует

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

низует совещания. Координатор распределяет проверяемый материал

между участниками за несколько дней до совещания. Он отвечает за

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

ника и управление

дискуссией,

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

явление дефектов, а не на решение проблем. Кроме того, в его обязан-

ности входит информировать менеджеров или того, кто занимается

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

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

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

ли рассмотрены должным образом.

Читатель. Один из проверяющих выступает в роли читателя. На сове-

щании он перефразирует положения спецификации — по одному тре-

бованию

за раз. Затем другие участники указывают на потенциальные

290 Часть II. Разработка требований к ПО

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

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

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

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

важно,

чтобы роль читателя выполнял не автор.

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

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

возникающих

вопросов и дефектов, выявлен-

ных

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

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

инспектирования

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

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

ка-

ждой проблемы.

Входные критерии

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

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

ных критериев (entry criteria) четко обрисовывает авторам то, как следу-

ет подготовиться к инспектированию. Они также удерживают команду от

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

экспер-

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

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

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

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

документ должен соответствовать шаблону;

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

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

1 для экспертизы подготовлены все необходимые

проверяющем

лицам предшествующие документы или документы, на которые

имеются ссылки;

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

документе,

чтобы облегчить

ссылки на определенные

элементы

в течении совещания;

I все нерешенные

вопрсы

помечаются значком

«TBD»

(to be deter-

mined — необходимо определить);

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

10-минутной

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

Этапы экспертизы

Экспертиза—

это многоэтапный процесс, как показано на рис. 15-2.

Цель каждого этапа кратко описана далее в этом разделе.

Глава

15.

Утверждение требований

Первом

чальны

продук

Совеи

—

— —

ГРГ,Ф~

#ние

Ппанировани

Переработка

Получение

продут I

щлежащего/

качества

{г

Рис.

15-2.

Экспертиза - это многоэтапный процесс.

Пунктирные линии указывают на то, что определенные этапы экспертизы

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

Планирование. Экспертизу совместно планируют автор и координа-

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

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

совещаний, необходимых для охвата всего материала. Количество об-

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

(Gilb

и Graham,

1993). Как видно на рис. 15-3, чем медленнее изучается спецификация

требований к ПО, тем больше дефектов удается выявить (весьма рас-

пространено альтернативное толкование этой связки: «Темпы провер-

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

ошибок»).

Поскольку ни

одна

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

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

мание риск пропуска важных дефектов. Чаще всего —

от

двух

до четы-

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

ся максимальный эффект ниже примерно в два раза (Gilb и Graham,

1993).

При выборе темпа работы учитывайте следующие факторы:

i дату предыдущей экспертизы;

i объем текста на каждой странице;

сложность спецификации;

I риск не заметить ошибку;

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

риал;

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

292

Часть II. Разработка требований к ПО

Много

Несколько

Мало.

Мало Несколько Много

Темп проверки (страниц в час)

Рис.

15-3.

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

Обзорная встреча. Во время обзорной встречи автор описывает

ис-

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

предпо-

ложения, которые он сделал, и его личные цели. Если все проверяю-

щие хорошо знакомы с проверяемым материалом, вы можете

пропус-

тить эту стадию.

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

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

этого они используют контрольные списки типичных дефектов (они

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

главе)

и другие приемы анализа (Wiegers

2002а). До 75% дефектов, обнаруживаемых при экспертизе, выявля-

ются на этапе подготовки (Humphrey,

1989),

поэтому этот этап пропус-

кать

нельзя,

Дополнительная информация Приемы по выявлению

недостающих

требова-

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

экспертизе.

Ловушка Не следует начинать совещание, если участники еще не изучили про-

дукт самостоятельно. Неэффективные совещания могут породить мнение, что экс-

пертиза не что иное, как пустая трата

времени.

Глава 15. Утверждение требований

293

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

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

спецификации необходимо исправить. Возможно, стоит обратиться к:

разработчикам, проверяющим спецификацию требований к ПО, с;

просьбой оценить ясность

(понятность)

требований по 5-балльной

шкале (Pfleeger,

2001).

Оценка

«1»

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

ни малейшего

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

о содержании требования, а «5» — что

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

Совещание. На совещании читатель знакомит членов команды с каж-

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

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

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

вится руководством к действию. Цель совещания — выявить в доку-

менте как можно больше ошибок. Совещание не должно длиться более

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

тивной. Если же вам нужно больше

времени,

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

еще одно совещание.

В заключение совещания команда принимает решение: следует ли

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

указать

на необходимость значительной переработки. Решение «необ-

ходимы значительные изменения" свидетельствует о наличии серьез-

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

Возможно,

стоит

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

как приступать к следующему этапу работы над спецификацией

(Kerth,

2001).

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

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

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

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

шений проблем. Это все, конечно, полезно, однако эти действия от-

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

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

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

слишком трудоемки

(Votta,

1993). Я же считаю, что на них можно вы-

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

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

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

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

сборки продукта.

Переработка. Практически на каждом этапе работы, связанным с

контролем качеством, выявляются определенные дефекты. После со-

294 Часть II. Разработка требований к ПО