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




КАРЛ И. ВИГЕРС

 

«Разработка требований к программному обеспечению»

 


Посвящается Крис


Software Requirements

Second Edition

Practical techniques for gathering and managering requirements throughout the development cycle

Karl E. Wiegers

 

NBctosoft Press

Two-time winner of the Software Development Productivity Award


Разработка

требований

к программному

обеспечению

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

Карл И. Вигерс Дважды лауреат Software Development Productivity Award


Содержание

Предисловие. 11

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

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

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

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

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

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

Часть I. Требования к продукту: что, почему и кто.. 14

Глава 1. Особенности разработки требований к ПО.. 15

Оговоренные требования к ПО.. 17

Особенности интерпретации требований. 18

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

Каких требований не должно быть. 21

Разработка и управление требованиями. 22

Разработка требований. 22

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

Каждый проект имеет требования. 24

Когда плохие требования появляются у хороших людей. 25

Недостаточное вовлечение пользователей. 25

«Разрастание» требований пользователей. 25

Двусмысленность требований. 26

«Золочение» продукта. 26

Минимальная спецификация. 27

Пропуск классов пользователей. 27

Небрежное планирование. 27

Выгоды от высококачественного процесса разработки требований. 27

Характеристики превосходных требований. 28

Характеристики отдельных положений спецификации требований. 28

Характеристики спецификации требований. 29

Глава 2. Требования с точки зрения клиента. 31

Кто же клиент?. 32

Сотрудничество клиентов и разработчиков. 33

Билль о правах клиента ПО.. 35

Билль об обязанностях клиента ПО.. 36

Что насчет подписи?. 38

Глава 3. Хорошие приемы создания требований. 41

Обучение. 43

Выявление требований. 43

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

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

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

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

Управление проектом.. 49

Начинаем применять новые приемы.. 50

Процесс создания требований. 52

Глава 4 Аналитик требований. 55

Роль аналитика требований. 55

Задачи аналитика. 56

Навыки, необходимые аналитику. 58

Знания, необходимые аналитику. 59

Становление аналитика. 59

Бывший пользователь. 60

Бывший разработчик. 60

Профильный специалист. 61

Создание атмосферы тесного сотрудничества. 61

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

Глава 5 Определение образа и границ проекта. 64

Определение образа продукта вплоть до бизнес-требований. 64

Конфликтующие бизнес-требования. 65

Бизнес-требования и варианты использования. 66

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

1. Бизнес-требования. 67

2. Образ решения. 69

3. Масштабы и ограничения проекта. 70

4. Бизнес-контекст. 71

Контекстная диаграмма. 72

Не упускайте границы из вида. 73

Глава 6 Как отобрать пользователей для работы над проектом.. 75

Основные источники получения информации о потребностях клиентов. 75

Классы пользователей. 77

Представители пользователей. 80

Сторонники продукта. 81

Сторонники продукта, приглашенные со стороны.. 82

Чего следует ожидать от сторонника продукта. 83

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

Как «продать» идею о необходимости привлечения сторонника продукта. 85

В какие ловушки можно угодить, привлекая сторонников продукта. 85

Кто принимает решения. 86

Глава 7 Как услышать голос клиента. 89

Выявление требований. 90

Польза семинаров. 91

Несколько советов о том, как собирать информацию.. 97

Поиск упущенных требований. 97

Как понять, что сбор требований завершен. 99

Глава 8 Как понять требования пользователей. 100

Подход с применением варианта использования продукта. 102

Варианты использования и сценарии использования. 103

Определение вариантов использования. 107

Документирование вариантов использования. 107

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

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

Каких ловушек следует опасаться при способе с применением вариантов использования. 116

Таблицы «событие - реакция». 117

Глава 9 Игра по правилам.. 121

Правила бизнеса. 122

Факты.. 122

Ограничения. 122

Активаторы операций. 124

Выводы.. 124

Вычисления. 125

Документирование бизнес-правил. 126

Бизнес-правила и требования. 127

Глава 10 Документирование требований. 131

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

Требования к именованию.. 132

Когда информации недостаточно. 133

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

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

1.Введение. 136

2. Общее описание. 136

3. Функции системы.. 138

4. Требования к внешнему интерфейсу. 138

5. Другие нефункциональные требования. 140

Приложение А. Словарь терминов. 140

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

Приложение В. Список вопросов. 140

Принципы создания требований. 140

Примеры требований: до и после. 145

Словарь данных. 147

Глава 11 Любое изображение стоит 1024 слов. 150

Моделирование требований. 150

От желания клиента к модели анализа. 151

Диаграмма потока данных. 152

Диаграмма «сущность - связь». 155

Диаграмма перехода состояний. 157

Карта диалогов. 162

Диаграмма классов. 165

Таблицы решений и деревья решений. 166

Последнее напоминание. 168

Глава 12 Обратная сторона функциональности: атрибуты качества ПО.. 170

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

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

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

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

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

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

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

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

Глава 13 Прототипы как средство уменьшения риска. 183

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

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

Вертикальные прототипы.. 184

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

Эволюционные прототипы.. 186

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

Оценка прототипа. 190

Риски прототипирования. 191

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

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

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

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

Шкала приоритетов. 196

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к проектам, выполняемым сторонними организациями. 227

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

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

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

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

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

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

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

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

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

От требований — к дизайну и коду. 237

От требований — к тестированию.. 240

От требований — к успеху. 241

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

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

Базовая версия требований. 245

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

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

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

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

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

Глава 19 Изменения случаются. 253

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

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

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

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

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

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

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

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

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

Изменение не бесплатно: анализ влияния. 267

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

Шаблон отчета об анализе влияния изменения. 271

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

Трассируемость требований. 274

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

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

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

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

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

Глава 21 Инструментальные средства управления требованиями. 284

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выявление требований. 315

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

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

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

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

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

Эпилог. 320

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

Приложение Б. Модели совершенствования требований и технологических процессов 326

The Capability Maturity Model for Software. 326

CMMI-SE/SW... 328

Приложение В. Руководство по поиску и решению проблем, связанных с требованиями 331

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе. 392

 

 


Предисловие

Несмотря на более чем пятидесятилетнее существование компьютерной отрасли, многие компании разработчики программного обеспечения по-прежнему прикладывают значительные усилия для сбора и документирования требований к ПО, а также управления ими. Недостаточный объем информации, поступающей от пользователей, требования, сформулированные не полностью, их кардинальное изменение — вот основные причины, из-за которых зачастую командам, работающим в области информационных технологий, не удается вовремя и в рамках бюджета предоставить клиентам всю запланированную функциональность[1]. Многие разработчики не умеют спокойно и профессионально собирать требования пользователей к ПО. У клиентов зачастую. не хватает терпения участвовать в разработке требований к ПО, или они норовят передать свои пожелания через совершенно неподходящих для этого дела людей. Иногда участники проекта даже не могут прийти к единому мнению, что же такое «требование». Как заметил один писатель, «программисты скорее предпочтут расшифровать слова классической песни Кингсмена (Kingsmen) «Louie Louie», чем требования клиентов».[2]

Разработка ПО включает по крайней мере столько же общения, сколько и обычная работа с компьютером, но зачастую мы делаем акцент на работе с компьютером и не уделяем достаточно внимание общению. В этой книге описаны дюжины способов, позволяющих реализовать это общение и помогающих разработчикам ПО, менеджерам, маркетологам и клиентам использовать на практике эффективные методы формулирования требований к ПО. Настоящее издание дополнено новыми главами, посвященными роли аналитика требований, важности бизнес-правил, а также рассказом о том, как формулирование требований важно для проектов по обслуживанию, для комплексных решений, для извлечения данных из внешних источников и новых проектов. Во многочисленных врезках я привожу реальные примерь, иллюстрирующие типичные ситуации, возникающие при формулировании требований.

В книге описаны основные «отличные способы» формулирования требований, а не экзотичные или тщательно разработанные методологии, обещающие решить все проблемы, возникающие при формулировании требований. С тех пор, как в 1999 г. вышло первое издание этой книги, я провел свыше 100 семинаров, посвященных формулированию требований к ПО, для сотрудников коммерческих и правительственных организаций всех толков. Я понял, что эти способы годятся практически для любого проекта, включая развертываемые частями, маленькие проекты и крупномасштабные гиганты, а также те, что разрабатываются «с нуля», и проекты по обслуживанию. Кроме того, эти способы не ограничиваются только областью разработки ПО, и вполне годятся для проектирования оборудования и систем. Как и в случае с любыми другими способами разработки ПО, чтобы понять, какие из способов формулирования требований подходят вам более всего, следует руководствоваться здравым смыслом и опираться на собственный опыт.

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

Из всех возможных способов совершенствования процесса разработки ПО наибольшее преимущество за формулированием требований. Я уделяю особое внимание описанию проверенных на практике способов, которые помогут вам:

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

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

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

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

Моя цель — помочь вам усовершенствовать процессы сбора и анализа требований, написания и оценки спецификаций, определяющих требования, а также процессы управления требованиями на протяжении всего цикла разработки продукта. Надеюсь, вы на самом деле станете применять усовершенствованные способы, а не просто прочтете о них. Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе.

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

Она для тех, кто так или иначе вовлечен в сбор и формулирование требований к программному продукту. Основная аудитория — аналитики требований и разработчики продукта независимо от того, работаю" они полный день или привлекаются к проекту время от времени. Более широкий круг читателей — дизайнеры, программисты, тестеры ПО и другие члены команды, задача которых понять и удовлетворить чаяния клиентов, а также маркетологи и менеджеры по продуктам, которые должны проникнуться «духом» и особенностями продукта, чтобы сделать его в полной мере конкурентоспособным. Менеджеры проекта, отвечающие за своевременный выпуск, также найдут здесь для себя немало интересного: они узнают, как управлять показателями, связанными с требованиями к проекту, а также реагировать на изменение этих требований. Еще один сегмент аудитории — клиенты, которые жаждут высказать свои пожелания о создаваемом продукте. Настоящая книга поможет им понять роль процесса формулирования требований и их место в этом процессе.

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

Книга состоит из четырех частей. Первая часть «Требования к продукту: что, почему и кто» начинается с ряда определений и описания некоторых характеристик требований, которые считаются качественными. Если вы занимаетесь техническими вопросами, надеюсь, вы поделитесь концепциями главы 2, посвященной взаимодействию клиентов и разработчиков, со своими ключевыми клиентами. В главе 2 описано несколько дюжин хороших приемов создания и управления требованиями, а также процесс формулирования требований в целом. Глава 4 посвящена роли аналитика требований.

Вторая часть «Разработка требований к ПО» начинается с описания способов для определения бизнес-требований к проекту. Другие главы этой части посвящены тому, как правильно выбрать представителей клиента, узнать у них требования и задокументировать варианты использования, бизнес-правила, функциональные требования и атрибуты качества. В главе 15 обсуждается несколько моделей анализа, представляющих требования с разных точек зрения, в главе 13— применение прототипов ПО, позволяющих снизить риск выпуска продукта ненадлежащего качества. Прочие главы посвящены расстановке приоритетов и оценке требований. Завершается вторая часть описанием особенностей формулирования требований для нескольких конкретных проектов и рассказом о том, как требования влияют на другие аспекты работы над проектом.

В третьей части «Управление требованиями к ПО» речь пойдет о принципах и способах управления требованиями, особое внимание уделяется технологиям, позволяющим реагировать на изменение требований. В главе 20 рассказано, как отслеживать изменение требований с самого начала до их реализации в продукте. Третья часть завершается описанием коммерческих утилит, расширяющих возможности управления требованиями к проекту.

Заключительная часть книги «Особенности реализации процесса построения требований» поможет вам перейти от теории к практике. В главе 22 рассказано, как включить новые способы формулирования требований в действующий процесс разработки. Глава 23 посвящена рискам, связанным с требованиями к проекту. Приложение А позволит вам оценить применяемые способы формулирования требований и определить области, требующие совершенствования. В прочих приложениях представлены руководство по устранению проблем, возникающих при формировании требований, а также примеры задокументированных требований к проектам.

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

Методы, описанные в книге, я иллюстрирую примерами, за основу которых взяты реальные проекты; это касается и информационной системы среднего размера под названием Chemical Tracking System. (He волнуйтесь - чтобы разобраться в этом проекте, знание химии вам не потребуется.) Диалоги участников проектов из примеров разбавляют текст книги. Думаю вне зависимости от того, что за ПО разрабатывает ваша команда, вы найдете эти диалоги интересными и полезными,



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-12 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: