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

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

Глава

12.

Обратная сторона функциональности:

атрибуты качества ПО 232

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

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

235

Атрибуты, важные для пользователей 237

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

24:!

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

•

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

Planguage

24'

Компромиссы для атрибутов

249

Реализация нефункциональных требований

251

Глава

13.

Прототипы как средство уменьшения риска 253

Что такое прототип и для чего он нужен 254

Горизонтальные прототипы 255

Вертикальные прототипы 25(5

Одноразовые прототипы 257

Эволюционные прототипы 25!3

Бумажные и электронные прототипы 261

Оценка прототипа 263

Риски

прототипирования

265

Факторы успеха прототипирования 266

Глава

14.

Назначение приоритетов требований 269

Зачем определять приоритеты требований 270

Игры, в которые люди играют с приоритетами 271

Шкала приоритетов 273

Определение приоритетов на основе ценности, стоимости и риска 274

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

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

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

Проблемы при просмотре требований 298

Тестирование требований 300

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

Глава

16.

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

Требования к проектам по обслуживанию 309

Начните сбор информации

310

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

313

Перемещайтесь по цепочке трассируемое™

314

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

315

Содержание ix

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

315

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

Работа с

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

317

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

318

Требования к

проектам,

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

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

Бессистемная

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

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

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

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

изменениями

324

Глава

17.

От

разработки

требований — к следующим этапам 326

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

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

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

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

От требований - к тестированию 337

От требований - к успеху 339

Часть III. Управление требованиями к ПО 341

Глава 18. Принципы и приемы управления требованиями к ПО 342

Базовая

версия

требований

344

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

Контроль версий 346

Атрибуты требований 348

Контроль статуса требований 351

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

Глава

19.

Изменения случаются 356

Управление незапланированным ростом объема 358

Процесс контроля изменений 360

Политика контроля изменений 361

Описание процесса контроля изменений 362

Совет по управлению изменениями 369

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

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

Средства контроля измений 372

Измерение активности

изменений

373

Изменение не бесплатно: анализ

влияния

376

Процедура анализа влияния изменения 377

Шаблон отчета об

анализе

влияния изменения

362

Содержание

Глава 20. Связи в цепи требований 384

Трассируемость

требований

38Е

Мотивация для трассируемое™ требований

38Е

Матрица трассируемое™ требований

39С

Средства трассирования требований

394

Процедура трассирования требований

39£

Осуществимость и необходимость трассирования требований 397

Глава

21.

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

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

Преимущества

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

инструментальных средств

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

40*

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

4(М

Реализация автоматизации управления требованиями 407

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

408

Изменение культуры работы

409

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

411

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

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

413

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

414

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

415

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

41Г

Основы совершенствования процессов разработки ПО 420

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

Оцените текущие технологические процессы 423

Создайте план совершенствования

425

Создайте, опробуйте и реализуйте новые процессы 426

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

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

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

431

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

432

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

434

Глава 23. Требования к ПО и управление риском 436

Основы управления риском при создании ПО 433

Составляющие управления риском 439

Документирование рисков проекта 440

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

Содержание

Риск, связанный с требованиями 444

Выявление

требований 445

Анализ требований 446

Спецификация требований

447

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

448

Управление требованиями 448

Управление риском - ваш друг 449

Эпилог 451

Приложение А. Самостоятельная оценка применяемых вами

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

Приложение Б. Модели совершенствования требований

и технологических процессов 461

The Capability Maturity Model for Software 461

CMMI-SE/SW

465

Приложение В. Руководство по поиску и решению

проблем,

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

469

Анализ основных причин 470

Общие симптомы проблем, связанных с требованиями 471

Общие препятствия для реализации решений 472

Приложение Г. Примеры документации требований 495

Документ об образе и границах проекта 496

Варианты использования 503

Спецификация требований к ПО 510

Приложение А. Словарь и модель данных 521

Приложение Б. Модели анализа 525

Бизнес-правила

525

Словарь терминов 528

Библиографический список 540

Об авторе 554

Содержание

Предисловие

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

ной отрасли, многие компании — разработчики программного обеспе-

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

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

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

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

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

работаю

щим в области информационных технологий, не удается вовремя и

рамках бюджета

предоставить

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

функ

циональность*.

Многие разработчики не умеют спокойно и

профессио

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

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

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

неподходя-

щих для этого дела людей. Иногда участники проекта даже не

могу;

прийти к единому мнению, что же такое «требование». Как заметил

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

ело

ва классической песни Кингсмена (Kingsmen) «Louie Louie», чем требо-

вания

клиентов»**.

Разработка ПО включает по крайней мере столько же

общения,

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

ак-

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

внимание

общению. В этой книге описаны дюжины способов, позволяющих реа-

лизовать это общение и помогающих разработчикам ПО, менеджерам,

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

Исследование «CHAOS Report», проведенное компанией

Standish

Group International, 1995.

Peterson, Gary. Статья «Risque Requirements» в апрельском номере журнала CrossTalk за

200-'.

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

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

важности бизнес-правил, а также рассказом о том, как формулирова-

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

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

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

примерь,

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

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

В книге описаны основные «отличные способы» формулирования

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

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

ровании требований. С тех пор, как в 1999 г. вышло первое издание

этой книги, я провел свыше

100

семинаров, посвященных формулиро-

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

ПО,

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

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

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

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

рабатываются «с нуля», и проекты по обслуживанию. Кроме того, эти

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

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

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

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

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

венный опыт.

Что дает эта книга

Из всех возможных способов совершенствования процесса разработ-

ки ПО наибольшее преимущество за формулированием требований.

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

бов, которые помогут вам:

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

разработки,

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

изводительность;

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

изменения

требований;

сделатьклиентадовольным;

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

Моя цель — помочь вам усовершенствовать процессы сбора и ана-

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

Предисловий

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

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

Надеюсь,

вы на самом деле ста-

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

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

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

Кому предназначена эта книга

Она для

тех,

кто так или

иначе вовлечен

сбор

формулирование

тре>

бований к программному продукту. Основная

аудитория—

аналитики

требований и разработчики продукта независимо от того, работаю"

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

Более

широкий круг читателей — дизайнеры, программисты, тестеры ПО и

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

чаяния

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

которые

должны проникнуться «духом» и особенностями

продукта,

чтобы

еде

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

проекта,

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

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

связан

ными

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

изменение

этих требований. Еще один сегмент аудитории — клиенты, которые

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

щая

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

требо

ваний и их место в этом процессе.

Краткий обзор

Книга состоит из четырех частей. Первая часть «Требования к

продукту:

что,

почему и кто» начинается с ряда определений и описания

некото

рых

характеристик требований, которые считаются качественными.

Ее

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

поделитес-»

концепциями

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

работчиков, со своими ключевыми клиентами. В главе 2 описано

не-

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

требования-

ми, а также процесс формулирования требований в целом. Глава 4 по-

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

Вторая часть «Разработка требований к ПО» начинается с описания

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

гла-

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

представите-

Предисловие

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

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

буты качества. В главе

обсуждается несколько моделей анализа,

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

— при-

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

ненадлежащего качества. Прочие главы посвящены расстановке при-

оритетов и оценке требований. Завершается вторая часть описанием

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

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

пекты работы над проектом.

В третьей части «Управление требованиями к ПО" речь пойдет о прин-

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

ся

технологиям,

позволяющим реагировать на изменение требований.

В главе 20 рассказано, как отслеживать изменение требований с

само-

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

опи-

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

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

Заключительная часть книги «Особенности реализации процесса

построения требований» поможет вам перейти от теории к практике.

В главе 22

рассказано,

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

требований в действующий процесс разработки. Глава 23 посвящена

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

позволи-

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

оп-

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

приложе-

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

при формировании требований, а также примеры

задокументирован-

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

Примеры из практики

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

торых взяты реальные проекты; это касается и информационной сис-

темы среднего размера под названием Chemical Tracking System. (He

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

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

текст книги. Думаю, вне зависимости от того, что за ПО разрабатывает

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

Предисловие

От принципов - к практике

Трудно

представить,

сколько энергии потребуется на

преодолении

препятствий,

мешающих изменению и практическому применению но-

вых знаний.

Заманчивей

оставаться в

зоне

комфорта, которая

опреде-

ляется

знакомыми — если не сказать, не всегда эффективными —

спо-

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

знаний

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

«Что

теперь?»,

гдз

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

отношении реального проекта. На моем Web-узле

http://www,proces-

simpact.com вы найдете аннотированные шаблоны документов для

ог-

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

при-

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

же полезные вещи для многих других процессов. Используйте эти

ма-

териалы, чтобы применять полученные значения на практике. Начните

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

вая на завтра.

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

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

люди откровенно

неблагоразумны,

и если вы имеете дело именно с та-

кими людьми, описанные здесь способы работать не будут. Исполь-

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

менеджеров.

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

ших при работе над предыдущими проектами, и обсуждайте

потенци-

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

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

усовершенствованные способы формулирования требований. В гла-

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

в проектах по обслуживанию. Постепенное внедрение новых

спосо-

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

вованию процесса

разработки,

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

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

ным проектом.

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

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

таточно времени, вы можете быть

уверены,

что свели к минимуму риск

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

проекта. Эта книга научит

вас,

как объединить усилия нужных людей

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

Предисловие

xvii

Благодарности

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

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

шенствованию ее текста. Рецензенты первого издания — Стив Адольф (Steve

Adolph),

Никки

Бьянко

(Nikki Bianco), Билл Дэгг (Bill Dagg), Дейл Эмери (Dale

Em-

ery),

Крис Фальбуш (Chris

Fahlbusch),

Джиоф

Фламанк

(Geoff Flamank), Линда

Флеминг (Lynda

Fleming),

Кэти

Гетц

(Kathy

Getz),

Джим Харт (Jim Hart), Тэмми

Хогэнсон

(Tammy

Hoganson),

Майк Малек (Mike

Malec),

Дипендра

Мойтра

(Deep-

endra

Moitra),

Майк

Ребацк

(Mike

Rebatzke),

Фил Рекио (Phil Recchio), Кэти Род

(Kathy Rhode), Джоанна Ротман (Johanna Rothman), Джойс

Стац

(Joyce Statz),

Дорис

Штурценбергер

(Doris

Sturzenberger),

Пракаш

Упадхайюла

(Prakash Up-

adhyayula)

и Скотт Витмайр (Scott

Whitmire).

Что касается настоящего,

второго,

издания, то я высоко ценю

вклад

Стива Адольфа (Steve Adolph), Росса Колларда

(Ross

Collard),

Ричарда Дальтона (Richard Dalton), Криса Фальбуша (Chris Fahl-

busch},

Линды Флеминг

(Lynda

Fleming), Элен

Готтесдинер

(Ellen

Gottesdiener),

Линды Льюис (Linda Lewis), Джеффа Пинка (Jeff Pink), Эрика Симмонса (Erik Sim-

mons), Дэвида

Станденфорда

(David

Standerford), Дэниса Стефенсона (Dennis

Stephenson), Скотта

Витмайра

(Scott Whitmire), Ребекки Вирш-Брок (Rebecca

Wirfs-Brock)

и Триши Цвирнбаум (Trish

Zwirnbaum).

Спасибо сотрудникам Microsoft Press, принявшим участие в работе над пер-

вым изданием этой книги, в том числе редакторам Бену Раину (Ben Ryan), Джону

Пирсу (John Pierce), Мэри Колбах Барнард

(Магу

Kalbach

Barnard), Мишель

Гудман (Michelle Goodman), Робу Нэнсу (Rob Nance) и Поле Горлик (Paula

Gorelick). За работу над вторым изданием благодарю

Даниеля

Берда

(Danielle

Bird), Томаса Польмана (Thomas Pohlmann),

Дэвона

Масгрейва (Devon Mus-

grave),

Санди Резник (Sandi Resnick), художника Майкла Клопфера

(Michael

Kloepfer) и наборщицу Джину Кассил (Gina Cassill). Значительную помощь мне

оказали и слушатели семинаров по формулированию требований к ПО, за по-

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

Пожалуйста, пишите мне по адресу

kwiegers@acm.org

и делитесь со мной

опытом.

Выражаю глубочайшую признательность Крис Замбито (Chris Zambito)

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

может только мечтать.

xviii

Благодарности