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

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

Ниже перечислены четыре точки зрения (им посвящена Глава 15), ко-

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

ется обслуживанием:

I автора требований — при модификациях или улучшениях;

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

марке-

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

описаны необходимые изменения;

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

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

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

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

Все существующие представления требований следует обновлять по

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

мо-

дифицируемой системы. Если обновление обременительно, то им

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

перейти к следующему запросу на обновление. А устаревшая

доку-

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

дальнейшем обслуживании. В индустрии ПО бытует страх того, что

Hia

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

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

новлением документации к требованиям. Однако какова цена того, что

вы не обновляете требования и специалисту по обслуживанию (а, мо-

жет, им станете вы сами!) придется воссоздавать информацию? Отве-

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

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

Требования для пакетных решений

Даже при покупке готового пакета в качестве части или всего

решения

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

продукть,

как правило, нужно конфигурировать, настраивать, интегрировать

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

всех

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

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

собов такой оценки предлагает следующее

(Lawlisn

др.,

2001):

в оценить ваши требования по шкале от 1 до 10, чтобы определить

важность каждого ;

Глава

16.

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

315

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

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

ния, 0,5 — для частичного удовлетворения и 0 — если вас все не

устраивает. Вы можете найти информацию, чтобы выполнить оцен-

ку, в литературе о

продукте,

в ответе поставщика на запрос на пред-

ложение (приглашение принять участие в торгах по проекту) или с

помощью прямой проверки продукта;

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

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

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

ные в главе 12;

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

поставщика,

поддержку

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

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

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

ми или ограничениями для вашей среды.

Готовый

пакет

Рис.

16-2.

Готовые пакеты

настраиваются

и интегрируются в существующую среду

приложений, и расширяются с помощью дополнительных элементов.

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

тре-

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

отвечающего вашим потребностям (рис. 16-2),

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

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

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

приобре-

316

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

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

на уровень требований

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

И здесь вам помогут варианты

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

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

своим способом. Варианты использования

позволят

вам

обнаружить

пробелы и выявить те

фрагменты,

где необходима настройка или рас-

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

потребностям.

Многие пакеты предоставляют готовые решения для удовлетворения

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

долж

ны

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

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

стандартные отчеты.

Вряд

и вы найдете готовые решения для

каждо

го варианта использования, поэтому расставьте их и сообщения по

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

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

дальнейших

расширений

ибес)

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

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

вы-

полнять их задачи, и если

да,

то насколько хорошо, на основе

вариан-

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

варианть

тестирования. Включите в них варианты использования, в которых рас-

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

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

сценариев, представляющего ожидаемые модели использования — и>

еще

называют

оперативным профилем

(Musa,

1996).

Работа с бизнес-правилами

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

рым готовый

продукт

должен соответствовать. Сможете ли вы сконфи-

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

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

ми? Насколько легко вносить коррективы при изменении этих правил и

положений? Создаются ли отчеты в корректном формате? Вы также

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

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

несогласованности между вашими структурами данных и набором мо-

делей данных поставщика.

Некоторые пакеты учитывают глобальные бизнес-правила, напри-

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

ходах, Уверены ли вы, что они реализованы корректно? Обеспечит ли

sac поставщик новой версией пакета в случае изменения этих правил и

расчетов? Если да, то как быстро? Предоставит ли поставщик список

Глава

16.

Проблемы при разработке специальных

требований

317

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

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

ли вы отключить или изменить их?

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

Атрибуты качества и

задачи,

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

торых рассказывалось в главе 12, — еще один аспект требований

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

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

мере,

следующие ат-

рибуты.

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

емлемое для определенных операций? Может ли пакет обработать

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

пропускную способность транзакций?

1 Легкость и простота использования. Соответствует ли пакет

всем принятым стандартам пользовательского интерфейса? Похож

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

комы пользователи? Насколько легко ваши клиенты смогут обучить

работать с пакетом?

1 Гибкость. Насколько легко разработчики смогут изменить или рас-

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

пакет соответствующие «ловушки» (точки подключения и расшире-

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

расширения?

Способность к взаимодействию. Насколько легко вы сможете

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

компании? Используются ли стандартные форматы для обмена

данными?

Целостность. Допускает ли пакет контроль допуска пользователей

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

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

па? Можете ли вы определять различные уровни привилегий поль-

зователей?

При приобретении готовых пакетов организация получает меньшую

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

«под

заказ».

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

можностей не могут быть предметом

переговоров,

а какие вы может

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

Единственная

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

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

обретаете пакет.

318

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

Требования к

проектам,

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

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

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

всего,

прямые

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

минималь-

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

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

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

показано на рис. 16-3.

Запрос

на

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

требования,

критерий

приемлемое!!'

Продуй,

документадин

Рис.

16-3.

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

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

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

принятия

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

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

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

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

зациями

(Wiegers,

2003). При подготовке требований для удаленной

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

описаны далее.

Детализируйте запрос. Если вы распространяете запрос на предло-

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

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

(Porter-Ro1h,

2002).

Избегайте неясностей. Остерегайтесь неясных терминов (табл.

10-1),

они становятся причиной полной неразберихи. Как-то раз я читал спе-

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

организа-

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

подцерж*а.

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

Однако специалисты этой организации не знали, как

значение

этого

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

выражение

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

Определите точки

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

с поставщиком. Если с разра-

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

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

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

типы позволяют

понять,

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

Поэтапная разработка, при которой поставщик периодически постав-

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

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

вать курс, когда разработчики поставщика

из-за

непонимания выбира-

ют неверное направление.

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

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

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

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

беседовать с поставщиком, чтобы снять все

вопросы,

касающиеся требований.

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

ниями. В ходе разработки

примерно

45% проектов, выполняемых сто-

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

разрастаются (Jones,

1994}.

У изменений всегда есть цена, поэтому

управление изменениями,

позволяющее

контролировать границы

проекта, жизненно важно при работе по контракту. В контракте необ-

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

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

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

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

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

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

«Проведение семинаров по требованиям», следующим был указан этап

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

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

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

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

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

и разработчика разделял континент. При этом обмен информации при

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

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

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

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

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

Определите критерий приемлемости. В соответствии с

рекомен-

дацией Stephen Covey «начинайте, думая об окончании» (Covey,

1989i,

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

разрабатываема-

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

шать, пора ли делать финальный платеж?

Дополнительная информация В главе 15 предлагается несколько приемов

для

определения критерия приемлемости.

Требования

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

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

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

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

В некоторых проектах, где, как правило, проблемы хорошо

обоснова-

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

функциональности на ранней стадии. Для них имеет смысл заранее

разработать согласованные требования.

Однако в более неопределенных проектах предполагаемые воз-

можности системы проясняются только со временем. Для таких новых

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

Поэто-

му необходимо и требования, и ПО разрабатывать поэтапно и посте-

пенно (Highsmith, 2000). При быстрой разработке проектов, для кото-

рых учитываются

растущие

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

обще-

принятых приемов создания требований. Вместо этого за основу

берут неясные, высокоуровневые положения о бизнес-целях.

Однаж-

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

ПО

для

Интерне-

та, сообщил мне в разговоре, что у них часто возникают

проблемы,

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

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

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

не

удел

ял

и времен и

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

сайта,

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

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

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

вело к созданию различных методик быстрой разработки. Их цель —

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

(Gilb,

1988; Beck, 2000; Cockburn, 2002). В них применяется упрощен-

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

лению требованиями. Требования описываются в терминах характери-

стик продукта или в форме историй

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

похожими на

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

главе 8. Вместо под-

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

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

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

В философии быстрой разработки изменения ПО рассматриваются

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

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

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

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

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

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

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

ционных систем и Интернет-проектов. Однако он меньше подходит

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

ботки встроенных систем,

Совершенно

очевидно,

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

ван на ясном понимании

того,

что пользователи хотят делать с помо-

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

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

рительную разработку требований. Однако по мнению Jeff

Gainer

(1999):

«Трудность для разработчиков ПО заключается в

том,

при по-

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

бования и расширить объем работ». Если этими циклами управлять

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

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

завершенного дизайна, кода и тестов.

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

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

нетерпения

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

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

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

«время

Интернета» как оправ-

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

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

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

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

следующих разделах.

Бессистемная спецификация

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

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

систем,

создаваемых небольшими, географически не разделенными

команда-

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

граммированием (Extreme Programming), рекомендует документиро-

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

санных на учетных карточках (Beck, 2000; Jeffries, Anderson и

Hendrickson,

2001).

Обратите внимание, что даже при этом подходе

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

но

ясно,

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

Ловушка Не следует ожидать, что для успеха проекта хватит и телепатической

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

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

ных лиц, обновлять их и управлять ими на протяжении разработки проекта. Кроме

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

Присутствие клиента

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

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

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

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

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

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

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

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

Клиент в поле зрения

Однажды я писал программу

для

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

ло расположено примерно в 10 футах от моего стола. Джон мог моментально отве-

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

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

офис, расположенный на том же этаже того же здания. Я

заметил,

что моя произво-

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

ции от Джона. Я стал тратить больше времени на устранение проблем, поскольку

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

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

вовремя

не получал корректи-

рующих указаний. При

раработке

ничто не заменит тесное взаимодействие с

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

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

требоваться 15 минут на повторное погружение в крайне

эффективное,

сосредото-

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

(DeMarco

и Lister,

1999).

Сам по себе находящийся рядом клиент не гарантирует желаемого

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

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

кими: «В то время как близость оказала благотворное воздействие на

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

были смешанными. Один из них был в центре

всего,

и все же умудрял-

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

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

ствительно убыстряет разработку ПО».

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

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

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

эффективно.

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

на ранних стадиях

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

ничают при выборе порядка реализации функций. Задача команды раз-

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

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

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

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

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

просты,

насколько

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

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

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

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

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

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

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

разработку.

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