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

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

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

меньшей стоимости (Karlsson и Ryan, 1997; Jung, 1998). Субъективная

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

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

Другая

альтернатива—

Quality Function Deployment (QFD),

всесто

ронний метод определения относительной ценности для

клиента

предлагаемых функций продукта (Zultner, 1993; Cohen, 1995). Третий

подход, заимствованный из Total Quality Management

(TQM),

позволяем

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

успеха

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

приоритетов

требований. Тем не менее, по-видимому, лишь немногие организации-

разработчики ПО готовы применять QFD или

TQM.

В табл. 14-2 показана крупноформатная модель, которая поможет

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

ис-

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

эту

таблицу в формате Microsoft Excel можно с

http://www.processim-

pact.com/goodies.shtml. В табл. 14-2 перечислено несколько функций

Chemical Tracking System (а каких же

еще?).

Эта схема заимствует

из

QFD концепцию обоснования ценности для пользователя;

учитываете*

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

продукте

так и неудобство, если она отсутствует

(Pardee,

1996). Привлекатель-

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

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

цией. При прочих равных условиях функции с наибольшим

значением

ценность/стоимость должны иметь наивысший приоритет. При этом

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

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

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

требованиям, не имеющим наивысшей ценности. Не нужно включать в

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

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

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

нормам. Если нет возможности назначить этим функциям со временем

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

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

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

те табл.

14-2,

чтобы оценить по шкале относительных приоритетов ос-

тавшиеся

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

участвуют:

Глава 14. Назначение приоритетов требований 275

менеджер

проекта, который ведет процесс, разрешает

конфликты

при необходимости адаптирует данные, поступающие от других

участников;

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

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

дукта;

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

общающие данные о стоимости и риске.

Таблица

14-2.

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

для Chemical Tracking System

Относительный

вес

функция

1. Распечатка

списка данных

по безопас-

ности мате-

риалов

Запросе

ста-

тусе

заказа

поставщика

3. Создание отче-

та о инвентари-

зации склада

химикатов

4. Просмотр ис-

тории исполь-

зования каждо-

го контейнера

с химикатом

5. Поиск хими-

ката по ката-

логам постав-

щиков

ос

о а

1 3

'з

_о

О X

§ 1

сР

5,2

8,4

16,1

9,7

16,8

€

S О

Е о

5 5

е^

2,7

5,4

13,5

8,1

0,5

>ж

О ас

с£

о.

3,0

9,1

6,1

24,2

о,

1,22

1,21

0,89

0,87

0,83

276

Часть

II.

Разработка требований к ПО

Таблица

14-2.

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

для Chemical

Tracking

System

(продолжение)

Относительный

вес

Функция

6. Поддержка

списка опас-

ных химикатов

7. Модификация

невыполнен-

ных заявок

на химикаты

8. Создание отче-

тов об инвента-

ризации от-

дельных ла-

бораторий

Проверка

в базе данных

по обучению

наличия запи-

>х

О X

си о прохожде-

нии обучения

по обращению

с опасными

веществами

10.

Импорт хими-

ческих структур

из инструмен-

тальных

средств для

рисования

структур

Итоги

1 х

сР

9,7

7,1

9,0

6,5

11,6

afi

I 8 §

49 155 100,037

8,1

10,8

24,3

100,0

0,5

>х

Ь'

о.

12,1

6,1

9,1

6,1

21,2

а.

0,68

0,64

0,59

0,47

0,33

100,0

Глава 14. Назначение приоритетов требований

277

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

зуйтесь следующим планом.

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

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

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

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

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

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

личии функции А), в анализ включайте только ведущую функцию.

Эта модель работает лишь для нескольких дюжин функций, далее

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

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

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

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

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

ду, которую каждая функция дает клиенту или бизнесу, по шкале от

1 до 9: 1 балл означает, что никто не находит ее полезной, а 9 — что

она крайне ценная. Эти оценки выгоды отражают связь функций с

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

3. Оцените относительный урон, который потерпит клиент или биз-

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

шкалу от 1 до 9: 1 балл означает, что никто не расстроится, если ее

не окажется; 9 показывает серьезный урон. Требования, имеющие

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

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

привлекательно, но не стоят инвестиций. Оценивая урон, учиты-

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

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

речиленным

ниже.

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

ми эту функцию?

I Будут ли какие-либо юридические или контрактные последствия?

I Не

нарушители

вы какой-либо юридический или промышленный

стандарт?

Не лишит ли это пользователей возможности выполнять

какие--

либо необходимые или ожидаемые действия?

1 Намного ли сложнее добавить эту функцию позже, в качестве мо-

дернизации?

I Возникнут ли проблемы из-за того, что отдел маркетинга обещал

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

клиентов, но команда решила не включать ее?

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

4. В этой таблице подсчитаны итоговые значения для каждой

функ-

ции как сумма баллов ее выгоды и урона. По умолчанию выгода и

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

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

табли-

цы. В примере, взятом для табл.

14-2,

выгода оценивается

дважды,

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

тан процент от общего значения для каждого набора функций,

рав-

ного сумме ценностей каждой функции

(%).

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

реа-

лизации каждой функции, опять-такии по шкале от 1 (легко и быст-

ро) до 9

(трудоемко

и дорого). В таблице подсчитан процент общей

стоимости, составленной из вклада каждой функции.

Разработчи-

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

функции,

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

циальную возможность повторного использования

существующе!

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

6. Подобным же образом, разработчики оценивают относительную

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

функцией, по шкале от 1 до 9. Технический риск — это вероятность

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

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

озна-

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

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

использованием

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

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

следуют из высоких оценок риска. В таблице подсчитан

общий

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

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

оцениваются

одинаково, но вы можете изменить их вес. В табл. 14-2 риск

имеет

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

урон. Если вы не желаете учитывать риск вообще в этой модели,

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

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

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

каж-

дой функции:

приоритет = % ценности

стоимости * вес стоимости) +

риска * вес риска)

8. Отсортируйте список функций по уменьшению подсчитанного при-

оритета. Функции вверху списка характеризуются наиболее благо-

приятным сочетанием ценности, стоимости и риска и поэтому -

Глава 14. Назначение приоритетов требований 279

при равенстве остальных факторов — должны иметь наивысший

приоритет.

А можно еще на кулачках

Одна

компания,

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

приоритетов,

осно-

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

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

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

для

проекта, и команда оказалась в безвыходном положении. Анализ с помощью

табли-

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

ной,

позволив команде

прийти

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

двигаться дальше.

Консультант Johanna Rothman

(2000)

писала:

«И

предлагала эту электронную табли-

цу своим клиентам в качестве инструмента для принятия решений. Хотя те, кто про-

бовал ей

пользоваться,

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

куссия,

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

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

чрезвычайно полезна для опре-

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

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

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

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

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

Точность этого метода ограничена возможностью команды оцени-

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

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

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

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

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

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

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

ная последовательность приоритетов хорошо сочеталась с вашей

постфактум-оценкой

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

бования в вашем калибровочном наборе. Это даст вам некоторую уве-

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

становки приоритетов в ваших проектах.

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

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

считанных значениях приоритетов. Данный

полу

количественны

метод не претенду-

ет на математическую точность. Ищите группы требований с похожими значениями

приоритетов.

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

важность того или иного требования и потенциальный уровень от

его

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

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

заинте-

ресованных в проекте лиц. На странице Multiple

Stakeholders

(Множе-

ство пользователей) загружаемой электронной таблицы скопируйте

колонки Relative Benefit (Относительная выгода) и Relative Penalty (От-

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

участвующего в анализе. Затем назначьте вес для каждого участника,

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

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

щихся проекта. В таблице будет учтен вес каждого участника при под-

счете общего значения ценности.

Эта модель также поможет вам принимать решения о

компромиссах

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

их приоритеты соответствуют приоритетам требований в принятой

ба-

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

реали-

зации.

Старайтесь, чтобы ваш процесс определения приоритетов был на-

сколько возможно простым, но не проще этого. Стремитесь превра-

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

форум, где за-

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

Это

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

симальной бизнес-ценностью.

Глава 14. Назначение приоритетов требований 281

Что дальше?

1 Примените модель определения приоритетов, описанную в этой главе, к 10-15

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

шо подсчитанные этим способом приоритеты совпадают с теми, которые вы оп-

ределили каким-либо другим методом? Насколько хорошо они соответствуют

вашим

субъективным

ощущениям правильной расстановки приоритетов?

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

лью, и

теми,

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

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

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

разные зна-

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

пока она не даст

результаты,

соответствующие

вашим

ожиданиям.

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

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

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

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

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

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

Барри, руководитель по

тестированию,

вел

семинар,

участни-

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

личие проблем. Во встрече принимали участие представители

двух

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

Дже-

реми и аналитик Гриш, которая написала спецификацию тре-

бований к ПО. В требовании 83 было указано: "Система обес-

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

DMV,

посредством отключения неактивных терминалов по

истече-

нии тайм-аута». Джереми представил группе свою интерпре-

тацию этого требования:

«В

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

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

ра-

бочей станции, подключенной к системе

DMV,

если на ней на-

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

времени».

«У

кого-нибудь есть вопросы по этому требованию?» — поин-

тересовался Барри.

Первым высказался

Хью-Ли,

один из сторонников

продукт,!.

«Как система определяет, что терминал не активен? Это

как.

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

скажем,

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

сеанс

пользователя закрывается? Это может раздражать,

например,

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

этих пяти минут».

Триш

добавила: «На самом деле в требовании ничего не гово-

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

означает "безопасность... по истечении

тайм-аута».

Я предпо-

ложила, что это означает окончание сеанса, но, может,

доста-

точно просто ввести пароль»,

283

Джереми был также озадачен. «В этом требовании речь идет о

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

ме

ОМУили

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

подключе-

ны к системе

DMV

в данный момент? О времени ожидания ка-

кой длины мы говорим? Возможно, существует некое руково-

дство по безопасности для таких случаев?»

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

зрения. «Ну

хорошо,

похоже, что в требовании 83 есть не-

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

стности, не определено время ожидания. Гриш, не могла ли

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

ре-

шить этот

вопрос?».

Большинству разработчиков знакомо чувство расстройства, возни-

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

требования. Если они не могут получить необходимую информацию,

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

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

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

вания показали, что в

100

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

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

бований

(Boehm,

1981; Grady, 1999). Другие исследования свидетель-

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

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

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

до

часов

{Kelly,

Sherif

и Hops, 1992). Ясно, что любые усилия, затра-

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

мят реальные время и деньги.

Во многих проектах тестирование — одна из последних стадий про-

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

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

вания системы или их не обнаружит клиент. Если вы начнете

планиро-

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

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

их появления. При этом вы предотвратите дополнительный ущерб, на-

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

На рис. 15-1 показана V-образная модель разработки ПО, когда

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

няются параллельно

(Davis,

1993). Эта модель

указывает,

что приемоч-

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

пользователей,

тестиро-

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