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

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

Что

теперь?

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

решения,

обращаетесь к

сторонним разработчикам или

создаете

проект «с

нуля»,

изучите приемы форму-

лирования требований, описанные в главе 3, чтобы выбрать

из

них тот, который

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

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

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

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

новные причины. Если вы воспользуетесь приемами из главы 3 или способами,

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

возникновение

проблем в

следующем проекте подобного типа?

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

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

к следующим этапам

Работа над Chemical Tracking System продвигалась просто за-

мечательно. Но спонсор проекта

Жерар

и сторонник продукта

от персонала, работающего на складе, Роксана, сомневались,

стоит ли тратить много времени на определение требований,

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

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

нинг, посвященный работе над требованиями к ПО. На этом

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

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

целей и нужд пользователей. Кроме

того,

всех участников оз-

накомили с терминологией, касающейся требований, концеп-

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

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

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

По мере развития проекта Жерар получил отличные отзывы от

представителей пользователей о том, насколько хорошо

прошла разработка требований. Он даже организовал ланч

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

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

системы. На ланче Жерар поблагодарил тех, кто занимался

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

коллективную работу. А затем сказал:

Теперь, когда с

требо-

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

появ-

ления готового кода».

«Мы

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

проекта,

—Мы

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

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

дополнениями. С помощью прототипов мы получили четкое

326 Часть II.

Разработка

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

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

харак-

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

Если на этой стадии мы потратим еще немного времени на ди

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

не

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

нальность к системе».

Жерар

расстроился. Все выглядело так, как будто разработчи-

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

к работе. Однако не делал ли он преждевременных выводов?

Опытные менеджеры проекта и разработчики понимают ценность пре-

образования требований к ПО в надежный дизайн и рациональные

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

пред-

ставляет 1 или 100% всего конечного продукта. В этой главе мы рас-

смотрим, как преодолеть

пропасть,

которая отделяет разработку тре-

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

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

показано на рис.

17-1.

^^„„^^

•

Используйте

требования

для

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

s'*'

""""""Ч

^Р

304613

основывайтесь

на

размере

продукта

Планы проекта

• Обновляйте планы при

изменении

требований

Учитывайте приоритеты требований при выполнении

итерации

Попросите

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

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

Учитывайте атрибуты качества при дизайне архитектуры

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

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

Начинайте разработку тестирования на ранних стадиях

Используйте требования

при

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

Попросите пользователей разработать проверочные тесты

Отследите требования до тестов

Рис. 17-1. Влияние требований на планирование проекта,

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

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

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

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

на основе требований. Однако необходимо помнить, что наиболее

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

бизнес-целям,

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

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

Глава

17,

От разработки требований - к следующим этапам 327

В требованиях и планах указана первоначальная оценка затрат на про-

ект,

определенная членами команды. Однако границы проекты могут

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

дай

планы

могут

оказаться невыпол-

нимыми. Кроме

того,

бизнес-потребности, бизнес-правила и ограни-

чения проекта могут

измениться.

Успех проекта

сомнителен,

если вы

не будете обновлять ваши планы в соответствии с изменяющимися

целями и обстоятельствами.

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

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

которыми обычно занималась наша команда, этот этап обычно стоил

от

до

15%

всех затрат (Wiegers,

19Э6а),

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

от объема и сложности проекта. Несмотря на опасения, что работа над

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

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

щие примеры:

изучение 15 проектов в сфере телекоммуникаций и банковской

сферы показало, что в наиболее успешных проектах примерно 28%

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

(Hofmann

Lehner,

2001):

11%—

на сбор информации по требованиям, 10% — на мо-

делирование, а 7% на проверку и утверждение. На разработку тре-

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

необходимой,7%

всех ресурсов и

38,6% времени;

в проектах NASA, в которых затрачивалось более

10%

всех ресурсов

на разработку требований, затраты и отклонения от графика оказа-

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

валось меньше ресурсов (Hooks

иРаггу,

2001);

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

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

и усилий требованиям, чем более медленные команды (табл. 17-1)

(Blackburn,

Scudder

Van

Wassenhove, 1996).

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

начале проекта, как в модели «водопада» или последовательной моде-

ли жизненного цикла. В итеративных моделях определенное время на

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

Цель таких проектов — реализовывать функциональность каждые не-

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

мало. На рис.

17-2

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

период разработки продукта

распределяются

усилия на требования.

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

Таблица

17-1.

Затраты на требования ускоряют разработку

Усилия, затраченные

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

Время,

затраченное

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

Более быстрые проекты 14%

Более медленные проекты 7%

17%

Модель

«водопада»

Итеративная

модель

Последовательная модель

Время

Рис.

17-2.

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

разрабатываемых на основе различных моделей жизненного цикла

Ловушка Старайтесь избегать паралича аналитического процесса. Если в са-

мом

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

требований -

«раз

навсегда»,

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

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

ваний вообще только из-за боязни паралича аналитического процесса.

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

Первый шаг при оценке проекта —

прикинуть

объем продукта ПО.

Эт;з

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

прототипов

или элементов

пользовательского

интерфейса. Хотя не существует

идеального мерила размера ПО, чаще всего используются

следующие:

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

1995);

Глава

17.

От

разработки

требований

к следующим этапам

329

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

точки и характерные точки (Jones, 1996b) или трех-

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

ции и элементы управления

(Whitmire,

1995);

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

тельского интерфейса

{graphical

user interface, GUI);

1 оценка строк кода, необходимого для реализации

специальныхтре-

бований;

1 количество классов объектов или других объектно-ориентирован-

ных метрик

{Whitmire,

1997).

Все эти методы годятся для расчета размера. Выбирайте любой,

учитывая собственный опыт и природу разрабатываемого ПО. Пони-

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

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

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

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

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

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

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

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

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

оценки ПО опубликована на

http://

www.laatuk.

com/tools/effon_estima-

tionjools.html.

Если вы не сравните ваши расчеты с действительными результата-

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

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

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

требуется время. Ваша цель

—вывести

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

уверенностью оценить размер завершенного ПО на основании

требо-

ваний к нему.

Однако даже самые лучшие методики не сработают, если клиенты,

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

ния настолько

велики,

что аналитик и разработчики не успевают их

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

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

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

Определенные крайние сроки поставки — головная боль для менед-

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

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

воры. Менеджер проекта, который может аргументировать расчеты,

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

реговорах гораздо лучше, чем оперирующий предположениями. Если

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

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

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

проекта: они будут определять, стоит ли уменьшить объем,

добавить

ресурсы или согласиться

на

некоторое снижение качества. Такие

ре-

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

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

Есть час?

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

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

леги могли ее использовать. «Есть час?» - спросил меня наш менеджер, передавая

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

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

ше. Я потратил 100 часов только на написание

программы,

которая им была нужна,

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

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

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

нить масштаб и

составить

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

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

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

не-

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

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

неизбежнь,

заложите в график и бюджет резерв для непредвиденных обстоя-

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

(Wiegers,

2002d).

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

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

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

что

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

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

упущена в ходе сбора информации.

Отведите время на выбор соответствующих измерений для тех

ти-

пов проектов, над которыми работает ваша команда. Между размером

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

вре-

менем становления команды существуют сложные нелинейные взаи-

моотношения (Putnam и Myers, 1997). Если вы разберетесь в них, вы

сможете избежать «области

невозможного»,

то есть такой комбинации

факторов, зависящих от размера продукта, графика и

сотрудников

при которой еще не один продукт не был успешно разработан.

Глава 17. От разработки требований - к следующим этапам 331

Ловушка Не позволяйте, чтобы на ваши расчеты влияли желания других. Ваши

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

ком большое

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

в прогнозах

указывает

на необходимость переговоров.

Требования и график

В некоторых проектах применяется график

«справа—

налево»: снача-

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

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

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

функциональность соответствующего уровня. Более реалистично оп-

ределить требования к

ПО

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

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

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

дого-

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

удов-

летворит его в указанные сроки. Как и всегда, расстановка

приорите-

тов требований — ключевой фактор для успеха проекта.

Для сложных систем, в которых ПО является лишь частью конечного

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

работки требований на уровне продукта

(системы)

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

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

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

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

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

Рассмотрите возможность поэтапного планирования и финансиро-

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

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

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

Проекты,

требо-

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

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

пить к созданию качественного ПО задолго до полного выяснения тре-

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

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

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

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

не в том, что они плохие специалисты. К главным ошибкам планирова-

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

ков, а также проектных рисков, необоснованный оптимизм. Кроме то-

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

вание проекта предполагает наличие следующих элементов:

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

оценку

размера

продукта;

информацию о производительности специалистов, основанную на

прошлом опыте;

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

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

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

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

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

Ловушка Не поддавайтесь давлению и не принимайте на себя невыполнимых

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

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

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

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

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

дизайна. В идеале на описание предполагаемых функций системы не

должно влиять представление о дизайне (Jackson, 1995). Надо при-

знать, что во многих проектах

учитываются

ограничения дизайна, на-

лагаемые

разработанными

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

дыдущими продуктами — самое стандартное требование. Именно по-

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

некоторая информация о дизайне. Однако в спецификации не

должны

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

—то

есть ненужные или не-

запланированные ограничения конечного дизайна. Подключите

дизай-

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

удостове-

риться,

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

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

вателей влияют на архитектуру продукта (Bass, Clements и Kazman,

1998).

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

разные

точ

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

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

базируют

ся на следующем посыле: «Если я правильно понимаю требования, то

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

Те-

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

про

тотип), поможет ли это мне лучше разобраться в требованиях?»

Глава 17. От разработки требований - к следующим этапам 333

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

ненты

ПО и оборудования, а также для сложных систем, состоящих ис-

ключительно из ПО. Важный этап анализа требований — распределе-

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

мам и компонентам. Системный инженер, аналитик или архитектор

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

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

оборудованию

(Lettingwell

Widrig, 2000).

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

ких элементах дизайна будет отражено каждое

требование.

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

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

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

возможна

низкая

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

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

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

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

оборудования! Хотя ПО само по себе более гибко, чем

оборудование,

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

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

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

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

рамках заданных ограничений.

Распределение системных функций по подсистемам и компонентам

надо выполнять «сверху вниз» (Hooks и

Farry,

2001).

Представьте DVD-

проигрыватель, в который входит мотор, открывающий и

закрываю-

щий лоток дисковода и вращающий диск, оптическая подсистема для

считывания данных с диска, ПО для формирования изображений, мно-

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

дру-

гое, как показано на рис. 17-3. Подсистемы

взаимодействуют

для

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

скажем,

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

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

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

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

ар-

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

При разработке некоторых проектов дизайн ПО немного

изменяется,

тем не менее на дизайн время никогда не бывает потрачено зря. Разно-

образные разработки ПО удовлетворяют большинству требований к

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

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

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

по существу разрабатываете ПО «на лету». Вы разрабатываете какой-то

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