Главная страница

Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга


Скачать 37.95 Mb.
НазваниеDevelopment Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
Родительский файлWinRAR_ZIP_archive.zip
АнкорWinRAR ZIP archive.zip
Дата20.02.2014
Размер37.95 Mb.
Формат файлаpdf
Имя файлаТехнологии программирования - Wiegers.Software R
оригинальный pdf просмотр
ТипКнига
#5238
страница1 из 62
Каталог
Полное содержание архива WinRAR ZIP archive.zip:
1. Технологии программирования - Wiegers.Software Requirements.pdf
38858.85 Киб.
Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М.: дом «Русская Редакция», 2004. ил. Isbn 5-7502-0240-2 Эта книга
5. Технологии программирования - Методические указания практика.docx
25.12 Киб.
Практика по дисциплине «Технологии программирования» Задания на практические занятия
6. Технологии программирования - Модуль_1.ppt
818 Киб.
Технология программирования и основные этапы ее развития Технология программирования и основные этапы ее развития
7. Технологии программирования - Модуль_2.ppt
1252 Киб.
Виды программного обеспечения Виды программного обеспечения
8. Технологии программирования - Модуль_3.ppt
1781 Киб.
Проектирование пп при структурном подходе
10. Технологии программирования - Тестовые_вводный.docx
38.64 Киб.
Тема: Системы счисления и двоичное представление информации в памяти компьютера
  1   2   3   4   5   6   7   8   9   ...   62


Разработка

требований

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

обеспечению

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

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

Карл И. Вигерс

Дважды лауреат Software

Development Productivity Award

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

Software

Requirements

Second Edition

Practical techniques for gathering and managering

requirements throughout the development cycle

Karl E. Wiegers

Two-time winner of the Software

 Productivity Award

 Press

Разработка

требований

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

обеспечению

Практические приемы сбора

 и управления

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

Карл И. Вигерс

 лауреат Software

Development Productivity Award

Москва 2004

УДК 004.45

В41

 Карл

 Разработка требований к программному

 с англ. — М.:

 дом «Русская Редакция», 2004.

 ил.

ISBN 5-7502-0240-2

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

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

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

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

создать эффективное ПО. Это перевод второго издания оригинальной книги,

которое

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

 а также о том, как формулирование требований важно для

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

тываемых сторонними организациями.

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

а также дизайнеры, программисты, тестеровщики ПО и другие члены коман-

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

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

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

ре конкурентоспособным.

Книга состоит из 23 глав, 4 приложений,

 терминов и библиогра-

фического списка.

УДК 004.45

 к изданию по лицензионному договору с Microsoft Corporation,

Вашингтон, США.

Microsoft, Microsoft Press, Visual Basic и Windows являются товарными знаками или

охраняемыми товарными знаками корпорации

 в США и/или

 странах. Все

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

 фирм.

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

примерах,

 и не имеют

 отношения к реальным компаниям, органи-

 продуктам и лицам.

ISBN

 (англ.)

ISBN

© Оригинальное

 на английском

языке,

 2003

© Перевод на русский язык, Microsoft

Corporation, 2004

© Оформление и подготовка к изданию.

 дом "Русская

 2004

Содержание

Предисловие xiii

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

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

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

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

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

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

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

Глава

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

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

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

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

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

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

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

Управление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто же клиент? 28

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

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

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

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

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

Обучение 43

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

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

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

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

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

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

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

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

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

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

Задачи аналитика 64

 необходимые аналитику 67

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

Становление аналитика 70

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

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

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

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

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

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

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

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

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

vi Содержание

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

 Бизнес-требования 82

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

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

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

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

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

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

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

 информации о потребностях клиентов 95

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

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

Сторонники продукта 1СЗ

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

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

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

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

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

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

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

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

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

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

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

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

Как

 что сбор требований завершен 1  1

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

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

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

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

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

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

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

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

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

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

Содержание

v

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

Правила бизнеса 163

Факты

Ограничения 164

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

Выводы 166

Вычисления 167

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

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

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

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

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

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

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

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

 Введение

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

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

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

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

6.

 требования

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

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

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

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

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

Словарь данных 203

Глава

 Любое изображение стоит

 слов 206

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

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

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

Диаграмма

 - связь»

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

Карта диалогов 222

Диаграмма классов 226

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

Последнее

 231

viii Содержание

Глава

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

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

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

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

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

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

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

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

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

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

Глава

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

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

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

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

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

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

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

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

Риски

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

Глава

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

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

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

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

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

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

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

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

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

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

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

Глава

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

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

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

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

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

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

Содержание ix

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

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

Работа с

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

Требования к

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

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

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

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

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

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

 324

Глава

 От

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

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

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

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

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

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

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

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

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

Базовая

 344

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

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

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

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

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

Глава

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

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

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

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

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

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

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

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

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

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

 373

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

 376

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

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

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

Содержание

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

 требований

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

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

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

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

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

Глава

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание

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

 требований 445

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

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

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

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

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

Эпилог 451

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

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

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

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

The Capability Maturity Model for Software 461

 465

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

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

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

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

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

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

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

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

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

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

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

 525

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

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

Об авторе 554

Содержание

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вания

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

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

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

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

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

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

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

 Group International, 1995.

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

xt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

венный опыт.

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

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

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

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

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

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

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

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

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

требований;

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

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

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

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

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

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

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

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

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

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

Она для тех, кто так или иначе вовлечен в сбор и формулирование

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

 аналитики

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

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

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

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

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

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

 чтобы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предисловие

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

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

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

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

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

 — при-

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

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

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

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

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

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

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

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

ся

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

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

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

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

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

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

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

В главе 22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предисловие

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

Трудно

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

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

вых знаний.

 оставаться в

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

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

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

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

 гдз

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предисловие

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

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

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

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

 Никки

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

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

 (Geoff Flamank), Линда

Флеминг (Lynda

 Кэти

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

 (Tammy

 Майк Малек (Mike

endra

 Майк

 (Mike

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

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

 (Joyce Statz),

Дорис

 (Doris

 Пракаш

 (Prakash Up-

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

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

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

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

(Ross

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

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

 Fleming), Элен

 (Ellen

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

mons), Дэвида

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

Stephenson), Скотта

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

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

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

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

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

 Barnard), Мишель

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

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

 (Danielle

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

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

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

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

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

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

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

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

опытом.

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

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

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

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

Особенности разработки

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

«Привет, Фил, это Мария из отдела персонала.  нас проблема

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

трудниц изменила имя на

 Старлайт, а система не прини-

мает это изменение. Ты можешь помочь?»

Юна вышла замуж за парня по имени Старлайт?»

 она просто взяла другое имя, — ответила Мария. — В

этом-то и проблема. Как будто мы можем брать другое имя

только при изменении семейного положения».

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

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

этому-то диалоговое окно «Изменить имя» доступно только из

окна «Изменение семейного положения», — сказал Фил.

«Я

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

нять имена, когда захотят, — ответила Мария. — Мы должны

 это к пятнице, а то Спакл не сможет обналичить чек.

Ты сможешь исправить этот дефект к такому сроку?»

 не

 

 резко парировал Фил.

 знал, что вам

нужна эта функциональность. Сейчас я занимаюсь оценкой

производительности системы.

 что потребуется менять

 другое».

 да здесь есть еще кое-

что. Я, вероятно, смогу исправить это в конце месяца, но не на

этой неделе. Извини меня. Но в следующий раз с такими

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

«А что же я скажу Спакл? — возмутилась Мария. — Ей придется

залезать в долги, если она не сможет обналичить чек».

«Эй, Мария, это не моя вина, — запротестовал Фил. — Если ты

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

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

изменять имена в любое время, этого и нет в системе. Ты не

можешь винить меня за то, что я не умею читать мысли в твоей

голове».

Сердитая и смирившаяся, Мария отрывисто сказала: «Это как

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

ни мне, как только сможешь исправить недостаток».

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

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

 кото-

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

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

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

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

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

те

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

Масса проблем с ПО возникает из-за несовершенства

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

и модификации требований к ПО. Как в случае с Филом и Марией,

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

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

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

ного изменения процесса.

Большинство людей при строительстве дома даже не интересуются

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

желания и не уточнят все детали. Покупатели понимают, что внесение

изменений влечет за собой изменение цены; им это не нравится, но

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

касается разработки ПО. Ошибки, допущенные на стадии сбора требо-

ваний, составляют от 40 до 60% всех дефектов проекта (Davis, 1993;

 1997). Две наиболее распространенные проблемы, о

рых сообщается в большом Европейском обзоре индустрии ПО, — оп-

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

не мене многие организации еще применяют неэффективные методы

на этих стадиях разработки ПО. Типичный исход — неожидаемые про-

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

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

* Я использую термины

 взаимозаменяемые в этой

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

элементы, которые вы строите.

  1   2   3   4   5   6   7   8   9   ...   62

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